pov2mesh is a command line utility for Windows that accepts a POV-Ray .pov
file as input and produces a Maya .obj file as output.  While pov2mesh does
not yet understand the full range of .pov syntax, it is nevertheless a
valuable tool in its own right.

At present, pov2mesh accepts a subset of the POV-Ray scene description
language, executes the CSG operations specified in the .pov file and
tessellates the resulting shapes to produce an .obj polygon mesh file.  As
new versions are released, pov2mesh's support for the POV-Ray language will
increase accordingly.

http://www.geocities.com/psenzee/pov2mesh/

Post a reply to this message

Paul Senzee wrote:
> pov2mesh is a command line utility for Windows that accepts a POV-Ray .pov
> file as input and produces a Maya .obj file as output.  While pov2mesh does
> not yet understand the full range of .pov syntax, it is nevertheless a
> valuable tool in its own right.

Why Windows only?

Interesting tool but i wonder if you don't agree with the FAQ excerpt 
you put on top of the page or if you are simply trying to do the 
impossible... ;-)

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> Interesting tool but i wonder if you don't agree with the FAQ excerpt 
> you put on top of the page or if you are simply trying to do the 
> impossible... ;-)

  Supporting *everything* that povray support will, indeed, be an almost
impossible task. Or at least extremely laborious. And also a task which
has to be careful to not to break the usage license of POV-Ray.

  One simple case: Supporting the trace() function will require support
for raytracing *all* possible objects which can be generated with povray.
(As we know, trace() can be used for eg. place objects on the surface of
another object.) Another similar function is inside() (which can be used
to place objects inside another object, for instance). Objects may be
created using a pattern, a pigment or a whole texture declaration, and
they may be created using user-defined functions, so the converter would
have to emulate all of this.
  It may be tempting to use povray's own code for this, but that would
break the usage license, so it's out of question. One would have to
implement tracing of all objects from scratch as well as simulate all
of povray's patterns, pigments and textures.

  There's another simple case which falls in a gray area: rand().
If, for example, objects are placed using rand(), the converter program
would have to use the exact same rand() function as povray uses. While
I suppose one could get express permission to use the exact same function,
it's still a gray area with regard to the usage license...

  Then there are some practical issues. For example, you can create
an infinite non-planar surface with POV-Ray (for example using a poly
object). Since a mesh cannot be infinite, the program will have to
decide on some arbitrary boundaries inside which it will tesselate
the surface in question. It just may happen that the boundaries are
too tight for some scene and that in the result there will be a border
not visible in the original.

  Some polys may be finite, but not bounded. I don't know if there's any
easy way of determining the boundaries of a polynomial, so tesselating
such beasts may be a rather heavy job.

-- 
                                                          - Warp

Post a reply to this message

Thanks for your comments!

>Why Windows only?

The code is actually quite portable.  If there's interest, I'd release
versions for other platforms.

> Interesting tool but i wonder if you don't agree with the FAQ excerpt
> you put on top of the page or if you are simply trying to do the
> impossible... ;-)

I don't think it's impossible, exactly, just very hard. ;)  Unfortunately,
the tool is nowhere near complete as far as it's support of pov sdl goes, so
it's still up to me to prove it!

Little by little, I'm adding more functionality.  Hopefully before too long
it'll be an essential tool for pov users.  There are actually two major
issues to be addressed in future releases:

1.) Full support of Pov's sdl.
2.) It currently doesn't scale well.  Simple scenes convert quickly, but
complex scenes can take forever and consume huge amounts of memory.

Fully supporting the pov sdl will be a fair amount of (tedious) work, but
certainly doable.  Getting it to scale well, on the other hand, that's going
to be tricky..

Paul Senzee

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:dprmu9$qqs$1@chho.imagico.de...
> Paul Senzee wrote:
> > pov2mesh is a command line utility for Windows that accepts a POV-Ray
.pov
> > file as input and produces a Maya .obj file as output.  While pov2mesh
does
> > not yet understand the full range of .pov syntax, it is nevertheless a
> > valuable tool in its own right.
>
> Why Windows only?
>
> Interesting tool but i wonder if you don't agree with the FAQ excerpt
> you put on top of the page or if you are simply trying to do the
> impossible... ;-)
>
> Christoph
>
> -- 
> POV-Ray tutorials, include files, Landscape of the week:
> http://www.imagico.de/ (Last updated 31 Oct. 2005)
> MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Paul Senzee <pse### [at] yahoocom> wrote:
> Fully supporting the pov sdl will be a fair amount of (tedious) work, but
> certainly doable.

  Can you be a bit more specific on how will you be achieving this feat
without using copyrighted code from POV-Ray (breaking its usage license)?
As I noted in my previous post to this thread, simply *parsing* the input
file is not enough; in order to have full support for POV-Ray scenes you
have to implement quite a lot of the raytracing functionalities, such as
tracing objects, calculating their inside and supporting the evaluation
of textures.
  While it certainly is possible to do all this with original genuine code,
it will be a HUGE job...

  Another thing to address is how you will be tesselating infinite
non-planar surfaces.

-- 
                                                          - Warp

Post a reply to this message

Hi Warp,

