|
![](/i/fill.gif) |
> Rather than nitpicking about the function syntax, we should try to solve
> the initial query.
it was a problem in the logic of thinking ...
What I changed was:
#local pp1=vnormalize(p1-c)+c+Fn(p1.x,p1.y,p1.z)*p1;
#local pp2=vnormalize(p2-c)+c+Fn(p2.x,p2.y,p2.z)*p2;
#local pp3=vnormalize(p3-c)+c+Fn(p3.x,p3.y,p3.z)*p2;
to the following:
#local pp1=vnormalize(p1-c);
#local pp2=vnormalize(p2-c);
#local pp3=vnormalize(p3-c);
#local pp1=pp1+Fn(pp1.x,pp1.y,pp1.z)*pp1+c;
#local pp2=pp2+Fn(pp2.x,pp2.y,pp2.z)*pp2+c;
#local pp3=pp3+Fn(pp3.x,pp3.y,pp3.z)*pp3+c;
.
So it was neither the bozo, nor an accuracy-problem ...
What makes me wonder is, WHY this makes a difference ?
Shouldn't the first approach treat the congruent(?) points of the adjacent(?)
triangles all in the same way, so they still should be all in the same point
?
Obviously they are not, but why? Furthermore, Why did the second way solve
this ?(Indeed, it is no longer the identical function to the first way, but
it
fits to my needs)
Now, Okay .. The resulting image is in p.b.i ... I did the spheres as meshes,
to
be able to play a bit with LevelOfDetail Algorithms ...
--
Jan Walzer <jan### [at] lzer net>
Post a reply to this message
|
![](/i/fill.gif) |