I think I found a bug in Poser 6, SR2. When I enter a value for a light's intensity, Poser changes the value! The value isn't changed that much, but why is Poser changing it in the first place? See above image. I don't know if this is an existing bug in Poser 6 or if it's a bug in the new SR2. --John

Existing. This dates back to P5.

Yep...it's been around for awhile. If I want 'precise' values, I type it as "xx.0". It isn't a huge problem for me, but this habit of Poser's is an annoyance...and I don't want to think of whatever else may be getting arbitrarily changed.

Does this happen when you type in a value, or just when you set it via a dial?

The value diaplayed on paramiter dial is rounded out, this is so even in Poser 4. In P4 I think the value in the ones columb (1.) flips to the next highest digit when value after the decimal place reaches point five one (.51).

When entering critical values it's always best to type them in. (Cross post)

Message edited on: 11/12/2005 13:40

This comes from the way that Floating Point (IE numbers which contain a decimal point) numbers are held in memory. This oddity shows up in all sorts of applications, not just Poser (and here I'm talking about anything from games through the operating system itself through to financial software. Although the last have to take extra-special precautions to avoid problems..) The values which are actually saved are (probably) close enough to to the value you typed for it not to make any noticible difference to the final render (or to anything else, for that matter). Ignore it. EG: 64.99998 (from the example above) is "wrong" by about 2/100,000. Anybody render in sizes which exceed 500,000 (in any direction)?? Cheers, Diolma (and yeah, I know, there are very, very occasional times when it really does matter. In that case, enter the ".0" as pteryx suggested..)

My hunch is that when they moved the parameter dials out into a separate thread (dumb idea if ever there was one) they passed across only the internal FP representation of the number. Then when it necessarily gets converted back to real numbers you get this error. With P4 and PP the original real number is presumably still accessible, so the rounding error isn't displayed. As diolma points out the error will exist internally anyway, because the rendering engine (preview or final) will use the internal FP number. So you can safely ignore the error. But it is every annoying given that the dials are effectively broken in P5 and P6 on Windows due to that separate thread design screw-up, err, choice. It bites you when you are forced to make small changes via typing in decimal place increment changes: you end up often having to re-type the whole number, rather than just the digit you were changing. Can we start a lobby for CL/EF to put the dials back inside the main Poser thread so they can again work correctly and responsively? If they did that we could finally all drop P4?PP and stay exclusively in P6.

I'm typing in the value "65" and Poser displays the "64.9999998" number. If I turned the dial, I would expect the value to be an odd number. Yes, I know that "65.999998" is basically "65", and this isn't a "critical value"... but I typed "65", so the that's what the value shoud be! :) Who asked Poser to change my number to an 8 digit floating point value? :) --John

I find it slightly annoying, but there are many other bugs with the lights that need to be fixed first. It's only a matter of ten-thousandths, and Poser/Firefly isn't an accurate renderer so it won't affect image quality. This type of bug is acceptable, since it only annoys those of us who are anal enough to care about such things :-)

Attached Link: http://babbage.cs.qc.edu/courses/cs341/IEEE-754.html

For your computer's FPU, 65 and 64.999998 **are** the same, it's just the way floating point numbers work. Just try it, go to the web site I linked above, enter 64.999998 in the first input field and press the "rounded" button: It will return 65. Now press the "not rounded" button: It returns as 64.999992.

This is how your CPU works. It has a limited amount of precision and the very last digit usually has no significance whatsoever. (Yes I am aware of double precision floats. If you want your scene to take twice as much RAM, sure, then they are an option...)

Message edited on: 11/13/2005 11:26