Conceptually this is very close to what I try to do. However, I have to change the source code of the shaders, because blind merging causes name collisions. It might be possible to automatically adjust shaders sources, but I’ve left this for later on.
I have already done the simple shaders (they only require a color buffer). I’m now in the phase of deciding how to process other buffers. I have started with a property “shader type” – something like “blood type” that defines compatibility of shaders. However, I liked the idea of having needsDepth, needsNormal and other similar flags. I just have to foresee whether this will lead to some polution in the future (i.e. I do not want to end up with 20 needsSomething flags)
For now I have identified two general cases when shaders cannot or should not be merged into one shader:
the first shader produces data in another buffer and the second shader needs these data
the first data samples many fragments and the second shader also samples many fragments
For example, a “should-not” case is a blur that is done in two passes – one horizontal blur with N samplings and then one vertical blur with N samplings. Such case will require 2N samplings if the shaders are run in different passes; but N2 when merged into one shader.
My general intention is first to make it work and then to make it as close to the current EffectComposer/Passes style as it is possible.
Edit: I need to prepare some images and will continue this reply… stay tuned
The following image captures my goal and it is quite in line with your idea of generic pass, effectcomposer’s analyzer and scene pass. The left image shows the current situation – many individual passes with shaders (vertex+fragment) behind each of them and direct access to uniforms. My goal is to allow the user to think that the effect composer is … composed of effects and their parameters, i.e. the user should not think about passes, shaders and uniforms. However, internally it will be again passes with shaders, but the analyzer will determine how to combine shaders in the most performant way.
Hmm… I wouldn’t want to break backwards compatability - I intentionally forced the dependency on postprocessing so that people could updated to N8AOPass without changing a line of code in their codepass. Maybe just have two different build files here - or like a vanilla only one?
Okay there’s been a lot of drama about the sourcing of this AO code and N8AO/HBAO and I want to say a few things:
#1. I am completely fine with Rabbid76’s PR in concept. There’s nothing wrong with taking my code and simplifying it for submission to threejs. I do, however, think that an external example to N8AO maybe just be easier than trying to distill N8AO down into a single threejs friendly pass. But I don’t take any ethical issue with what Rabbid did.
#2. I think maintaining three.js is a very difficult job and we should always shout out and appreciate the maintainers (@donmccurdy@Mugen87@mrdoob, countless more) - they work incredibly hard and we owe this amazing library to them. There’s a difference between giving constructive feedback and assuming bad faith (which I know for a fact they don’t have).
#3. I think the debate around external tooling is a valid one - the threejs repo has philosophies and architecture choices that give it external consistency, and external libraries may deviate from that. It’s not an easy line to walk, and I understand why such intense discussion occurs.
So, to summarize:
I think adding N8AO as an external example is a good idea. I also think keeping Rabbid’s HBAO/GTAO is fine, and I don’t have an issue with Rabbid’s original PR. I appreciate the threejs maintainers and think we should assume everyone is acting in good faith and in what they believe to be the best interests of the library.
Thanks for all the discussion, and sorry I didn’t see this sooner.
But I’m curious - what’s the problem with the postprocessing import - it’s just a quick define in the import map, and then N8AOPostPass can be ignored.
Is it like a thing of principle - threejs external examples should only depend on three.js? If so that makes total sense, and I’ll probably just make a vanilla-only build of N8AO.
Yes, it would be. The only solution to that would be a custom file with JUST n8aopass and not the postprocessing component - would you like me to go ahead with that solution? How should I go about naming it…? Let me know if you have any advice.
Don’t worry about it! A proper vanilla N8AO import that doesn’t really on postpro would be great… just need to figure out how to do it without breaking backward compatibility.
One thing that’s been mentioned multiple times but we just need a PR for is adding an “external” example for the postprocessing package for three.js. This could be a good opportunity to add one. It’s a very impressive project and ultimately does perform better at the cost of some code simplicity worth promoting. I think it’s only natural that this would happen when there are dedicated maintainers for a postprocessing stack compared to how we’re spread out with core and examples maintenance in three.js.
One thing I’m excited for and interested in seeing in the future that could help move both internal and external postprocessing forward are more features that help enable a deferred-rendering pipeline. A lot of postprocessing effects are currently hacking around this a bit to get different render passes and screen textures. MRT was a big step - and I think the next one will be node-based materials. I’m not sure if there’s anything more needed but that might be a discussion for another thread.
just live in a moment, lol. stick to specific versions, do not update unless you have to. if you still have to update your product after many years when some of the dependencies died - accept and be happy that your product did not.
That sounds a little bit like YOLO but of course, it depends on what you are building. At least from my experience, it’s good to have a solution that is stable and long-living. But I think that does not add anything to the initial discussion anymore. So I’ll stop arguing about software maintenance here. We can discuss it at some better place if you like
but of course, it depends on what you are building. At least from my experience, it’s good to have a solution that is stable and long-living. But I think that does not add anything to the initial discussion anymore. So I’ll stop arguing about software maintenance here. We can discuss it at some better place if you like 
