Speeding up particle previews

[Redsandro]

Are there some tricks I missed, to speed up working with particles?

I have a flock of particles to decorate my comp. It's only about 500 particles most of the time. But whenever I jump back and forth (in time), the pRender will take about 10 seconds to render. There are computergames with 10 times as much particles that run smoothly in software mode.

I understand the particle pre-roll is rather sophisticated and takes time, but I would applaud some tips on making the particleworks a little less painstaking.

It's nice to have the final render take forever (12 hours for 30 seconds) if it's mandated by quality, but that's completely weird. During render, each frame pRender pre-rolls. During playback, the renderer only pre-rolls once, which makes mathematical sense. Rendering would be 90% faster if it didn't preroll again and again.

I would have my preview faster if I advanced each frame, made a screenshot, cut the screenshot and manually add the screenshot to a flipbook again and again 'till I reach the end of the range.

Why is this continuously prerolling happening?
What happens when no tool updates for 30 seconds even though it's rendering?
Why is render3d rendered 2 times even when motion blur is disabled?

[ShadowMaker SdR]

What kind of particles are you using? And as for the preroll part - Max's particles do the same thing: move forward it's fast. Move backward it's slow.

[Redsandro]

What kind of particles are you using?

Bitmap particles with alpha channel in an ordinary pRender.

And as for the preroll part - Max's particles do the same thing: move forward it's fast. Move backward it's slow.

Indeed, but rendering is like moving foreward. In Fusion, I might as well render backwards because the preroll keeps firing. It doesn't make sense, so either I'm missing a big point or I have a silly quirck in my configuration.

I can't imagine option number 3; Eyeon folks never thought about it.

[hevonen]

Why is this continuously prerolling happening?
What happens when no tool updates for 30 seconds even though it's rendering?
Why is render3d rendered 2 times even when motion blur is disabled?

Well it sounds like bugs and badly chosen algorithms. In addition Fusion particle engine is not multithreaded.

I've noticed Fusion in general does unnecessary calculations just for the kicks, for example result from static tools with single frame loader were not cached but instead recalculated each frame for reasons that escape me.


I would try downscaling particle bitmaps before feeding them to emitter, maybe to something like 64x64 or 128x128 to better suit graphics card (I presume Fusion would do this automatically but then maybe not). Then I would make sure that there really isn't too many particles to choke Fusion - it might be faster to work with dot style particles until final render. You could also try OpenGL renderer if time is spent rendering instead of calculating particle positions.

[Redsandro]

Interesting point.

About resizing bitmaps, I don't think that's the issue as the preroll calculations are about the particles' locations in space; not about drawing the bitmaps. Rendering itself is actually done quite swiftly in preview mode's. I can rotate around fully rendered particles in the camera viewpoint (realtime) as fluently as playing quake4.

Is it easy to implement a way to append a frame to a video file each time you send the timeline playhead to the next frame (e.g. pressing ']')?

[Redsandro]

-update-

Even though there are some questionable calculations going on in Fusion, the cause of the particle problem seems to be a rather simple one.

I overlooked a long ago placed slight defocus node. Honestly I even wouldn't know it caused upstream rerenderings on request. One would think the pre-roll wouldn't be necescary to render the same frame from a slight different angle, but passing through defocus nodes fixes this.

[hevonen]

Good that you found a solution.

Are you orienting particles to camera?

[Redsandro]

Are you orienting particles to camera?

Yes, if you mean that I'm facing the bitmaps to the camera. Why?

[hevonen]

Yes, if you mean that I'm facing the bitmaps to the camera. Why?

Well you said:
"One would think the pre-roll wouldn't be necescary to render the same frame from a slight different angle"

I was thinking that changing camera angle might then change particle positioning (at least if facing is implemented via particle rotation), which could be the reason for rerendering.

[DanielKoch]

If Fusion is re-rendering something, there's usually a good reason for it. We go to a lot of effort to eliminate unnecessary re-rendering.

Single-frame or held-frame loaders and non-animated tools connected to them do cache in most circumstances. Defocus is like most other tools, and won't re-render for no reason. Animation is a reason, of course, as is any sort of script or expression (as they could well require re-rendering - we can't easily tell), or simply running low on memory to keep the tool cached.

If you find that your comp IS re-rendering unexpectedly, I'd be happy to look at it and offer an expert opinion on why. Eyeon tech support is always available for the same. If you really have found a genuine case where Fusion is re-rendering for no good reason, we'll fix it.

Particles are usually pretty good about keeping the prerolls to a minimum. Whenever you change frames, it will hunt backwards for a cache and only preroll from there. Rendering sequentially forwards thus only needs to calculate one frame's change. Skipping randomly around will be slower initially, but if you let it cache the results, that will help. Large particle sets can require a great deal of memory to cache, however.

Changing the camera position doesn't require particles to recalculate their position, just to redisplay, and this is reasonably efficient. By way of comparison, my 2.4GHz CPU and $100 gfx card can display 1M camera-facing bitmaps w/ alpha at around 3 fps (1M points is 30+ fps. Recalculating the position & velocity of those million moving points (and displaying them) happens at about 2.6 fps (for the slower-displaying bitmaps it drops to 1.4 fps).

Incidentally, we have of course experimented with multithreading particle calculation, and found the benefits to be variable. Some calculation-heavy tools (e.g pFlock) show significant speedup, but simpler tools are more bandwidth-limited, and spend too much time on the extra overhead necessary to e.g. keep their random number sequences in sync between CPUs.

One more tip: For saving the results while advancing frames, check out Saver's Save Frames - High Quality Interactive setting.