So impressed with AR 2.5

[Ernest Burden]

unfortunately that is not correct for my experience. this slowdown becomes intollerable after only 50 or so frames in most cases.
it just seems to be a case of flushing the samples before each next frame render.

Therefore it makes sense that using 'recalc = always' would solve it, but it doesn't. It reduces the problem at first, but you still end up screwed after 1 - 2 seconds of frames. I sent my lovely hospital exterior animation scene to Srek as he suggested. Maybe he can spot where we're going wrong.

Janine,

Whether Lightwhatever posts images or not, it is a valid point to look at a comparison between mesh-refinement radiosity, Maxwell-style pseudo-physics or however vRay works as a comparison to how AR2.5 does things. You didn't respond to my Lightscape example--I think it holds up pretty well for 1998 technology. Perhaps AR does not offer enough in variety of GI render options. No method is perfect, which version of imperfection fits your needs for speed/quality? Hopefully in a few months I (all of us) will have more options.

[lightblitter22]

Alright, I'm gonna post a little video of how Maxwell renders, because I don't think people get how the grain thing works. A grainy image in Maxwell = an unfinished render. You'll see how it works when I upload the vid.

[STRAT]

Therefore it makes sense that using 'recalc = always' would solve it, but it doesn't. It reduces the problem at first, but you still end up screwed after 1 - 2 seconds of frames. I sent my lovely hospital exterior animation scene to Srek as he suggested. Maybe he can spot where we're going wrong.

here's my original thread for a reminder.

http://forums.cgsociety.org/showthread.php?t=173988

[lightblitter22]

Here's about 6 mins of Maxwell rendering timelapsed down to 30 seconds. Its a 640x480 pixel frame rendering with just skydome GI. The scene is the Vray couchscene somebody posted in a thread a few days ago. Towards the end I'm zooming in and out with the mousewheel.

http://www.zippyvideos.com/4655139151130086/maxgrain/original

note: the original vid is 640x480 QT. For some stupid reason zippyvideos scales the QT down, so its a bit smaller here. The dancing white pixels are Sorenson codec generated, not Maxwell. The yellow watermark is from a trial version of a screencap program.

[andronikos916]

Here's about 6 mins of Maxwell rendering timelapsed down to 30 seconds. Its a 640x480 pixel frame rendering with just skydome GI. The scene is the Vray couchscene somebody posted in a thread a few days ago. Towards the end I'm zooming in and out with the mousewheel.

http://www.zippyvideos.com/4655139151130086/maxgrain/original

note: the original vid is 640x480 QT. For some stupid reason zippyvideos scales the QT down, so its a bit smaller here. The dancing white pixels are Sorenson codec generated, not Maxwell. The yellow watermark is from a trial version of a screencap program.

I do not understand what are you showing there? ...what is your point?

:rolleyes:
Andronikos

[Simon Wicker]

so i've finished my test and i'm sorry but i don't see anything that contradicts what is written in the manual.

so to recap the manual states that for speeding up the rendering of a GI animation and to reduce flicker you should use the single camera animation option.

i tested this out using an old scene of mine (which janine will probably remember as she worked on it with me at moving picture company) from a film called stage beauty - the shot in question was 375 frames long, a flyover of 16th century london. i stripped out the textures and rendered this out at pal res (720x576) using some standard settings (accuracy 70%, 1 bounce, 300 samples, min 200 max 600). the scene was 390,000 polys in total.

the standard GI render took 2 hours and 15mins to render 150 frames and the results flickered like crazy.

the camera animation render took 26 minutes to render 150 frames and the results were almost flicker free.

so in this test the single camera animation version was five times faster than the standard GI version and the result was exactly as stated by the manual.

until someone posts a contradictory scene then i'm going to have to call nonsense on this one because nothing i have seen during or after testing this feature supports what people are saying here. i can understand a slowdown after rendering thousands of frames but there is certainly no slowdown in my scene after rendering six seconds worth of animation (which both strat and ernest said would happen).

cheers, simon w.

[Janine]

A grainy image in Maxwell = an unfinished render.

But how do you make a finished one...?

[STRAT]

until someone posts a contradictory scene then i'm going to have to call nonsense on this one because nothing i have seen during or after testing this feature supports what people are saying here.

me and Ernest were obviously sold duff copys then

[Per-Anders]

me and Ernest were obviously sold duff copys then

well, you could always post a "contradictory scene"...

[STRAT]

well, you could always post a "contradictory scene"...

no can do. it's confidential work material :(

maxon have already had a copy though and confirmed the problem.

[AdamT]

I've never been able to create the problem either. Last time Strat brought it up I did a 500+ frame flythrough animation of a condo model with over 1/2 million polys. The last frames rendered at about the same speed as the first frames.

[STRAT]

EBIII and I are obviously doing a certain type of archi render that fits the criteria.

although saying that, perhaps it's our overall styles, as i suffer from this problem every time.

[AdamT]

Did you guys send sample scenes to Srek? It's impossible to fix this if the developers/testers can't recreate the problem.

[STRAT]

i havent posted it to Srek himself, but his collegues in maxon germany and usa have each had a copy of one of my offending files to deal with and they both stumbled uppon the same problem i did when they tested my file. i've spend a good few sessions on the phone to them trying to sort out the problem and i had the same response -

"yup, you're right. it's definately a problem that exists. we've never experienced this before and dont know how to solve it. good-by."

that was a year or 3 back and they dont seem to have taken any notice of it ever since. but why should they? i'm just 1 person. and if janine and some of the others are correct, not many peeps use the AR for advanced full-on archi GI animations to actually find out.

[lightblitter22]

I do not understand what are you showing there? ...what is your point?

My point is that the grain gradually becomes finer and disappears as it renders. I think you're forgetting that only a handful of us on this board actually went for the Maxwell beta. The rest has neither seen a working version nor a demo, because there isn't one yet, so I thought I'd at least show a timelapse of how it renders.

I really don't know how else to explain the renderprocess to people. All you get on this board is people going "the grain! the grain!". Yes, its grainy if you stop the render 20% into it and post an intermediate image. AR is just as bad. 20% into your 20 hour arcviz GI render all you have to show is an image that is 1/5th done and 4/5ths black.

[Per-Anders]

My point is that the grain gradually becomes finer and disappears as it renders. I think you're forgetting that only a handful of us on this board actually went for the Maxwell beta. The rest has neither seen a working version nor a demo, because there isn't one yet, so I thought I'd at least show a timelapse of how it renders.

But i'm pretty sure everyone already knows this. It's not showing anything to anyone that they didn't arleady know, nor is it justifying maxwell in any way as a production ready engine.

I really don't know how else to explain the renderprocess to people. All you get on this board is people going "the grain! the grain!". Yes, its grainy if you stop the render 20% into it and post an intermediate image. AR is just as bad. 20% into your 20 hour arcviz GI render all you have to show is an image that is 1/5th done and 4/5ths black.

