I’m getting some flickering black frames on the bloom TOP when my input is at higher bit depths. It’s very inconsistent and hard to reproduce. What I can say is that it seems to happen more often when I’m dropping frames but I’m not 100% sure those are linked.
I’m on TD 2025.30060 on windows and have seen the issue on multiple PCs with different nvidia cards and driver versions.
Let me know if ever I can help provide more info. Thanks!
EDIT: I actually did some more digging and I found the issue. It’s possible when rendering at 16 bit to get values that are NaN from the render TOP. Then when going into the bloom TOP even if there’s just 1 pixel with a value that is NaN the whole TOP will be black which is expected, I guess it’s coming from the mip maps being blurred and added together and having a NaN value. Maybe adding a check in the shader to set NaN or INF values to 0 would be worth it (this is currently what I’m doing in a glsl TOP right before going to the bloom TOP)
Hey, can you post an example how of how those NaN values are being generated? mips shouldn’t ever generate a NaN. Ideally we can just fix the source of the NaN
Hey @malcolm,
I wasn’t super clear maybe, but the NaN values aren’t being generated in the bloom TOP but in the render TOP. I see that I’m getting NaN when the normals of my geometry are vec3(0,0,0) (which is somehow happening in my setup) and the geo is using a pbr MAT along with an environment light. The bloom TOP when generating the mips I guess is making the NaN values “spread” so the whole TOP becomes full of NaN values.
Here’s an example:
nan.toe (6.5 KB)
Cheers
Alex
Having NaN values on output from any TOP will break many downstream operations. The goal should be to avoid the NaNs at the source. We don’t check for 0-length normals since that would slow down all rendering operations for the rare case where this occurs. Can you look more at your geometry network and determine how these 0-length normals are created?
I’ll chime in that I encounter this issue as well when working with 16bit+ rendering setups. Usually it’s when I’m pulling in third party 3D models. In my experience it can be tricky to fix or sort out at the source (one would hope the Attribute SOP would recalculate normals in a way that avoids this, but it doesn’t tend to fix the NaNs.)
It happens for me most often when working with PBR materials + HDRI environment maps, rendering in 16-bit and then doing a linear to gamma conversion. Often times the NaN values are a few scattered pixels, so a rough solution can be to convert to 8-bit before the Bloom TOP, though this only works if the final output doesn’t need to be 16-bit+, and when it doesn’t make a noticeable difference in the resulting image.
Next time I find an example of this I’ll see if I can document and share (if that would be useful.)
Ah good idea. You should be able to use 16-fixed to be preserve your precision (at least within the 0-1 range), rather than 8-bit.
I’ll add an RFE to the Math TOP to allow cleaning up NaN/Inf pixels, while leaving the other pixels in their original 16-bit float values.
1 Like