Increasing render time with each frame

[paulselhi]

are you using GI animation setting ? C4D has an issue with this

[b52down]

Yes, GI, object animation.

Also the strange thing was, on frame 0 and 1 there was almost no image to render but took forever, I had to start rendering with frame 3.

Maybe it has to do with the amount of times starting a render (start/stop/start/stop/etc) within a cinema 4d session. When quiting the app and starting again.. everything works fine for the time being.

[paulselhi]

as i said GI animation mode has a known bug whereby renders take progessivevly longer to calculate though this is only noticable of long renders ( i.e many frames)

[b52down]

thanks, then let's wait for an update.

[Srek]

as i said GI animation mode has a known bug
I think i already cleared that part up in some older threads.
The increase in rendertimes when using GI Animation isn't a bug but caused by the increase in sample data over time that need to be taken into account. With each frame additional data is added to the GI solution.
The only solution to make it faster is to not render long camera moves but make shorter cuts.
Cheers
Björn

[b52down]

The increase in rendertimes when using GI Animation isn't a bug but caused by the increase in sample data over time that need to be taken into account. With each frame additional data is added to the GI solution.


Björn, this means that the quality of the GI increases with each frame? So if I render for example frames 1-30 in one sequence frame 30 is of better quality than I render frame 30 standalone?

[Per-Anders]

no, it just means that there are more cached point samples in the scene, for the areas that come into view as the camera moves (the little red and green dots).

[b52down]

Ok, but maybe a big part of the cached data will never be used again especially in an animation? Is the renderer never flushing its cache after x frames?

So the best way is to break up your animation in seperate rendering parts and manually flush the cache in between?

[STRAT]

So the best way is to break up your animation in seperate rendering parts and manually flush the cache in between?

yes. what a pain in the ass though. also, breaking up and disrupting the cached data will usually result in a blip in the gi solution which will be visible in the animation.

[Srek]

Ok, but maybe a big part of the cached data will never be used again especially in an animation? Is the renderer never flushing its cache after x frames?
Only after the whole animation and GI caching is done it would be possible to determine which sampels are not needed anymore, this simply can't be foreseen.

So the best way is to break up your animation in seperate rendering parts and manually flush the cache in between?
Manual flushing should not be neccesary.

Cheers
Björn

[STRAT]

Manual flushing should not be neccesary.

Cheers
Björn