well no, that's not the same thing at all. the cinema render will finish and the pixels already rendered are done and dusted. but the maxwell one will only be done when you the user says it's done (or it reaches the predefined limit). also with traditional render engines you can give a reasonably good estimate on how long it's going to take to finish based on how much has been completed already. and that's the thing, a traditional engine completes a bit and moves on. with maxwell no part is ever complete (it'll constantly refine forever if needs be, but of course there comes a point when it should be considered acceptable).

[interactiveBoy]

so how do you render animations using maxwell then? I guess by setting some sort of limit on quality so once reached, it moves on to the next frame?

I've seen some of keytoon's animations (in the Maxwell gallery as well as on keytoon's site) and I must say, that look really, really good. But I can't help but think that it must have taken AGES to render them that cleanly.

sorry, slightly OT. :)

[andronikos916]

An average maxwell user knows and can predict the time needed for a rendering to be noise free and good quality...

But this is again out of topic discussion. In my opinion as I have mentioned before, Maxwell will be a Arch. animation tool pretty soon.

Our jaws will drop once again...
cy,
Andronikos
:eek:

P.S.
I will also try to make a 400frame arch viz with R9 to see if that "time increase bug exists"

[AdamT]

i havent posted it to Srek himself, but his collegues in maxon germany and usa have each had a copy of one of my offending files to deal with and they both stumbled uppon the same problem i did when they tested my file. i've spend a good few sessions on the phone to them trying to sort out the problem and i had the same response -

"yup, you're right. it's definately a problem that exists. we've never experienced this before and dont know how to solve it. good-by."

that was a year or 3 back and they dont seem to have taken any notice of it ever since. but why should they? i'm just 1 person. and if janine and some of the others are correct, not many peeps use the AR for advanced full-on archi GI animations to actually find out.

I'm sure whoever you dealt with before forwarded the problem on, but since Srek is head of Q&A it's likely it will get more emphasis.

While you and Ernest are just two people, you're also two of the few people on the board who do arch vis full time. Since you're both having the same issue it stands to reason other arch vis pros are experiencing the same issues.

[lightblitter22]

so how do you render animations using maxwell then? I guess by setting some sort of limit on quality so once reached, it moves on to the next frame?

You can set two cutoffs currently. Time in minutes (say 3mins max per frame) or sample level (say 5). What you don't see in the vid I posted is that everytime the frame is updated it jumps sample level - 0, 1, 2,3, 5 and so on. Like Andronikos said, its pretty easy to guess which cutoff time or sample level is sufficient. Its a very predictable renderer in its behaviour.

[Janine]

Its a very predictable renderer in its behaviour.

Yes, predictably grainy. Sorry, couldn't resist. ;)

[andronikos916]

just an advise for Maxwell users!

Never stop a rendering animation with setting maximu desired time per frame: this will result in non-constant illumination and will produce different noise levels and pattern!

You should always specify the desired SL level !

For example if you are happy with SL 15 just set SL 15 and time: 9999999.

Each frame (according to complexity) - caustics, materials, bounces needed etc. will reach SL 15 therefore will be identical and flicker free!

...sorry guys for the out of topic again - just don't want people to read wrong stuff here.

thanx,
Andronikos

[andronikos916]

Yes, predictably grainy. Sorry, couldn't resist. ;)

no offense Janine, you are AR fanatic and beta tester as well. I am a Maxwell guy and just trying to correct and help people here...

Time will tell. I just like Mediteranian guys...simple as that.

hehe :buttrock:

thanx,
Andronikos

[lightblitter22]

Andro, I mentioned the time cutoff limit because it can be useful if you need to render a preview animation in a given amount of time, lets say 5 hours, and then the boss or director wants to come in and take a look at it. Yes, you'll get frames that differ in the sample level they reach, but the preview sequence WILL BE FINISHED in the alloted time limit and you have something moving to show with minor quality differences between some frames.

The rendermethod is also great for things like doing print work on a deadline. Suppose your boss tells you at 9pm to start a 8000x6000 pixel render, because it needs to be handed to the printers tomorrow at 5pm latest and will go up as a billboard on a building the next day.

With an ordinary renderer, you have to be very careful how you set your quality settings, because it would suck if at the 5pm deadline the render has the bottom 20% of the frame missing. With Maxwell, you'd hand over whatever sampling level you were able to reach in that time. Printed in large format, that low level noise will be no more distracting than light photographic grain.

Plus there's always noise reducation methods like noise ninja and various other post tricks.

[Simon Wicker]

that was a year or 3 back and they dont seem to have taken any notice of it ever since. but why should they? i'm just 1 person. and if janine and some of the others are correct, not many peeps use the AR for advanced full-on archi GI animations to actually find out.

what are the render settings you use? can you post a screenshot?

cheers, simon w.

[andronikos916]

Andro, I mentioned the time cutoff limit because it can be useful if you need to render a preview animation in a given amount of time, lets say 5 hours, and then the boss or director wants to come in and take a look at it. Yes, you'll get frames that differ in the sample level they reach, but the preview sequence WILL BE FINISHED in the alloted time limit and you have something moving to show with minor quality differences between some frames.

The rendermethod is also great for things like doing print work on a deadline. Suppose your boss tells you at 9pm to start a 8000x6000 pixel render, because it needs to be handed to the printers tomorrow at 5pm latest and will go up as a billboard on a building the next day.

With an ordinary renderer, you have to be very careful how you set your quality settings, because it would suck if at the 5pm deadline the render has the bottom 20% of the frame missing. With Maxwell, you'd hand over whatever sampling level you were able to reach in that time. Printed in large format, that low level noise will be no more distracting than light photographic grain.

Plus there's always noise reducation methods like noise ninja and various other post tricks.

I agree with you, but there are people that do nt see any of the benefits of maxwell...

There many times that I have cancelled a renderer because something was wrong t the bottom left corner or a texxture problemm...

All these Maxwell advantages one will understand if he start using it and then try to go back to that AR lines!!! ...if you know what I mean..

But my personal problem about AR is not the lines..it is the Animation time bug and the non-cooperative rendering option...

that is my problem...

...I do not haveAR2.5 yet to tell exactly but these two are my big issues!

cy,
Andronikos

[Per-Anders]

The rendermethod is also great for things like doing print work on a deadline. Suppose your boss tells you at 9pm to start a 8000x6000 pixel render, because it needs to be handed to the printers tomorrow at 5pm latest and will go up as a billboard on a building the next day.

see, finally a decent argument for maxwell. the issue is though that at 5pm will the animation be useable for anything other than a preview (and will it even be useable for that)?

this sort of comes back to having/being a good producer though (which make no mistake isn't an easy thing to be), and knowing the limits of your tools and skills. so therefore it's the same with any engine.

[Ernest Burden]

While you and Ernest are just two people, you're also two of the few people on the board who do arch vis full time. Since you're both having the same issue it stands to reason other arch vis pros are experiencing the same issues.

It's interesting that Simon's test came in at about 5 minutes per frame, front to back. My files (and this has happened before except I was too green to know what was going wrong) will start with a sequence at 3 minutes and after 30 frames it can be up to 1 1/2 hours, stop and restart NetRender and its back to 3 min. again with a nasty flicker for my troubles.

So what is it about the scenes then? I don't know, since I've never made a scene that didn't create a run-up (I don't animate all projects). If some of you do not have this happen then it stands to reason there is a particular cause and it can be found and dealt with. Which, if you are scoring at home, is great news.

I emailed a link to my current scene this afternoon to Srek, let's see what he finds out. I hope he finds I'm at fault, then we don't have a bug.

Distant light without a far clip limit?

[Per-Anders]

ah, well i notice the use of the word "NET" in there. it's possible that this is really a NET render issue in that case (I don't think this was touched on before and i don't know if simon was using net).

however logically a net render situation would require it to backrender all the radiosity samples up to that frame (of course i don't know this for a fact)! however i know that cinema outputs a radiosity cache file somewhere (or at least it claims to on it's render settings), in theory this could be helped if the net render would somehow pass that cache around to the machines as they need, and fill it up on the core machine. that should reduce the problem somewhat (of course it may already do that).

[STRAT]

It's interesting that Simon's test came in at about 5 minutes per frame, front to back.

eh? i worked it out at under 1 min per frame with standard gi and 10 secs per frame with camera gi -



the standard GI render took 2 hours and 15mins to render 150 frames and the results flickered like crazy.

the camera animation render took 26 minutes to render 150 frames and the results were almost flicker free.



this doesn't look anywhere near complex enough to put the AR through a proper test. i'm talking about still frames that take at least 3-4 mins plus to render on a dual xeon @ 640x480 res. (and even my models are more optomised than you can ever get)

if you can render your frames at under 1 min (or even 10 secs for that matter) per frame then you wont have a problem.

btw, i dont use net render.


@Srek - if it helps, do you want me to send you one of my test files?

[Continuumx]

Alright, I'm gonna post a little video of how Maxwell renders, because I don't think people get how the grain thing works. A grainy image in Maxwell = an unfinished render. You'll see how it works when I upload the vid.

From what I understand, FPRIME works the same way as well.

[Continuumx]

But how do you make a finished one...?

You cook the render longer. Translation: More time is needed to allow the calculations to approach a perfect unbiased solution.

I think one of the features that the developers of Maxwell Limit had hinted around would be some method for Maxwell Render to tell the user how long it would take in time to reach a perfect unbiased solution. I hope this makes it into the final release if it is at all possible.

Maybe some kind of code based on a large cross section of different cpu speeds that would make it possible to approximate the render time for a perfect unbiased solution.

[Continuumx]

see, finally a decent argument for maxwell. the issue is though that at 5pm will the animation be useable for anything other than a preview (and will it even be useable for that)?

this sort of comes back to having/being a good producer though (which make no mistake isn't an easy thing to be), and knowing the limits of your tools and skills. so therefore it's the same with any engine.

I agree with this comment in the lines that yes, it takes good skill to recognize which of your tools are going to be the best match for a given job or deadline. If you have AR, Maxwell, and Final Render, then you have some tools that can match a wide range of needs. What happens next is your level of experience, skill, and knowledge of how to use these tools to make it a very efficient task.

I am still learning Maxwell and AR and so in time, I hope to master this. I know Maxwell Render enough at this stage of the game, to know about how long a render will take for a given resolution size. I also know how to manipulate the settings to get a certain surface. The same goes for shutter speeds, fstop, and iso settings. This is easier because of my previous photo experience. As far as lighting issues goes, there is always much to learn. I think I have some time to go before I can just know what level for light emitters is going to do the job. What I hope to have happen here is a translation of these skills to AR so that my level of skill in that engine improves.

[AdamT]

no offense Janine, you are AR fanatic and beta tester as well.
Ah, but you're a Maxwell fanatic and beta tester as well. :)

I agree that the fast preview is nice, but so far cooperative rendering has been anything but. Hopefully it's working better in recent versions, because it's a total non-feature in the general release.

[dann_stubbs]

It's interesting that Simon's test came in at about 5 minutes per frame, front to back. My files (and this has happened before except I was too green to know what was going wrong) will start with a sequence at 3 minutes and after 30 frames it can be up to 1 1/2 hours, stop and restart NetRender and its back to 3 min. again with a nasty flicker for my troubles.

So what is it about the scenes then? I don't know, since I've never made a scene that didn't create a run-up (I don't animate all projects). If some of you do not have this happen then it stands to reason there is a particular cause and it can be found and dealt with. Which, if you are scoring at home, is great news.



ernest and strat - i think i noticed that simon and others mentioned city flyovers etc... but also i think i notice your renders exhibiting the issue are interior - is that right?

dann

[lightblitter22]

Maybe some kind of code based on a large cross section of different cpu speeds that would make it possible to approximate the render time for a perfect unbiased solution.

It'll probably be much easier to do that thank you think. The little preview window in Maxwell reaches a final-looking result pretty quickly. It should be possible to estimate based on the amount of calculations that go into doing the preview roughly how long the larger frame will take. In my experience, Maxwell slows down majorly only as a result of either a lot GI bounces in a scene or large objects with a difficult to render shader taking up a lot of space in the frame (e.g. a large object with a dielectric shader). Even if the larger frame has small details in it that don't really get rendered as much more than a pixel in the preview, I don't think that will throw the overall completion time estimate off by much.

[Simon Wicker]

this doesn't look anywhere near complex enough to put the AR through a proper test. i'm talking about still frames that take at least 3-4 mins plus to render on a dual xeon @ 640x480 res. (and even my models are more optomised than you can ever get)


strat,

i can't quite see what you mean by complex. if i had wanted the render to take an hour a frame then i would have adjusted the radiosity settings to give me this 'tough' render or left in the textures, added a couple of area lights and rendered with best AA, all of which would have punched up the render times way beyond the levels you are talking about.

i had no need to do this in this case because i am not trying to make a pretty picture or tax my memory limits or processors. this was simply a test of whether or not the single camera animation GI setting does what it says it does and whether it accumulates samples and whether the render slows down hugely after 50 frames.

to test this i deliberately stripped out everything in my scene BUT the effects of the gi on the geometry. i have geometry, a sky dome, some radiosity, nothing more and nothing less. there are 390000 polys in the scene. do you want me to subdivide the geometry? add in some extra buildings? up my min max levels or the bounces i used? would this then hit the target for you?

however i can state that doing that will not fundamentally change the way the render happens, standard GI is slow, the camera animation is faster, over 150 frames there was no slowdown due to accumulated samples.

once again i would like to ask for a screen cap of the render settings you have used when you have the slowdown.

cheers, simon w.

[Ernest Burden]

You cook the render longer. Translation: More time is needed to allow the calculations to approach a perfect unbiased solution.

The Titanic was said to be unsinkable. Some people refused to sail her because the claim taunted God. Maxwell perfect?


ernest and strat - i think i noticed that simon and others mentioned city flyovers etc... but also i think i notice your renders exhibiting the issue are interior - is that right?

In the cases where I have had the 'problem' yes, they are exteriors. Large areas. But Simon's London would qualify as a large area. I have an interior to animate this week so we'll see how bad my life can really get. Yes, I wondered, could it be the distant light? If I had a moment to test the theory, I would. But I'm not a beta tester for Cinema. I'm still waiting on my 9.5 and I have work to hand in.

Strat--Sunday math. I wasn't even drunk yet.

[Per-Anders]

i guess it depends where the cache data is stored. if it's in memory then if you use high desnity gi sampling etc, there's a change that you will simply run out of ram, and it will start being applied to ascratch disk... in that situation things will suddenly slow down by quite a huge ammount, and it wont be apparent in low gi settings situations (as they will use up far less ram cache).

where is the slowdown itself by the way? in the precalc, in the gi prepass, or in the final pass?

[lightblitter22]

The Titanic was said to be unsinkable. Some people refused to sail her because the claim taunted God. Maxwell perfect?

A friend and I are going to put that to test not too long from now. We're going to do a live action + Maxwell VFX short with a real horror tinge at some point, probably around the time the 1.0 release is supposed to come out. If I'm right about Maxwell, the end result will look eerily realistic and not at all like comped in CG. :)

