Hello!

My Situation:

I'm rendering animations with very large SDL code (60Mb+). It takes about 3
minutes for the parsing process. My data are meshes of smooth triangles
converted from vrml files generated by a different software application. On top

rendering time of 1 frame is about 30 seconds.

Questions:

Can parsing be skipped when rendering a camera animation where nothing else is
changing? (I'm aware of the real time raytracing with "clockless" animation, but
this is useless for me ever since it does not save the result to disc.)

Is there meanwhile a out of the box solution to "cache" large images for image
mapping? Unfortunately I'm not a programmer like Brent Fraser who simply
implemented this back in 2008 for his own need (see Message
<4930353d$1@news.povray.org>).

Is it thinkable to implement something into SDL like a "permanent" or "static"
keyword/command that would designate geometry that will never change during the
animation and for that reason needs to be parsed only once? Again, I'm not a C
programmer, but I know implementing something that sounds so simple can be a
huge task. On the other side I don't think I'm the only one wishing for a
function like that. I bet it would be appreciated by many.

Any help or suggestions?
Thanks!

Andi

Post a reply to this message

Am 20.06.2010 19:42, schrieb CAD-Andi:
> Is there meanwhile a out of the box solution to "cache" large images for image
> mapping? Unfortunately I'm not a programmer like Brent Fraser who simply
> implemented this back in 2008 for his own need (see Message
> <4930353d$1@news.povray.org>).

Unfortunately there is no way yet except for hacking up the POV-Ray 
source code (or find someone who has done that already).

Post a reply to this message

CAD-Andi wrote:

> Is there meanwhile a out of the box solution to "cache" large images 
> for image mapping?

for this special case you might get an improvement by
setting up a ramdisk for the image location and using
an uncompressed image format.

> Is it thinkable to implement something into SDL like a "permanent" or
>  "static" keyword/command that would designate geometry that will 
> never change during the animation and for that reason needs to be 
> parsed only once?

I did try a hack for something like this using an older beta of 3.7
and it was quite useful for me. A hack mostly because the keeping-it-
around part was easy but a clean way of getting-rid-of-it at some
later time was not due to the way the render process is organized
in frontend and backend (although it may not be a problem for
someone with more experience with the povray source code).

So a static variable was essentially a bit of a memory leak.
Although on the other hand "static" could also extend beyond
the animation case in which case this becomes a feature, i.e.
the variables actually stick around as long as the process
is running and can be used to keep data between individual
renders and even exchange it between different scenes (note
this applies to the GUI version on Windows, for the command
line version of course process life time is usually the same
as image or animation rendering time.

I think it is useful although it didn't get too much resonance
in the newsgroups. Maybe I should add the stuff I played with
as a feature request to the 3.7 bug tracker. Even without
cleanup it can be very useful, possibly tagged as an
experimental feature?

I didn't try to patch the change into the latest beta sources yet.
However, even if I did, I think I would not be allowed to give away
the sources or binary as far as I understand the beta licensing.

Post a reply to this message

Christian Froeschlin wrote:

> I did try a hack for something like this using an older beta of 3.7
> and it was quite useful for me.

BTW what I used it for was the visualization of a largish data set, see

http://news.povray.org/povray.binaries.animations/thread/%3C4ab01be4%40news.povray.org%3E/

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:

> I think it is useful although it didn't get too much resonance
> in the newsgroups. Maybe I should add the stuff I played with
> as a feature request to the 3.7 bug tracker. Even without
> cleanup it can be very useful, possibly tagged as an
> experimental feature?

That would be fantastic if you could do that. Do they still consider new
features for 3.7? Having a feature like that would actually be extremely useful,
I absolutely agree. I think povray is the best way to do my animations because
of it's possibilities, but recently I questioned my approach because the
repetitive parsing for every image.

> I didn't try to patch the change into the latest beta sources yet.
> However, even if I did, I think I would not be allowed to give away
> the sources or binary as far as I understand the beta licensing.

It would be awesome if the makers of povray could allow you to make a "patched
binary" public, but I do understand that everything has to be done the official
way. Is there a channel/possibility of communication that allows requests like
that?

Thanks for your efforts!

Andi

Post a reply to this message

CAD-Andi wrote:

> Do they still consider new features for 3.7?

Only in exceptional cases so I wouldn't get my hopes up.
Also I'm not sure when I'll get around to playing with the
newest source code.

> It would be awesome if the makers of povray could allow you to make a
> "patched binary" public

Well the good news is that the normal license allows for this so
once 3.7 final is out anyone can publish patched versions of it.

In the mean time, note that if all you need to do is render the
same scene from multiple view points in one pass, you could do this
using Mega-POV and camera_view pigments (where the main camera looks
at a grid of boxes displaying the individual frames, resulting in one
huge image which you then have to tile later).

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> > It would be awesome if the makers of povray could allow you to make a
> > "patched binary" public
>
> Well the good news is that the normal license allows for this so
> once 3.7 final is out anyone can publish patched versions of it.

Any idea as far as when this will happen?

> In the mean time, note that if all you need to do is render the
> same scene from multiple view points in one pass, you could do this
> using Mega-POV and camera_view pigments (where the main camera looks
> at a grid of boxes displaying the individual frames, resulting in one
> huge image which you then have to tile later).

Interesting idea. I'll have to look into that. I could cut the frames after
rendering using image magick. Cool!

Andi

Post a reply to this message