Hi

> Is there a way to convert POV-Ray's internal representation of a 3D
> shape (i.e. one constructed using CSG) into another 3D format -
> perhaps mesh or mesh2?

There are some C++ libraries that can do CSG using meshes:
GTS: http://gts.sourceforge.net/
OpenCSG: http://www.opencsg.org/
As far as I know, the second one cheats using some OpenGL features, 
whereas the first one really generates a mesh. Unfortunately, they are 
C++ libraries only, so you have to write your own application for your 
task. Together with an implementation of the marching triangles 
algorithm (as mentioned by Warp), you could do nearly everything:

First convert all primitives to isosurfaces. (Is that possible?) Then 
convert them to meshes. Finally do the CSG using the GTS.

It is really time that someone implements a Povray to Mesh converter 
which works for most scenes. Unfortunately, I do not have the time to 
start such a project.

Greetings
Urs

Post a reply to this message

Thanks for the comments so far.

After a quick look around I found this site that talks about the CAT() 
macro. This seems to do something similar in that is scans a "CSG" 
object. See the following for more details:
http://www.persistencia.org/CATHELP/CAT.html

I also found the following previous thread discussing this subject:
http://news.povray.org/povray.newusers/thread/%3Cweb.4acb6d8f90192b14fedfeaac0@news.povray.org%3E/

Are there any other macros/utilities/converters that I should be aware of?

Thanks in advance

Reuben


Warp wrote:
> Alain <aze### [at] qwertyorg> wrote:
>> You are not the first one to think of that.
>> There are macros that can convert most objects into a mesh equivalent.
>> The most notable is one to convert an isosurface into a mesh.
> 
>   AFAIK the best algorithm to convert an isosurface into a mesh is the
> so-called marching triangles algorithm (it's better than other tesselation
> algorithms because it is able to create more and smaller triangles in high
> curvature places and less and larger triangles in low-curvature places, and
> avoids extremely thin triangles; I think it also handles sharp edges much
> better than other algorithms, although I'm not completely sure of this).
> The same algorithm could probably be used with more or less success with
> CSG objects as well (although they have some pitfalls that isosurfaces
> don't have, as CSG objects need to be traced, which introduces its own
> problems, while isosurfaces just need to be evaluated).
> 
>   However, I have never heard of anyone actually going through the trouble
> of implementing the marching triangles algorithm for POV-Ray. So no such
> luck there.
>

Post a reply to this message

Reuben Pearse <reu### [at] pearsecouk> wrote:
> After a quick look around I found this site that talks about the CAT() 
> macro. This seems to do something similar in that is scans a "CSG" 
> object. See the following for more details:
> http://www.persistencia.org/CATHELP/CAT.html

  Creating smaller objects inside one larger object is a completely different
(and far more trivial) thing than tesselating an object (ie. converting it
into a triangle mesh).

-- 
                                                          - Warp

Post a reply to this message

>  However, I have never heard of anyone actually going through the trouble
> of implementing the marching triangles algorithm for POV-Ray. So no such
> luck there.

I started to implement it in POV from some paper, but when different parts 
of the mesh needed to join back up again it never worked properly.  I 
couldn't figure out from the paper how to fix this, so gave up.  Attached is 
about as good as I got meshing a sphere using the algorithm (the next few 
steps after this started to screw up big time).

Post a reply to this message

Attachments:
Download 'marching triangles.jpg' (76 KB)

Preview of image 'marching triangles.jpg'

scott <sco### [at] scottcom> wrote:
> I started to implement it in POV from some paper, but when different parts 
> of the mesh needed to join back up again it never worked properly.  I 
> couldn't figure out from the paper how to fix this, so gave up.  Attached is 
> about as good as I got meshing a sphere using the algorithm (the next few 
> steps after this started to screw up big time).

  That indeed demonstrates (some of) the strengths of the marching triangles
algorithm: There are no thin triangles, and all the triangles are distributed
rather evenly.

  It would be pretty useful if someone could get it to work fully.

-- 
                                                          - Warp

Post a reply to this message

>> However, I have never heard of anyone actually going through the trouble
>> of implementing the marching triangles algorithm for POV-Ray. So no such
>> luck there.
>
> I started to implement it in POV from some paper, but when different
> parts of the mesh needed to join back up again it never worked properly.
> I couldn't figure out from the paper how to fix this, so gave up.
> Attached is about as good as I got meshing a sphere using the algorithm
> (the next few steps after this started to screw up big time).
>
>
>

You try to connect each points to 6 other points.

You need to allow points to connect to less than 6 neigours. For the 
sphere, some points only connect to 5 others. Fore some other shapes, it 
can go down to 4 or 3 points. In some cases, a point may need to connect 
to 7 or even 8 or more points.

Try setting some angle or distance thresshold.


Alain

Post a reply to this message

Reuben Pearse <reu### [at] pearsecouk> wrote:
> Hi everyone,
>
> Is there a way to convert POV-Ray's internal representation of a 3D
> shape (i.e. one constructed using CSG) into another 3D format - perhaps
> mesh or mesh2?
>
> Would it possible to write a POV-Ray macro to scan the surface of an
> object and create mesh2 type co-ordinates (would the trace function be
> able to do this?)
>
> I'm just thinking it would be nice to be able to easily convert POV-Ray
> models to other formats :-)
>
> Thanks in advance
>
> Reuben
> reu### [at] pearsecouk

