Hi again,
I noticed a strange thing lately:

1. If I pick a figure from the library and pose it,  save the scene and export it.
2. Revert/Reopen the scene
3. Export it again.

There are few differences,  some vertexes appear to have moved ~ 0.00001 units. Not many  of them though, its a minority. Most of them keep their places.

I still wonder: Why is this??   When I save the scene, I expect it to load back to just what it was?

Is this a difference someone could ever note? I tried to move a figure for 0.00001 through the translation dials on the BODY actor, but I could not tell whether the figure was moving at all, even when magnifying it quite a bit. What do you think? Neglectable?

Thanks,
col

It happens because the file format is text, and the numbers are written in decimal, with a certain arbitrary number of digits. But the real numbers are in binary. The conversion to a truncated decimal representation loses some precision, and when the value is read back, it's gone.

For example, it should be familiar to all that the fraction 1/3 cannot be expressed as a finite decimal number. It is .33333333333333333333333333333333... forever. Whereas, the fraction 1/10 is precisely .1 in base 10 notation.

Similarly, in binary, the fraction 1/10 is an infinitely long number and cannot be represented accurately. It reads out as .09999999999999.... when you print it in decimal. Then if it is chopped off at .09999, you get a discrepancy of .00001, which is what you are experiencing.

Now what is .00001? Depends on your chosen Poser display unit. If that's inches, then we're talking about a discrepancy of 1/100,000 of an inch. That's pretty small and you're never going to notice.

If we're talking about a Poser Native Unit, then it's about 1/1000 of an inch.or .026 mm for our metric friends.

Whatever it's cause, the effect is extremely annoying, especially when a whole number like 5 suddenly becomes 4.999991, or something similar. I'm fairly sure that this problem never existed in P4.

Yes, that might be possible. But I wonder why the number of points showing a deviation is so small. If it was due to truncation, shouldn't there be a kind of uniform distribution of the deviations of the verts?

@les: Did you also note that effect on any occation?

Quote - Yes, that might be possible. But I wonder why the number of points showing a deviation is so small. If it was due to truncation, shouldn't there be a kind of uniform distribution of the deviations of the verts?

I would have guessed that 1/2 or 1/4 were rounded off incorrectly. I don't really know.

Conversions to/from decimal are tricky. The Python library recently introduced a new facility that finally gets it right, and it is very sophisticated. It can write floating point numbers with exactly the smallest number of decimal digits necessary to reproduce the binary representation without any lost precision.

For example, it will write .1 instead of .09999999. It will do other interesting things like (I'm making this one up) .87654321375 as .87654321 because the last three digits come out to 375 anyway due to limited precision, even if they are not written.

so they're just going to the bit bucket, then...;)