but unfortunately it is :(

[paulselhi]

If you bake the gi into the textures you will avoid the problem you are experiencing. But then baking may take a long time !!

[dann_stubbs]

but unfortunately it is :(

i think what bjorn means is that if the walkthrough is broken down into multiple shots (renders) - hopefully with good transition points that will hide any flicker between each shot (render) - then each shot (render) will start over with a new cache so manual flushing is not needed.

since the point data will only be relavent to the particular shot being rendered rather then draggin all that cache data from the other rooms along with it (for instance in an arch walk through)

dann

[JoelOtron]

Good to know that the scene breakup is a solution to the cache buildup---
but wonder how this approach will affect procedural affects like TP mograph, cloth, hair, dynamics etc. I would cache whatever is cacheable, of course.

Setting the same project to render frames 0 to 20 for isntance, then rendering the next shot from frame 21 to 40---this would work--however wont c4d still have to recaluclate every frame from frame 0 once again?

Thinking ahead for an upcoming GI project. Guess I have some tests to do.

[Ernest Burden]

The increase in rendertimes when using GI Animation isn't a bug but caused by the increase in sample data over time that need to be taken into account.

With all due respect, this is either a bug or as limiting in how we can use C4D that it might as well be. I know this is a difference of wording only, but let's admit that it is the biggest Achille's heal in using C4D for arch-vis. FinalRender2 doesn't do that. (It has it's own problems). It uses a different method to avoid that issue, but so could Maxon. Why haven't you addressed this problem in several major releases since STRAT first brought it to your attention? It matters in his business and mine. We're not feeling the love.

I don't mean to get all surly here, though I think I have. Can we just fix this whatever-it-is please, and soon? Please?

[Ernest Burden]

Good to know that the scene breakup is a solution to the cache buildup---

It isn't. Been there, done that. I have found the time increase begins within a few frames, and by 15 frames you may have gone from five minutes to nearly an hour.

My solutions have been to render in stochastic mode (slow but consistent, also looks beautiful though grainy) and to bake the crap out of my file. Otherwise, buy fr2.

Setting the same project to render frames 0 to 20 for isntance, then rendering the next shot from frame 21 to 40

Unless you're cutting an MTV video, do you really think limiting yourself to under 1 second per shot is viable? Mixing parts of shots across different machines via NetRender causes bad flickering. So you have to force each shot to run on ONE machine to avoid that. And how do you do that and still make use of a small farm? Or, how do render animation and NOT use a farm?

Baking is your friend.

[b52down]

Setting the same project to render frames 0 to 20 for isntance, then rendering the next shot from frame 21 to 40---this would work--however wont c4d still have to recaluclate every frame from frame 0 once again?


No, in that case the GI cache will be exact as big as rendering the 0-20 shot and you didn't have to break up/stop the renderer. GI points calculated in frames 0-20 may never been used in frames 21-x.

Maybe a solution is a checkbox or input field in the GI render settings:

Clear GI cache after: each frame/x amount of frames/frame numbers x,x,x

[JoelOtron]

It isn't. Been there, done that. I have found the time increase begins within a few frames, and by 15 frames you may have gone from five minutes to nearly an hour.

My solutions have been to render in stochastic mode (slow but consistent, also looks beautiful though grainy) and to bake the crap out of my file. Otherwise, buy fr2.

There was another method posted by simon which I havent tried personally. He rendered in stchastic mode but used scene motion blur and no AA (I believe) to blend out the noise in each frame.

Been looking at fr2 and other renderers for a long time now--but Im on a mac and fr2 from what Ive gathered isnt viable yet? Also, I use lots of "in-cinema" only effects, particles etc, so have to think about these issues too. The best solution for all of course would be a much optimized AR3.



Unless you're cutting an MTV video, do you really think limiting yourself to under 1 second per shot is viable?


No. But really, Im just compiling what the ins and outs for each workflow is at this stage.
Definitely sounds like a pain int he ass to work like this (I usually stick to rendering complete shots with no breakup). I have little experience in this area to be honest--just strategizing and learning what the hard facts are.



Mixing parts of shots across different machines via NetRender causes bad flickering. So you have to force each shot to run on ONE machine to avoid that. And how do you do that and still make use of a small farm? Or, how do render animation and NOT use a farm?

Baking is your friend.

Baking might be an issue for the work I do--sometimes it works sometimes it just doesnt. I deal with lots of oozing changing surfaces, moving lights, etc--as opposed to camera moves through static environments, for instance. But I am looking into ways to make baking work in more instances.
Thanks Ernest

[Ernest Burden]

There was another method posted by simon which I havent tried personally. He rendered in stchastic mode but used scene motion blur and no AA (I believe) to blend out the noise in each frame.

Thank you for reminding me!

I meant to do some test with that, but completely forgot about it.


Been looking at fr2 and other renderers for a long time now--but Im on a mac and fr2 from what Ive gathered isnt viable yet? Also, I use lots of "in-cinema" only effects, particles etc, so have to think about these issues too. The best solution for all of course would be a much optimized AR3.

The upcoming vray/C4D should have a Mac version. That's what I recall, that vray1.5 will work on Mac. How much of your dynamics would translate I can't say, I know it wouldn't all into fr2.

I hate to say it, but it sounds like your best bet would be to fake the lighting bounces and render without any GI. You can do some test stills with GI using multipass and compare the GI with the same frame without GI and you will see where you would need to fill in. In truth, most GI is pretty close to an ambient fill, and where you have strong transfers you can add some short-falloff omnis.

[JoelOtron]

TThe upcoming vray/C4D should have a Mac version. That's what I recall, that vray1.5 will work on Mac. How much of your dynamics would translate I can't say, I know it wouldn't all into fr2.

I've been looking at vray (it will be available for mac). I dont "NEED" GI animation at this very moment, so its hard for me to justify investing in it yet (although of course Id like to do it just for the support). We know that a killer C4d renderer is ineviteable--which makes it more of a risk to sink money into a 3rd party renderer unless the paying job is there. Of course who knows when AR3 will come--could be this summer could be next summer. And if it shows up, will it have everyhting that users want?

I hate to say it, but it sounds like your best bet would be to fake the lighting bounces and render without any GI. You can do some test stills with GI using multipass and compare the GI with the same frame without GI and you will see where you would need to fill in. In truth, most GI is pretty close to an ambient fill, and where you have strong transfers you can add some short-falloff omnis.

Thanks--the GI -no Gi comparison is a good tip.
Yes--fake GI is also on my list. Rendering out diffuse and AO passes and compositing in post is another method.

well--hope b52down figures things out.

[STRAT]

Thank you for reminding me!

I meant to do some test with that, but completely forgot about it.



me done and tested.

it does work, you do get a nice rendered image, but for the amount of frames it renders just to compile a single still image, especially with modest arcitectural scenes, you might as well not bother. your render times are even longer in most cases.

but, if you're prepared to cope with longer render times, using the scene motion blur on a stoch mode or accurate 100% type animation render it might be worth it - the amount of time you'll save with constant, (but longer) render times should more than compensate for stopping/restarting and faffing about with conventional gi rendering methods.

again, it's dependant on how your scene is and will your scene suit this style. Externals maybe, but internal anims? i shouldn't think so in a month of sundays.

I've been faking it for too long to remember these days where animations are concerned.

[Ernest Burden]

I've been faking it for too long to remember

So sad........

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.