7 replies to this topic

[Mitch Deoudes]

So as it's been explained to me:  Houdini supports non-cubical voxels. In fact, its volumes are stored as a unit cube at the lowest level which is then scaled up to the correct dimensions. Due to the floating point scaling the world space voxel size often ends up not quite cubical even when this has been specified in a Houdini node (e.g. specifying a Div Size in Volume Resize).

I've found that (for instance), with a fluid Division Size of 0.3, I get voxel sizes like this:  (0.299988 0.3 0.299999). For reasons I have no power to affect, this causes a problem for the proprietary software here, which expects voxels to be square to the sixth decimal place.  Obviously, the problem is worse when resizing the fluid on every frame - but it seems to be a problem even if I lock the size, and just translate it.

Is there any way to force houdini to stick to absolutely square voxels - even as a post process that introduces some inaccuracy?  I've tried Volume Resample at the SOP level, but it seems to assume that 0.299988 is "close enough", and doesn't actually change anything.

[Macha]

What happens when you create a new volume of static and known size (something that divides nicely) and then volumemerge your old one?


(BTW, your proprietary software seems very iffy about perfect cube voxels. I just happened to do some reading up of CFD and it seems that it is possible to use all kinds of fancy sizes for your grid elements!)

Edited by Macha, 17 May 2012 - 07:15 AM.

[Mitch Deoudes]

Macha, on 17 May 2012 - 07:15 AM, said:

What happens when you create a new volume of static and known size (something that divides nicely) and then volumemerge your old one?

Thanks for the idea.  It seems that just setting the "Center" on the new volume is enough to cause the inaccuracy.  (So a static volume, with size set to an exact value based on fluid division size * resolution, if moved from the origin shows non-square voxels.)

Though I am relying on our proprietary software to get the voxel sizes - I don't know if it's calculating them itself from resolution & bounds, or asking houdini for them.  I'm not aware of how to get that info from Houdini itself.  Either way, it sounds like Houdini is doing some rounding somewhere under the hood.

[hamburger]

http://en.wikipedia....i/IEEE_754-2008

Edited by hamburger, 01 June 2012 - 07:39 PM.

[edward]

hamburger, on 01 June 2012 - 07:08 PM, said:

http://en.wikipedia....i/IEEE_754-2008

<sigh> I wish more people read What Every Computer Scientist Should Know About Floating-Point Arithmetic ... Sometimes, I think there should be a "What Every CG Artist Should Know About Floating-Point Arithmetic" as well.

PS. Is this H12 or H11? In H12, all parameters/channels have moved to double precision.

[Mitch Deoudes]

Not sure exactly what the last two posts are trying to imply, if anything (particularly the odd & now-edited comment about which software was "lying").

To be clear, though:  I understand floating-point error.  And though I won't try and calculate the expected precision, since I don't know exactly what transforms are going on under the hood...  what I am saying is that I'm surprised there are discrepancies in the fifth (or fourth, in some cases) decimal place, given that a float has something like 7 (?) significant digits and a double more than that.

My original post was asking for a way to force the discrepancy to be rounded away in houdini, possibly as a post-process by resizing the volume.  In the meantime, our dev guys have done essentially that in our in-house software by choosing one axis to call "accurate", so problem solved for now.

[edward]

Mitch Deoudes, on 03 June 2012 - 07:21 PM, said:

what I am saying is that I'm surprised there are discrepancies in the fifth (or fourth, in some cases) decimal place, given that a float has something like 7 (?) significant digits and a double more than that.

Personally, I don't find it surprising for single precision rounding errors. I think you're also confusing "precision" with "representation". 0.3 is not representable as a base-2 floating point number. The only reason you "see" 0.3 at all are due to artifacts between keeping what you typed as a string in the UI and due to rounding when converting from base-2 back to base-10 (text) representations.

My comment was more of a general rant as I quite frequently run into issues due to misunderstanding of how floating point numbers work in computers.

[Mitch Deoudes]

According to a randomly chosen online 10-to-2 (and back) calculator, 0.3 becomes 3.00000011920928955078125E-1 in single precision float.  I'd be curious what the subsequent chain of operations is that causes the error to creep up several places - but unfortunately, my knowledge of houdini's internal handling of volumes isn't that deep.  (I'd think that this sort of thing would pop up more often - particularly in rendering, for instance - if just a scale+translate was enough to push the limits of the underlying representation.)  Or maybe other stuff is handled as doubles, and this just got overlooked.

Then again, I'm not writing software for a living, so I'm not paying attention to this stuff regularly.  Perhaps I have willfully blinded myself to glaring inconsistencies in nearly every aspect of daily life, in order to not be constantly freaking out.  I pity those poor souls in development who don't have the same luxury.