"clipka" <nomail@nomail> wrote:
> "Reactor" <rea### [at] hotmailcom> wrote:
> > I'm working on a fairly complicated model that contains both mesh2 and povray
> > primitives...

> 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.

Already done.

> > 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.

This I'll look into - I'd have to come up with something to do it by automated
means.  The majority of the meshes have a single texture, with one entry per
face instead of 3.  They are all "stripped" of unnecessary UV data, but I could
pull the texture_list

> 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.
>

No loops, but I should go back through and pre-compute anything that has a fixed
value.

> 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.

That doesn't apply in this case, but it does have me thinking about using a RAM
disk for rendering animations - parsing speed concerns seem to be mainly around
disk I/O hmmm...

> 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'd forgotten abut that, since I am still placing geometry and haven't put in
the image maps or height_fields yet... More to look forward to!

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


That's ok, I doubt I'll be finished with this model before then ;)
Of course, when I do finally finish, I'll make these issues someone else's
problem by putting the model in Object Collection.

-Reactor

Post a reply to this message