Should triplanar and UVW Randomiser be last in the chain?

[Jpjapers]

When im playing around with lookdev i often end up with really long and complex material graphs in the SME and sometimes they feature the triplanar or the uvw randomiser nodes. When i go back and try to optimise them i often wonder what to do with those nodes.

It got me thinking if theres any 'order of operations' logic that says they should be the final node in a graph or whether its fine to have multiples in one graph?
Are there any internal calculations that would affect render efficiency when the nodes are further up the graph?

Thanks

[romullus]

If i'm not mistaken triplanar indeed should be the last node before plugging maps branch in to material, because it creates new mapping. For randomizer the order is not that important, because it only modifies already existing mapping and does not create a new one.

[Jpjapers]

If i'm not mistaken triplanar indeed should be the last node before plugging maps branch in to material, because it creates new mapping. For randomizer the order is not that important, because it only modifies already existing mapping and does not create a new one.

Ive been doing alot of work with triplanar maps and adding dirt and grime to things for instance, and if i only wanted the dirt overlaid onto the existing albedo, a triplanar and a mix map usually works fine but i do sometimes notice a slowdown the more of them i use. Was just curious if it was because of material complexity or node position or both.

[romullus]

I don't think that map order could influence rendering performance, but shader complexity definitely can. Another thing that can add a lot to slowdowns is show material in viewport, especially when maps like Corona colour correct, multi-tile and others are plugged in base colour.

[Jpjapers]

I don't think that map order could influence rendering performance, but shader complexity definitely can. Another thing that can add a lot to slowdowns is show material in viewport, especially when maps like Corona colour correct, multi-tile and others are plugged in base colour.

It probably is shader complexity yeah, I was just curious about the order of operations and whether having multiples of either node within a map was a no-no.

[romullus]

Multiple triplanars within the same branch is definitely a no-no. It makes no sense, since the last triplanar will always override everything that goes before it.

I guess multiple randomizers can be used, but not recommended, since it would add to shader complexity and lead to performance loss. Try to see if you could simplify the shader tree by combining several randomizers into one. I'm struggling to imagine situation where more than one randomizer is necessary, so it would be interesting to see an example if you have one.

[BardhylM]

May I ask another question in this thread related to this, it's about UVW Randomiser and been wondering for a while now.
If you plug UVW Randomiser on Normal maps, I would think it should be in hierarchy above CoronaNormalMap. As that is defined the bump is a Normal map.
But the bump results in wrong normal orientation because of the Randomiser, obviously with the rotation option turned on 360 degrees.
Am I doing this wrong, should I add another node before connecting in the bump slot, or is Randomiser not meant for Normal Maps.

[romullus]

Normal map is a special kind of map, because its colours modifies mesh normals vector. You can't arbitrary rotate normal map and expect to get meaningful result. To answer your question, you can use randomizer on normal map, as long as you don't touch rotation.

[BardhylM]

Yeah that makes sense, I just thought does Corona recognize somehow this as a baked height after the CoronaNormalMap option.
It would be a neat thing to have an option in which you can tick "normal map" in Randomiser which would take in consideration this, and have the normals rotated.
Don't know how complicated that is though, as some external programs need computing power to "rotate" those normal maps, keeping the color orientation fixed.

[Jpjapers]

Multiple triplanars within the same branch is definitely a no-no. It makes no sense, since the last triplanar will always override everything that goes before it.

I guess multiple randomizers can be used, but not recommended, since it would add to shader complexity and lead to performance loss. Try to see if you could simplify the shader tree by combining several randomizers into one. I'm struggling to imagine situation where more than one randomizer is necessary, so it would be interesting to see an example if you have one.

Perhaps im fundamentally misunderstanding the map creation process here then.

If im adding procedural dirt and paint flakes/chips to something, i usually will add a uvw randomiser after each bitmap node that i have plugged into say a mix map. I had assumed that this would randomise both maps every time the map is applied to a different object, resulting in less chance of noticeable repetitions.

However i would do the same with triplanar if further down the branch i had a map coming into the branch that i didnt want to be applied with triplanar in the final texture. I also use it if i want bot input maps to be mixed at different triplanar sizes. But its just occurred to me that ive never actually tested this. I must have just assumed it and adopted it out of habit.

EDIT: It does work how i imagined. I did a quick test with some checkerboards.

[romullus]

I didn't test this either, but i'm pretty sure that if you remove all triplanars and only leave the one that is closest to the material, it would render exactly the same, but maybe a bit faster :]

[Jpjapers]

I didn't test this either, but i'm pretty sure that if you remove all triplanars and only leave the one that is closest to the material, it would render exactly the same, but maybe a bit faster :]

When i say i have multiple in the same map i generally dont have multiple affecting more than one input bitmap. I did a quick test and it does work how i imagined it would. I can control the triplanar of each bitmap that feeds into say, the albedo, separately. An example would be using a triplanar scratches bitmap as a mix map for a paint and a metal albedo, and then feeding those into another mix map that mixes in a triplanar map of some dirt or oil using a noise map. The paint and metal textures retain their original mapping but the map that mixes them does so in triplanar space and the dirt is applied over the top in triplanar space too.

However as i think you were explaining, if you have a load of triplanars upstream, and THEN plug those into a triplanar at the end, it does render the same if you remove the upstream triplanars.

[romullus]

It would be nice if you could attach a screen of your shader tree, as indeed we could be talking about different things.

[Jpjapers]

It would be nice if you could attach a screen of your shader tree, as indeed we could be talking about different things.

So 1 triplanar per input map is fine even if you have multiple triplanars feeding into the final node in the branch, you can control them all separately.

Any bitmaps that have 2 triplanars affecting them will render the same if you remove all but the one closest to the material.

The first image is just a few combinations.
The second image is showing the difference between having multiple upstream triplanars feeding into a map vs just one at the end.

[romullus]

Honestly, i didn't know that would work. Still, i think such setup with multiple triplanars is unnecessary. You should be able to achieve the same by manipulating UV tiling in the bitmaps themselves and/or replacing additional triplanars with randomizers. The ideal setup in my eye is the second example from your first image. On the other hand, if it works for you, then i guess there's nothing wrong in using it :]