2
$\begingroup$

I have a blender project setup, it is simply a building and a pond that are sitting on a sculpted ground plane. The ground plane has several particle systems setup on it: big and little trees (for a forest), two kinds of grass, some reeds around the edge of the pond. Then I have a camera that does a dolly move around the bank of the pond, while facing the building. The way the particle systems are setup is: a few parents and very many children that are generated at the time of render. All of the particles are static, (they don't change in any way through the extent of the dolly move).

So when rendering the ground plane particles have to be generated for EVERY frame of the animation even though the particles don't move or anything.

My question is this: is there a way for the children particles to be generated for the first frame and used again and again for the full duration of the animation?

I've done a lot of searching for baking in Blender, but that only has to do with textures (from what I've read). I've searched for "precompiling particles" but that didn't yield anything along the lines of what I was wanting. As you can tell, I'm not even sure what terminology I should be using. Any advice would be appreciated!

Here's a low frame-rate and "rough draft" of my animation: enter link description here

Improve this question
$\endgroup$
5
  • $\begingroup$ What makes you think that they are being regenerated every frame? I don't have any evidence either way, but I always assumed that this is not the case. $\endgroup$ – gandalf3♦ Jan 16 '14 at 21:54
  • $\begingroup$ @gandalf3 Well, across the top of the render pane, there is a row of text that tells what blender is doing... Before every frame, it flies through a bunch of different items, then gets to one that says "Synchronizing Object | Ground Plane" it stays there for 20-30 seconds before going on to finish the rest of the objects and begin sampling. I probably don't understand it properly, but I assumed that's why it stay on the synching the ground plane for so long. $\endgroup$ – Circle B Jan 16 '14 at 22:43
  • $\begingroup$ I guess we need a developer.. I always thought that was just because there were so many particles (you'll notice it does the same thing on very dense meshes). $\endgroup$ – gandalf3♦ Jan 17 '14 at 9:12
  • $\begingroup$ Is Physics set to 'No' for the particles? If they are all static as you described, it should help somewhat. $\endgroup$ – Mike Pan Mar 20 '14 at 18:42
  • $\begingroup$ I'll check on that.... $\endgroup$ – Circle B Mar 22 '14 at 20:22
2
$\begingroup$

You can turn particles into real objects with the convert button in the particles modifier panel.

In this case I think what you may be looking for is BVH caching. Under Render Properties there is a Performance panel. There you will find an option to cache BVH. Blender internal has some different options.

From the 2.62 Release notes -

For renders where only the camera or materials are changing, while meshes stay fixed, it is now possible to skip the sometimes slow BVH step, by enabling BVH Cache in the Performance panel. This will store the BVH on disk for subsequent (animation) renders of the same scene. Note that if the scene does change in the animation, enabling this option will make rendering somewhat slower.

From your sample animation this may not help as the mesh objects in the scene appears to be changing, unless you are making the materials transparent. If you do have this enabled then maybe disabling it will help.

One possibility may be to render the background animation and then composite the shed animation onto it. Another is to animate material transparency instead of object visibility.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I'll try the BVH caching... As far as the object visibility, I'm doing that with a restrict render keyframe, so do you think that makes my animation fall in the category of the "scene changing"? $\endgroup$ – Circle B Jan 17 '14 at 21:02
  • $\begingroup$ I'm not sure of the specific workings but I think the render visibility would alter what mesh data gets sent to the renderer, I would expect that to effect the bvh caching. $\endgroup$ – sambler Jan 18 '14 at 3:33
  • $\begingroup$ Well, I tried BVH caching and it increased render times from 20min to 2.5hr. :-( $\endgroup$ – Circle B Jan 18 '14 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.