non-square voxel sizes
Posted 17 May 2012 - 06:30 AM
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.
Posted 17 May 2012 - 07:15 AM
(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.
Posted 17 May 2012 - 08:32 AM
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.
Posted 03 June 2012 - 06:35 PM
<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.
Posted 03 June 2012 - 07:21 PM
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.
Posted 03 June 2012 - 08:21 PM
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.
Posted 03 June 2012 - 08:54 PM
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.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users