Forces a part to be rendered over everything else. If you have multiple of them, the one closest to the player will render over the others. This would allow creation of 3D Gui much easier, as we wouldn’t have to worry about the part clipping behind non-gui objects.
I’ve been wanting something like this for a long time actually. I love the idea of 3D guis, but it can be really impractical sometimes since the player can move the camera into/behind another part that blocks the parts being displayed.
4 Likes
A lot of other people are in need of this as well – the following thread had a ton of thanks prior to the switch: ZIndex for 3D part render priority
Not sure if AlwaysOnTop would work better than the 10 ZIndexes I suggested in the thread I linked, but AlwaysOnTop sounds a lot like what @zeuxcg mentioned in the thread, so I’d assume so.
1 Like
Sounds like your on top of things here.
Hope they take this requests seriously. It’d be super useful for so many things.
2 Likes
This would be pretty cool. I’d use it for sure.
1 Like
This also needs to have an “AlwaysAtBottom” or something so it’s lowest render priority, this is useful for tiny 3D skyboxes attached to the camera, useful for creating something in the background without causing too much lag.
2 Likes
Why not just have an Int Value which acts the same as Z-indices work for 2D GUIs? By default, parts will be set at 1, and anything higher has a higher priority. Seems to make more sense with layering parts for 3D interfaces.
Unfortunately that isn’t really possible ):
2 Likes
That’s unfortunate. Thanks for explaining why though 
1 Like
Couldn’t they just render all layers separately and paste them on top of each other?
No “render 20 parts with different ZIndex values”, just “render 5 parts”, “render another 10 parts”, “render 5 parts more” and “paste the resulting images on top of each other”.
(Where you would see the skybox, it would be have to be transparent instead)
This regular screenshot, with the mentioned ZIndexes:
Could lead to this layers being created:
Which combined gives this:
Which, after drawing over the skybox results in:
(OP paint.net skillz)
[size=11](+ useful screenshot button in studio)[/size]
They wouldn’t need to change anything to shadows, water reflection, …
(ok, water reflections might look a bit weird then, but eh, worth it)
You’re basicly saying “don’t listen to logic, render this part over this one”.
That’s all that should happen. One part being rendered over the other.
Lightning and shadows shouldn’t be changed really.
(Although an option BasePart.NoLightning would be nice)
Another example: Xray!
3 Likes
I’m no rendering expert, but zeuxcg said that wasn’t really feasible. I’m guessing there’s more to it than meets the eye.
1 Like
sigh probably.
1 Like
I don’t think they will be very keen on (probably) having to de-optimize a lot of rendering code to make this happen. 
If this is the case, couldn’t they just let the AlwaysOnTop = false parts only use it?
In other words they have to introduce exceptions in behaviour (not a generalized behaviour for all parts) and that’s never fun when you’re trying to optimize, exactly what I meant.
You pretty much only have one depth buffer to work with. You could… maybe write incorrect values to it, but that breaks some optimizations.
Is there any way to work around it?
It’s just not likely. It breaks too much of the pipeline. Of course, I’m not that involved in rendering, so someone else would have to say. From what I’ve heard from @zeuxcg, it’s probably not happening any time soon.
1 Like