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