 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been experimenting with the file Spiral_poly8.
At first I tried different values for C in the poly 8. The mathematical
derivation gives a zero, but then there is a line along the y-axis visible.
In the past I had to put a very small value in it to prevent sudden
system break downs. That's not the case anymore, but a bit bigger
value, such as 0.0001, makes the central line disappear. In fact
there is a growing cilinder along the y-axis, if C gets bigger, that
wipe out any surface there. You can see that if you choose the
Minor_X_Radius almost as big as the Major_Radius.
If you choose the Minor_X_Radius greater then the Major_Radius,
it still renders, but values smaller then zero are not possible, so
there are no intersecting surfaces.
To see the form of the spiral I toke a look from a greater distance,
but to see it better I narrowed the angle of view. Le_Forgeron was
speaking of noice in its picture with the poly16 file. I wonder
if this is the same effect. If rendered with three different viewing
angles and adjusted the z-distance to compensate for the greater
pictures, because it actually acts like zooming in if you lower the
viewing angle of the camera. You can see the results in the
pictures. At 'normal' distance nothing to see, but the further
away you go, the more noise there is. I'm puzzled here. How
can this influence the poly-solver, for obviously it does.
Maybe this helps finding a solution for the noise.
Jaap Frank
Post a reply to this message
Attachments:
Download 'spiral_poly8_angle 5.png' (285 KB)
Download 'spiral_poly8_angle 15.png' (142 KB)
Download 'spiral_poly8_angle 45.png' (157 KB)
Download 'us-ascii' (12 KB)
Preview of image 'spiral_poly8_angle 5.png'
Preview of image 'spiral_poly8_angle 15.png'
Preview of image 'spiral_poly8_angle 45.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/12/2010 02:56, Jaap Frank nous fit lire :
>
> Maybe this helps finding a solution for the noise.
Holy cows!
I tried again my 16th order (7 holes torus) with an orthographic camera.
Simply changing the position of the camera (removing the "/6") changes
the image to a cloud of points. The cloud is trendy and currently
advertised by a big firm, but that's no use here for us.
That does not give me a clue about the issue in the solver, maybe
someone with more insight on the subject could help.
Post a reply to this message
Attachments:
Download 'aa6.png' (28 KB)
Download 'aa.pov.txt' (7 KB)
Preview of image 'aa6.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>"Le_Forgeron" schreef in bericht news:4d0ef88b@news.povray.org...
>That does not give me a clue about the issue in the solver, maybe
>someone with more insight on the subject could help.
If thougt about it and got the following reasoning:
As I remember, the ray direction is subsituted in the equation.
We get noise if the distance gets bigger, so bigger values make
the solver get astray.
The distance vector can be normalised without changing its
meaning, so will it help to normalize the direction vector first
or is that already done.
I can't remember if the position vector is substituted as well,
but normalizing that vector will change his meaning and I
can't think of a reason to substitute that. But who am I :-)
Is it possible that you sent me the newest poly.c and possible
your binary of Pov, so I can study the solver again and can
experiment with the poly16. I'm recently retired from work and
have plenty of time now to crunch main brain about it ;-)
Do you have a clue for me about the mathematics of the solver?
I will search the internet as well, for thirteen years ago or now
makes a very big difference.
Jaap
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 20/12/2010 18:02, Jaap Frank nous fit lire :
>> "Le_Forgeron" schreef in bericht news:4d0ef88b@news.povray.org...
>> That does not give me a clue about the issue in the solver, maybe
>> someone with more insight on the subject could help.
>
> If thougt about it and got the following reasoning:
> As I remember, the ray direction is subsituted in the equation.
All happen in Poly::intersect().
Well, the start & direction of the ray is substituted in the equation.
From x,y,z and the polynomial of order N in x,y,z we get to a polynomial
of same (or less) order in t with x = S.x+D.x*t (and so on for y & z; S
begin the start of the ray, D it's direction).
Then the solver is called, and it stacks the result in the Depth stack.
> We get noise if the distance gets bigger, so bigger values make the
> solver get astray.
> The distance vector can be normalised without changing its meaning, so
> will it help to normalize the direction vector first
> or is that already done. I can't remember if the position vector is
> substituted as well, but normalizing that vector will change his meaning
> and I
> can't think of a reason to substitute that. But who am I :-)
The normalisation of Direction is done in Poly::All_Intersections()
(which then call Poly::intersect())
When the stack of t is got back, t smaller than DEPTH_TOLERANCE are
rejected (1.0e-4 in polynom space, from start of ray, to avoid ).
t[k] is also searched in the list of t from start to k-1, to avoid
duplicate root.
When t[k] is ok, the point is converted back into scene-space to check
against the clipping object. If still ok, the t[k] (and its point in
scene space) is pushed on the actual stack of intersection (removing the
normalisation of the direction by using t[k]/len, len being the original
length of the direction vector).
>
> Is it possible that you sent me the newest poly.c and possible
> your binary of Pov, so I can study the solver again and can experiment
> with the poly16. I'm recently retired from work and
> have plenty of time now to crunch main brain about it ;-)
My binary is for linux/ubuntu amd64, would it work for you ?
There is more than just poly.cpp impacted, hopefully it should appears
soon (or would a diff/patch file be ok for you ?).
>
> Do you have a clue for me about the mathematics of the solver?
It's all in math/polysolv.cpp... but even the 3 FUDGE_FACTOR seem magic
to me.
If the coefficient of lowest power (as updated by the transformation in
t) is less than ROOT_TOLERANCE (1.0e-4), the order is reduced by 1.
(because t = 0 is obvious solution in any ( t.(anything)=0 )
I wonder if it would not be better to iterate that order reduction in a
loop instead of doing it once only.
Then (polysolve): the order of coefficient is reversed and each one is
divided by the top. (so last one of the new sequence is 1, if I'm right;
constant is first, highest power is last now)
Black magic about the sturm... and then bisection is used to find the
roots (might be recursive).
If one root only, try using regula_falsa method, or if it fails:
For far points, if the interval divided by its medium value to bisect
would be smaller than RELERROR, the root is set to the medium value.
For near points, if the interval would be smaller than RELERROR in size,
the root is set to the medium value.
(RELERROR is 1.0e-12)
Regula_falsa (when 1 root to find only):
evaluate the polynomial at each end.
if both ends of same sign, failure.
if one ends small enough (less than SMALL_ENOUGH : 1.0e-10), select that
end has ok.
otherwise iterate: compute x as the linear interpolation between both
ends (assuming the curve is a straigth line) and evaluate polynomial at x.
if value is far from 0 (> RELERROR), x far enough
and value/x < RELERROR, x is the root. (huh ???)
If value is near 0 (<RELERROR), x is the root.
otherwise, replace the end that has the same sign value of x for its
value with x (and divide the value of the other end by 2 in some/most
case ( ??? why ??? it seems that it happens when two consecutives ends
reduction occurs on the same side, probably meaning the influence of the
other (fixed) end is too much))
if the new interval to consider is small enough (<RELERROR), exit loop
(x is the root anyway (it's the fresh end)
In the sturm magic: it seems to compute the coefficient of the
derivative (dropping the constant term, adjusting each coefficient by
it's power/max order;
so 1 + x + x^2 +x^3 gives 1/3 + 2.x/3 + 3.x^2/3
Then it's boggling my mind, because it goes down one more level (and
repeat) by computing the modulus the first equations by the second (its
derivative), removing neo-coefficient smaller than SMALL_ENOUGH
(1.0e-10) in the process when they are on the high power side.
And before computing the next modulus (derivative by first modulus), it
reverse the sign and normalise the highest power (so it's -1).
On the last stage (where the result is only a constant), the coefficient
is only reversed.
Using the array of (sturm) equations, it computes the number of roots
between +infinity & 0.
numchanges & visible_roots seems to be doing the same kind of jobs,
with +infinity replaced by MAX_DISTANCE (1.0e7)
> I will search the internet as well, for thirteen years ago or now makes
> a very big difference.
I would question the choice made to get the far points. (line 530+ of
polysolv.cpp) (interval/mean < RELERROR ?)
>
> Jaap
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>"Le_Forgeron" schreef in bericht news:4d0fba5a@news.povray.org...
.....
>All happen in Poly::intersect().
>Well, the start & direction of the ray is substituted in the equation.
>From x,y,z and the polynomial of order N in x,y,z we get to a polynomial
>of same (or less) order in t with x = S.x+D.x*t (and so on for y & z; S
>begin the start of the ray, D it's direction).
>
>Then the solver is called, and it stacks the result in the Depth stack.
>
>> We get noise if the distance gets bigger, so bigger values make the
>> solver get astray.
>> The distance vector can be normalised without changing its meaning, so
>> will it help to normalize the direction vector first
>> or is that already done. I can't remember if the position vector is
>> substituted as well, but normalizing that vector will change his meaning
>> and I can't think of a reason to substitute that. But who am I :-)
Silly me, in 2D you search for instance the intersection of a line and a
circle. In 3D it's of course x = S.x+D.x*t (and with y and z in it) with the
polynomial. The t eventually will give the distance from the source
and in this case the camera. In the processing of this three separated
substitutions I noticed that there are crossterms between x,y and z
involved, so at the moment I think that one t-value will be the result
and that this t-value can be used for x, y and z in the ray equation.
Because I have the impression that the distance from the camera to
the object is involved, I took the angle 5 camera and increased the
Major_Radius, letting everything else the same. As you can see, with
increasing object size (so decreasing distance from the camera) the
noise disappears.
So I have at the moment the following idea:
a.Put a spacious bounding box around the object, it must not touch
the object, so 110% of the normal bbox.
b. Recalculate the ray with a start from the boundingbox surface
(intersection must be calculated) into the object, so temperary
delete the distance from the camera to the bounding box.
c. Do the intersection calculations and put afterwards the deleted
part back.
Is this a silly idea? Is it difficult to test this, for the pictures seem
to confirm my idea.
>The normalisation of Direction is done in Poly::All_Intersections()
>(which then call Poly::intersect())
>When the stack of t is got back, t smaller than DEPTH_TOLERANCE are
>rejected (1.0e-4 in polynom space, from start of ray, to avoid ).
....
>My binary is for linux/ubuntu amd64, would it work for you ?
>There is more than just poly.cpp impacted, hopefully it should appears
>soon (or would a diff/patch file be ok for you ?).
I use Win7 so alas, I can't use the binary.
I've downloaded the beta40 source, so for the math I have an updated
file. In polysolv.cpp in line 1609 (comments part) Enzo Enzman is
speaking of surface acne, so I think at the moment that these tollerence
factors are involved.
> >Do you have a clue for me about the mathematics of the solver?
>
>It's all in math/polysolv.cpp... but even the 3 FUDGE_FACTOR seem magic
>to me.
>
>If the coefficient of lowest power (as updated by the transformation in
>t) is less than ROOT_TOLERANCE (1.0e-4), the order is reduced by 1.
>(because t = 0 is obvious solution in any ( t.(anything)=0 )
I agree with you about that and further will a value for t = 0 put the
camera
on top of the surface of the object (or visa versa). I think that ruling
out that solution can in individual cases be wrong, but it's only a very
short
distance.
>I wonder if it would not be better to iterate that order reduction in a
>loop instead of doing it once only.
....
>Black magic about the sturm... and then bisection is used to find the
>roots (might be recursive).
I've only studied that part briefly, because I'm not familiar with all
variable notations of C++ (I hate all that -> notations, but I must
get used to it because I've planned to learn myself C++ in my
retirement).
What comes into my mind is the Newton-Raphson method in
finding a root. That uses the tangent of a point to find a intersection
closer to the root. If sturm is a recursive algorithm, then it maybe
an adapted Newton-Raphson . I will look into that, for I'm curious
how that works.
>If one root only, try using regula_falsa method, or if it fails:
....
>
>In the sturm magic: it seems to compute the coefficient of the
>derivative (dropping the constant term, adjusting each coefficient by
>it's power/max order;
>so 1 + x + x^2 +x^3 gives 1/3 + 2.x/3 + 3.x^2/3
>
>Then it's boggling my mind, because it goes down one more level (and
>repeat) by computing the modulus the first equations by the second (its
>derivative), removing neo-coefficient smaller than SMALL_ENOUGH
>(1.0e-10) in the process when they are on the high power side.
It's the function modp that reminds me of the Newton-Raphson algorithm.
In the comment it says it devides the function by the derivation and take
the modulus. In N-R you do the same, but no modulus. In fact I can't find
a modulus calculation, but maybe it's hidden in the algorithm.
>And before computing the next modulus (derivative by first modulus), it
....
I thank you for sharing your thoughts with me. It will be a great help.
I've still a lot to study.
Jaap
Post a reply to this message
Attachments:
Download 'spiral_poly8_angle 5_r1.png' (285 KB)
Download 'spiral_poly8_angle 5_r2.png' (217 KB)
Download 'spiral_poly8_angle 5_r4.png' (124 KB)
Download 'spiral_poly8_angle 5_r8.png' (62 KB)
Download 'spiral_poly8_angle 5_r16.png' (47 KB)
Preview of image 'spiral_poly8_angle 5_r1.png'
Preview of image 'spiral_poly8_angle 5_r2.png'
Preview of image 'spiral_poly8_angle 5_r4.png'
Preview of image 'spiral_poly8_angle 5_r8.png'
Preview of image 'spiral_poly8_angle 5_r16.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 21/12/2010 19:54, Jaap Frank nous fit lire :
> I use Win7 so alas,
So go get beta 41 and you will have the new range & syntax too.
It's Xmas time! Thanks Chris!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>"Le_Forgeron" schreef in bericht news:4d112a85$1@news.povray.org...
>
>Le 21/12/2010 19:54, Jaap Frank nous fit lire :
> I use Win7 so alas,
>
>So go get beta 41 and you will have the new range & syntax too.
>It's Xmas time! Thanks Chris!
Thank you, merci Le_Forgeron.
Marvelous, merveilleux.
Merry Christmas, Bon Noël.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/21/2010 06:30 PM, Le_Forgeron wrote:
> Le 21/12/2010 19:54, Jaap Frank nous fit lire :
>> I use Win7 so alas,
>
> So go get beta 41 and you will have the new range & syntax too.
> It's Xmas time! Thanks Chris!
Yes and thanks Jérôme for helping me get the doc entry fixed up ... I've
had a very scattered day and your assist was just what was needed ...
Happy Holidays to you and yours
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
