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 :]

[Aram Avetisyan]

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.

Hi,

In the second image, you are creating two different textures, with two different mappings - the left material has only checker triplanared, the rest are using existing UVMapping, on the right all maps are being triplanared.
If you simply use one checker with multiple triplanars, you will see that only the first triplanar is taken into account, the closest to the textmap.

In the attached "1x1mPlane.jpg" there is a 1x1m plane, first triplanar is 25cm, the second triplanar is 100cm. You can see that only the closest/first triplanar is being considered.

Now check the other images:
In "RedGradient.jpg" the red gradient goes through the 100cm triplanar, it is the closest to it - 1 round gradient is seen on 1x1m plane.
In "RedGradient2.jpg" the 100cm triplanar size is set to 30cm, and you can see that the checker is the same, but red gradient is tiled ~3 times, because 30cm triplanar is the closest to it.

You should use UVWRandomizer before Triplanar.
If there are multiple triplanars in the chain, only the triplanar closest to the textmap will be considered.

Hope this helps.

[Jpjapers]

Hi,

In the second image, you are creating two different textures, with two different mappings - the left material has only checker triplanared, the rest are using existing UVMapping, on the right all maps are being triplanared.
If you simply use one checker with multiple triplanars, you will see that only the first triplanar is taken into account, the closest to the textmap.

In the attached "1x1mPlane.jpg" there is a 1x1m plane, first triplanar is 25cm, the second triplanar is 100cm. You can see that only the closest/first triplanar is being considered.

Now check the other images:
In "RedGradient.jpg" the red gradient goes through the 100cm triplanar, it is the closest to it - 1 round gradient is seen on 1x1m plane.
In "RedGradient2.jpg" the 100cm triplanar size is set to 30cm, and you can see that the checker is the same, but red gradient is tiled ~3 times, because 30cm triplanar is the closest to it.

You should use UVWRandomizer before Triplanar.
If there are multiple triplanars in the chain, only the triplanar closest to the textmap will be considered.

Hope this helps.

Thanks for that, I think we are talking about the same thing?
My point being that as long as youre using a triplanar to control the input of a bitmap into a node and just not the output of the whole branch, youre fine to have multiple within a branch.
So if i understand it correctly, the priority that triplanar maps are evaluated in, is from the material outward. And each map will be affected by its closest triplanar and not any subsequent ones.

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 :]

Are you suggesting using the tiling feature of the uvw randomiser to get the same effect as triplanar blending? I hadnt actually considered that. I may try it and see if its any quicker. It would be useful to know which node is more computationally intensive as in big scenes with lots of complex shaders it might add up to a decent difference in render time.

[romullus]

Are you suggesting using the tiling feature of the uvw randomiser to get the same effect as triplanar blending?

No, you can't substitute triplanar blending with other maps, i was referring to this remark "I also use it if i want bot input maps to be mixed at different triplanar sizes." - you can change texmap size, by changing its U and V tiling, or by changing scale in randomizer, there's no need to use additional triplanar just for that.

[maru]

The original thread about Triplanar and UVW Randomizer got a bit confusing. If there are still some unanswered questions, please let us know, and we can even ask the devs what makes most sense performance-wise.
One note about this: UVW Randomizer operates on the UVWs. Triplanar discards any UVWs. So I would expect the combination to produce different results depending on the order of operations.

And another note for Romullus and BardhylM - this is just something I need to clarify! :)
It's pure magic, but normal maps actually do work fine with the UVW Randomizer, even if you rotate them! It was intentionally made this way so that you can randomize whatever you wish!



I highly recommend using a baked sphere as a normal map for debugging purposes like this.

[romullus]

That's interesting. I will surely test this out, but of course i will do this with my own maps - there's no value in the feature if it only works with specifically tailored texture :]

[BardhylM]

Thanks Maru for the clarification, that is perfect. No need for extra "ticks" as it is.
I've applied it on some occasions the bump randomization with rotation for a plaster material and got some funky results, so I've set a mental note to ask here if it is correct workflow.
As I stand corrected, it was probably the error of texture, because I tested now with some textures from megascans and it works flawlessly.
Thanks again and sorry for hijacking the thread!

