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

Post a reply to this message

Le 2010-02-03 16:25, Reuben Pearse a écrit :
> 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

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.


Alain

Post a reply to this message

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.

-- 
                                                          - Warp

Post a reply to this message

"Reuben Pearse" <reu### [at] pearsecouk> schreef in bericht 
news:4b69e9ce$1@news.povray.org...
> I'm just thinking it would be nice to be able to easily convert POV-Ray 
> models to other formats :-)
>

In addition to those macros converting isosurfaces to mesh2 mentioned by 
Alain and Warp, Moray is also able to convert csg objects into meshes, which 
you can then either edit internally or export to Poseray and/or any other 
modeller for fine tuning. The conversion is not always perfect but enough 
for many cases. Be aware however that it is not possible to import directly 
pov-ray csg object into Moray. You will have to build them first in Moray.

Thomas

Post a reply to this message

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

Le 2010-02-09 06:27, scott a écrit :
>> 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

Le 2010-02-11 14:48, bgimeno a écrit :
>> 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

Marching triangles isn't the same as marching cubes I assume? I'm not able to
find much on marching triangles. I was thinking about trying to implement the
marching cube algorithm.

Post a reply to this message

jhu <nomail@nomail> wrote:
> Marching triangles isn't the same as marching cubes I assume?

  No. Marching cubes is much simpler, but produces significantly poorer
results (does not take into account the curvature of the surface in order
to dynamically produce more triangles in high-curvature areas, which means
that it often misses smaller details, and it often produces extremely thin
triangles which may cause problems).

  The marching cubes algorithm also has a negative fame because some idiot
patented it on the US. (The patent might be expired by now.)

-- 
                                                          - Warp

Post a reply to this message

On Sat, 20 Mar 2010 12:41:15 -0300, Warp <war### [at] tagpovrayorg> wrote:

>   The marching cubes algorithm also has a negative fame because some  
> idiot
> patented it on the US. (The patent might be expired by now.)
>

Yes, the marching cubes patent expired in 2005.

Hugo.

Post a reply to this message

Le 20/03/2010 18:41, Hugo nous fit lire :
> On Sat, 20 Mar 2010 12:41:15 -0300, Warp <war### [at] tagpovrayorg> wrote:
> 
>>   The marching cubes algorithm also has a negative fame because some
>> idiot
>> patented it on the US. (The patent might be expired by now.)
>>
> 
> Yes, the marching cubes patent expired in 2005.
> 
That's a good news. I had patches of 3.1g which used marching cube to
tesselate solid object into mesh... with due restriction about import in
US zone.

Have you any accurate data (such as exact expiry date of marching cube ?)
(Gif was also troublesome)

Post a reply to this message

On Sat, 20 Mar 2010 22:08:09 +0100, Le_Forgeron <jgr### [at] freefr> wrote:
>
> Have you any accurate data (such as exact expiry date of marching cube ?)

http://www.google.com/patents/about?id=T1Q3AAAAEBAJ&dq=4710876
  or
http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F4710876

U.S. patents generally last up to 20 years.



-- 
FE

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 20/03/2010 18:41, Hugo nous fit lire :
> > On Sat, 20 Mar 2010 12:41:15 -0300, Warp <war### [at] tagpovrayorg> wrote:
> > 
> >>   The marching cubes algorithm also has a negative fame because some
> >> idiot
> >> patented it on the US. (The patent might be expired by now.)
> >>
> > 
> > Yes, the marching cubes patent expired in 2005.
> > 
> That's a good news. I had patches of 3.1g which used marching cube to
> tesselate solid object into mesh... with due restriction about import in
> US zone.

  I really think we should concentrate on the marching triangles algorithm
and forget about marching cubes. The latter, bluntly put, outright sucks as
a tesselation algorithm. The results are horrid.

-- 
                                                          - Warp

Post a reply to this message

You know, an object-to-mesh2 ability in the next version of Povray would be
nice. BTW, what's the walking triangle algorithm? I can't find a good
description of it.

Post a reply to this message

jhu a écrit :
> You know, an object-to-mesh2 ability in the next version of Povray would be
> nice. BTW, what's the walking triangle algorithm? I can't find a good
> description of it.

Would you rather use an empty glass-bottle of beer or a old shoe to nail
a nail in a set of planks ?

what is the exact interest of transforming to mesh ?

Post a reply to this message

"jhu" <nomail@nomail> wrote:
> BTW, what's the walking triangle algorithm? I can't find a good
> description of it.

I don't know anything about it, but I think it's called 'marching triangle'
algorithm.  A search on Google pulled up a bunch of sites.

Ken

Post a reply to this message

Le_Forgeron <lef### [at] freefr> wrote:
> what is the exact interest of transforming to mesh ?

  Rendering speed, free transformations (at vertex level, at least),
conversion to other formats.

-- 
                                                          - Warp

Post a reply to this message