The displacement on this SSS spires is by a shader I've created which is based on inspiration from Star War's Geonosis world. This is a more stylized version with more rough angular shapes, though that can be disabled for smoother shapes (it's PF powered redirection of the underlying displacements).
It also outputs a RGB map of the Horizontal Scalar, Vertical Perlin Scalar, and Cave Scalar, which can then be used for masks and texturing.
Interesting spires. But your setup seems very complicated. It can be done very simple, though yours may have some additional benefits.
Everytime i see stuff like this it makes me think that this software needs an update.
I find quite alarming that to produce a simple shape like that it requires so many nodes, great work nonetheless WAS.
These shaders are for people to use without needing to understand any of the logic of the shaders or mess with them. Just change displacement settings, and PF seeds or settings, etc, as if it was a complete shader itself.
The simple shape is simple, nothing special, it's what you can do with it. Similar to my voronoi displacement shader or my faux strata, almost infinite possibility without diving into what shader is actually using what feature, or plugging new nodes, etc.
If I was just doing simple perlin or sin, I'd just do that. But this is meant to be flexible without all the recreation of node networks in new scenes. If you look closely, the function is very simple. It's just been set up in a way to expose settings so there are no confusing transform shaders and colour adjusts you have to search for or be aware of to know what they're doing. It's all named out, categorized, and organized.
Nice work. Terragen needs a node to package this sort of work better.
Quote from: mhaze on April 09, 2021, 05:08:43 AMNice work. Terragen needs a node to package this sort of work better.
Yeah I was thinking the same thing a while back. Maybe flag scalars and PFs as "settings" and it compiles it into a shader. One tab for scalar settings by their name, and the rest of the tabs any marked shaders like PFs and such, loading that shader as a subtab of a tab sorta deal.
Well, you can put not-to-be-used nodes inside a group (so invisible) and only keep the variables out in the open and link appropriately. Rather clean that way. Not for me, as I like to see clearly what's going on, but maybe for people who get frightened of a lot of nodes (nodefobia), it's a solution.
I was having trouble lately with nodes inside a container in anothr container. Stuff disconnecting when everything is named when you import the TGC or copy paste.
Yeah, that can happen even if there's only one similarly named node somewhere. Nuisance. That's why I always delete the default shader inside the sphere, for instance. I don't use it, and it may interfere if adding another somewhere and try to link that to something. It may choose the wrong link, especially if you have many 'choices'.
That's a really good and important information in my eyes, because I had this effect very often when copying nodes in very complicated scenes and didn't know why it happened.
Quote from: Dune on April 10, 2021, 09:16:13 AMYeah, that can happen even if there's only one similarly named node somewhere. Nuisance. That's why I always delete the default shader inside the sphere, for instance. I don't use it, and it may interfere if adding another somewhere and try to link that to something. It may choose the wrong link, especially if you have many 'choices'.
Yeah that's always confused me. The parsers should be looking at things as a whole to compare the strings. I do notice that similarly named things sometimes disconnect. I wonder if the logic in that code can be improved. Honestly I think I'd literally compare just the whole strings, less overhead. But i know there is also the shader number computation so I dunno.
Congratulations Jordan for this work even if honestly I do not understand anything and am overtaken by this complexity!