I have a unique case where I’m keen to swap out an objects .map with a new image, however, the normal and ambient should remain. The normal and ambient have repeat set to 4, but I’d like the new map to have a repeat of 1. I noticed that a while ago this was discussed in various forums as being a limitation to Three.js that mentioned a nodeMaterial. Interested in any info on that too.
This is not supported by the default built-in materials. You indeed have to use NodeMaterial
for this use case (where you can have for each texture an own set of texture coordinates with individual texture transforms).
Thanks mate, I’ll look into it, hey just a quick bonus question. Is there any risk of passing parameters to materials that they don’t support? For instance shininess used in a Standard Material. Reason being is that I want to pass an object to a class that will return the correct type of material based on a ‘type’ property. For instance “textured”, “metal” etc. To abstract away some of the different types of materials for the user. When the class selects a material, I can either spread the object into it and the correct ones will hit, others will pass warnings to the console that the material doesn’t support that property, any other affect other than the warning?
AFAIK no. The only thing that should happen in this case is the generation of a warning by Material.setValues()
.
I’ve been curious about this before - do you know why we warn for materials? In general the three.js philosophy is not to warn when parameters are incorrect so this is a little out of keeping with other parts of the library.
I’m not sure about the history of this particular warning. I could imagine that at the time of its introduction, it was important to highlight that there is no common material parameter object that could be applied to all material constructors. Otherwise users would assume stuff like shininess
exists for all materials.