Edit: in all seriousness, thank you 
Iāve been waiting for some of these.
1 Like
Wait, was Roblox fully CPU based? I am confused.
Itās always been <3
Nope ā not true. When I upgraded to Windows 10 my graphics driver for my laptop didnāt get upgraded correctly so everything was being super slow since it was being run on the CPU and I was getting ~10 FPS on ROBLOX. After I fixed the graphics driver issue, it ran fine. If it didnāt use GPUs at all there would have been no performance difference.
Do you use an iGPU?
iGPU as in integrated GPU / on-board GPU? Yeah ā itās a laptop. Model: Acer Aspire 5750
Yes! Thank you! Can I get caveats on how the C0/C1 updates work, and if thereās anything I should to maintain performance?
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
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
ā(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.
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.
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?
6 Likes
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 
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
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.
8 Likes
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:
2 Likes
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. 
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