I believe this was discussed about a year back, but I can't find the
thread.  Warp had quite a lot to say on the matter (surprised? ;)

IIRC, it was considered too difficult to implement now, but reasonable
to do in the V4 rewrite.  IIRC of course...



"Philippe Lhoste" <Phi### [at] GMXnet> wrote in message
news:3d4958b8@news.povray.org...
> I would like to promote the idea of a PoV-Ray binary scene format.
> I know the idea isn't orginal, I have even found something like that
in the
> VFAQ, but I hope to give here one or two new ideas...
>
> Actually, I am not a big fan of binary file formats, because it is
easier to
> hack (and break :-) textual files within a text editor.
> But binary files have the advantage of being compact and easy/fast to
parse,
> ie. no conversion of textual representation of numbers to their binary
> values, read a 16bit or 32bit token instead of several characters for
a
> keyword to hash and lookup, etc.
>
> Note: I have seen in the PoV-Ray VFAQ that binary format (it was for
mesh
> files) was out of question, partly because of portability issues, ie.
not
> the same binary representation of float numbers between platforms.
Some
> programs, like the Lua language, are very portable and still manage to
write
> and read binary data with float number (Lua's bytecode, for example).
So it
> is not an impossible task.
>
> The base idea relies on the idea I have on the way PoV-Ray parses the
scene
> files. I can be wrong (I haven't checked the code) and this whole
message
> can be pointless :-)
>
> I believe the parser reads the text file, tokenises it (replacing
keywords
> and identifiers by numbers) and then the engine executes this bytecode
> (running loops, etc.), creating object data in memory. When the scene
> creates an object, the engine allocates a structure representing the
> attributes of the object, sets defaults values, and fill in the
indicated
> values. The final result is a in-memory binary representation of the
scene.
>
> Of course, this data isn't suitable for raw serialisation (output to a
> file). Pointers have to be relative, etc., plus it is non-portable, as
the
> internal representation of objects is subject to change from one
release to
> the next.
>
> We need then a robust file format, probably using chunks like [T]IFF
or PNG
> formats.
> Older engines will ignore unkown data while newer ones will provide
default
> values where missing data.
>
> So, we could ask the engine to output the scene data after parsing, or
to
> load one and render it.
> Note that this would be a secondary file format, I don't suggest to
drop the
> current format!
>
> What would be the use of such file?
> Among numerous ideas:
> - To give a model without revealing some tricks used to make it. So it
still
> can be rendered with different point of view, lighting, etc.
> Of course, this format can be disassembled, but in "unrolled" format,
ie.
> with only the raw list of generated objects, without the coding
wizardry
> that could have been used to create it.
> - To ease the creation of PoV-Ray to other 3D formats converters. They
are
> quite rare currently, because you either have to rip the parser from
> PoV-Ray, or write your own, with probably incompleteness. With this
unrolled
> format, you avoid at least the task of interpreting the procedural
language,
> of checking syntax, etc.
> - In the same spirit, to ease the creation of PoV-Ray pre-viewers, eg.
> converting objects to OpenGL to quickly see a scene under various
points of
> view. See VOP
> <http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html>
for an
> example.
> - To provide detailed/complex mesh models with files of reasonable
size.
> - To write other scene description languages. If an API to read and
write
> this file format is released (like libpng), we can write programs to
> generate such files. So programers could use their favorite language
to
> create scenes: C[++], Perl, Python, Lua (my choice :-), etc.
> The current SDL is complete but a bit primitive (on the procedural
side),
> and using higher level languages (and perhaps faster) could be a
bonus.
> Of course, we can already write programs that output PoV-Ray scene
files,
> but you still have to parse them, which is a waste of time,
particularly for
> large scenes.
>
> -- #=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=# --
> Philippe Lhoste (Paris -- France)
> Professional programmer and amateur artist
> http://jove.prohosting.com/~philho/
>
>

Post a reply to this message