I have no idea if this is possible or if not whether anyone things it's a
good idea. (So please be gentle with your responses)

I am rendering out several images in a file queue, each image re-uses pretty
much the same objects. Every time an image is rendered several large tree
meshes are parsed. So here's the question is it/would it be possible to
cache that mesh in memory for the next image (some sort of marker on the
object description). So when the next image was rendered it would not need
to re-parse it. This could potentially save lots of time.

I imagine this would speed up some animations for instance.

Post a reply to this message

Ok, I just saw "Storing height_field mesh between frames of an animation"
below, I should have read that before posting this.

Post a reply to this message

"MattM" <nomail@nomail> wrote:
> Ok, I just saw "Storing height_field mesh between frames of an animation"
> below, I should have read that before posting this.

It's good to see someone else had the same idea, and since that other thread
fizzled out I'm glad you posted your message. I'm not familiar with how
POVRay works internally, but it seems it should be straightforward to store
objects in memory for use in multiple renders.

An animation I'm working on takes about 100 cpu hours to render, with a
significant fraction of that time spent on redundant calculations. We
mustn't be the only people who'd like to speed up our renders (or throw in
more eye candy instead!).

Post a reply to this message

You have run into a resource issue with your way of making movies-- using
meshes. What if you were to make your objects out of povray blobs?  Let's
say you were Pixar or some company with a whole lot of business-folks to
examine how you produced a movie, and say you were going to stick with
povray.   I wonder what eventually proves to be the most
"business-case-efficient" means of making movies  (considering engineering
+ model making + animating + rendering)--  meshes or blobs?

Perhaps someone on the POV-Team already knows the answer based on what the
software *is*.  But my hunch is that modelling things out of blobs is the
best business case for say making an Oscar(TM)-winning Best Short Film.
You can for example use #while loops to string out blobs along a spline,
then Reorient, translate, and scale each sphere to make just about any
shape you can imagine. You can then animate the spline and have all sorts
of fun.

Apologies if I'm hijacking your thread, but I've always wondered the answer
to this question.




"MattM" <nomail@nomail> wrote:
> I have no idea if this is possible or if not whether anyone things it's a
> good idea. (So please be gentle with your responses)
>
> I am rendering out several images in a file queue, each image re-uses pretty
> much the same objects. Every time an image is rendered several large tree
> meshes are parsed. So here's the question is it/would it be possible to
> cache that mesh in memory for the next image (some sort of marker on the
> object description). So when the next image was rendered it would not need
> to re-parse it. This could potentially save lots of time.
>
> I imagine this would speed up some animations for instance.

Post a reply to this message

MattM wrote:
> I have no idea if this is possible or if not whether anyone things it's a
> good idea. (So please be gentle with your responses)
> 
> I am rendering out several images in a file queue, each image re-uses pretty
> much the same objects. Every time an image is rendered several large tree
> meshes are parsed. So here's the question is it/would it be possible to
> cache that mesh in memory for the next image (some sort of marker on the
> object description). So when the next image was rendered it would not need
> to re-parse it. This could potentially save lots of time.
> 
> I imagine this would speed up some animations for instance.
> 
> 
> 

If a significant portion of your background objects don't change between 
renders, you could try rendering them in an image map and using that as 
your background (spherically mapped, of course).  The downside is that 
you won't get interaction (shadows, lighting, media etc) between the 
background and the 'real' objects in your scene.

...Chambers

Post a reply to this message

MattM wrote:
> I am rendering out several images in a file queue, each image re-uses pretty
> much the same objects. Every time an image is rendered several large tree
> meshes are parsed. So here's the question is it/would it be possible to
> cache that mesh in memory for the next image (some sort of marker on the
> object description). So when the next image was rendered it would not need
> to re-parse it. This could potentially save lots of time.

With version 3.7 this is technically possible (with some work). Since 3.7
can handle multiple scenes simultaneously (this is internally; we don't
expose this facility), it would be possible to parse and store the object
you want in one scene which is parsed without rendering it, and not
deleted. Then there would need to be some means of importing that parsed
scene; i.e. merging it with a newly-parsed scene (this is where the work
comes, as there is currently no support for that).

However on the surface it seems possible and I'm sure that once the 3.7
code is released, if there is sufficient interest in the concept someone
will do it.

-- Chris

Post a reply to this message

> I wonder what eventually proves to be the most
> "business-case-efficient" means of making movies  (considering engineering
> + model making + animating + rendering)--  meshes or blobs?

Meshes are much more efficient (timewise) than blobs.

> Perhaps someone on the POV-Team already knows the answer based on what the
> software *is*.  But my hunch is that modelling things out of blobs is the
> best business case for say making an Oscar(TM)-winning Best Short Film.
> You can for example use #while loops to string out blobs along a spline,
> then Reorient, translate, and scale each sphere to make just about any
> shape you can imagine. You can then animate the spline and have all sorts
> of fun.

You can do the same thing with meshes, but adding parse time to
a scene by programmatic object generation at parse slows an animation...
the trick is to pre-generate your mesh by macro, then just store
it in a file using #fopen and #write for future #include, don't re-calulate
it unless it changes, preferably you could store a "flipbook" of your
mesh object(s), then just re-use it in other parts of an animation.

Post a reply to this message

Thanks Chris Cason, you answered my question. It's not possible but could be
implemented in future. It was obvious in an animation type situation that
povray is spending lots of time doing the same thing, parsing, dumping from
memory, parsing, dumping, etc etc. In my case the parse time is as long as
the render time so it would make a massive impact on rendering multiple
images.

Just so people get the gist of what I was suggesting it could be something
like

object {tree cachename="tree1"} // tree is a large mesh object

cachename would tell povray to store the the cached object in memory. Then a
subsequent frame with the same object would just look up 'tree1' and use the
parsed in memory object (and save all that parse time).

That's just my humble suggesting I don't care how it's implemented but I'm
sure it would save some people lots of time.

Post a reply to this message