displacementMap ignoring offset

[kishalmi]

the phong (and most likely others) vertex shader uses uv instead of vUv
resulting in texture.offset having no effect.
suggestion to use vUv here.

#ifdef USE_DISPLACEMENTMAP

    transformed += normal * ( texture2D( displacementMap, uv ).x * displacementScale + displacementBias );

#endif

[WestLangley]

Displacement maps are normally closely-coupled to the geometry, so offset/repeat would not make sense. The exception, I expect, would be if you were displacing a plane geometry for a terrain.

The problem with supporting offset/repeat with displacement maps is you may want to repeat the map, but not the displacement map. I have been under the assumption that is the most common use case.

When offset/repeat does not make sense, uv2 is more appropriate. We could have displacement maps use the 2nd set of UVs, instead.

vUv is not defined for displacement maps.

#if defined( USE_MAP ) || defined( USE_BUMPMAP ) || defined( USE_NORMALMAP ) || defined( USE_SPECULARMAP ) || defined( USE_ALPHAMAP ) || defined( USE_EMISSIVEMAP ) || defined( USE_ROUGHNESSMAP ) || defined( USE_METALNESSMAP )

    vUv = uv * offsetRepeat.zw + offsetRepeat.xy;

#endif

uv2 is defined for lightmaps and aomaps only.

#if defined( USE_LIGHTMAP ) || defined( USE_AOMAP )

    vUv2 = uv2;

#endif

/ping @bhouston

[mrdoob]

It's issues like this that shows the benefits of NodeMaterial...

[bhouston]

I think the next issue is getting NodeMaterial into the core of ThreeJS as well as adding the ability to load and save it. But generally I think NodeMaterial addresses nearly every flexibility issue people have with materials -- with the exception of multi-layered materails (that still needs to be added.)

[WestLangley]

@mrdoob @bhouston Apart from waiting for NodeMaterial we should make a decision here.

One thing that this post makes clear is we have 3 uv sets:

1. uv
2. uv-modified-by-offset-repeat
3. uv2

Thinking outside the box... One thing we could do is remove uv2, and replace it with uv. That would make things simpler, and would still allow for the original uvs and the offset-repeat-modified uvs.

We would then require only one set of uvs, and simply say that lightmap and aomap and maybe displacementmap do not respond to offset/repeat.

[bhouston]

I believe NodeMaterial is now merged :) Clara.io supports any number of UV sets and it supports offset/repeat per texture as well - and this is how I feel it should be in Three.JS as well, and with NodeMaterial it can be.

DisplacementMap can be tied to the diffuse texture at least in high end cases, both ray tracing rendering and game engines. It is only on the low end with WebGL 1.0 that it seems to be tied completely to the geometry. Normally one can shift it around easily and get good results because one has render-time adaptive tessellation.

[bhouston]

I think that uv and uv2 are both required for things like floors and other types of repeating texture objects that require light maps. This allows for the light maps to be low resolution which the texture itself is high detail -- this is usually the case that baked global illumination representing light maps contain low frequency details.

[WestLangley]

@bhouston OK. I am trying to understand which you prefer; for MeshPhong/Standard/Material we have to pick one of the following to implement for now.

1. Leave the code as is. That means displacement maps use the first set of uvs but do not respond to offset/repeat. (They would continue to be a special case in that regard.)
2. Modify the code so displacement maps continue to use the first set of uvs but respond to offset/repeat just like map does. (This is what the OP requests.)
3. Modify the code so displacement maps use the 2nd set of uvs like lightmap and aomap do.

[bhouston]

I'd go with #2 as OP suggests. Essentially #2 is a super set of #1 with just more flexibility. Often displacement maps follow the diffuse texture, so this makes sense. In Clara.io's custom branch of Three.JS I read a unique offset/repeat for nearly every single map, rather than having a global shared one -- this is a future direction I would suggest but can be easily handled by NodeMaterial.

I do suggest that NodeMaterial be the primary focus going forward -- it probably needs more tooling though to be easier to use.

[WestLangley]

@bhouston OK, we can do (2).

Just remember that it is limiting in that if you don't want to repeat the displacement map, you are forced to repeat it if you repeat the map.

The problem with supporting offset/repeat with displacement maps is you may want to repeat the map, but not the displacement map.

---

Do you envision NodeMaterial replacing Mesh*Material at some point? I was under the assumption that Mesh*Material will remain for convenience, and we would add MeshPhysicalMaterial, too.

BTW, keeping Node*Material in sync with Mesh*Material is going to be a pain, I expect.

[bhouston]

I think it is possible to have at least MeshBasicMaterial, MeshPhongMaterial and MeshStandardMaterial be build upon NodeMaterial -- they would just setup preset graphs or something like that. I think that NodeMaterial may need more flexibility to replace all the other materials, but I think that is a worthy goal. :)

[bhouston]

Just remember that it is limiting in that if you don't want to repeat the displacement map, you are forced to repeat it if you repeat the map.

I am not sure that is very common. But all these tradeoffs we have to consider carefully these days just do not apply as we move towards NodeMaterial... :)

[WestLangley]

@bhouston OK, now I understand what your vision is. That sounds good. : - )

Well, in trying to implement this, I see that since displacement mapping occurs in the vertex shader, it is a special case which needs to be handled differently from the other maps -- it will have to wait.

[mrdoob]

I think it is possible to have at least MeshBasicMaterial, MeshPhongMaterial and MeshStandardMaterial be build upon NodeMaterial -- they would just setup preset graphs or something like that. I think that NodeMaterial may need more flexibility to replace all the other materials, but I think that is a worthy goal. :)

👍

[kishalmi]

great to see, how this sparked such a lively discussion.
the NodeMaterial approach sounds really promising!

@WestLangley apologies if at any point you were under the impression that I was demanding things, it was a mere suggestion. your guess of usecase was spot on though, it is indeed a map/terrain I'm moving around. :)

meanwhile I simply rolled my own shaders that do use vUv for displacement,
just wish this limitation would have been more obvious from reading the documentation.
so maybe the matter of there only being uv and uv2
while each texture has its own offset/repeat vector should be briefly mentioned in the respective sections of the docs?

[bhouston]

@kishalmi I've implemented an alternative solution in this PR #8278 that works with MeshStandardMaterial, and hopefully soon the other built in materials.