Everybody seems to think that Maxwell is just for arcviz use. I think its an allround photorealism weapon with some very serious rendering capabilities. We'll see how it turns out... </famous last words>

[Ernest Burden]

Everybody seems to think that Maxwell is just for arcviz use. I think its an allround photorealism weapon

It may be good for arch-vis, we'll see, but I will be bypassing some of the more 'photoreal' aspects like chromatic aberation and DOF for my arch-vis. There's no DOF in painting. DOF may relate to a camera, but the better the lens the less aberation and DOF you deal with. I don't want to reproduce a photo. That's not really real. I bought Maxwell because the lights make logical sense to me.

[Ernest Burden]

i guess it depends where the cache data is stored. if it's in memory then if you use high desnity gi sampling etc, there's a change that you will simply run out of ram, and it will start being applied to ascratch disk...
where is the slowdown itself by the way? in the precalc, in the gi prepass, or in the final pass?

I don't think that's it. I have mostly run these anims via NetRender, so you get zero feedback about what its doing. But I always have the TaskManager open to keep an eye on available RAM. This does not happen only if it runs out (it never has). This is on an XP machine, an XP-home and a W2K.

What caught my eye about Simon's test was that he was using a skydome only for light. That's a clue.

[Jorge Arango]

It may be good for arch-vis, we'll see, but I will be bypassing some of the more 'photoreal' aspects like chromatic aberation and DOF for my arch-vis. There's no DOF in painting. DOF may relate to a camera, but the better the lens the less aberation and DOF you deal with. I don't want to reproduce a photo. That's not really real. I bought Maxwell because the lights make logical sense to me.

I agree with you. As a photographer I have to deal with the limitations of the photographic media and it is a joy to work with the freedom of CG. Of course, things like DOF can help in enhancing one part of a picture and photorealism might be necessary when you are compositing. But in CG I prefer plain realism to photorealism. This subject makes me think of the early photographers who were always imitating painting with blurry and fuzzy pictures and it wasn't until they decided to exploit the strengths of the new technique that photgraphy took off as an autonomous art.

Just my thougths,


Jorge Arango

[STRAT]

