Rendering fixes (January 2016)

I could set up a test environment for you. I think the reason it ran so fast for me is because Anchored parts don’t require as much effort from the physics engine, right?

This kills me :\

There’s a transparent part in the far distance with a decal on it which is overlapping a transparent part in the foreground with a decal on it. Does anyone know any kind of solution?


If I had to guess the transparent part in the foreground is actually a giant part that envelops your entire world. You should split your part into smaller parts. Somebody should write a wiki article about this :slightly_smiling:

Basically ROBLOX sorts transparent objects based on their centers. If you have a giant object its center is who-knows-where and sorting results usually make no sense. Splitting an object into smaller objects - like think of splitting a sphere into several pie-slices - makes each center correspond to geometry location better and usually fixes the sorting.


This unfortunately is not a factor in the issue

1 Like

I have a laptop with both an integrated GPU and a NVidea GeForce series thing.
ROBLOX has always ran on the GPU for me, both W8.1 and W10.
(I might had to set my GPU settings to “Use NVidea as preferred”, not sure)

1 Like

Something like this is happening in your gif:

Due to the angle of the camera, the center of the semi transparent part in the background is closer to the plane on which the camera lies, so it gets sorted before the center of the transparent foliage part.


With the recent update to tone shifting:
If outlines are off, roads cframed into each other no longer experience z-fighting /flicker. THIS IS GREAT, (but look past these 2 images)

Z-fighting on roads/walls stopped while outlines are off:

Bounding boxes so you can see the geometry:

If outlines are off, but your graphics are low, tone shifting comes back. THIS IS WEIRD. We asked for the ability for tone shifting to be toggled off, and we got it, but it still comes back?

Normal graphics: (smooth curved roads everywhere)

Low graphics (z-fighting rears its ugly head again!):

Low graphics and same location as above:


Neat find. I think z fighting does occur you just can’t see it because they’re the exact same color.

1 Like

Z-fighting is the describing word for that flicker, so it actually doesn’t occur. “Occupying the same space” is instead used for that glorious smooth road, and “z-fighting” isn’t used to describe it. :smiley:

I hope @zeuxcg / @ConvexRumbler / @ConvexRumbler1 see this! (What’s up with the 1 in some names, why do the clones still exist lol)

1 Like

This is not tone shifting, this is per-vertex specular AFAICS.

Basically on low quality we compute specular per-vertex using the vertex normal and the vector between the camera position and the vertex position and interpolate the result. On high quality we interpolate the normal/position and then compute the precise view vector & specular.

In this case specular values are different between different parts on low quality so you get “tone shifting” (which is not tone shifting, but just a shading artefact - hey, it’s low quality after all!)

And yeah, z-fighting still happens in high-quality, you just can’t see it since the pixels from different parts have the exact same color.


Aw, man, it had me fooled. Have any ideas on how to get rid of the artifacts on curved roads?

Ideas I’ve used so far:

  1. CSG - but on mobile, sections often becomes invisible because of slow load times (and of course some csg errors)
  2. Deviating each piece’s y position value between 0.001 to 0.1 until they look good from 30 studs away online (very time consuming and ruins neat + clean placement)
  3. Inserting a mesh in each piece and changing its y scale, similar to option 2
  4. Just hope most people use high graphics for the updated interpolation we see now. (May just use this! It’s still great.)
1 Like

Do you mean artifacts due to z-fighting? I had an idea some time ago that we never tested to randomly apply a z-offset to all parts in hopes that it’d fix z-fighting on intersecting parts…

In terms of workarounds, CSG seems like the cleanest option.

1 Like

CSG unions can be invisible for a while if your connection isn’t great though. Trying to get a screenshot of it on my phone. Edit: Couldn’t capture the invisible ones. The map filled with unions does lag my phone to super slow-mo physics though.

I think the mesh scale trick might be better than unions, but I think I’ll stick with option 4 now that high graphics + no outlines + smoothplastic = no flicker.

Edit: Don’t want to spam with new replies: Just comparing SmoothPlastic (left side) vs Plastic (right side) and you can see SmoothPlastic being seamless with this update, while Plastic (along with other materials) have seams/flickers still.

1 Like

Off topic but - at RDCW I heard that CSG was getting a complete recode. Is there an ETA on that or is it planned anytime soon?

Why not use triangles?

1 Like

I always get weird glossy marks on unions, similar to how this looks. :confused:

1 Like

That is an ongoing Studio project. No ETA.

1 Like

Ah. Well at least you guys haven’t quit, so there’s hope :smiley:

How are you going about it this time?

If I had to program CSG, I’d probably approach it with convex meshes made out of planes, then just compute the minimal-triangle model from the given convex meshes each time I perform an operation on them. There’s probably a lot I’m not thinking about.

i have no idea of what is going on in there
this is basically a CSG piece with decals all around it, 0 transparency both on the decal and on the helmet model
as you can see something is happening with the light at the top, also here is a picture of how the shadows go trough the helmet, if you lower the graphics where shadows dont show anymore this doesnt happend.
10 quality

9 quality

also one last thing, decals detach from the brick that is moving if its tweening and the server is slow.
(the stripe on my helmet stays still when the helmet moves sometimes, then it just teleports on the helmet after its done tweening)