When there are no moving parts, there should be no lighting updates because shadow positions are not changing. We see this properly reflected in the Roblox Studio game window, using FPS Unlocker to confirm the optimal performance.
Similarly, we should expect the same behavior if we are moving parts with CastShadow turned off, because again there should be no effective changes to shadows.
This assumption and expected behavior is absolutely critical for making any sort of game that can perform well on ShadowMap.
Bug Description:
Currently, if you move a part (physically based or property setting) with CastShadows turned off, Roblox lighting will still recompute shadows and we see massive framerate drops.
Video Demo:
Comparing the studio game window with guaranteed non-moving parts.
Moving part with CastShadows ON (Expected performance drop)
Moving part with CastShadow OFF (Same performance drop - Should not happen!)
Screenshots:
Rendering time taken for game with ZERO moving parts - Fast with no shadow recomputations
Turn on FPS Unlocker in Roblox Studio to measure rendering performance
In Roblox Studio, set a part to CastShadows false
Move the part around and observe the framerate drop (as shown in video example)
NOTE: We do this test in studio because we can never get optimal performance in live servers; our character models will always force lighting updates.
Conclusion:
If this behavior gets changed, the implications would be huge for roblox performance across the board.
We can effectively establish “baked lighting” by simply turning shadows off for all moving parts, which engines outside of Roblox heavily depend on to run great looking games.
ShadowMaps (as proven in studio running at 250~ FPS on a 10k part count map) will greatly become useable if developers are vigilant with ensuring any moving parts will not cast shadows.
Hi @litozinnamon, thanks for the clear bug report and video. The “occupancyUpdateChunkPerform” block you see is due to updates of our voxelization info when parts move. Even when using Shadowmap mode, the voxelization info is still used for our crude GI approximation (indoors/outdoors classification) as well as occupancy info which can be used by other systems. Updating a part triggers updating a chunk in the voxel grid, and changes will need to be propagated to other chunks appropriately. These updates still need to happen even with CastShadow false.
You are correct that this can be a bottleneck, and we are investigating methods to improve upon this.
Hi can you explain why this behavior doesn’t apply when the moving part has a humanoid in the parent as seen in the attached video? (Note the FPS, occupancyUpdateChunkPerform doesn’t show up in the microprofiler either.)
Seems like we can abuse this behavior and literally put humanoid objects in all our moving models just to bypass the voxel updates for better performance and have zero impact on the relevant map shadows (based on raspy’s video clip).
This leads me to believe there is some sort of special check for whether a model has a humanoid object that can bypass voxel chunk updates.
Which by extension, it should be feasible to have a some sort of tag/property check (i.e. CastShadow = false??) to ignore the voxel updates.
To me, this looks like evidence that the voxel updates are actually not necessary then??
Would really like some updates on this, especially with the new FiB3 coming out still suffering from the same performance costs as shadowmap.
Any update on this? We’ve been battling performance drops in our game for years and this thread finally explains it, since we have massive moving objects (boats, trains) and never saw significant performance improvements when disabling CastShadow.
We can’t just humanoid-ify them either since adding humanoids into a boat with complex collisions causes massive performance issues of its own… =(
