Chaos Corona Forum
Chaos Corona for 3ds Max => [Max] Bug Reporting => [Max] Resolved Bugs => Topic started by: matsu on 2018-03-20, 11:15:04
-
I was setting up a brick material using triplanar mapping in the texture slots, and noticed something funny. (Not funny, really.)
Displacement is calculated first, then the other mapping is applied to the displaced geometry, resulting in mapping mismatch.
Attaching images. First with triplanar, and then without (using ordinary UVW mapping).
-
This seems very very logical to me. But let's see what the dev team has to say.
-
hmm... logical or not, it isn't very useful.
BTW this isn't the only situation where displacement f*cks up UVW. When using different mat ID's in a Corona multimap the UVW is distroyed too. And when using displacement in a multimaterial shit happens too :(
I really hope displacement will have a major update in next release.
-
Imagine you are texturing some kind of terrain. You apply displacement like noise or some kind of fractal, and then texture it using triplanar. It makes sense to displace first, and then texture.
Also, if the texturing was done first, and then displacement, then you could easily end up with stretched textures - which triplanar is supposed to prevent.
Last point - it does not make much sense to talk about UVWs with triplanar, as triplanar is designed to make UVWs obsolete. :)
-
Get your points. But that means that displacement won't work with triplanar map, and that displacement should be avoided with "normal" UVW mapping, since this will give you "stretched textures".
-
The theoretical scenario where this would be preferred method is in my opinion outside of common usage.
Displacement always stretches existing mapped texture, after all the map is driving it in first place, why should other map be applied afterwards in different order ?
Possible solution to this would be that material displacement always acts on existing UVWs, as expected, not as shown in this thread, and geometry displacement modifier being given option to take precedence.
-
Exactly!
-
The theoretical scenario where this would be preferred method is in my opinion outside of common usage.
Quoted for emphasis. In 99.999% of the cases, I want triplanar mapping to behave the way normal UVWmapping does.
Option (even though I'm genereally opposed to adding more and more buttons/checkboxes) would be to add a switch that lets you decide the mapping behaviour - if you want mapping applied before or after displacement.
-
Is there any consensus about this issue? Will it be addressed? I'm creating my own material library and to my dismay i found that i can't use triplanar with materials that have displacement :[
-
Why would you use triplanar for bricks/tiles? Doesn't seem like the type of material to benefit from it.
-
Brick here are only because that material very clearly shows the issue, but any material with displacement is affected.
-
Displacement and UVs have always been a struggle for me... I came across another issue recently. I tried to mix two textures and plugged them in the displacement slot. One texture was UV channel 1 and the other was UV channel 2 ( Tried to mix decals (no tiling) over road surface (tiled)). The result was calculated only with UV channel 1. The workaround is to set everything UV1 and play with tiling values in the maps which introduce some cumbersome workflow for decals placement.
That's probably what happened here, displacement is calculated on UV channel 1, not on triplanar projected UVs. -> mismatch
IDK if making displacement working with multiple UV sets is hard to do but if we're discussing displacement behavior, This has to be taken into account I guess.
-
I highly doubt that, because in 99,9% of cases, mismatch would be too severe to ignore. Anyway that's easy to check...
-
I highly doubt that, because in 99,9% of cases, mismatch would be too severe to ignore. Anyway that's easy to check...
Just checked you are right, that's not what happened with triplanar. Was just a random assumption.
Anyway, even if it's not the issue in your case, I think the point I highlighted above has to be addressed too.
-
Of course it should, just make sure that there is bug report about that. If not, then please create separate report, so it won't be lost.
As for my case, i just found that i made big mistake by plugging normal texture in to triplanar first and then in Corona normal node. Apparently triplanar always has to go last (first in to material). That didn't solve displacement mismatch though. Now i will have to fix all the materials i made during weekend *sigh*
-
Of course it should, just make sure that there is bug report about that. If not, then please create separate report, so it won't be lost.
It just worked on my simple test.... Looks like the issue is on the layered material side. Will test it further and make an appropriate bug report (if needed as i've just seen there are some existing report on layered materials with displacement). So nothing correlated to your issue, forget what I said :)
-
Is there any consensus about this issue? Will it be addressed? I'm creating my own material library and to my dismay i found that i can't use triplanar with materials that have displacement :[
I don't think that's really "fixable" because of two things:
1) Triplanar is by definition supposed to work outside of any UVW restrictions
2) If we would "fix" that, then people would complain that they are displacing some landscape, and then triplanar is not working how they would expect :)
-
1) Triplanar is by definition supposed to work outside of any UVW restrictions
I don't know technical details, but isn't this just a matter of order of operations? If displacement would be applied last instead of first, then it should give better result.
2) If we would "fix" that, then people would complain that they are displacing some landscape, and then triplanar is not working how they would expect :)
Trying to thing logically, how many cases there is, where current behaviour makes conventional materials unusable, versus number of cases where somebody wants to use triplanar for displacing the mountains? I think that Juraj and others already threw in some good ideas, how this can be improved. I think that this definitely should be fixed.
-
Possible solution to this would be that material displacement always acts on existing UVWs, as expected, not as shown in this thread, and geometry displacement modifier being given option to take precedence.
I think both displacement methods should behave the same way otherwise it will introduce some confusion. Consistency is the key. I'd rather have an option for displacement order in the triplanar map itself. That way, it would also allow mixing both methods in a single material (even if I don't see any use case of this right now, anyway it's there). Kind of a "compute before displacement" checkbox, unthicked by default so the current behavior is not affected.
-
Ok, let's see what The Powers That Be have to say about this...
-
The official answer here is that currently the Triplanar map works as expected and we are not going to change it. The object is displaced first, and then the Triplanar map is projected from all axes. This means that Triplanar mapping should be used for uniform details such as scratches or noises, and for defined patterns running in some specific direction it is best to use classic UVW mapping. More details here: https://forum.corona-renderer.com/index.php?topic=20616.0
We are of course open to further discussion.
-
Well, that's a second sad news i heard today. It looks like my day has started on the wrong foot :/
-
Hi Maru. That is how one would expect displacement to work when using a displacement modifier. But inside a material, I would certainly expect all maps to "follow" each other - meaning displacement should be added last! This is bad!!
-
(internal id=259037790)
-
new thread https://forum.corona-renderer.com/index.php?topic=38236.0