Volume density values in VOPs - not always right?

   4064   4   1
User Avatar
Member
65 posts
Joined: July 2005
Offline
I'm finding that, in the VOP context at least, values in Houdini's volumes aren't always what I have set them to be. By this I mean I used a Volume VOP (or a hand-coded .geo file) to store 1.0 density values everywhere in a volume and, in a later Volume VOP, I get density==1.0 failing for some voxels.

The problem seems to crop up consistently on the -X, -Y, -Z sides of the volume bounds, although I've occasionally had it show up in seemingly random spots near the middle of the volume too (couldn't reproduce this for a simple attachment).

Ok, the workaround (round the density to the closest integer value) is easy, so this isn't a show-stopper … but it's really weird and annoying to have to worry about.

Any ideas? I'll admit I didn't spend much time RTFM before coming here


9.5.315

Attachments:
badVolumeVOP.hipnc (67.8 KB)

User Avatar
Member
65 posts
Joined: July 2005
Offline
Any thoughts? Can anyone at least reproduce this?
User Avatar
Member
606 posts
Joined: May 2007
Offline
Can repro, yes.

If you multiply the value&diff by a million before printing, you will see
that the ~7th digit differs from the exact value. My personal guess would
be that this just the “normal” floating point accuracy issue. Floating
point numbers are ill suited for storing exact values, and you should probably
test against a small epsilon value instead of absolute equality. In this case e.g. diff < 0.000001

eetu.
User Avatar
Member
65 posts
Joined: July 2005
Offline
eetu
Can repro, yes.
My personal guess would
be that this just the “normal” floating point accuracy issue. Floating
point numbers are ill suited for storing exact values, and you should probably
test against a small epsilon value instead of absolute equality. In this case e.g. diff < 0.000001
eetu.

Generally floats aren't good for specific values, but if your number can be expressed as the sum of powers of 2 (in this case I'm storing 1, which is 2^0), they _should_ be perfect.
User Avatar
Member
606 posts
Joined: May 2007
Offline
rjpieke
Generally floats aren't good for specific values, but if your number can be expressed as the sum of powers of 2 (in this case I'm storing 1, which is 2^0), they _should_ be perfect.

Ah, ok, I stand corrected

..but maybe the value sampling code has some sort of interpolation/scaling
going on? Dunno, if the volume vop is called once per cell by definition, I guess there shouldn't.. good question

eetu.
  • Quick Links