[Jpjapers]

That's a good point Maru, I basically use triplanar for adding surface variation to objects I don't want to spend the time unwrapping and that's one of the main reasons for using it in the way I do.

I agree It's a pretty confusing topic given there's so many different applications and variations of ways to use it. I think my original question of whether it should always be at the end of the branch has been answered.

[maru]

That's interesting. I will surely test this out, but of course i will do this with my own maps - there's no value in the feature if it only works with specifically tailored texture :]

Whut? It works with any normal map.

I've applied it on some occasions the bump randomization with rotation for a plaster material and got some funky results

Maybe you had incorrect order of normal and uvw randomizer?

[romullus]

Maybe i failed to understand what you wanted to say then:

I highly recommend using a baked sphere as a normal map for debugging purposes like this.

Anyway, i will test it sometime later and try to understand what's going on with normal maps after randomizer - there has to be a reason why people (including me) see abnormal results. Maybe it has something to do with blending, while rotation by itself is ok?

[maru]

Maybe i failed to understand what you wanted to say then:

I highly recommend using a baked sphere as a normal map for debugging purposes like this.

I only meant that you can use some "test" bitmaps yourself to quickly answer questions like "which node should go first" or "does UVW randomizer work with normal maps". You don't have to use this specific texture, but it will show you whether a feature is supported or not.

[romullus]

I see, thanks for clarification!

[romullus]

I still think there's something wrong with UVW randomizer and normal maps. Here's two simple renders. In one of them the ground is randomized only by U and V offset and it is rendering correctly. In the other one, W rotation added to randomization and it is clear that the normal map is working incorrectly. Both examples rendered without randomization per each tile. What's interesting is that by changing randomization seed, sometimes you can get normal map working correctly.

[maru]

Thanks for the test, Romullus. Could you share this scene?
Are you using V10 dailies here? There is a known issue with normal maps working incorrectly with the new Mapping Randomizer, but I am not aware of any issues with V9 Uvw Randomizer.

[romullus]

Sure, i will prepare the scene and will send it to you. That's 9HF1 - i'm yet to try V10 dailies.

[dj_buckley]

I still think there's something wrong with UVW randomizer and normal maps. Here's two simple renders. In one of them the ground is randomized only by U and V offset and it is rendering correctly. In the other one, W rotation added to randomization and it is clear that the normal map is working incorrectly. Both examples rendered without randomization per each tile. What's interesting is that by changing randomization seed, sometimes you can get normal map working correctly.

This is the same issue I was having here right? https://forum.corona-renderer.com/index.php?topic=37957.0

[romullus]

So, i've tried to approach the issue more systematically and set up comparison between various texture rotation methods. My findings are interesting - when normal map is involved, you can only rotate UV coordinates at object level, but not at a map level, otherwise inevitably you will get wrong result. It's not randomizer's fault, you will get the same wrong result if you rotate coordinates in bitmap node, or indeed in Photoshop. It's logical outcome when you think about it. The only solution i can think of, if Corona would remap normal texture on the fly based on W angle rotation. I think technically this shouldn't be hard to do, although it might be quite expensive computationally. It still would be better than current situation where no normal map rotation is possible at a map level.

Below i'm attaching rendered examples. 1st is displacement only, no normal map. This is ground truth. 2nd to 4th - normal map is rotated at object level - renders correctly. 5th and 6th - normal map is rotated at map level - renders incorrectly.

Sorry for not providing the scene, but UV rotation is mess in 3ds Max, each method has its own mind where rotation center should be and even how offset works, so my test setup ended up pretty complicated. On the other hand it's very easy to reproduce the issue, you just need any normal map with distinct features, map it on a plane, create light source with sharp shadows and rotate the texture at the map level (with randomizer, or in bitmap node directly), you should notice the issue in no time.

This is the same issue I was having here right? https://forum.corona-renderer.com/index.php?topic=37957.0

Yes, i believe it is.

[romullus]

Just to update things - apparently the solution to the issue is to keep correct order of nodes. Corona normal node must go before UVW randomizer, which must go before triplanar. More information about this can be found at Chaos support portal: https://support.chaos.com/hc/en-us/articles/13800753963537