Hello there! I’d like to showcase to our community my personal ThreeJS scenes gallery / portfolio made with React. The website is constantly being updated and from now on I’ll try to create a new ThreeJS scene per week. Navigation through the scenes are seamless, and the homepage can switch to a Shader gallery canvas as well (also rendered using ThreeJS), through the navbar toggle switch. All the scenes and shaders are audio-reactive.
this is really sweet, id love to compare notes on how to handle this. Are you using any of those react/three libraries or you’ve got something homegrown?
Unfortunately I couldn’t find a React/Three library that could handle post-processing properly, so I ended up writing it all by myself. I use plain Three imported as module, and I created a small lib to handle post-processing.
Thanks to @Mugen87 all the postprocessing files are now available as modules.
They’ll be in the NPM package from the next release, or you can get them from the dev branch on GitHub now.
Thanks Pailhead. The shaders are loaded dynamically as you use the navigator on the menu bar. I created a module that uses Three fileloader to async load and parse them from .frag files once you request the next shader, so I don’t need to bloat the visitors memory with shaders or scenes that he may not visit. The only shader loaded immediately when you visit the website is the default vertex one. Except in cases in which I need a special vertex shader, like in this Three scene: https://mgz.me/?scene=Instances
In cases like this, I load the vertex shader dynamically as well.
Thanks a lot for your positive feedback. I really appreciate it!
We lately get a little bit more restrictive when contributors want to add new example code to the repository. It is already big and thus hard to maintain. Using the “Showcase” category is the best option for sharing your shaders .
There’s one specific shader that I’d love to contribute with. The result of it can be seen here: https://www.youtube.com/watch?v=u__lpFvR4kA It does dithering, besides emulating specific color palettes of many retro gaming platforms (and being able to smoothly transitioning through them), like AppleII, Commodore VIC-20 and 64, MSX, IBM PC CGA mode 4, etc. If you consider it to be useful for the project, it will be a pleasure to provide the code as per the requirements format. Once again, thanks for the post-processing available as modules Mugen. It is a big deal!
Shouldn’t we be removing unnecessary stuff from the repo, or otherwise working to make it manageable, rather than telling people not to contribute?
Otherwise we’re being unfair to new contributors. We’re saying that something like the Glitch or Kaleidoscope effects are included, just because the contributor got in early, while a probably more useful retro-gaming palette pass gets rejected outright because we’ve arbitrarily decided that we’re full now.
To be clear, I’m not suggesting that we should include this (even though it’s a cool effect). The post-processing section of the repo could do with a complete overhaul and simplification IMO, with a quite a few things removed, and should focus on standard passes like color correction, tone mapping, brightness, contrast, bloom, AA, AO, etc., rather than app specific cool and crazy effects.
But I do think that “the repo is hard to maintain” is not a valid reason for telling people not to contribute their work. That’s something we need to fix. We either need a proper roadmap and set of criteria for what we want to include, and we need to remove the existing stuff that no longer fits, or we should split things like post-processing off into separate projects so that they can expand to include all the weird and wonderful Glitch, Pixelate, and Retro effects that people want to contribute.
IMHO a simple solution here could be to merge this into one example called “post processing”. Another far better would be to set up a repo called examples and then have a post processing section there.
Even it’s own post processing repo could be warranted. The same way the threejs.org site is built, there could be a much more specialized UI for browsing or editing the post processing effects.
As you’ve pointed out, some person a long time ago, writes some demo using three.js, and it just becomes part of three.js, and now there’s no room for new stuff, and claiming all those examples of three.js as “being three.js” seems to bog down the project.
Unity would call this a package i believe, or a library. It could be something like threejs-standard-image-effects.
I’m curious why it seems like only contributing to the threejs repo is considered a contribution. Also why would it even be considered a contribution if it slows down the development of the project. I think as long as this code exists somewhere where it’s licenced as open source and available for download, it’s considered a contribution. I consider random jsfiddles and such also as contributions, and i could easily call @prisoner849 a main three.js contributor.
I wrote an article about a year ago that touches on this. An extremely easy fix for all of this would be to remove absolutely everything from the /examples folder and leave a readme.md file in it saying.
The examples now live in their own repository at [link].
This repository is now focused solely on developing the core of the three.js library.
For issues WITH THE EXAMPLES please use the examples repository.
I made a one liner PR half a year ago that could open the doors to many new examples, but it’s probably being lost in the sheer number of tickets since they include a lot of the examples.
I agree with @pailhead here. It’s not necessary to commit something to the three.js repo to be a three.js contributor.
The problem is that too much stuff was added in the past. And now it’s harder to introduce new features since we have to guarantee that the examples still work. Removing stuff is easier said than done since people can rely on a particular code as soon as it lands in the main repo. So we need a compelling reason for doing this like the code is not referenced in the entire repo.
Besides, we also have to ensure that the code in the examples directory is on an equal quality level. Reviewing PRs and communicate feedback can be incredibly time consuming. Time that is missing for other, maybe more important stuff.
There was a lot of “discussion” on this topic. At the time someone else was pushing some kind of a solution to the core while this PR is just an example. In a perfect world, if i was just pushing an example to some special repo, i doubt it could have caused this amount of comments and i dare say trolling.
this got published as it’s own thing https://www.npmjs.com/package/three-instanced-mesh, a fair amount of people are using it (several thousand seem to have downloaded it since the last version was published). The module can be improved and it can be done by anyone - open source.
However, some improvements cannot be made until some problems of the generic inner workings of three.js are solved. So instead of three.js having many many examples, i’d say, three.js could generically improve how it works with say “plugins” (effect composers, instancing, etc).
Anyone can contribute to the repo. But since these plugins are not considered a three.js contribution, a lot of people may be unaware of them. I’d say theres some useful stuff on npm, three-bas is the first thing that comes to mind. It’s such an awesome example of how to use three.js but i don’t think it’s mentioned anywhere in the repo.
a ton of duplicated effort:
the above mentioned PR would have been an example of how to do instancing with any material.
This one was an example of how to use onBeforeCompile - a legitimate feature of the library. Removing 100 redundant lines could potentially simplify the example - users would have less code to understand, maintainers to maintain.
https://github.com/mrdoob/three.js/pull/16161 repeats all this work, and looks like it’s going to be rejected. But this is perhaps less important than the fact that the pattern happening here is to have webgl_buffergeometry_instancing_${material}. If one made examples for all three.js materials using the webgl_buffergeometry_instancing_lambert i think it would bring a massive amount of duplicated code. Instancing should be generic to all materials, onBeforeCompile independent of instancing, generic to extending materials.
I really think that just nuking /examples may be the easiest fix here. As far as this post processing exapmle, i’d love to see it in its own repo.
That was kind of an easter egg to me, as I arrived to the website through another link. I turned on the music halfway through, and it suddenly struck me that the “thingy” responded very well to the music.
Very impressive, creative and beautiful demos. Nice retro / geek nostalgia feel too. If I miss anything, it is a better sense of interactivity. In the demos that depend on mouse position, the position does not seem to be captured correctly. Maybe you should check out the different position properties in the mouse events, such as event.clientX.
People can keep their old copies of builds and examples, and update their own applications when they update the three.js build.
I think this forum and the extensive usage of JSFiddles/CodePens by helpful users may have made beginners use other sources than the examples, sources that are outside the control of the repo maintainers. Especially since many of the examples are so old.
2021 update with a gazillion new scenes (more like 10 or 20, but those numbers are not so compelling to motivate the community to visit and check it out ) https://mgz.me
First of all congrats on your portfolio!
I would like to ask you about the fullscreen implementation on screen’s orientation (from portrait to landscape). I’ve managed to achieve it on android devices, but I struggle with iOS and safari especially. It seems it can be achieved only with some kind of user action like scroll but not automatically on change of screen orientation. Can you share more about your implementation?
.
)