The relationship between the next link and this thread can be considered as very
subtle (at best), but can serve as inspiration to try another ways. I regret the
absence of more examples and the presence of syntactic and grammatical errors.

regards,
B. Gimeno

http://www.persistencia.org/CATHELP/CAT.html

Post a reply to this message

"B. Gimeno" <bgi### [at] lycoses> wrote:

>
> The relationship between the next link and this thread can be considered as very
> subtle (at best), but can serve as inspiration to try another ways. I regret the
> absence of more examples and the presence of syntactic and grammatical errors.
>
> regards,
> B. Gimeno
>
> http://www.persistencia.org/CATHELP/CAT.html

Thanks for the link!
That cubic golfer guy looks quite cool and inspiring. I'll give this a try when
I have some time again to do some POV-Ray experiments :)
Does this warning "VERY VERY VERY IMPORTANT: Ignore or forget this section will
dramatically raise up the parsing time without obtain results" refer to section
5 or to section 5.1 ?

Best wishes,

Simone

Post a reply to this message

> Does this warning "VERY VERY VERY IMPORTANT: Ignore or forget this section 
> will
> dramatically raise up the parsing time without obtain results" refer to 
> section
> 5 or to section 5.1 ?

To Section 5. The inclusion of the keyword "inside_vector" is well 
peremptory, without which the process is perpetuated without result. Thanks 
for your comment.
Soon, Mr. Cubic will be published at a higher resolution on your favorite 
news server.

B. Gimeno

P.D. That you look like a man playing golf is a Poserguy playing in a 
Discobolo pose being misunderstood by my macro, with several boxes aligned 
to the vector determined by vector_inside

Post a reply to this message

>> Does this warning "VERY VERY VERY IMPORTANT: Ignore or forget this section
>> will
>> dramatically raise up the parsing time without obtain results" refer to
>> section
>> 5 or to section 5.1 ?
>
> To Section 5. The inclusion of the keyword "inside_vector" is well
> peremptory, without which the process is perpetuated without result. Thanks
> for your comment.
> Soon, Mr. Cubic will be published at a higher resolution on your favorite
> news server.
>
> B. Gimeno
>
> P.D. That you look like a man playing golf is a Poserguy playing in a
> Discobolo pose being misunderstood by my macro, with several boxes aligned
> to the vector determined by vector_inside
>
>

In that case, try changing the orientation of the inside vector.
If it was "inside_vector x" change to "inside_vector <1,0.1,0.1>"

The cause of your problem is probably that the inside_vector is parallel 
to some triangle of the mesh.


Alain

Post a reply to this message