Made some slight changes, and it took a whole minute less then the last
version to parse and render. I added support for smooth triangles but you
have to provide all the formulae for the normal computatiom, so I'll be
looking at a way to fix that, any suggestions would be appreciated. Still
haven't added a save mesh feature yet, thats one of the next changes I plan
on making.

--
Kevin
http://www.geocities.com/qsquared_1999/
#macro _(r)#if(r<12)#local i=asc(substr("oqshilacefg"
,r,1))-97;disc{<mod(i,7)-3,div(i,7)-1,6>,z,.4
pigment{rgb 10}}_(r+1)#end#end _(1)//KL

Post a reply to this message

Attachments:
Download 'field-2.jpg' (66 KB)

Preview of image 'field-2.jpg'

If you can predict which new triangles will be joining
the mesh, you could calculate for each triangle-corner the
surrounding triangles also touching that corner, gather
the surface-normals of all of these triangles, and average
it for the smooth-normal. Aside of that, you could perhaps
trace() the isosurface itself and gather the normal from that,
obviously, you should have an isosurface present. It'll
take a longer parsing time, sure, but you'll end up with a mesh
which you can render fast in trials.

--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

Post a reply to this message

I considered using trace(), but then decided against it because of the fact
each vertex is only an approximation of the iso and will not neccesarily be
right where it's supposed to be. By using trace() the normal approximation
could be off by a lot resulting in a really strange shading. I would use the
average of the neighboring faces but since I'm not storing them that could
cause just a bit of a problem. I've been looking into ways of approximating
it based on the function supplied, I think I have an idea of how to do this,
but I'm not sure yet, but thanks for the suggestions.

--
Kevin
http://www.geocities.com/qsquared_1999/
#macro _(r)#if(r<12)#local i=asc(substr("oqshilacefg"
,r,1))-97;disc{<mod(i,7)-3,div(i,7)-1,6>,z,.4
pigment{rgb 10}}_(r+1)#end#end _(1)//KL

Post a reply to this message

> I added support for smooth triangles but you
> have to provide all the formulae for the normal computatiom, so I'll be
> looking at a way to fix that, any suggestions would be appreciated.

If you have the formula for the object, the normal at a given point <x,y,z>
is

(<func(x+small_val,y,z),func(x,y+small_val,z),func(x,y,z+small_val)> -
<func(x,y,z),func(x,y,z),func(x,y,z)>) / small_val

Taken from memory, I might have screwed that up. It's basically just the
gradient of the function.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

"Kevin Loney" <klo### [at] pt2mcom> wrote in news:3e94b3a3@news.povray.org:

> I considered using trace(), but then decided against it because of the
> fact each vertex is only an approximation of the iso and will not
> neccesarily be right where it's supposed to be. By using trace() the
> normal approximation could be off by a lot resulting in a really
> strange shading. I would use the average of the neighboring faces but
> since I'm not storing them that could cause just a bit of a problem.
> I've been looking into ways of approximating it based on the function
> supplied, I think I have an idea of how to do this, but I'm not sure
> yet, but thanks for the suggestions. 


The vGradient() macro should be able to do the job.

Here's the documentation for it:

http://www.povray.org/documentation/view/253/


Tor Olav

Post a reply to this message

that is exactly what I need!

thanks

--
Kevin
http://www.geocities.com/qsquared_1999/
#macro _(r)#if(r<12)#local i=asc(substr("oqshilacefg"
,r,1))-97;disc{<mod(i,7)-3,div(i,7)-1,6>,z,.4
pigment{rgb 10}}_(r+1)#end#end _(1)//KL

Post a reply to this message

> I considered using trace(), but then decided against it

I've tried your macro and it works! But it seems to generate some
unnecessary triangles, like small lines that nearly go by unnoticed. Besides
that I had a shock at the parsing time.  ;o)  As 80x80x80 segments takes
forever (I guess that's the penalty) guess what, I am going to need
something like 1000x1000x500 on a slow isosurface, so this method is out of
the question. Unfortunately. I'll try with trace and hope it's faster.

Grimbert's tesselation patch. (To my knowledge there aren't any builds of
it, on the windows platform.)

Are you going to add mesh2 output?

Regards,
Hugo

Post a reply to this message

On Wed, 14 May 2003 16:58:12 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> > I considered using trace(), but then decided against it
>
> I've tried your macro and it works! But it seems to generate some
> unnecessary triangles, like small lines that nearly go by unnoticed. Besides
> that I had a shock at the parsing time.  ;o)  As 80x80x80 segments takes
> forever (I guess that's the penalty) guess what, I am going to need
> something like 1000x1000x500 on a slow isosurface, so this method is out of
> the question. Unfortunately. I'll try with trace and hope it's faster.

http://www.silvertome.com/packages/triscan.html

ABX

Post a reply to this message

> http://www.silvertome.com/packages/triscan.html

Thanks for the link!  I'll try right away.

Best regards,
Hugo

Post a reply to this message

I've modified your macro to output wavefront obj files, though it doesn't
deal with duplicated vertices. Now I want to clean up and optimise the mesh
outside POV-Ray. I load the file in AccuTrans converter, and the mesh shows
up fine in the OpenGL window. Now is the time to remove duplicate vertices,
and the converter doesn't seem to do it right. The faces remain disjointed,
and when I ask the converter to calculate normals, they are all a mess. The
next step I wanted to do was triangle decimation, to optimise the mesh. I
have the Vizzup optimiser, but in this case it doesn't work. Probably
because the faces are not joined with each other.

If you know of any other tools I can try for the above purpose, please let
me know.

-Hugo

Post a reply to this message