 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've ask in the Povray Bug Tracking System to raise the maxpower of the poly
object with one power to 16.
Le_Forgeron asked me for a genuine poly 16 file to test the system. It's
attached to this post.
If someone else is interested, there is a working poly 8 file too, so you
can play with a high power object.
Both files produces spirals that are build from a mathematical described
distorted Oval Torus (poly 8 and poly 16), followed by chopping up the
distorted torus in peaces that builds a spiral. No mesh or Isosurface is
used.
Jaap Frank
Post a reply to this message
Attachments:
Download 'us-ascii' (3 KB)
Download 'spiral_poly8.png' (135 KB)
Download 'us-ascii' (11 KB)
Download 'us-ascii' (36 KB)
Download 'us-ascii' (17 KB)
Preview of image 'spiral_poly8.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16/12/2010 02:14, Jaap Frank nous fit lire :
> I've ask in the Povray Bug Tracking System to raise the maxpower of the
> poly object with one power to 16.
> Le_Forgeron asked me for a genuine poly 16 file to test the system. It's
> attached to this post.
There is a syntax error on line 318. Can you fix it (just post the
corrected line) ?
/* x^6.y^2.z^4 */ ,
-12*T6*P4*R4-48*T4*P2*R2*(5*R2+A2)-40*T2*(R2-A2)*R2+3*A2)
Notice the closing parenthesis with no opening.
So far I just tried to raise the limit (easily)... but it render only a
yellow stone and black sky.
I might take more time than expected if I have to found an actual
surface. (oh, well, I might provide a new syntax as well... it's too
late for 3.7 anyway). At least your demo scene confirmed me that a lot
of values are 0.
You are right about the code of binomial(): it is dead. (the array is
used all the time, due to the parser limiting the order)
In fact it is silly computing the binomial coefficient by the absolute
formula b(k,r) = k!/((k-r)! * r!), using optimisation of factoring the
numbers in stacks and removing common parts, to avoid big numbers.
It is also silly, because it try to factor for all odd numbers instead
of just primes. What a waste of modulo computation.
It is far simpler to know that it's the pascal's triangle, with
b(k,r)=b(k-1,r-1)+b(k-1,r) when r>0 and r<k;
b(k,0)=1 as well as b(k,k)=1.
Must have been some "smart" coding of that old time.
32 bits unsigned int can store down to depth 35.
64 bits go down to depth 69.
>
> If someone else is interested, there is a working poly 8 file too, so
> you can play with a high power object.
> Both files produces spirals that are build from a mathematical described
> distorted Oval Torus (poly 8 and poly 16), followed by chopping up the
> distorted torus in peaces that builds a spiral. No mesh or Isosurface is
> used.
>
> Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>"Le_Forgeron" schreef in bericht news:4d0a5fa2@news.povray.org...
>
>Le 16/12/2010 02:14, Jaap Frank nous fit lire :
>> I've ask in the Povray Bug Tracking System to raise the maxpower of the
>> poly object with one power to 16.
> >Le_Forgeron asked me for a genuine poly 16 file to test the system. It's
> >attached to this post.
>
>There is a syntax error on line 318. Can you fix it (just post the
>corrected line) ?
>
>/* x^6.y^2.z^4 */ ,
>-12*T6*P4*R4-48*T4*P2*R2*(5*R2+A2)-40*T2*(R2-A2)*R2+3*A2)
>
>Notice the closing parenthesis with no opening.
-12*T6*P4*R4-48*T4*P2*R2*(5*R2+A2)-40*T2*(R2-A2)*(R2+3*A2)
The opening parenthesis is just before the last R2 > > > > ^
In case I forgot an other one, all the factors look alike and have a
R2 and an A2 between the parenthesis and no other variables.
A few times there is a (R4 -A4).
>So far I just tried to raise the limit (easily)... but it render only a
>yellow stone and black sky.
Did you take a look at the poly8 file? It should give the same result.
I can't guarantee that the poly 16 formula is correct, but the result
looks oke.
>I might take more time than expected if I have to found an actual
>surface. (oh, well, I might provide a new syntax as well... it's too
>late for 3.7 anyway). At least your demo scene confirmed me that a lot
>of values are 0.
>
>You are right about the code of binomial(): it is dead. (the array is
>used all the time, due to the parser limiting the order)
>In fact it is silly computing the binomial coefficient by the absolute
>formula b(k,r) = k!/((k-r)! * r!), using optimisation of factoring the
>numbers in stacks and removing common parts, to avoid big numbers.
>It is also silly, because it try to factor for all odd numbers instead
>of just primes. What a waste of modulo computation.
>
>It is far simpler to know that it's the pascal's triangle, with
>b(k,r)=b(k-1,r-1)+b(k-1,r) when r>0 and r<k;
>b(k,0)=1 as well as b(k,k)=1.
>
>Must have been some "smart" coding of that old time.
When I searched my old stuf I found a manual for POV 0.5 beta,
together with one for POV-Ray 1.0gw (27 april 1992). There were
no poly objects in those times. I think they were introduced in version 2
or maybe stil later in version 3. That would make the code at least
15 years old.
But you are right, the Triangle of Pascal is far more simpler. I always
used the triangle to show the beauty of mathematics to students who
found mathematics dull and to difficult. They were always amazed
they could write out (a+b)^7 in a few moments and sometimes began
to like mathematics a bit because of that.
I would say, keep the hard code until pow 16 and use your way to
expand it if necessary.
>
>32 bits unsigned int can store down to depth 35.
>64 bits go down to depth 69.
Is it possible that high powers gives problems with the minimum (or
maximum) values that can be used. Values of 0.001 for x,y or z are
quit normal, but raised to power 16 you already get 1E-48. It may be
the reason for limiting to maxpower 15 in the past.
If that's a problem, stick to maxpower 16 then.
Thanks for reacting to my request.
Jaap Frank
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>"Jaap Frank" schreef in bericht news:4d096803@news.povray.org...
>
>I've ask in the Povray Bug Tracking System to raise the maxpower of the
>poly
>object with one power to 16.
>Le_Forgeron asked me for a genuine poly 16 file to test the system. It's
>attached to this post.
>
>If someone else is interested, there is a working poly 8 file too, so you
>can play with a high power object.
>Both files produces spirals that are build from a mathematical described
>distorted Oval Torus (poly 8 and poly 16), followed by chopping up the
>distorted torus in peaces that builds a spiral. No mesh or Isosurface is
>used.
>
>Jaap Frank
In the poly 16 file there was one parenthesis avaporated in line 318.
In this file it is corrected, so overwrite it with this one. Le_Forgeron
is changing the allowed maxpower, so I hope we can use the file
in the future.
Jaap Frank
Post a reply to this message
Attachments:
Download 'us-ascii' (36 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16/12/2010 23:01, Jaap Frank nous fit lire :
> In the poly 16 file there was one parenthesis avaporated in line 318.
> In this file it is corrected, so overwrite it with this one. Le_Forgeron
> is changing the allowed maxpower, so I hope we can use the file
> in the future.
>
> Jaap Frank
I rendered the poly 16... part of it are noisy. I need to probably to
adjust some settings in the solver & poly code (if it can fix something
at all)
To ease the input, I'm adding a new syntax (no more ordering, you can
omit the coefficient at 0, it save a bit !)
#declare Spiral_Shape = object { polynom { 8
/* x^8 */ xyz(8,0,0): 1
/* x^6.y^2 */ xyz(6,2,0): 2*T2
/* x^6.z^2 */ xyz(6,0,2): 4
/* x^6 */ xyz(6,0,0): -2*((1-P2*T2)*R2+A2)
/* x^5.y */ xyz(5,1,0): -8*R2*Slope*T2
/* x^4.y^4 */ xyz(4,4,0): T2*T2
/* x^4.y^2.z^2 */ xyz(4,2,2): 6*T2
/* x^4.y^2 */ xyz(4,2,0): 2*T2*((1-P2*T2)*R2-A2)
/* x^4.z^4 */ xyz(4,0,4): 6
/* x^4.z^2 */ xyz(4,0,2): -2*((3-2*P2*T2)*R2+3*A2)
/* x^2.y^2.z^4 */ xyz(2,2,4): 6*T2
/* x^2.y^2.z^2 */ xyz(2,2,2): 2*T2*((2-P2*T2)*R2-2*A2)
/* x^2.z^6 */ xyz(2,0,6): 4
/* x^2.z^4 */ xyz(2,0,4): -2*((3-P2*T2)*R2+3*A2)
/* x^2.z^2 */ xyz(2,0,2): 2*(R2-A2)*((1+P2*T2)*R2-A2)
/* x.y.z^4 */ xyz(1,1,4): -8*R2*Slope*T2
/* y^4.z^4 */ xyz(0,4,4): T2*T2
/* y^2.z^6 */ xyz(0,2,6): 2*T2
/* y^2.z^4 */ xyz(0,2,4): 2*T2*(R2-A2)
/* z^8 */ xyz(0,0,8): 1
/* z^6 */ xyz(0,0,6): -2*(R2+A2)
/* z^4 */ xyz(0,0,4): (R2-A2)*(R2-A2)
/* C */ xyz(0,0,0): 0.000000001 sturm }
// end poly
} // end object
Post a reply to this message
Attachments:
Download 'neo8.pov.txt' (8 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>"Le_Forgeron" schreef in bericht news:4d0d02fc@news.povray.org...
>
>Le 16/12/2010 23:01, Jaap Frank nous fit lire :
>
>> In the poly 16 file there was one parenthesis evaporated in line 318.
>> In this file it is corrected, so overwrite it with this one. Le_Forgeron
>> is changing the allowed maxpower, so I hope we can use the file
>> in the future.
>>
>> Jaap Frank
>
>I rendered the poly 16... part of it are noisy. I need to probably to
>adjust some settings in the solver & poly code (if it can fix something
>at all)
I'm curious, is the central line along the y-axis disappeared?
If it is still there, then the fact that C = 0 may be the answer to that.
Maybe it is not possible to solve very high powers with the poly solver
correctly and you get a bit fuzzy answers.
I've find an other derivation leaving to poly 12, but the result
was not what I wanted, but it rendered well. Interested?
>To ease the input, I'm adding a new syntax (no more ordering, you can
>omit the coefficient at 0, it save a bit !)
>
>#declare Spiral_Shape = object { polynom { 8
>/* x^8 */ xyz(8,0,0): 1
>/* x^6.y^2 */ xyz(6,2,0): 2*T2
>/* x^6.z^2 */ xyz(6,0,2): 4
>/* x^6 */ xyz(6,0,0): -2*((1-P2*T2)*R2+A2)
>/* x^5.y */ xyz(5,1,0): -8*R2*Slope*T2
>/* x^4.y^4 */ xyz(4,4,0): T2*T2
>/* x^4.y^2.z^2 */ xyz(4,2,2): 6*T2
>/* x^4.y^2 */ xyz(4,2,0): 2*T2*((1-P2*T2)*R2-A2)
>/* x^4.z^4 */ xyz(4,0,4): 6
>/* x^4.z^2 */ xyz(4,0,2): -2*((3-2*P2*T2)*R2+3*A2)
>/* x^2.y^2.z^4 */ xyz(2,2,4): 6*T2
>/* x^2.y^2.z^2 */ xyz(2,2,2): 2*T2*((2-P2*T2)*R2-2*A2)
>/* x^2.z^6 */ xyz(2,0,6): 4
>/* x^2.z^4 */ xyz(2,0,4): -2*((3-P2*T2)*R2+3*A2)
>/* x^2.z^2 */ xyz(2,0,2): 2*(R2-A2)*((1+P2*T2)*R2-A2)
>/* x.y.z^4 */ xyz(1,1,4): -8*R2*Slope*T2
>/* y^4.z^4 */ xyz(0,4,4): T2*T2
>/* y^2.z^6 */ xyz(0,2,6): 2*T2
>/* y^2.z^4 */ xyz(0,2,4): 2*T2*(R2-A2)
>/* z^8 */ xyz(0,0,8): 1
>/* z^6 */ xyz(0,0,6): -2*(R2+A2)
>/* z^4 */ xyz(0,0,4): (R2-A2)*(R2-A2)
>/* C */ xyz(0,0,0): 0.000000001 sturm }
>// end poly
>} // end object
Splendid, that's far more easier! It makes the file better to read.
Do you start with all zero's and put the given factors in
their correct position? I expect something like that will
be the way to do that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19/12/2010 01:45, Jaap Frank nous fit lire :
> Do you start with all zero's and put the given factors in their correct
> position? I expect something like that will
> be the way to do that.
Yes. (I didn't want to change the internal, only the interface to input
the coefficients)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] free fr> wrote:
....
> #declare Spiral_Shape = object { polynom { 8
....
http://www.merriam-webster.com/dictionary/polynom
--
Tor Olav
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 19/12/2010 13:00, Tor Olav Kristensen nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
> ....
>> #declare Spiral_Shape = object { polynom { 8
> ....
>
> http://www.merriam-webster.com/dictionary/polynom
Your suggestion is welcome...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <jgr### [at] freefr> wrote:
> Le 19/12/2010 13:00, Tor Olav Kristensen nous fit lire :
> > Le_Forgeron <jgr### [at] freefr> wrote:
> > ....
> >> #declare Spiral_Shape = object { polynom { 8
> > ....
> >
> > http://www.merriam-webster.com/dictionary/polynom
>
> Your suggestion is welcome...
How about polynomial ?
--
Tor Olav
http://subcube.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