Simon - i dont know what the answer is, but i can assure you there is a problem, whether you experience it or not it cannot be ignored as nonsense. even Maxon acknowlege it.

there's nothing special about my scenes and materials either, and it happens interiors and exteriors. i'm just saying that if you can render an animation with a 10 second per frame render time then a) i wouldn't be complaining and b) you'd hardly (if atall) notice any slow down.

you probably are experiencing this slow down, but your ratio of render times to slow down is so small you wouldn't see it. now turn on your AA and materials again (ie, put the scene back to normal) so the render times go up a couple of mins a frame then see what happens over 150 frames or so.

perhaps it's a culmination of everything in the GI prepass - materials, AA, GI etc etc

mdme - i couldnt tell you exactly where this slow down occures, i can only tell you it does. i suspect it's in the gi prepass, but i'd be guessing.

EBIII - i get slow down using distant or plain old spot/omni lights. i always use a gi emmiting skydome with a plain self illumed color to it, but of course, a skydome is integral to the render process. i think the problem is literally how Srek described it - i dont think it can be pin-pointed down to 1 offender in the process. it's a case of different coding to be implemented maybe.

[Srek]

@Srek - if it helps, do you want me to send you one of my test files?

Yes please, i have not a single scene here that shows such a problem. Please send it with a description of the environment you used when encountering the problem.
Cheers
Björn

[STRAT]

cheers Srek. i'll dig out an 'offender' for you sometime today. watch this space.

[STRAT]

cheers Srek. i'll dig out an 'offender' for you sometime today. watch this space.

ah. development. 9.5 just dropped on my lap. let me install that and test the same file with it as soon as i can, and i'll get back to you then :) (might be a day or 2)

[Srek]

Hi Ernest,
thanks for the link, just starting to download now.
Cheers
Björn

[STRAT]

ok, i cant install and test 9.5 for atleast 2-3 days, so i'll email you my file anyway.


here's the general look of the internal.


http://www.nikclark.com/strat/steg.jpg


it's a 9.1 file with 250 frames @ 640x480 pixels @ about 6.5 MB. it's just doing a small slow pan.

and it's been optomised pretty heavily, ie, the gi settings are -

strength - 100
accuracy - 5
prepass - 1/3
diffdepth - 1
stoches - 200
min - 50
max - 100

camera anim mode set to recompute first time. The AA settings are Best, Animation, threshold of 25% and min/max of 1x1 and 2x2. No texture maps, just plain materials.

so you see, pretty basic.

on my pc (dual 2.8 xeon 1 gig ram) when test rendering, the render time was 1 min 30 secs for any of the frames i tested.

when i set the animation going frame 1 was 1 min and 30 secs and by the time frame 15 came around the time had crept up to 4 mins.

I've emailed a link for you to download the file. literally just hit RENDER when you recieve it.

Any help really would be appreciated. thank you very much for your time again Bjorn :)

[JamesMK]

accuracy - 5

Is this correct or a typo?

Because if it's correct, I sense there's a reason for a gradual slow-down right there.

[STRAT]

Is this correct or a typo?

Because if it's correct, I sense there's a reason for a gradual slow-down right there.

that is correct. accuracy of 5. this'll give my scene a sence and atmosphere of gi lighting.

but even if my accuracy is 50 i get a similar slow down. just higher times. what's ur thinking?

[JamesMK]

that is correct. accuracy of 5. this'll give my scene a sence and atmosphere of gi lighting.

but even if my accuracy is 50 i get a similar slow down. just higher times. what's ur thinking?
Okay, then I was not on target anyway.

I was just thinking that with low accuracy, you get relatively few sample points from the prepass, and once the image is rendered, these points need to be interpolated. Add a build-up of prepass cache information on a frame-by-frame basis to that, and the work needed to perform the interpolation would theoretically increase exponentially over time.

But if acc.50 gives the same problem, it's probably not that either.

[lightblitter22]

We're back on the air. Yay. I took the time in between to do a simple clay render with physical sky and an outdoor crowd scene (TP crowd setup courtesy of Rendermania... I just added some trees and lighting). About 2.2 million polys in all. Quite pleased with the result.

http://img390.imageshack.us/img390/5027/clayrender0iq.jpg

[Ernest Burden]

Oops, Srek did get my files. I didn't read all the new posts. My bad, sorry.

[Simon Wicker]

the gi settings are -

strength - 100
accuracy - 5
prepass - 1/3
diffdepth - 1
stoches - 200
min - 50
max - 100

camera anim mode set to recompute first time. The AA settings are Best, Animation, threshold of 25% and min/max of 1x1 and 2x2. No texture maps, just plain materials.

so you see, pretty basic.

on my pc (dual 2.8 xeon 1 gig ram) when test rendering, the render time was 1 min 30 secs for any of the frames i tested.

when i set the animation going frame 1 was 1 min and 30 secs and by the time frame 15 came around the time had crept up to 4 mins.

hi strat,

what is your save solution setting? checked or un-checked?

cheers, simon w.

[interactiveBoy]

(TP crowd setup courtesy of Rendermania... I just added some trees and lighting).

Why do you refer to yourself in the third person? :)

[lightblitter22]

I'll answer your question with a riddle:

When set loose I fly away,
Never so cursed as when I go astray.
What am I?

[interactiveBoy]

I'll answer your question with a riddle:

When set loose I fly away,
Never so cursed as when I go astray.
What am I?






hahahah. That's what i get for asking i guess.

[Srek]

Thanks to Ernest and Strat for the files,
Marcus (Abstrax) and me took a good look at them. It turned out that it was realy the hughe amount of samples, that is collected over time, that leads to the eventual slowdown.
The problem is that in both scenes the camera makes rather long moves, covering many different parts of the scene so that a large number of samples is generated over time.
For each frame all currently stored samples have to be interpolated and it is this interpolation that needs more and more time.
In short, the Speed advantage of Camera Animation GI only realy applies to very short sequences with strong changes, or to longer shots with little camera movement. The Flicker Reduction advantage of Camera Animation stays constant, regardless of the camera movement and length of shot.
Cheers
Björn

[STRAT]

Thanks to Ernest and Strat for the files,
Marcus (Abstrax) and me took a good look at them. It turned out that it was realy the hughe amount of samples, that is collected over time, that leads to the eventual slowdown.
The problem is that in both scenes the camera makes rather long moves, covering many different parts of the scene so that a large number of samples is generated over time.
For each frame all currently stored samples have to be interpolated and it is this interpolation that needs more and more time.
In short, the Speed advantage of Camera Animation GI only realy applies to very short sequences with strong changes, or to longer shots with little camera movement. The Flicker Reduction advantage of Camera Animation stays constant, regardless of the camera movement and length of shot.
Cheers
Björn

cheers again guys for all your help. yup, this was the conclusion that was found the last time i bought this up with maxon.

even if i do change my camera paths to more like you suggest i still suffer this slow down in render times. and it happens relatively quickly too, sometimes even after the first 10-15 frames or so render times more than double. it's certainly flicker free, but look how it slows down even with the ultra low settings we put on. cant image how long it would take with more modest settings.

do you think Maxon will take a more serious look at this problem in future AR releases, or even come up with an interim patch? because as it stands it makes the AR useless for me personally (and EBIII) for GI animations. sounds like FR2 will help, but it'd be nice to do it all in the AR too.

Simon - save solution checked or unchecked, it doesnt matter. the same still happens.

lightblitter22 - lovely render man, a very wintery feel.

[Srek]

I can understand that this is disappointing for you, but it's the way things are. The focus for Camera Animation was and is to reduce flickering. Getting a speedup in some scenarios is nice but not something that happens with every scene.
The main problem here is that the manual is acutaly wrong on this topic (this will of course be corrected in the future).
Cheers
Björn

[wuensch]

Since yesterday I have my Update her, too (did not bother to use the demo) and worked my way through the video-tutorials.
:thumbsup:
Totally stable so far, very powerful features, very impressive.
Also the FBX 6 support works flawlessly so far!
Great job!


The only thing I could not figure out is how to use Ambient Occlusion to substitute radiosity--
Can someone enlighten me?

