>"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'