Well, if you really do, i think this dead-end tool of mine might just allow it.
So back in 2018, i had a simple idea - create a dag, walk it, make a string that happens to be a valid ShaderMaterial and use it in three.js apps. I didn’t like the official nodes at the time, because i felt that something like this belongs outside the project, and i wanted to validate a concept that WebGLRenderer shouldn’t know about anything else other than said ShaderMaterial.
Well, this first concept kinda worked, you can see one of those first versions here. React-flow either didn’t exist, or i was unaware of it, so i started focusing on rendering the nodes themselves and having this ide of the operations being previewed at every step of the way.
To be fair, i didn’t actually use these kind of tools much, so i didn’t realize that most of them seem to put one node in focus and preview that way.
All this stuff proved to be not so easy, and the idea of targeting all three.js versions may also have been pretty poor in hindsight.
FWIW, i tried to normalize all the shader templates, from R77 to today, so that i can modify them to work with this tool. But this could have also been solved by shipping the whole material (importing unrolling the chunks) from whatever version three is at, and i think it would have still worked.
It’s super buggy, but i am actively trying to fix it, it was kinda fun to make some of these materials. Other than this some notes:
- nothing to do with TSL
- more or less everything was done from scratch, there is three.js and react but thats about it, no off the shelf design systems, the nodes are rendered with three.js
- i managed to load a stress test with 10k nodes and about 15k edges, and it still worked, although it took a minute to load, not that this matters much, because at that scale you cant really tell its a node with connections, but i think this means i may have overengineered it and that there is a budget to do more with rendering
- its very strict when it comes to making the graph, you need to manually compose and decompose values when they mismatch. I’ve built a lot of the ux around this.
2 Likes
I was able to make a parallax work with a procedural texture, but im overall having issues with this. I was thinking if it even makes sense to perhaps bake a part of the graph, basically render it to a texture and then pick it up from there for something like this.
Does anyone find this at all interesting? Are these types of tools doomed now that we have claude? Would it have any value if you could use an agent to edit the graphs or make functions? Use your own keys etc?
Also added a walkthrough with some explanations for the shortcuts and interaction.
2 Likes
Man if you could implement SiPOM w it.. that would be siiick.
1 Like
On one hand, this doesn’t do much other that compose functions, so if someone published this somewhere it would be trivial to get it in. On the other, it’s not easy to make a multi pass shader, and at that point I think I’d be reinventing TSL 
So if this effect needs a bunch of buffers, targets and like three draw calls, I’m not sure what to do. If exploring “what the world would have been like if we still had the WebGL renderer” then it could be an interesting project. But if it were to be actually useful I think it would have to start targeting TSL.
Eg I was curious how could I modulate AO if it were at all possible. You’d have to run some logic before an AO pass, and after. While this would be easy to do in the tool, you’d need to also have some framework on the client end to know when to do the passes and break things up, it’s no longer just a material instance.
While I do actually like this approach (keep three lean), TSL seems to have extended these capabilities by a lot. My understanding is that by just having a material instance, you can control a whole bunch of stuff, like several passes, render to targets etc. I haven’t used it, but I don’t see a reason why a material couldn’t have a node that actually controls writing to a texture, not just sampling it. while with WebGL renderer you have to manage the renderer and targets.
i don’t think it needs multiple buffers.. but it needs discard; to carve out the silhouette at the edges.. idk.. if it determines the edge margin from the UVs or wut.. yeah.. Probably a bit out of scope. 
Was just a thought, since I’ve been seeing it talked about a lot lately from Crimson Desert discourse on the web. It’s a cool effect.
The other thing is, it doesn’t seem straightforward to do these sorts of effects on procedural textures. If you have a bunch of noise and voronoi and whatnot chained together, getting a derivative requires running it all again several times. Thats why I’m thinking even if you do distribute voronoi for example in 3d, should you bake it to 2d to run effects like this (blur, texture offset for parallax etc).
But then, say your noise and voronoi are not animated, the logic up to that point would never even exist at runtime, at that point you’re just editing a 3d texture and baking it to a regular texture.
1 Like
right but.. I think the core logic is the same as your POM you have there. the main difference being that they have to expand the planes outwards a bit by their normal.. like a shell shader…so there is enough overlap for them to have a contoured edge and join together correctly. It sounds super hard.
1 Like
Related:
https://x.com/ToJans/status/2052781559158030791
As far as I know, this uses TSL to generate procedural textures, stores them in image textures and then uses them in the traditional way.
1 Like
Is there a way to open this if one doesn’t want to use twitter? I hate paywalls.
Is there a gap in between where the first steps saves “my_procedural_texture_uv1” or is it all part of the framework.
Animating a voronoi and sampling it for parallax would require the latter. But if the former, it could be generated in unity, via cli, have maybe more stable noise and whatnot when computed on the cpu and such.
I can see it without being logged in:
And here is closeup:
1 Like