and how to add catalogues with content to the new Content manager.
But then, I guess the manuals are in the making ;-)

Olli

[dann_stubbs]

Thanks to Ernest and Strat for the files,
Marcus (Abstrax) and me took a good look at them. It turned out that it was realy the hughe amount of samples, that is collected over time, that leads to the eventual slowdown.
The problem is that in both scenes the camera makes rather long moves, covering many different parts of the scene so that a large number of samples is generated over time.
For each frame all currently stored samples have to be interpolated and it is this interpolation that needs more and more time.
In short, the Speed advantage of Camera Animation GI only realy applies to very short sequences with strong changes, or to longer shots with little camera movement. The Flicker Reduction advantage of Camera Animation stays constant, regardless of the camera movement and length of shot.
Cheers
Björn

http://www.postforum.com/forums/read.php?f=6&i=109703&t=109703

"i see this behavior too - my thoughts on it are with the GI cache is computes the first time and for each successive frame it reuses what it can.

well, that means it has to go through a cache to look for changes, then make new sample points for the new area then render. the next frame it has to do it again except now there are more samples to check and depending on how it does that internally can mean more overhead.

i don't know if my thoughts are technically accurate but it seems to explain the slowdown in my mind. i'm sure any processing to clear or flush the cache of excess data would take just as much time as the current GI cache slowdown.
"

so this was a fair assumption? this was from last year 9/2004

dann

[ThirdEye]

The only thing I could not figure out is how to use Ambient Occlusion to substitute radiosity--
Can someone enlighten me?

http://forums.cgsociety.org/showthread.php?t=129843&highlight=ambiente

[wuensch]

http://forums.cgsociety.org/showthread.php?t=129843&highlight=ambiente

thanks a lot!

Olli

[Srek]

so this was a fair assumption? this was from last year 9/2004

Yepp, you were correct on that, except that clearing the old samples is no option. This would create flickering.
Cheers
Björn

[dann_stubbs]

Yepp, you were correct on that, except that clearing the old samples is no option. This would create flickering.
Cheers
Björn

exactly and it would probably take more time to try to clear or flush the non-visible samples then just resampling from new again - so negating the process of camera animation.

i don't know if there is really a solution to "fix" the issue and do just agree it is more of a limitation to the process. in a couple years we will laugh at this problem when we will be able to set samples so high to eliminate flicker with no concern for slowdown due to cheap 16 core cpus etc... and then we can laugh again at these old "workarounds" : )

dann

[lightblitter22]

But this is again out of topic discussion. In my opinion as I have mentioned before, Maxwell will be a Arch. animation tool pretty soon.

Our jaws will drop once again...

Quick question for you Andronikos. Is M~W 1.0 going to speed up significantly over the current beta? I'm aware of the other features coming from the Maxwell board (materials UI, baking and so forth), but wondering mostly if the raw renderspeed will increase.

[Ernest Burden]

Thanks to Ernest and Strat for the files

In short, the Speed advantage of Camera Animation GI only realy applies to very short sequences with strong changes, or to longer shots with little camera movement. The Flicker Reduction advantage of Camera Animation stays constant, regardless of the camera movement and length of shot.


Bjorn

Thank you so much for reviewing the files. I wish you had an answer for us. This problem leaves me in a very difficult position, business-wise.

So are we ready to say Cinema is not a particularly usable program for typical architectural animation? I am.

Camera animation is not usable when I end up with an hour or more to render a 3 minute frame. So which of the four modes of GI animation would you say I could use to produce my work, with the file you reviewed being fairly typical of my models and camera moves?

I rendered that exterior animation with stochastic (still running frames right now) and at least the frame times are stable, though long. Now I have the interior, which is testing at an hour per frame for stochastic, so not viable. I'ld try baking...if my 9.5 would hurry up and get here.

[Srek]

Honestly i wouldn't have choosen GI for this animation. To make a flicker free GI animation you need this kind of rendertime. If it is timecritical and it has to be animated then it is better to create a standard lighting setup instead of using GI.
Alternatively you can try to use much higher GI settings without Camera Animation, this would give you high but more predictable rendertimes for each frame.
Once you have 9.5, baking should be a good alternative too.

Cheers
Björn

[Simon Wicker]

now that the word has come down from on high from srek and marcus i'd like to apologise to ernest and strat for being the insufferable sceptic. sorry guys! especially that there doesn't seem to be a work around for the problem for your scenes. hopefully some of the ambient occlusion and baking in 9.5 will help you out.

cheers, simon w.

[AdamT]

Seems to me AR needs some additional methods for dealing with GI. As I understand it, both VRay and fR-2 are able to do animated GI scenes without flickering *or* frame creep. I don't know how they do it, but I have faith Philip will find a way. :)

[Ernest Burden]

Seems to me AR needs some additional methods for dealing with GI. As I understand it, both VRay and fR-2 are able to do animated GI scenes without flickering *or* frame creep. I don't know how they do it, but I have faith Philip will find a way. :)

I asked this earlier in the thread:

