My personal ThreeJS scenes gallery / portfolio made with React

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.

You can find it at: https://mgz.me?mode=Three

Any kind of suggestions / feedback is highly appreciated.

Thank you all so much for your valuable time checking out my project.

My best regards,

Marco.

9 Likes

Looks very stylish and slick! :dancing_women:

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?

Also wow, this is really tightly bundled/compiled, loads super fast.

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.

3 Likes

This is so great! Thanks a lot for the work @Mugen87 . How can I contribute with some new post processing shaders?

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!

1 Like

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 :+1:.

1 Like

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!

It is already big and thus hard to maintain.

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.

3 Likes

Why do you need it to be in the main repo? Why not have a separate github repo, optionally an npm package?

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.

1 Like

I mean check out this PR: https://github.com/mrdoob/three.js/pull/16576

There are already objections if you want to remove a file that is not even referenced in the entire repo…

We kinda hijacked the thread but it does seem like a relevant discussion.

Check this out, https://github.com/mrdoob/three.js/pull/10750, i saw this demo presented at GDC in 2017, and then it just kinda stalled and never got merged.

Several issues i see here:

  • 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.