Should triplanar and UVW Randomiser be last in the chain?

[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