Is there any consideration being given to a Lightscape-style mesh refinement method of GI? Such a method has been added to Max (and not very well, from what I've seen). Is this something that Maxon is testing or has it already been looked at and rejected?

I realize that what we are talking about here is weighted to the oh-so-boring field or architectural visualization, and therfore does not affect everyone. But I think that is an important market for the C4D product, especially in the United States where its market share is less than in Europe. I think the product needs to either develope better methods for arch-vis animation, and fast, or start admitting these deficiencies to prospective customers in my field.

This problem is causing me some serious stress right now. I will try other ways to get my work done, but so far the only suggestion I am getting is 'don't use GI for animation'. That just doesn't cut it for me.

[STRAT]

Alternatively you can try to use much higher GI settings without Camera Animation, this would give you high but more predictable rendertimes for each frame.

Cheers
Björn

thats something i've use in the past, but to completely eliminate flicker you MUST use an accuracy of 100% with relatively high stotch samples. but then you may as well use stoch mode instead :sad: a lower accuracy (even 99%) with uber high samples just doesnt work.

Is this something that Maxon will look into rectifying? if FR2 and Vray and Max dont suffer, why should C4D?

Simon - no sweat m8, it's a frustrating thing, and difficult to purposfully recreate. when i get time i'm definately going to try 9.5 baking, but unless it's a mirical solution i doubt it's up to the job. i'm most cynical at the mo, but hey, i hope to proove myself wrong. besides, hopefully FR2 will solve all probs when it finally arrives too :)

but ultimately i want to do it all in the AR via GI camera animation :twisted:

[wuensch]

I dont want to sweet-talk an obviously not satisfying feature here, but with xhundred frame Gi animations I would seriously consider to outsource rendering to a renderfarm.
I dont know about FR2 or Vray, but i know that Mentalray also needs some serious rendertime for flickerfree GI .
GI just taking its toll on redering, i guess.

Baking is no wonderweapon, but could be an alternative for you.
The Baker is kick-A* as far as I have tested and super-convenient to use, so you will be testing the usability as soon as you have 9.5 i guess.
If you donta naimate the light it might be the best solution.
Sky is also a very mighty tool , btw.(not that that has anything to do with it ;-)


Olli

[Continuumx]

Honestly i wouldn't have choosen GI for this animation. To make a flicker free GI animation you need this kind of rendertime. If it is timecritical and it has to be animated then it is better to create a standard lighting setup instead of using GI.
Alternatively you can try to use much higher GI settings without Camera Animation, this would give you high but more predictable rendertimes for each frame.
Once you have 9.5, baking should be a good alternative too.

Cheers
Björn

I was about to comment, that since nothing is changing in this scene except the camera (if I understand it correctly) then scene baking is the way this kind of scene would be done if I were to do it.

[AkaKico]

I'm really enjoying AO. Fun on all levels. Playing with AO+ Sketch & Toon

[Ernest Burden]

since nothing is changing in this scene except the camera (if I understand it correctly) then scene baking is the way this kind of scene would be done if I were to do it.

Normally that is the case, I just use a static SUN. In the case of my current project I animated the sun position to give me the best shadow angles on the two ends. But I could have gotten by without moving the sun. I also have an animated color gradient that puts parts of the picture into cool or warm light based on the view, so I was just taking advantage of being able to animate these things. I hate to simply give it up.

I dont want to sweet-talk an obviously not satisfying feature here, but with xhundred frame Gi animations I would seriously consider to outsource rendering to a renderfarm.

That is how I have to handle the interior. But farms don't come cheap--the 3minute frame rendering for 1 1/2 hours X 2000 frames is going to bankrupt me. The same problem that happens on my machines will happen on the farm, too.

I dont know about FR2 or Vray, but i know that Mentalray also needs some serious rendertime for flickerfree GI .
GI just taking its toll on redering, i guess.

Baking looks like my best hope for the near future.

But look at all I was saying about Lightscape animation--no noise, no flicker, lightning fast per frame. There are ways to do GI-based architectural animation and not have to freak out like I'm doing now. But for now Cinema is seriously 'challenged'. What about vertex-colored mesh-refinement style baking?

[flingster]

I'm really enjoying AO. Fun on all levels. Playing with AO+ Sketch & Toon

cool idea...:thumbsup:

[lightblitter22]

I realize that what we are talking about here is weighted to the oh-so-boring field or architectural visualization, and therfore does not affect everyone.

Think so? Read these threads:

http://www.gamedev.net/community/forums/topic.asp?topic_id=311544
http://www.gamedev.net/community/forums/topic.asp?topic_id=191523
http://www.gamedev.net/community/forums/topic.asp?topic_id=183185
http://www.gamedev.net/community/forums/topic.asp?topic_id=181977

That's realtime GI and raytracing for games being discussed. I don't know why some people here seem to believe that animation GI is some strange, exotic use of technology. We'll probably see Nvidia and ATI running neck-and-neck to produce the gamecard that can do the fastest GI, DOF, motionblur and so on at some point in the future.

[Ernest Burden]

Think so?

It seems that only we arch-vis guys are screaming about our little 'problem' with C4D. The fact that so many of you haven't even believed us shows just how few here actually use the same features we must be using. Like GI animation. Also, I wanted to show I understood that most of you probably have heard enough about this to vomit. I'm going to spew from stress, maybe.

[Continuumx]

It seems that only we arch-vis guys are screaming about our little 'problem' with C4D. The fact that so many of you haven't even believed us shows just how few here actually use the same features we must be using. Like GI animation. Also, I wanted to show I understood that most of you probably have heard enough about this to vomit. I'm going to spew from stress, maybe.


I agree wholeheartedly with you Ernest, architectural visualization is one of the technological forces that moves rendering technology and will continue to do so until we have full blown realtime physically accurate lighting/textural/feedback virtual reality (includes full blown persistant resolution and depth) at full scale physical immersion.

What does this all mean? Fully persistant, virtual designs that inhibit complete visual and tactile feedback in realtime. Now, not only can we show you an image of your new house, but lets take a realtime, fullscale tour of your new house before it is built, so we can verify that this matches your design concept.

Still I am impressed with AR2.5!

[LucentDreams]

Think so? Read these threads:

http://www.gamedev.net/community/forums/topic.asp?topic_id=311544
http://www.gamedev.net/community/forums/topic.asp?topic_id=191523
http://www.gamedev.net/community/forums/topic.asp?topic_id=183185
http://www.gamedev.net/community/forums/topic.asp?topic_id=181977

That's realtime GI and raytracing for games being discussed. I don't know why some people here seem to believe that animation GI is some strange, exotic use of technology. We'll probably see Nvidia and ATI running neck-and-neck to produce the gamecard that can do the fastest GI, DOF, motionblur and so on at some point in the future.

there is already raltime Motionblur dof, HDR, SSS, everythign except GI has realy been achieved in ralteime systems now. However, if you've seen any of the esamples that contain SSS, DOF,a dn motinoblur, you'll see they are at the level that CPU rendersystems were at ages ago, and still suffer form a lot of limitations. I can see us doing entire TV episodes and such using realtime renderers in the near future, and archviz I'm sure woudlnt' be tof ar behind. Personally I think a lot of clients woudl be more impressed with a well made realtime tour of their building then a few stil images or a non navigatable movie, but that all depends on the clents, I know a lot who are unwilling to pay or wait for things like GI in a still render of a room too. For every one of you Archviz guys doing the highend beautiful archviz renders, I know probably around 8 or 9 that never would get a job that woudl allow them to use such things, thats why renderers like the oh so crappy renderworks still get so much use. i think Maxwell has caused the one exception to this were the quality of the renders is really driving a willingness for smaller fimrms to investigate realistic rendering technologies, which is ironic imo as they are so much slower compared to Vray, AR, and the likes.

It will be a long time stil before realtime systems are used for films, but the technollogy is getting there. Seriously can't way to play games though that have motionblur an dDOF at the same time.

[Continuumx]

there is already raltime Motionblur dof, HDR, SSS, everythign except GI has realy been achieved in ralteime systems now. However, if you've seen any of the esamples that contain SSS, DOF,a dn motinoblur, you'll see they are at the level that CPU rendersystems were at ages ago, and still suffer form a lot of limitations. I can see us doing entire TV episodes and such using realtime renderers in the near future, and archviz I'm sure woudlnt' be tof ar behind. Personally I think a lot of clients woudl be more impressed with a well made realtime tour of their building then a few stil images or a non navigatable movie, but that all depends on the clents, I know a lot who are unwilling to pay or wait for things like GI in a still render of a room too. For every one of you Archviz guys doing the highend beautiful archviz renders, I know probably around 8 or 9 that never would get a job that woudl allow them to use such things, thats why renderers like the oh so crappy renderworks still get so much use. i think Maxwell has caused the one exception to this were the quality of the renders is really driving a willingness for smaller fimrms to investigate realistic rendering technologies, which is ironic imo as they are so much slower compared to Vray, AR, and the likes.

It will be a long time stil before realtime systems are used for films, but the technollogy is getting there. Seriously can't way to play games though that have motionblur an dDOF at the same time.

Kai, you took the words right out of my mouth here. But I have no doubt this technology and more will be here within the next 20 but at the pace of technology must sooner like 10 to 15 years.

My evidence for this is it was not that long ago, circa 1987, that the stage of 3D rendering was little more than black and white dithered forms on an Atari 1040 ST, or simple color filled polygons mostly primitive objects on other privately affordable computer systems. Short of 20 years, the biggest rave for the personal computer was the ability to render ray traced reflective mirror surfaces--Those images took days to render!?!?!?! I think I still have one of them somewhere for viewing.

Now 20 years later, we can rival any photographed image. In the next 10 to 15, the visual field of virtual reality should be in complete refinement and I do hope that the field of tactile rendering on personal computer systems will have begun. At that time, there would probably be files that you could download that some tactile artist created that when rendered mimics the feel of plush velvet.

But it does not stop there, not only can you render this, but you could say, render it in such a way that you feel every micro-fiber and you could even feel every micro fiber, one fiber at a time.

[lightblitter22]

Kai, if you have Halflife 2, get Gary's mod to play around with DOF, bloom, color correction and so on:

http://www.garry.tv/garrysmod/wiki/index.php/Main_Page

Its worth it just to see how powerful the Source engine's dynamics capabilities are.

[Ernest Burden]

it was not that long ago, circa 1987, that the stage of 3D rendering was little more than black and white dithered forms on an Atari 1040 ST, or simple color filled polygons mostly primitive objects on other privately affordable computer systems.

In 1987 I began using 3D modeling to layout all of my renderings. The first one was a somewhat ornate 20 story or more tower in a city environment. Modeled, perspective layout and then transfered to illustration board and painted.

[STRAT]

hmmm. not impressed yet. i've installed it but havent been able to put it through it's paces as yet, other than a few renders. so i'm prolly being a tad hard on it so far.

and i can report there's so far a big fat ZERO in render speed increases. (give or take literally 4 or 5 seconds over a 3 min render)

trouble is, all my meshes are imported from other applications. absolutely nothing is C4D created. so i suppose the new AA algorithms that are massively sped up will have no effect on a non-c4d created object :(

i appreciate the area shads and blur refs may be faster, but for plain old gi rendering, unless you use the c4d nurb orientated meshes, i'm so far not getting no speed increases whatso ever. not a sausage.

looking forward to testing AO though :)

[AdamT]

AA advances should work with imported as well as native meshes. Most likely you're not seeing much improvement because your meshes are low-poly. Well, hopefully only two weeks to fR-2. [Is it here yet?] :)

[Ernest Burden]

Well, hopefully only two weeks to fR-2. [Is it here yet?] :)

