The lighting… howwww…
Post please cuz it’s beautiful. 
1 Like
Since this is still January and I’m too lazy to create another thread…
- Fog regression was fixed. Unfortunately this also reverted the fog animation fix. We’ll fix it once more in a later update!
- (hopefully) ROBLOX should now use the dedicated GPU for NVidia Optimus and AMD PowerXpress systems.
- Motor C0/C1 updates do not require rendering invalidation any more; this fixes geometry update issues and improves performance in Phantom Forces, Kart Racing and probably other games.
10 Likes
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 :\
https://i.gyazo.com/8ab3ac6b774b1cb924da49ee2dd07f7a.gif
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