Well, I've checked my include file (in p.binaries.scene-files), and I'm 
not sure what the problem is.  I've verified that, when used only once, 
the correct number of triangles is generated (LOD^2).  However, when 
invoked multiple times, an excess number is generated, and I'm not sure 
why.  If others could help me look at this, I'd appreciate it.

Thanks in advance,

...Chambers

PS If needed, I can supply a sample scene which demonstrates this 
problem.

Post a reply to this message

Okay after what you told, I checked your macro again.. Could it be as simple
as this?  ;o))

#declare LOD=LOD+1;

... this happens every time you invoke the macro because it's a global
variable! You don't undefine it after the macro is finished, so next time
your macro takes the variable, it's +1 ..  Don't worry, we all make
mistakes.. Assuming this was the bug cause I didn't test it yet.

Regards,
Hugo

Post a reply to this message

Your macro seems to result in sharp edges between the triangles. For
example, try changing the smooth_triangles to regular triangles in
curvetri.inc, and rendering this scene:

// -----
#include "curvetri.inc"

camera { location <0, 3, -6> look_at <0, 0, 0> }
light_source { <-30, 30, -30> rgb 1 }
plane { y, -1 pigment { rgb 1 } }

mesh {
  curved_triangle (<-4, 0, 0>, <-1, 0, 0>, <0, 2, 2>, <0, 1, 0>, <0, 2, -2>,
<0, 1, 0>, 50)
  curved_triangle (<4, 0, 0>, <1, 0, 0>, <0, 2, 2>, <0, 1, 0>, <0, 2, -2>,
<0, 1, 0>, 50)
  pigment { red 1 }
}
// -----

Another problem is that if you scale the entire scene by a constant factor,
the shapes of the curved_triangles change. Also, if the lengths of the
normal vectors aren't 1, the vertices don't match up with the specified
points.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

Hugo wrote:

> Okay after what you told, I checked your macro again.. Could it be as
> simple
> as this?  ;o))
> 
> #declare LOD=LOD+1;
> 
> ... this happens every time you invoke the macro because it's a global
> variable! You don't undefine it after the macro is finished, so next
> time
> your macro takes the variable, it's +1 ..  Don't worry, we all make
> mistakes.. Assuming this was the bug cause I didn't test it yet.
> 
> Regards,
> Hugo

Doh!  For some reason, that did it.  I thought it wouldn't matter, 
since it is an argument to the macro... I guess it mattered :)

...Chambers

Post a reply to this message

Anders K. wrote:


> Another problem is that if you scale the entire scene by a constant
> factor, the shapes of the curved_triangles change. Also, if the
> lengths of the normal vectors aren't 1, the vertices don't match up
> with the specified points.
> 
> Anders

Hmm... the shapes shouldn't change, but I'll take a look.

By the way, I've fixed the normal thing in my C++ implementation... 
now, the length of the normal affects the curvature of the triangle.

...Chambers

Post a reply to this message

> By the way, I've fixed the normal thing in my C++ implementation...
> now, the length of the normal affects the curvature of the triangle.

Would it be a good idea to get the C version into the next MegaPOV?

Regards,
Hugo

Post a reply to this message

Looking at the algorithm you described, you're offsetting points based on
normal values, and as the size of the triangle increases, this offset
becomes less significant. Also, while adjacent edges between triangles will
be continuous when the normals are the same, there's no reason for them to
be smooth. I think you're going to need a completely different algorithm to
ensure this.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

Anders K. wrote:

> Looking at the algorithm you described, you're offsetting points based
> on normal values, and as the size of the triangle increases, this
> offset becomes less significant.

Right - if you scale the triangle, you must also scale the normals 
(odd, but true :)

> Also, while adjacent edges between
> triangles will be continuous when the normals are the same, there's no
> reason for them to be smooth.

Hmm...  I hope that's not the case, but it may be.  Anyway, in the 
tests I've done it's come out smooth, but I haven't tested many meshes 
extensively (just large, odd shapes to make sure things look right).

> I think you're going to need a
> completely different algorithm to ensure this.

Could be.  I looked into using bezier splines for the three sides, but 
the middle section always got me bogged down in how to compute it.  
This method seems much more elegant, although it requires tracking a 
large amount of data (points, normals, magnitudes and, if wanted, 
texture coordinates etc).

...Chambers

Post a reply to this message

Hugo wrote:

>> By the way, I've fixed the normal thing in my C++ implementation...
>> now, the length of the normal affects the curvature of the triangle.
> 
> Would it be a good idea to get the C version into the next MegaPOV?

<lol> First, let's get it working right :)  Then, we'll see.

...Chambers

Post a reply to this message

> > Would it be a good idea to get the C version into the next MegaPOV?
>
> <lol> First, let's get it working right :)  Then, we'll see.

Yeah, well maybe it could be improved.  :o)  I finally did some more tests,
now the LOD is working.. It seems that poor edges from a mesh doesn't really
"smooth out".. The normals are turned into -- curves? But I'm not sure if
this merely means a linear curve.

Regards,
Hugo

Post a reply to this message