Neveerrrmind, it fixed itself on its own idk how
MeshParts make any transparent portions of UV maps show as neon grey.
What does that have to do with my issue? There’s no transparent portion to the texture.
Ah, I thought there were. Whoops
1 Like
actually i think this needs to be moved to client bugs.
Yep, you can edit the category yourself by the way, just edit the post / the title and change Studio Bugs to Client Bugs.
So what is the expected behavior here?
1 Like
Both the MeshPart and SpecialMesh in OP’s screenshot should look the same – same mesh, same texture, but currently there’s a difference in appearance between the two.
1 Like
And why is it expected?
1 Like
You would expect that because both examples share the exact same mesh ID & texture ID it should display properly no matter if they’re a SpecialMesh or a MeshPart.
They should look 100% identical no matter what and clearly they do not. If this is intentional for some reason, clarification would be appreciated.
2 Likes
Same, MeshId, same TextureId.
Left SpecialMesh, Right MeshPart.
Why isn’t the texture applied the same way?
1 Like
Disregard this, it fixed itself. lock or somethin
OP has issue resolved, but to answer your question: The largest reason being that texture maps are saved to meshes – the mesh files themselves dictate how a given texture should be applied, and the type of instance the mesh is in-game is unrelated to that.
From a usability standpoint, MeshParts were designed to be physically accurate meshes – this would be the first I’d ever heard of them being intended to be visually different as well. If it was ever intended for them to be visually different, this was never communicated to anyone, so of course we’d expect them to appear the same.
Mesh files only contain texture coordinates. How a texture is “applied” (wrong term, btw.) is dictated by shaders (for which “applied” is a wrong term either), which are selected by specific materials based on properties only a portion of which is exposed to users in a direct way. Throughout the years there have been a lot of special cases regarding which material features are used by meshes, and which are e.g. reserved solely for parts.
And the type of instance is very relevant here, because the concrete corresponding C++ class is responsible for supporting those features. Being a separate class in OOP sense (and an unrelated class for that matter) strongly communicates the message that functionality contained inside is different.
It was never intended for MeshParts to be bug-to-bug-compatible with SpecialMeshes either. In fact, compatibility was exactly why we introduced a new kind of mesh, rather than adding new functionality to SpecialMeshes.
2 Likes