Left is a SpecialMesh with a Decal added to apply the texture to the mesh
Right is a MeshPart with the Texture property set to the same as the Decal
It seems like this is somehow intended to work (since it does with the SpecialMesh + Decal), would be great if it worked for the texture property on meshes too so we don’t need separate instances for collision / visuals.
And MeshParts aren’t neon anymore!! thank you Arseny please fix this one too
Update: posted the same myself in feature requests, however, after two weeks of nothing I searched the forum more thoroughly and can confirm this is apparently truly a bug. Curiously, this is the closest to an official response this issue has ever gotten.
I can sympathise, however, this has been posted in October 2016. It has been at least 10 months that this problem is known. This bug prevents standard mesh functionality from being utilised. If nothign else, could we at least get as much as a status update on this?
This is intentional. To enable texture transparency, change the mesh transparency value to at least 0.001.
Can I ask why this is intentional? It doesn’t seem very useful, and making the MeshPart transparent makes the part have other issues with z sorting and it being, well, transparent.
Efficiency. Transparent geometry is very expensive, both to dispatch en masse on the CPU, and to render on the GPU.
What would be the officially supported way for using MeshParts with clothing? The default Shirt/Pants instances may not cover all bases (e.g. if I have an NPC with 4 arms, a Shirt will only cover two).
So the problem is render cost that inherits from transparency? Thats understandable, but why do we then need to enable transparency for the entire mesh and its geometry for the texture alpha to work? This only makes the mentioned problem worse and doesn’t make much sense to me. Needing to resort to non-obvious hacks such as making a normal part with a specialmesh + decal to enable texture transparency is also not very user-friendly. There needs to be a better solution for this.
Thats understandable, but why do we then need to enable transparency for the entire mesh and its geometry for the texture alpha to work?
This is how transparency works in 3D graphics.
Alternatives do exist (e.g. OIT), but at present they are only viable on top hardware. Ask me in 5 years.
Needing to resort to non-obvious hacks such as making a normal part with a specialmesh + decal to enable texture transparency is also not very user-friendly.
In general, realtime 3D graphics is not very user-friendly. You can’t have a 100% bulletproof abstraction that doesn’t leak the underlying implementation details.
Not really sure we’re talking about the same things, transparency sorting is not what needs to be solved here. The problem is specifically how meshparts handle transparency on textures only. Using a specialmesh with a decal lets the texture of the decal show the underlying color of the part wherever the decal texture is transparent. This is the desired behavior for meshparts as well.
I find it hard to believe that the current behavior of texture transparency on meshparts is unsolvable/can’t be changed; it already works using a specialmesh + decal with no noticeable performance loss. If it’s due to some current limitation with meshparts specifically that is understandable, but that’s not the explanation I’m getting.
I see, so it’s not really about mesh transparency, good.
The described behavior, is not a bug, though. Comparing Meshparts with SpecialMeshes is incorrect, because they were never designed to look or behave the same way.
Absence of a feature is not a bug. You might, however, want to post a feature request, so our Dev Relations team can see it.
While not a “bug” perhaps, it was allegedly (according to a staff member) a “known issue” about a year ago. Semantics, huh. Still: here’s a feature request concerning this.
Yep, same problem there: it was misunderstood to be about mesh transparency via alpha channel rather than that just being a mask for diffuse color blending.