You're right of course.  The fundamental differences between raytraced
scenes and mesh based models are such that any conversion is in the end an
approximation.  There are even cases where the semantics of one domain are
nonsensical in another.  For example, what do you do with the camera in a
mesh based model?  Ignore it?

Nevertheless, an 'approximation' of a pov based scene as a mesh is very
useful.  The pov sdl is a concise and effective high-level way to describe
geometry.  In fact, the initial purpose of the program was to enable another
program to generate complex geometries (buildings, urban scenes) in a
straightforward way and produce meshes in the end.

As far as the use of copyrighted code from pov goes, the parser I've written
has no connection to pov code whatsoever.  This shows, as the current parser
certainly has its limitations.  However, I'm writing a new parser from the
BNF spec that will hopefully be far more faithful to pov's sdl.  I have not
and will not use any code from pov's code base.

As far as evaluation of textures goes, it will be quite some time (if ever)
before I get to that.  Infinite surfaces are clipped at the edges of a
bounding 'universe' box.  To completely support pov sdl IS a huge job.  For
now, I'm attempting only part of it.

Paul Senzee

"Warp" <war### [at] tagpovrayorg> wrote in message
news:43ce17b6@news.povray.org...
> Paul Senzee <pse### [at] yahoocom> wrote:
> > Fully supporting the pov sdl will be a fair amount of (tedious) work,
but
> > certainly doable.
>
>   Can you be a bit more specific on how will you be achieving this feat
> without using copyrighted code from POV-Ray (breaking its usage license)?
> As I noted in my previous post to this thread, simply *parsing* the input
> file is not enough; in order to have full support for POV-Ray scenes you
> have to implement quite a lot of the raytracing functionalities, such as
> tracing objects, calculating their inside and supporting the evaluation
> of textures.
>   While it certainly is possible to do all this with original genuine
code,
> it will be a HUGE job...
>
>   Another thing to address is how you will be tesselating infinite
> non-planar surfaces.
>
> -- 
>                                                           - Warp

Post a reply to this message

Paul Senzee <pse### [at] yahoocom> wrote:
> You're right of course.  The fundamental differences between raytraced
> scenes and mesh based models are such that any conversion is in the end an
> approximation.

  I think you didn't understand my point.

  I was not in any way questioning the rationale in approximating surfaces
with triangle meshes. That's just ok.

  What I was wondering is how you will be solving the problem of figuring
out *where* the objects are located in the first place. If an object is
placed using the trace() function on the surface of, for example, a 4D julia
object which has been differenced from a poly object, figuring that out
(without using anything from POV-Ray's source code) will be a big feat
indeed.

> As far as evaluation of textures goes, it will be quite some time (if ever)
> before I get to that.

  The problem I see with that is that it will be basically impossible to
replicate all of POV-Ray's patterns, wave functions etc without actually
looking at POV-Ray's source code and doing it exactly like it is doing it.

  Looking at a source code and replicating its exact functionality
"in your own words" (so to speak) could be in a rather shaky ground
with regard to copyright... For example if you simply change the names
of the variables and functions, I don't think that's enough...

>  Infinite surfaces are clipped at the edges of a
> bounding 'universe' box.

  Have you thought how many triangles in total that makes?

  Don't get me wrong, I think a pov2mesh converter would be quite great.
I'm just pointing out that it will be an almost impossible job.

  By the way, it would be much, much easier if you made it as a patch
for POV-Ray instead of an independent program. This way you would have
direct access to everything in POV-Ray with minimal effort, and it would
save you a huge amount of work (eg. you wouldn't need to do *anything*
to parse the input scene, to trace objects, to evaluate pigments, etc).
  Also, making it a patch would make it more probable that it becomes
popular, especially if it gets included in megapov.

  You should seriously consider that.

-- 
                                                          - Warp

Post a reply to this message

>  Looking at a source code and replicating its exact functionality
> "in your own words" (so to speak) could be in a rather shaky ground
> with regard to copyright... For example if you simply change the names
> of the variables and functions, I don't think that's enough...
>

So far, I've been going at it blind to avoid exactly that sort of ambiguity. 
As such, I'm not familiar with the pov code base.

>  By the way, it would be much, much easier if you made it as a patch
> for POV-Ray instead of an independent program.
...
>  You should seriously consider that.

Actually that's a fascinating idea I'd never thought of.  I *will* consider 
that.

Post a reply to this message

Paul Senzee wrote:
>>  By the way, it would be much, much easier if you made it as a patch
>> for POV-Ray instead of an independent program.
> ...
>>  You should seriously consider that.
> 
> Actually that's a fascinating idea I'd never thought of.  I *will* consider 
> that.

You couldn't charge a registration fee for it, then.

Another option is to write it as an SDL macro.  I believe this would 
allow you to continue selling it (I don't know how committed you are to 
making a profit off of this, so this might or might not be relevant).

...Chambers

Post a reply to this message

Chambers <bdc### [at] yahoocom> wrote:
> Another option is to write it as an SDL macro.

  This is one area where the SDL is absolutely non-suitable because of
efficiency.
  I estimate that doing this with SDL would be at least 30 times slower
than with a patch, and even the patch would already be slow enough for
many scenes...

  Besides, the SDL does not offer too many tools to do this anyways.

-- 
                                                          - Warp

Post a reply to this message