ZIndex for 3D part render priority

[EchoReaper]

Something like this looks awesome:

Then you aim downwards (while standing up) and oops part of the barrel disappears:

While crouched:

Or maybe you back into a wall:

So what can we do to fix it? Well, we could make the parts really small (for example, the arms could be size <0.2,0.4,0.2> and we could move them really close to the camera and because they were really close to the camera they’d appear normal size. Because they were so small and close to the camera, they’d also render over objects like that wall and floor. However, this does not work on ROBLOX, because if you move the camera too close this happens:

people have asked for solution on countless threads. For instance, there’s this thread, there’s also this thread, let’s not forget about this thread, there’s this thread, there’s this thread, and then there are likely a ton more that I couldn’t find in the search.

And even if ROBLOX does get that close-clipping fixed, there’s still the issue of animation. Have your gun move the magazine 2 studs down? The gun’s really close now, and the mag is really small, so if you made the gun 20x smaller, the magazine is going to move 20x more than it was supposed to. This means that making the gun smaller is not a desirable option.

In games like BF3 developed by professional studios, this does not happen (I’m so close to the plant that my camera is clipping through it, but the gun isn’t bisected by the plant at all):

So how do they do it? I assume they have a sort of ZIndex but for 3D models. We should be able to do something similar so our weapons/arms/torso/etc don’t clip through the environment in first person.

[SnakeWorl (Droopy440)]

I could’ve sworn they already made something for this I just can’t remember the name…

[pa00]

Something like an AlwaysOnTop bool (like in billboardguis) would be super cool for models.

[ROBLOX_MANNN]

Something like an AlwaysOnTop bool (like in billboardguis) would be super cool for models.

That wouldn’t necessarily solve the problem, because some of the parts you want in a certain order would also not necessarily be in the right order of rendering.

@OP; This is a good idea, and I was thinking of suggesting something similar too, but the problem with ZIndex for this in particular is that there is still a 3D aspect to the parts, and having parts with a higher ZIndex (assuming it works like GUI ZIndex) would make some parts render over others in unexpected ways. It is hard to explain,

Basically I think a better solution is having workspace be instanciable (with a minimum of 1 workspace) and have those have a property “ZIndex” to tell the computer which workspace you want to render first.

This would also kill other birds with 1 stone, like for instance [workspace:FindPartOnRayWithIgnoreList] can be easier to use, because you can simply store the objects you don’t want to account for into the other workspace (which can save resources).

Yes this would be a major re-work of how ROBLOX development works, but I don’t think it would break past games/scripts

[woot3 (Woot)]

ZIndex would definitely be useful. It should work in conjunction with GUIs for sure, that way we could display 3D objects in them easily too.

[zeuxcg]

FPS games have explicit Z layering. The common implementation is e.g.

• Render scene
• Clear depth
• Render gun

Some games do more complicated processing to avoid the extra clear. It’s always FPS specific and really really really painful.

Some games change the output depth and then have to go through crazy hoops to support certain styles of shading - e.g. since your depth buffer data is not convertible to the position of the pixel any more without knowing the type, you have to mask the gun with stencil and when you do full-screen postprocessing - for ROBLOX this would apply to SSAO and water reflections - you use one of the two camera parameters to reconstruct the depth.

Unfortunately, GPUs don’t have a good way to do this. We can’t really implement this in a general way because of this - most games that do this have literally 2 values for “ZIndex” and one of them is always the gun and there may be additional content restrictions e.g. for transparent objects.

[EchoReaper]

I guess I’ll just have to wait for that close camera clipping to be fixed and make separate animations for the first-person models.

[woot3 (Woot)]

Would it not be possible to add a container for 3D gui based objects instead? Transparency could be ignored for stage one and the container could have it’s own ZIndex, and only the basic lighting properties (ambient) would be applied. They cameras coordinate frame would be treated as the origin.

[EchoReaper]

Oh yeah, I’d love to be able to make things like that backpack that Clone made that shows the tools in 3D instead of 2D icons without having to sacrifice ScreenGuis and use SurfaceGuis to make the rest of the GUI appear behind the tool models.

[woot3 (Woot)]

[quote] Oh yeah, I’d love to be able to make things like that backpack that Clone made that shows the tools in 3D instead of 2D icons without having to sacrifice ScreenGuis and use SurfaceGuis to make the rest of the GUI appear behind the tool models. [/quote]I figured this would also solve your issue to a certain extent.

[EchoReaper]

Well, some guns have partially-transparent parts so I couldn’t use it for the guns

[TheRings0fSaturn (SaturianNightmare)]

It’s been almost four years since this thread was created, however, I’m curious if this feature could become a reality this year or next year.

Z-Index for parts would be so helpful in allowing for things like super small skyboxes that would render behind everything else while also being constantly set to the camera’s current position, or having first person view models.

Even with the creation of ViewportFrames, their usecase is very limited due to the lack of proper 3D rendering, lighting, and outlines that plague anything within them.

I think this is a feature that could be quite useful in Roblox’s current landscape.

[WhitexHat (endriu)]

I agree. Still looking forward this.

[Riptcage]

yes please! we need this feature. 100%