So I'm currently working on a project that involves creating animation frames
for a scene that contains one mesh composed of at least 100,000 triangles and
one light source.

Now the rendering times are great given the machine that I am suppose to work
with for this project. But I have identified a performance bottleneck that is
the reparsing of the scene every time a frame image is to be generated.

The mesh in my scene, however large it may be, is unchanged across all frames.
However, the light source location will vary across all frames.

I've looked up clockless animation, but that doesn't help me achieve my goals as
it is the light location that changes per frame not camera location. I've also
tried including the mesh information as an include file based on advice found in
older threads on this site but that still doesn't produce any noticeable
improvements.

So what I'm essentially asking is that is there any way to get povray to retain
the mesh information in memory to be used for all frames while only reparsing
the information for the light location?

P.S: I know about MegaPOV. It is unfortunate that persistent variables is not a
feature that is included in 3.7 and that the MegaPOV scrapped that feature at
one point.

Post a reply to this message

Le 15/02/2014 08:33, Excentp nous fit lire :
> So I'm currently working on a project that involves creating animation frames
> for a scene that contains one mesh composed of at least 100,000 triangles and
> one light source.
> 
> Now the rendering times are great given the machine that I am suppose to work
> with for this project. But I have identified a performance bottleneck that is
> the reparsing of the scene every time a frame image is to be generated.
> 
> The mesh in my scene, however large it may be, is unchanged across all frames.
> However, the light source location will vary across all frames.

parsing of mesh syntax is slower with increased size (each new element
need to be searched in previous parsed elements). If you can,
reformulate it with a mesh2 syntax (same object, same result, faster
parsing)

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 15/02/2014 08:33, Excentp nous fit lire :
> > So I'm currently working on a project that involves creating animation frames
> > for a scene that contains one mesh composed of at least 100,000 triangles and
> > one light source.
> >
> > Now the rendering times are great given the machine that I am suppose to work
> > with for this project. But I have identified a performance bottleneck that is
> > the reparsing of the scene every time a frame image is to be generated.
> >
> > The mesh in my scene, however large it may be, is unchanged across all frames.
> > However, the light source location will vary across all frames.
>
> parsing of mesh syntax is slower with increased size (each new element
> need to be searched in previous parsed elements). If you can,
> reformulate it with a mesh2 syntax (same object, same result, faster
> parsing)

Oh right I forgot to mention it is already a mesh2 object, but I would still
like to reduce parse times even further.

Post a reply to this message

I just checked the precise triangle count of my mesh, there are 511060
triangles.

I cannot reduce the number of triangles due to project requirements.

Also the parse time is around 3 seconds per frame but given enough frames the
performance cost really becomes noticeable.

Post a reply to this message

Unfortunately the speed of parsing of .pov files will probably not improve
until a possible rehaul of the input language system that may happen in
the future. (It's also possible that some kind of pre-parsed binary file
system might be introduced at some point to the current parser, but that's
also a "maybe" and in the future.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Unfortunately the speed of parsing of .pov files will probably not improve
> until a possible rehaul of the input language system that may happen in
> the future. (It's also possible that some kind of pre-parsed binary file
> system might be introduced at some point to the current parser, but that's
> also a "maybe" and in the future.)
>
> --
>                                                           - Warp

Well I wish I knew which files to hack so as to parse and declare an object in
the first frame and retain that declared object for all other frames until the
process has finished.

I think I'll ask in the programming forum.

Post a reply to this message

I have the same issue with parsing large mesh files. I ease the pain by running
multiple render tasks in parallel via separate render tasks (Povray instances)on
Windows and multiple simultaneous logged in users on Mac OSX. Parsing can only
utelize single core, but if you have many cores at your disposal you can chop up
your animation into many render jobs and run them in paralell. With this method
you utelize 100% of computing power out of your machine, even while parsing. If
you use only one render task only one core will be busy while parsing.

Post a reply to this message

Le 08/10/2014 13:25, CAD-Andi a écrit :
> I have the same issue with parsing large mesh files.

If you are using mesh{} (as opposed to mesh2{} syntax), this is
"normal": while parsing each additional vector (normal, vertex and so
on) of a mesh(), the parser perform a search on already parsed elements
of same kind.
For 1 million elements, that means 1 million search over an average of
half-million... can be very slow near the end.

Mesh2 syntax is optimised, but harder: it assumed the lookup as already
been done by the user. It is faster (really faster) on large mesh.

> I ease the pain by running
> multiple render tasks in parallel via separate render tasks (Povray instances)on
> Windows and multiple simultaneous logged in users on Mac OSX. Parsing can only
> utelize single core, but if you have many cores at your disposal you can chop up
> your animation into many render jobs and run them in paralell. With this method
> you utelize 100% of computing power out of your machine, even while parsing. If
> you use only one render task only one core will be busy while parsing.

-- 
Just because nobody complains does not mean all parachutes are perfect.

Post a reply to this message