Rendering fixes (January 2016)

Updates Announcements
#48

For rendering, just use Motors (Motor1D/Motor6D) and not Welds. Updating C0/C1 for Welds is still expensive and will probably stay that way.

I don’t think there are any real caveats for replication. If we expose the CFrame of the motor the replication may get more efficient but I’m not entirely sure about that - we optimize angle replication for motors only in the physics channel, and property updates don’t go through that.

Now C0/C1 updates for motors just update the internal cframe data pretty much, and then rendering treats the parts as independently moving - so having a motor that connects two moving parts is same cost for rendering as two independently cframed parts (probably this is more efficient than just cframing parts for other parts of the system).

1 Like
#49

Before this update on some dual-GPU setups (integrated GPU + dedicated GPU) we’d pick an integrated one.

I think this was a problem for all Optimus/PowerXpress setups but not for other (older?) systems so if you have a laptop with integrated+dedicated GPU it may have been working fine. I know some people had this issue and had to force the dedicated GPU in NVidia control panel after every release to work around that.

1 Like
#50

“(probably this is more efficient than just cframing parts for other parts of the system).”

I currently CFrame my joints and anchor the parts they use. Are you saying this is less efficient after the update, before the update? more efficient? I’m curious to see if I’m doing something on my own end or what, because I tested this summer my anchored system in an FPS and had 32 players each with 47 part sniper rifles.

I could run it at 60fps even on mobile, whereas with motors I couldn’t even get 60 on my beast PC.

#51

Were you cframing all parts every frame? I’d think motors should be more efficient in this case but maybe I’m wrong. Rendering-wise there is no difference but I was assuming that physics update for motors would be faster than Lua code updating all the parts.

If you have an example where you use a bunch of motors instead and it’s noticeably slower than cframing we can take a look.

#52

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?

#53

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?

6 Likes
Particles are drawn above/under decals based on camera angle instead of physical position
Decals visible behind other decals
#54

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.

3 Likes
#55

This unfortunately is not a factor in the issue

1 Like
#56

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
#57

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.

8 Likes
Decals visible behind other decals
Particles are drawn above/under decals based on camera angle instead of physical position
#58

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:

Pasted image1267×789 248 KB

Bounding boxes so you can see the geometry:

Pasted image871×669 89.5 KB

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:

Pasted image852×630 39.8 KB

2 Likes
#59

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

1 Like
#60

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
#61

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.

3 Likes
#62

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
#63

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
#64

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.

683×600 270 KB

1 Like
#65

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?

#66

Why not use triangles?

1 Like
#67

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

1 Like