Unpatched rendering bugs related to NaN or Infinite values

Note: NaN is equivalent to 0/0, and inf functions interchangeably to NaN.

If any component of a DataModelMesh’s Offset property is NaN then the rendering cluster the part is in that the Mesh is parented to will stop rendering completely. Something similar to this was possible years ago with BaseParts but was “fixed” when Roblox began to normalize the CFrame property of BaseParts. It’s actually still possible on the client, I have a sample of it actually but I haven’t been able to isolate it from my project and keep it working.

Similar things are also possible with the CurrentCamera and Atmosphere instances (independent from one another in this case), except their respective faultiness causes the entire workspace to stop rendering. This is possible by setting the HeadScale of the CurrentCamera to NaN, or the Density of a Atmosphere in Lighting to NaN, also requires a Sky instance in Lighting.

I’ve provided examples & code samples for all of these cases below:

  • SpecialMesh:

Code: local a = Instance.new('Part',workspace) a.Transparency = .5 a.Anchored = true local m = Instance.new('SpecialMesh', a) m.Offset = Vector3.zero / 0
Video:

  • CurrentCamera:

Code: workspace.CurrentCamera.HeadScale = 0/0
Video:

  • Atmosphere:

Code: Instance.new('Atmosphere', game.Lighting).Density = 0/0 Instance.new('Sky',game.Lighting)
Video:

1 Like

Hi Vixienshy,

Thank you for pointing out these edge cases.
Although this is funky, wrong behavior, we probably won’t be able to prioritize it enough to fix it since it doesn’t seem part of any real workflow.
Nonetheless, this is great feedback so that we can better “bulletproof” future features to avoid edge cases like this. Once again, thank you for pointing this out.
If you disagree and do think that this is part of a workflow and should be fixed, please let us know and we will reconsider :slight_smile:

Best,
M0bsterLobster

Sorry for the long wait,

I am aware that some of these are too obscure to happen in a normal game developer’s workflow.
However, the NaN bug that I mentioned that works on BaseParts is one that can, it was an issue that The Strongest Battlegrounds’ debris system has had for a very long time (it no longer does). If it happens to most developers, they’ll be stuck scratching their head because they likely won’t know what’s wrong until they pick a random part, look at its properties, and then search it up online.

Here’s a video of it happening in The Strongest Battlegrounds:

The NaN bug for SpecialMeshes is also an issue, you can pass NaN into a SpecialMesh’s offset property in F3X Building Tools to derender parts of the map on all clients. While this is mostly their fault for not checking for NaN values as stated in the Roblox documentation it would never have been a problem if NaN values didn’t mess up rendering.

Here’s a video of me weaponizing NaN SpecialMeshes to make a chunk of this house stop rendering with F3X Building Tools:

Hi Vixienshy,

Thanks for following up. I understand that this could happen to many developers, but we haven’t gotten many reports about it. As such, it’s really difficult to prioritize edge case bugs like these. We will reprioritize this bug if it continues to be brought up. Thank you nonetheless for the thorough report!

Best,
M0bsterLobster

1 Like

Although not high priority I guess it could help if attempting to set to NaN it warns in the output similar to where setting invalid types on certain properties now warns. It can still go through (no issue for people already doing it) but easy to spot and fix :slightly_smiling_face:

1 Like

Yeah well its happening to me so can you please fix it?