Corona Renderer Forum

General Category => Bug Reporting => Topic started by: matsu on 2018-03-20, 11:15:04

Title: Triplanar- and displacement mapping inconsistency
Post 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).


Title: Re: Triplanar- and displacement mapping inconsistency
Post by: maru on 2018-03-20, 19:32:40
This seems very very logical to me. But let's see what the dev team has to say.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: PROH on 2018-03-20, 19:41:07
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.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: maru on 2018-03-20, 19:58:16
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. :)
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: PROH on 2018-03-20, 20:00:20
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".

Title: Re: Triplanar- and displacement mapping inconsistency
Post by: Juraj Talcik on 2018-03-20, 22:26:40
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.

Title: Re: Triplanar- and displacement mapping inconsistency
Post by: PROH on 2018-03-20, 22:51:01
Exactly!
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: matsu on 2018-03-21, 10:42:29
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.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: romullus on 2018-07-22, 16:31:24
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 :[
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: steyin on 2018-07-23, 19:56:55
Why would you use triplanar for bricks/tiles? Doesn't seem like the type of material to benefit from it.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: romullus on 2018-07-23, 20:33:26
Brick here are only because that material very clearly shows the issue, but any material with displacement is affected.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: Fluss on 2018-07-24, 10:56:32
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.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: romullus on 2018-07-24, 11:24:46
I highly doubt that, because in 99,9% of cases, mismatch would be too severe to ignore. Anyway that's easy to check...
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: Fluss on 2018-07-24, 11:35:32
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.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: romullus on 2018-07-24, 11:47:15
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*
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: Fluss on 2018-07-24, 11:57:34
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 :)
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: maru on 2018-07-24, 13:06:20
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 :)
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: romullus on 2018-07-24, 13:57:28
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.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: Fluss on 2018-07-24, 14:35:45
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.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: maru on 2018-07-24, 15:41:18
Ok, let's see what The Powers That Be have to say about this...
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: maru on 2019-03-14, 11:16:59
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://corona-renderer.com/forum/index.php?topic=20616.0

We are of course open to further discussion.
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: romullus on 2019-03-14, 11:27:41
Well, that's a second sad news i heard today. It looks like my day has started on the wrong foot :/
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: PROH on 2019-03-14, 17:12:25
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!!
Title: Re: Triplanar- and displacement mapping inconsistency
Post by: maru on 2019-08-16, 10:17:53
(internal id=259037790)