Erroneous bloom, blur and glowing rendering artifacts in Studio

[ShoesForClues (Shoelee)]

So I actually started to witness this bug more than a month ago, and I figured it was probably just some error within my code. However, after investigating a bit further, I believe this is actually some bug within roblox itself. I’m not sure what’s causing it, nor do I know how to fix it.

So it first started off when I realized that the “base” part from my custom character is for some reason, visible and also glowing. And I even checked the properties in explorer window and it shows that the transparency is indeed set to 1, and that I can even change all the other properties of the part with no issues.

https://dl.dropboxusercontent.com/s/uq46a8nlef16b2s/2018-09-07_22-41-43.mp4

And then I was curious to what would happen if I took that part out of the player model and placed it into workspace. Well, this happened:

https://dl.dropboxusercontent.com/s/y4eu7bze3fz0kiy/2018-09-07_23-05-50.mp4

Note, my game doesn’t have any blur/bloom effects, or any post processing effects whatsoever. And as soon as I placed that part into workspace, every non-mesh part became all blurry and started to glow as if they were neon. And every part that were suppose to be transparent/invisible just became fully opaque.

https://dl.dropboxusercontent.com/s/3581xadpiir4asn/2018-09-08_13-43-50.mp4

Someone please explain why this is happening .-.

UPDATE:

Even though explorer properties already showed that the parts were smoothplastic, qqtt991 asked what would happen if I ran the command “for i,v in pairs(workspace.CurrentCamera:GetDescendants()) do if v:IsA(“BasePart”) then v.Material = Enum.Material.Plastic end end”

This still doesn’t explain the transparency issue or why these parts are neon to begin with despite the properties still showing “SmoothPlastic” before running the command.

Additional info:
Specs:
Processor - Intel I5 m3230M
Graphics - Intel HD 4000
Memory Size - 8GB
Operating System - Windows 7 64 bit

Repro file: render_bug_repro.rbxl (1.2 MB)

[codes4breakfast (Lucas)]

I’ve had the neon effect happen to me under certain conditions too, after part instancing was released. I’m not sure why those happen, but I can confirm your issues.

[buildthomas]

Could you please attach specs, a repro file, or link to a place file that exhibits the issue?

You missed some things from Steps to Report a Bug. Please add that information to your post because the steps are mandatory.

[ShoesForClues (Shoelee)]

Yes I apologize. I added my specs along with a repro file now.

[PeZsmistic]

In the repro file you can delete everything in the map under Camera except for the yellow neon part.
Some things I’ve noticed while playing with the repro:

• Relative to 0,0,0, if there is a neon part in the same x,z quadrant as the base part, the base part will always have the neon glow. If the base part is not in the same x,z quadrant as a neon part, it will only have the neon glow if there is a neon part in the direction the camera is looking - occlusion does not seem to matter. If you’re ~100 studs away from the neon part, the neon glow will stop appearing. Y coordinate doesn’t seem to matter, so there’s only 4 quadrants instead of 8 - not totally sure yet though.
  
• The neon part must be neon to trigger the glow on the base part inside the character, however the transparency issue on the base part persists regardless of the neon part’s material.
• The base part’s material exists beneath the neon glow. changing the material of the neon part will not result in that material overlaying on the base part, only the neon glow will be erroneously rendered.
• If you make the neon part’s transparency 1, the glow effect stops, but the base part is still erroneously visible.
• Deleting the neon part does not make the base part correctly invisible.

My specs:

[ShoesForClues (Shoelee)]

…Yeah so me and qqtt991 were able to find the source of this bug.

Let’s just say that I divided by zero.

After I remembered that the script will automatically set the player’s new parent model once the base’s parent has been changed, I recalled that the script also automatically sets the LocalTransparencyModifier of every part within the model based on the player’s camera distance. And realized that the variable “camera_view_toggle_threshold” can be set to zero and thus would result into a division by zero. I didn’t think it would be a problem because I even had a clamp() function to ensure it would only range from 0 to 1.

This doesn’t mean that it’s all blamed on the code though, this still shows that there’s an internal bug with the roblox engine for when you do set the localtransparencymodifer to -nan(ind) and to also encourage clamp() to take account of -nan(ind).