"Reactor" <rea### [at] hotmailcom> wrote:
> I'm working on a fairly complicated model that contains both mesh2 and povray
> primitives.  Because of the complexity of the objects, some of the included
> scene files are pretty large, around 5 Mb.  Reading and experimentation has
> shown that placing macros throughout those files can take a performance hit
> when the macro gets called from another file, so I've begun inlining them when
> possible.

That's to be expected; indeed, frequently-called macros should be copied to the
file they are used in for better performance, because each call of a macro in a
different file causes that file to be re-opened again.

> What are other things that can be done to reduce parse times (aside from
> reducing file sizes)?

Well... reducing file sizes even more, I guess :)

As for the mesh2 files, stripping any unnecessary blanks or leading zeros may
help (e.g. "0.123" can be written as ".123"), and likewise reducing the
precision of floating points (e.g. normal vectors probably don't need more than
2 or 3 digits); in addition, if the mesh contains UV coordinates you mach check
whether you need them.

If you have multi-textured mesh objects but don't need to use them in CSG
intersections or differences, you can decompose them according to texture, so
you don't have to specify texture on a per-triangle basis, eliminating all the
texture_index data. If you have single-textured mesh objects, make sure they're
exported without texture_index data and use a single texture statement instead.


Aside from those mesh2 objects, try to eliminate loops. With loops you can't do
without, try reducing the number of statements inside the loop. Try to reduce
the number of variable assignments. Try to eliminate function or macro calls in
loop conditions.

For frequent computations, use functions instead of macros where possible.

When generating scene description statements "on the fly" in time-demanding
loops, try writing those statements to a file instead, and then including that
file, and use a flag to control whether that include file is re-generated or
the existing version used.


Try reducing textures to the resolution you really need. Loading of
high-resolution textures can take some time, too (recognizable by the
parsed-tokens counter stalling).



> I know in the past there was talk about a preparsed, binary format.  Has anyone
> been doing anything with that lately?

The talk was about a new SDL for POV-Ray 4.0; we're not really there yet ;)

Post a reply to this message