 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've got a question in regard to the floating point precision. I've got a
saved amount positions and mesh2 objects, and I place these mesh2-objects
onto the positions. The length of these mesh2-objects was originally deriven
by the position itself. So I *do* unterstand that floating point precision
could lead to results in which the length of the mesh2-object differs
slightly. As I'm picking between set lengths, this difference can be quite
obvious when comparing two images, but doesn't matter that much as it won't
be used in animations (at least it's not designed for it, and this precision
problem actually makes it impossible, at least if I want to combine both
steps, generation and placement).
Anyways, what's interesting though is that the mesh2-objects get colored
according to a function which derives a color from the bozo-pattern using
the position. The colors are slightly different too! So either the objects
don't get placed at the exact same location, or at least the function comes
up with a slightly different result, even though the same pattern and
position is used.
So, my question is, can this be due to different calculations applied in
either scene? Where the first render generates all the data, the second does
less work and just includes the objects that have been written to disk.
Placing and selection is done with the same routines, which make use of lots
of dividing and such, so the precision could add up in such areas, but then
again, both use the same selection routines, they're not different.
It's slightly confusing as I don't see a reason for this to happen. It's
like POV-Ray is switching back and forth between a very low-value switch of
rounding up or done or such.
The scene (and macros) itself are far too big to post here, but I was
wondering if anyone could give some insight. Is it possible for a
calculation to differ slighty when other calculations have come before? The
technical side in me says "No, not possible" and I'm thinking that maybe the
calculations I'm doing add the precision problems to a degree where it gets
noticable when some parts are left out. I'll investigate, but any replies
appreciated!
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias nous apporta ses lumieres en ce 2005-02-03 13:08:
> I've got a question in regard to the floating point precision. I've got a
> saved amount positions and mesh2 objects, and I place these mesh2-objects
> onto the positions. The length of these mesh2-objects was originally deriven
> by the position itself. So I *do* unterstand that floating point precision
> could lead to results in which the length of the mesh2-object differs
> slightly. As I'm picking between set lengths, this difference can be quite
> obvious when comparing two images, but doesn't matter that much as it won't
> be used in animations (at least it's not designed for it, and this precision
> problem actually makes it impossible, at least if I want to combine both
> steps, generation and placement).
>
> Anyways, what's interesting though is that the mesh2-objects get colored
> according to a function which derives a color from the bozo-pattern using
> the position. The colors are slightly different too! So either the objects
> don't get placed at the exact same location, or at least the function comes
> up with a slightly different result, even though the same pattern and
> position is used.
>
> So, my question is, can this be due to different calculations applied in
> either scene? Where the first render generates all the data, the second does
> less work and just includes the objects that have been written to disk.
> Placing and selection is done with the same routines, which make use of lots
> of dividing and such, so the precision could add up in such areas, but then
> again, both use the same selection routines, they're not different.
>
> It's slightly confusing as I don't see a reason for this to happen. It's
> like POV-Ray is switching back and forth between a very low-value switch of
> rounding up or done or such.
>
> The scene (and macros) itself are far too big to post here, but I was
> wondering if anyone could give some insight. Is it possible for a
> calculation to differ slighty when other calculations have come before? The
> technical side in me says "No, not possible" and I'm thinking that maybe the
> calculations I'm doing add the precision problems to a degree where it gets
> noticable when some parts are left out. I'll investigate, but any replies
> appreciated!
>
> Regards,
> Tim
>
When you save your data to a file, you may loose some digit, truncating or choping off
the last
digits. Try adjusting the number of digit writen. When you evaluate the pigment, you
are using the
raw data from the FPU and are geting the full acuracy.
The result is that the saved data is no longer the same as it was, and is now
diverging from the
pigment.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> When you save your data to a file, you may loose some digit, truncating or
choping off the last
> digits. Try adjusting the number of digit writen. When you evaluate the
pigment, you are using the
> raw data from the FPU and are geting the full acuracy.
> The result is that the saved data is no longer the same as it was, and is
now diverging from the
> pigment.
Might be a possible clue, though the positions are already saved to disk on
both occasions, so it's not the reading of the positions. Only the
mesh2-objects get written and parsed, in the first scene they're used
directly & get written to disk, in the second only the saved ones are used.
It might be possible that the mesh2-objects then differ *slightly*, but it's
not the object that's different, rather than the selected length and it's
position. I'm thinking that I'm doing some arithmetic wrong at some point,
so that some objects get rotated away from their actual position, and it's
not the color that's changing, but the visible part is moved somewhere else
due to the wrong rotation.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, BTW: that "wrong arithmetic" is probably still due to some precision
problem, as the calculation for the rotation is 100% the same on both runs,
so the mistake should pop up in both scenes with no difference if this were
an ideal world. :-)
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So, I've done some tests and worked on the code to get rid of places where
precision was an issue, but superflous calculations could be applied later.
I've been using lots of vdot to project things onto planes, but have found
that the plane essentially always is the y-plane, so I could just multiply
the vector with <1,0,1> instead...
Anyways, I've come to a point where the error pops up much less than before.
*BUT* I've found something else, which I find a little disturbing, but
that's probably precision again...
I create a transform with only a matrix inside to rotate an object. I do
this in order to get hold of an arbitrary axis to rotate the object, then I
use the inverse matrix to re-align the object and use the usual axis' for
rotation. I've found that applying the inverse matrix and then the matrix
returned a different results that just leaving it out altogether on a few
occasions in hundreds of objects. It's a miniscule amount, but it suffices
to displace some objects very visibly.
My question: the inverse transform is probably applied to the entire
transform. Would it be feasible to implement my own macro to inverse a
matrix, or would that be wasted time?
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> My question: the inverse transform is probably applied to the entire
> transform. Would it be feasible to implement my own macro to inverse a
> matrix, or would that be wasted time?
Note to self: Wasted time. It suffices to multiply the matrix by a larger
value to have the values on a better scale (low-value calculations are
always prone to precision problems...)
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
