Old material texture tempering with new material display?

Unfortunately I am not allowed to share the presumably ‘guilty’ input file in a PG, but I’ll try to describe the issue as clearly as I can instead.

I import a .babylon scene and assign to a flat square mesh a standard material created in code, that has an opacity texture. That texture has the same proportions as the target mesh. I want the texture pattern to appear once, and to cover the entire mesh surface. To achieve that, I pretty much leave the texture settings untouched.

This worked as expected with the previous version of the product that I am working on.

I am now attempting to use a different set of input (.babylon scene + texture file) and the opacity texture is no longer displayed at the desired scale: the texture gets stretched along u, which means only a fraction of the image fits on the mesh.

The new mesh and texture file have different dimensions compared to the previous ones, but their proportions are still identical.

Using the Inspector in the Sandbox, I have spotted a difference between the old and the new .babylon scenes which I believe could be the source of the issue: In the imported scene, the mesh I’m having problem with is apparently assigned a material that contains a single channel (albedo). In the old scene, the texture for that channel had the same proportions as the mesh itself. In the new scene however, the texture is 20 times wider than the mesh.

Setting the uScale of my opacity texture to 20 effectively addresses the display issue, which suggests that I might have found the root cause.

But I would like to understand why the material that I define from scratch in code does not completely override any previous material settings contained in the input scene.

Side question: now that I have (hopefully!) spotted the texture that is causing the issue, how would you go about tracing down possible side effects of that texture on the display?

I can see that the original material using the albedo texture contains 4 meshMap objects. Three of which I have not attempted to modify, and a 4th one being ‘undefined’. (Maybe after I assign my material to that mesh?). But I don’t find much info about meshMap in the doc so before digging further that hole, I figured I would ask the pros for some advice :slight_smile:

Thanks for reading!

The problem here lies within the UVs of the model which would be different. It is not directly related to the material setup.

You should check with your artist to validate this point.

Thanks @sebavan .

The only noticeable difference in setup that I could spot when comparing the old and the new scenes in the the sandbox / inspector was the albedo textures I mentioned in my first post. (See screenshots illustrating what I meant, at the end of this post.)

Would that fall in the UV-delta category that you mention in your reply, or should I be looking somewhere else?

Old scene (albedo texture proportions match target mesh):

New scene (albedo texture x20 wider than target mesh):

Yup the UV are defined in the model itself, like positions and such and this is probably where the diff is.


So the root cause is confirmed. Thanks @sebavan ! :slight_smile:

But is it expected that if one create a new material from scratch (in code) and assign it to a mesh that had another material attached to it before (in an imported .babylon), then the UV settings of the new texture must be adapted to match that of the old one?

Because this seems to be what I am experiencing, and it doesn’t really make sense to me: why should I care about a previous state of the material mesh if I am explicitly overriding it?

Maybe I am not overriding the mesh material thoroughly enough? If so, any tips?

I could try to get a hold on the artist so we can agree on the right input format, as @sebavan suggested, but due to project constraints this is easier said than done. Also, a better understanding of the situation would certainly help driving the discussion.

Yup it is totally expected. Some of the materials info and its setup definitely needs to be ported over like culling and such. As you said tou override it so start back with default which might not be adapted to the current underlying mesh topology or use case.