mariom
June 12, 2019, 9:32am
1
Is it possible?most maps are mapped by first uv attribute, and that map scale is a Texture parameter…
All expect of light and ambient occlusion maps.
It is but you can only have a single uv-transformation. Hence, if you have a diffuse and normal map and define different uv-transformation for both maps, only the one of the diffuse map is respected. This is a limitation of the library. Some discussion about this topic right here:
opened 08:19PM - 10 Jan 15 UTC
closed 11:17AM - 17 Mar 21 UTC
Suggestion
UV offset and repeat (and probably some of the other texture properties) are uni… forms which are strangely passed from the texture into the material, which leads to issues where you have to clone textures per material (wasting a ton of memory) if you want per-material offsets/repeats, or roll your own custom shader. It's very inefficient to force people to do this, the best case being if someone wants to tile a texture across a surface based on the size of the object it's applied to, or use a texture as a spritesheet for animations. I can only see the current system as a hindrance with no real advantages, since the likelihood of needing shared UV offsets/Repeats on a "shared" texture is low, and would normally be better served by sharing a material. In anycase updating the uniforms off the texture is weird, since it really has no business being part of the texture, and ends up being confusing to the end user. For example, changing the offset/repeat when more than one map is applied to the material, example diffuse+normalmap, only uses the offset/repeat of the diffuse map, so the value of the normalmaps offset/repeat is completely useless in that context, when it really suggests it should affect the normal map offset/repeat. It's all around confusing.
I'm pretty sure the change is required in the "refreshUniformsCommon" function, but there's probably more to it. There's some changes required in the sprite plugin aswell. This would probably break a lot of peoples projects but it's a pretty big inconsistency in the texture/material API. It might be a better idea to make it an override that's normally null for materials, and when set ignores the values in the textures, just so it doesn't break everyones stuff.
2 Likes
mariom
June 12, 2019, 11:40am
3
Thank you for a quick explanation.
There’s an example here that gives you independent transforms for most maps:
Demo here:
http://dusanbosnjak.com/test/webGL/three-materials-extended/webgl_materials_extended_multiple_uvs_props_transform.html
Granted, this will go away eventually when NodeMaterial lands as you can see per comment, but it works for now. The demo was done i think with a pre 100 version.