Is 9.5 here yet?

US = last

Today would be great...

[STRAT]

the irony - us poor europeans getting something new way before our american friends :p

Adam - 2 weeks to go eh? cool, i'll quote you on that ;)

[AdamT]

Adam - 2 weeks to go eh? cool, i'll quote you on that ;)
It's just based on Cebas' expected ship date. No inside info. here.

[lightblitter22]

the irony - us poor europeans getting something new way before our american friends :p

The concept of purchase-and-download is too 21st Century for Europe I guess. My condolences while you wait for the delivery man to come riding by on his steampowered horse cart. :applause:

"Honey, what's that hissing noise outside? Sounds like something is on fire."

"Nothing darling. That's just steam-ex delivering the new C4D update on stone tablets."

[lllab]

you really wanna download some gb's of data? (thats what the maxon cds are, even for the update with all extra stuff this would be a hefty download:-)
stefan

[lllab]

Adam:

" It's just based on Cebas' expected ship date. No inside info. here."

i hope they do a really good developed, production use- first release(not like the maxwell trauma). if this takes a tiny bit longer i dont care...

cheers
stefan

[AdamT]

Adam:

" It's just based on Cebas' expected ship date. No inside info. here."

i hope they do a really good developed, production use- first release(not like the maxwell trauma). if this takes a tiny bit longer i dont care...

cheers
stefan
I'm with you, and that's basically where I'm at with Maxwell--not interested in playing around with a half-baked product if it's totally disconnected from development.

[Continuumx]

I'm with you, and that's basically where I'm at with Maxwell--not interested in playing around with a half-baked product if it's totally disconnected from development.

I am really excited with the this update, the new lights are blowing my mind along with the new 32 bit image exports. Image quality has increased. I need to spare some time to run through that AO tutorial by JamesMK.

[Continuumx]

Just finished both AO tutorials by James MK!

Excellent tutorials (Maxon - these should be included in the addendum for R9.5/AR2.5 because they are that good!), AO is really sweet, fast renders very comparable to GI. If you need it faster than GI can give it to you, then AO is your new best friend! It would also be in my opinion an alternative if you have a lot of elements, i.e. lights, environmental effects, heavy polygon scenes, and the rest of the bag of effects and tricks, then this is hands down the way to render.

R9.5 and AR2.5 are shaping up to be absolutely the icing on the cake for fantastic image color depth output and snappy new render ability with the new lights, small features, and AO!

[rsquires]

Just finished both AO tutorials by James MK!
!

Can you point me in the direction of these tutorials

regards

Richard

[Continuumx]

Can you point me in the direction of these tutorials

regards

Richard

Sure,

ref:

http://forums.cgsociety.org/showthread.php?t=266704&highlight=jamesmk

[Continuumx]

Just stumbled across an interesting thread over at Cebas Final Render forums,

Hope this answer helps Maxon tech with the Advanced Render related problem.

GI sample accumulation slowdown:

ref thread: http://www.cebas.com/forums/cebas/viewtopic.php?t=3011

Repost of conversation:

Fredrik Gullberg
Joined: 24 Feb 2004
Posts: 13
Location: Sweden
Thu Sep 29, 2005 2:55 pm
Post subject: Increasing rendering times?

When rendering an animation the rendering times are increasing. The scene is quite similar in all 300 frames. It is an architectural walkthrough. The first frame takes about 6 minutes in 768x432 pixels. When reaching frame 80 it takes 22 minutes. I'm using DR with a total of 5 dual XEON 3.6GHz, 4GB RAM each. As you can see it is a quite difficult scene. Anyway when resetting the GI-solution and render frame 79 and then reuse solution on frame 80 it takes about 7 minutes. From 6 to 7 minutes is a reasonable increase depending on what is visible and so on, but from 6 to 22 minutes? That's not OK.
By the way, the problem is not related to DR. I've done tests on 1 machine and the problem remains. There is a large number of animated maps in the scene (walking billboard people). Can this be be an issue?
_________________
Fredrik Gullberg


Ronald Mc Cargo
vcc
Joined: 05 Feb 2004
Posts: 431
Location: Germany
Thu Sep 29, 2005 3:52 pm

Hi, it seems as if the GI solution you´re reusing isn´t sufficient to the end of the animation. What happens is that additional GI information has to be calculated for every next frame.This accumulates and therefore rendertimes get longer. The less initial GI information is given the more it has to calculate later on. So, the best way is to gather a detailed GI solution from the start. I assume you precalced every 15th frame of the animation for the GI solution. However, I think your settings were too low.How long does frame 80 take if you only render it alone? If it´s a lot faster than I´d redo the GI solution with higher settings using the 15th frame technique.

cheers


Fredrik Gullberg
Joined: 24 Feb 2004
Posts: 13
Location: Sweden
Thu Sep 29, 2005 4:15 pm

If I render frame 80 alone it takes about 12 minutes. That is from scratch with a reset solution. It is not logical that it should take more time when reusing solution. (f80, 22 minutes when starting from f0)
I haven't used the 15th frame technique. Is that really an efficient way to go at it? Meaning does it save time until your total animation is output? You still have 2 separate passes to run before you have a finished image. In every pass the maps have to be loaded, the DR have to be synchronized and so on.
_________________
Fredrik Gullberg


Ronald Mc Cargo
vcc
Joined: 05 Feb 2004
Posts: 431
Location: Germany
Thu Sep 29, 2005 6:25 pm

I know it doesn´t sound logic at first when have longer rendertimes even with a reusable solution. Look at it like this:You rendered a GI solution for the first frame.Now, the further away you get from this point in 3D space the more extra samples have to be calculated in order to fill in the missing GI information.So rendertimes will gradually increase during your animation even if reusing the solution.However, if you precalc a GI solution for the whole animation by rendering every 15th frame first with reuse on and then saving this solution, then Finalrender doesn´t have to calculate new samples during animation.You´ll have a nearly global solution for the scene.Therefore rendertimes will might even drop during animation.

cheers

[AdamT]

Interesting. But not much fun manually rendering every 15th frame!

[andronikos916]

but I think that render slow down is with fR st1 not st2... or am I wrong?

[AdamT]

Hope you're wrong, but if they're using the same basic methodology I imagine the issue is still there.

[Continuumx]

Hope you're wrong, but if they're using the same basic methodology I imagine the issue is still there.

It is an interesting phenomenon. If they were able to solve the issue with FR2, I see no reason why Maxon could not look at this more closely to clear it from AR2.5 or AR3.

From the sound of it, rendering every 15th frame is not bad since that time is still much faster than the increasing accumulation of sequential frames that directly affects render time in a similar increasing length.

Rendering a example frame by itself yields much less than half the time of the accumulation example would be reason to do this. Is this a feature in animation that you can set which frame resets the gi solution in AR? I do not recall this, it is either reset for each and every frame or is reused for each and every frame. It would be nice to specify when to reset the gi solution calculation.

[Continuumx]

Interesting. But not much fun manually rendering every 15th frame!

The biggest part of the discussion was that the initial GI solution calculation may have not been sufficient hence, the additional samples needed to calculate the later frames.

I wonder did anyone test this with the AR?

[Ernest Burden]

The biggest part of the discussion was that the initial GI solution calculation may have not been sufficient hence, the additional samples needed to calculate the later frames.

I'm so sorry I checked into CGT tonight. I thought FR was without this problem. Remember that I never encountered GI flicker or time accumulation before working with C4D, since Lightscape was a baked/embedded solution. Anyway, I'm going to bed and may not get up for several days. Except for those deadlines...

I wonder did anyone test this with the AR?

