POV-Ray : Newsgroups : povray.programming : POV-Ray 3.1 to other file formats - a possible solution : Re: POV-Ray 3.1 to other file formats - a possible solution Server Time
28 Jul 2024 20:23:03 EDT (-0400)
  Re: POV-Ray 3.1 to other file formats - a possible solution  
From: Neil Freebairn
Date: 13 Aug 2000 17:19:41
Message: <399710ed@news.povray.org>
Chris Huff <chr### [at] maccom> wrote in message
news:chrishuff-F96918.12125111082000@news.povray.org...


> > Since everything including declaratives has to be achieved through the
> > execution of commands for which there always has to be a code string
> > representation, so long as we capture all such declaratives, we should
> > capture all such changes to an object's state.
>
> Would this be very useful? You would basically have to re-parse the
> whole thing, including identifiers, transformations, etc, only in
> POV-Script. I think it would be more useful to have the actual object
> data be translated into a string, as well as more efficent in use of
> memory and simpler. So "sphere {< 3, 5*2, 8>, Rad*0.5}" with Rad==2
> would be translated to "sphere{<3,10,8>,1 texture{...}interior{...}",
> with object flags and other additional data also being included.
> Transforms would be output as matrices. This would be much easier to
> parse within POV-Script itself for writing to another file format.
> Another use of this feature would be include files and macros which
> output a large number of objects...you could save the objects in an
> include to save calculation time.

As I see it, the difficulty in converting POV-Ray files to other common 3D
file formats is that POVScript dynamically generates a (static)
representation of the scene, whereas these other formats employ static
representations 'from the start', i.e. with POVScript you don't know what
you've drawn until you've drawn it, to paraphrase somebody famous (E.M.
Forster?). If so, we'll need (at least) 2 'interpretive passes' to convert
the POVScript to another representation, (at least) one to determine what we
end up with, and (at least) one to convert the resulting static
representation to another format. Because I'm not familiar with C, and
because I'd like to develop and use the tool soon, I'm trying to achieve
this, quick 'n' dirty, using PovScript itself plus whatever utilities I can
find to help implement a solution. The approach I've adopted uses Thomas
Baier's POB SDK, which, in v0.9, the latest incarnation I've been able to
find, can handle everything but macros and conditional directives. My
short-term goal has therefore been to create a tool which translates
POVScript 3.1 code into a version of POVScript parseable by POB SDK v0.9.
The process I've developed parses the original POVScript 3.1 files
(including all .inc files referred to) to create an intermediary POVScript
3.1 file that then creates a final POVScript 3.1 file that generates exactly
the same 3D scene and rendered output as the original, but has employs no
macros or conditional directives.

My desire to do this is to help both myself and a dozen or so other people
out there who through news.povray.org, c.g.r.r and other places have been
searching for the same tool, and to strengthen POV-Ray's integration with
other great 3D applications and utilities. There are no doubt better ways,
and my hope is that by developing the process, a way of integrating a file
format conversion utility such as the POB-SDK into POV-Ray more closely may
be found.

Neil


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.