Today I encountered what seems to be an issue with Trails moving over Semi transparent parts. From certain camera angles the trail effect behaves as normal but from other angles it goes completely invisible.
This bug is more apparent when the trail is over parts with a transparency of 0.1 or lower where the trail becomes invisible.
I also noticed the dragger and transparent parts that are laying on-top of the semi transparent baseplate are also is effected by this issue.
Demonstrations of the trail issue.
Issue with parts going invisible when they are both semi transparent (0.1) from different camera angles.
0.1 Transparent baseplate with 0.5 transparent part
0.5 Transparent baseplate with 0.5 transparent part
Reproduction
Have a part with a trail effect inside it
Have another part below that’s semi transparent, say 0.1 transparency
Drag the part with the trail over the semi transparent while changing your camera angle.
The transparency issues are because it’s really difficult for the rendering engine to figure out what “order” to draw objects in. This is a hard problem in most game engines that often require tricks to hack around.
Typically a fast-and-simple way rendering engines handle this is looking at the center of something, and then using that to determine which is “closer” to the camera. But for larger objects, this leads to increasingly less accurate results.
Here’s an example, you can see the part that is drawn first changes depending on which is closer to my camera center:
This will also happen to things like beams, particles (they all stop rendering if the emitter goes off-screen) to improve performance.
Definitely annoying when you’re trying to do some specific things, but my advice would be to avoid larger parts/particles/effects if necessary in favor of smaller ones, because the engine will compute these more accurately.
I find it extremely annoying when it come to drop currency on a semi-transparent floor.
The Billboard Gui do this focus change depending of the camera angle, which is also the same for particles and Surface Gui.
So, for now the only solution to this is to make it always on top, but i don’t want it to be on top of everything, only of this semi-transparent floor, otherwise it look bad.
Roblox could maybe add a feature for it, like for Gui’s, by sellecting which things have to be always on top only of the seletect part(s) in that case.
I doubt they’ll add this since it goes into the “super special-case” territory. AlwaysOnTop renders BillboardGuis as a part of the regular Gui pass, after all scene rendering is complete. To make the engine pause, render some guis, then go back to rendering parts on top, would require completely overhauling how the engine works and likely be much less fast than it is now.
Your best bet is to not have a transparent floor. I doubt this effect is that critical to your gameplay / design. You could also try using the Reflectance property, which renders the skybox on parts and might look similar to what you want.
tl;dr - a giant transparent baseplate is pretty much the worst thing you can do for layering transparent objects, because it’s almost always on-screen but the center is very far from the edges.
Alright, i didn’t knew it was that hard for the engine to do something like this.
Otherwise, another solution would be to do frequent raycasts from camera to LookVector, to then enable/disable Always on top property depending of certain circumstance.
It was a old project, so i don’t need it for now, but yeah it’s probably better to not use transparent floor in that case, or permanently use Always On Top enabled.
The answer from @AbstractAlex in post 3 is 100% spot on. This is exactly what is happening. And indeed it isn’t ideal.
To @Crygen54’s point adding a ‘ordering’ to it would provide another work around for the issue, but to (again) @AbstractAlex’s point “I doubt they’ll add this since it goes into the “super special-case” territory.” this is exactly why we’ve tried to stay away from it for now. We did prototype it at some point and run it through some tests, but to a group of people it was confusing how it worked (more so than the current limitations).
We also looked into a bunch of other techniques, but a lot of those have issues that require deeper understanding. For example things like Order Independent Transparency (OIT), but that has certain content authoring restrictions. We’ve looked into things like proper per fragment sorting, but that only works on high end devices. We’ve thought about doing things like dynamic BSPs, again some issues about performance and scalability.
(FWIW I have forwarded this post to our product people, because there are multiple similar posts on the forum, about various transparency sorting, and if there’s enough people hitting it then it will receive higher priority to address.)