You mean forcing a 'wide shot' GI frame to start an anim. sequence? No, I don't think we did. It's an interesting idea. Or, do you mean did we test the 'render every 15 frames for a GI post', no, there is no function to allow that within AR. Interesting that FR felt such a function was necessary. It's like the option when rendering animation out of Premiere to force a keyframe every -x- frames.

Did I mention that with that hospital animation I was doing I rendered the exterior with stochastic and the interior was largely baked? Any port in a storm.

[STRAT]

i'm hoping fr2 for c4d will iron this out.

but if not, the option for the renderer to auto recalc the gi solution at a set amount of rendererd frames pre determined by yourself would be ideal. a solution where it recalcs the gi solution mid render without the need to physically stop the render process atall.

[lllab]

if the mean the 15th(or25th) frame method used in vray it should work very well.

vray does that for you, you can set that up for an animation, the irradiance maps only is calculated new every xxth frame, in between it reuses a saved one i think. this method is very efficent and fast for vray users- so i think they mean something similar.

i guess you can do a precalc and then tell fr to renew(and flush the unused stuff) it every 15th frame...

well at least i hope fr can do this too . (vray and i think also brazil does it as described above no flicker of course in this method)

cheers
stefan

[STRAT]

sorry for the late rant guys, but i apparently posted this in the wrong post, and i just thought i wanted my feelings on the subject known. nothing drastic, just my personal opinions.

I'm a massive c4d renderer fan, but what do i like best about it the new 9.5? not much, or should i say nothing special. same as the other releases as far as i'm concerned.

i use c4d purely as a renderer, and have been dissapointed across the board, mainly with the reported render speed increases i was expecting, which so far have been neither here or there.

* the texture/light baking is a no go for complicated complex archi modelling rendering when dead lines loom.

* the AO is pretty sweet, but needs refining as far as speed goes imo. it's faster using conventional gi instead.

* stoch mode rendering is still off limits.

* and the render slowdown bug for gi animation rendering hasn't been looked at.

* havent tried the skyshader yet though, and even though the blurry refs and area shads are faster, i dont have much use of them.

* i'm still eager for unlimited material paths. i know there's work arounds, but 10 is nuts imo.


there are obviously some nifty little tid-bits added like double click for new material, full screen mode, updated tags etc etc, but even with these they dont really bother me - i just take them or leave them.

nothing's obviously perfect, but i've massive hopes for FR2. This is a dedicated render engine and the first proper dedicated render plugin for c4d, so Cebas hopefully should be ploughing all their efforts into it, where as the AR2 is part of a bigger machine. i hope i dont suffer the same dissapointments.

[STRAT]

if the mean the 15th(or25th) frame method used in vray it should work very well.

vray does that for you, you can set that up for an animation, the irradiance maps only is calculated new every xxth frame, in between it reuses a saved one i think. this method is very efficent and fast for vray users- so i think they mean something similar.

i guess you can do a precalc and then tell fr to renew(and flush the unused stuff) it every 15th frame...

well at least i hope fr can do this too . (vray and i think also brazil does it as described above no flicker of course in this method)

cheers
stefan

as long as you can do this without physically stopping the render process then all will be fine. anything else wont be acceptable.

[lllab]

as i said, i just now about vray- but for sure there it has nothing to do with stopping the animation? why what for? it is only i kind of more intelligent calculation method. (mabe comparable like keyframes in animation codecs).

beside do you really have no speed increase? i have massive increase here- the AA alone, and the lights etc...( i remember how i wished to use arealights and shaods- but is was impossible- now i use them and have rendertimes as i had with normal lights before!- wonderfull)

cheers
stefan

[STRAT]

there are obviouse speed increases, but i find only in the area lights and blurry refs, both of which i dont use much.

but i questioned the precalc issue because as it stands you have to stop the anim to physically re-calc in the AR, it's the only way, but not apparently so in FR :)

[Ernest Burden]

but i questioned the precalc issue because as it stands you have to stop the anim to physically re-calc in the AR, it's the only way, but not apparently so in FR :)

Remember that with AR and the accumulation bug, that when the time builds up, if you stop and then restart it (as easy as closing and re-starting a NetRender client) the time drops back to the original---BUT you get a big, ugly flicker! This recalc every 1/2 second had better not create a visible seam or we're no better off than with using the AR version.

STRAT--Baking is a very good option. Remember what I did with my hospital interior--I baked some key big stuff at a high setting, about 95%, and left all the rest alone. Doing so gave me a significant time savings per frame. So you burn a few hours baking large, critical stuff and end up with a map you can tweek if need be, but get much better render times ever after, and no flickering on those surfaces. I did my frames at 25% accuracy.

[STRAT]

STRAT--Baking is a very good option. Remember what I did with my hospital interior--I baked some key big stuff at a high setting, about 95%, and left all the rest alone

so you didn't bake the whole scene then?.

when you say 'key' stuff, what exactly is determined as 'key' stuff? how/what is it you decided to bake and what did you leave alone, and why?

and then when you set the final animation rendering with your 25% accuracy, what were the frame times like on that?

[Ernest Burden]

when you say 'key' stuff, what exactly is determined as 'key' stuff? how/what is it you decided to bake and what did you leave alone, and why?

No, I only baked parts. That was because it would have taken days to access all the objects and bake them and then copy the lum texture back into the original material (so I can keep stuff like my difuse noise and reflectivity). Baking a pre-made project is not so easy, since your OM structure is set up for normal use.

I baked the walls, some of the floor mats (the woodgrain one didn't bake well so I went back to the original mat) the doors, large ceiling area, that silly curvy wall in the middle. Watch the anim again (I sent a copy to STRAT, but haven't get posted a public one because of filesize/bandwidth) and look at those objects.

I had to set the baked stuff to generate GI, but the rendertimes were great. I think I went from 8 minutes to 3 per frame (I should check the baking thread) with no noticeable time accumulation across 2000 frames.

OK, my test times:
A test frame pre-bake 4:39
half-baked 1:50

[STRAT]

thanks for the reply.

it really is something i MUST research into. i can afford to wait until FR2 drops on my desk to try that first, as obviously the real gi solution would ultimately proove to be more appealing than baking would, but perhaps a hybrid bake would suit even better?

can you post the anim to my yahoo account please bud? my hotmail is pretty redundant these days. i did reply to you but i think there were a few crossed wires somewhere along the line.

cheers dude

[Ernest Burden]

thanks for the reply.

it really is something i MUST research into. i can afford to wait until FR2 drops on my desk to try that first, as obviously the real gi solution would ultimately proove to be more appealing than baking would, but perhaps a hybrid bake would suit even better?

Hybrid worked for me. I did not have time to modify the baked maps, but you have the option to do so at any point. You get to leave glass and small fiddly stuff alone and just bake big surfaces. You can then paint more or less 'radiosity' onto the maps, change colors in PS. My biggest problem was having to manually copy the lumin. texture back into my original material and re-apply it. That's why the OM structure got in my way. It was great for normal use, but a real pain for the baked stuff. Plan ahead, and it would be easier. The way the baker arranges the polygons of an object onto the texture is really good--flat rectangular stuff is laid out in an orderly ortho fashion. Really good if you wanted to do more work on them.

Link emailed, had trouble finding your Yahoo account, but did.

[STRAT]

hehe, sorry m8, should have posted my email addy here for you :p

anyway, d/l as we speak :)

[STRAT]

nice Ernest, very nice :) would be interesting to see the pre-noised version too, although i pressume the noise masks a fair bit of inadequacies in the render process that you had no time for (ie, AA, higher gi etc etc).

have you used the AO shader yet? i think the AO shader would have been IDEAL for this job. it doesnt loose render speed obviously, and, particulaly for your style, you can set a beautiful AO graininess during render time. and it's flicker free too.

did you see my interior animation test i did?


just an idea.

[Ernest Burden]

did you see my interior animation test i did?

No, where'sat?

[STRAT]

at the start of this post -

http://forums.cgsociety.org/showthread.php?t=278465

[Kutkin]

I'm really enjoying AO. Fun on all levels. Playing with AO+ Sketch & Toon

Excellent!
Any more tips how did you do that?

[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.