Flickering Colors When Using Vex

   300   5   0
User Avatar
Member
68 posts
Joined: Aug. 2015
Offline
Hello SideFX,

I just submitted a RFE which appears to be a bug when trying to use conditional statements in vex to assign a color. This color is going onto a deforming bounding box, and it is based on the normals of the object.

Here is a video describing the issue:
https://vimeo.com/1147066452/90951ee99a [vimeo.com]


Any and all are insights are much appreciated.
Thank you ahead of time!

- Tyler
User Avatar
Staff
5285 posts
Joined: July 2005
Offline
You may want to try comparing with tolerances -- eg.
if(a==0.0) --> if(abs(a) < 1e-6)  
if(a==1.0) --> if(abs(a-1.0) < 1e-6)
Edited by malexander - Dec. 16, 2025 14:00:40
User Avatar
Member
5100 posts
Joined: Feb. 2012
Offline
Hi Tyler,

The issue is float equality. Normals are approximate, not exact axis vectors. On some frames the components evaluate to values like 0.9999999403953552 rather than 1.0, so the == checks fail. You can see this by enabling full precision in the Details View.

So I would just do this:

@Cd = abs ( normalize ( @N ) );
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com] https://lnk.bio/animatrix [lnk.bio]
User Avatar
Member
68 posts
Joined: Aug. 2015
Offline
malexander
You may want to try comparing with tolerances -- eg.
if(a==0.0) --> if(abs(a) < 1e-6)  
if(a==1.0) --> if(abs(a-1.0) < 1e-6)

Okay, that worked.
float Nx = v@N.x;
float Ny = v@N.y;
float Nz = v@N.z;

float absValX = abs(Nx);
float absValY = abs(Ny);
float absValZ = abs(Nz);

if(absValY<1e-06 && absValZ<1e-06){
    v@Cd = {1,0,0};
    }
    else if(absValX<1e-06 && absValZ<1e-06){
    v@Cd = {0,1,0};
    }
    else{
    v@Cd = {0,0,1};
    }
    

Thanks malexander! It looks like the precision was off. Does this approximate precision with the Normal node have to do with the mathematical equation that generates the value? And do you know if the full precision is, by default, turned off?
Edited by tbay312 - Dec. 16, 2025 15:16:06
User Avatar
Staff
5285 posts
Joined: July 2005
Offline
The normal SOP would be taking 32b point positions and doing the calculation in 64b, then converting to the final 32b normal. The Geometry spreadsheet may be pretty-printing the value, so something like 0.9999998 would appear as 1.0. Floating point precision can be inexact, so unless you absolutely need to be checking against an exact value (often 0.0), use a fuzzy comparison with a small epsilon value. (Integers are exact, so you're fine doing exact comparisons there)
User Avatar
Member
68 posts
Joined: Aug. 2015
Offline
Thanks for the explanation. That makes sense on a technical level.

From a user experience perspective... well... I'm sure about 99% of newer Houdini users won't know what to make of it when the geo spreadsheet values shows them values that aren't the actual value by default. I suppose I'll just need to warn them about it.

Thanks again!
  • Quick Links