Formas Abstratas
"A small scene with heavy artworks on the composition nodes. In this scene a large array of transforming cubes follow some musical movements."
Session details
Session CPU Use
Session log
|
2011-12-01 22:16 UTC Registration
2011-12-01 22:23 UTC Submission
2011-12-01 23:46 UTC Accepted by admin
2011-12-01 23:46 UTC Preprocessing begin
2011-12-01 23:46 UTC Preprocessing ends
2011-12-01 23:46 UTC Render begin
2011-12-04 11:59 UTC Render ends
2011-12-04 11:59 UTC Postprocessing begin
2011-12-04 11:59 UTC Postprocessing ends
2011-12-04 11:59 UTC Encode begins
2011-12-04 12:57 UTC Encode ends
|
Comments
I was following this and some frames rendered really fast. But the last 15 ones are taking a big amount of time to render.
I think this has something to do with the ram requested. Some frames took an average of 6 minutes to render in my core2quad using almost 2gb ram. So I send the file demanding 2gb but I see in status that only 500mb were actualy requested. I believe this is why some machines are taking 10 hours to render some frames.
Other thing I noticed is that the frames rendered in my machine are in average 50% smaller in filesize. Do the renderfarm clients change the png encoding settings?
How can I follow these WUs? Did I made something wrong here?
You probably should have requested more ram. The 6 minute workunits seem to use about 1.5GB (peak). Gekko usually catches this when he approves the session, but may have missed this one.
I still don't understand why the 10 hour results (which are failing). I have a client that has been stuck compositing (Node Blur.002) for 4 hours. Maybe there's a bug in the compositing(?).
Gekko is the expert, maybe he'll chime in here.
This is a beautiful render BTW.
Actually I did requested more ram but it was approved with 500.
I was rendering the missing frames here and I realized that indeed the problem is the defocus blur node. And I have a theory: The reason of the extremely high prossesing demand are some objects that are extremelly close to the camera, covering all the view. So the node wants to calculate an high amount of blur but never ends because it's lot's of blur above more and more blur.
Is there a way to cancel the request?
Ah, sorry. Didn't notice this one was stuck / convo was going on here. That is some really odd stuff. I can't really figure out why the frames take so long all of sudden, but as you say it might be something like being close to camera. I filled the missing frames with dummy entries so the session doesn't cause more problems with the hosts. Sorry about the memory, I must have had my brain asleep while checking this.
DoF with z-values that are way outside the focal plane will cause the blur to take a really long time. For each pixel the compositor will have to perform a complicated sum over a large number of nearby pixels when this happens.
The DOF makes it look so much real.
I wonder how is this thing animated...
The scene is actually an experiment. The whole thing is just one default cube with 3 array modifiers, one deform and one displace modifier. Some modifiers are set to an empty. So all the animation remain on the camera movement and some modifiers parameter. The light is just one sun and simple ao.
The background is the same image from the render rescaled, inverted, blurred and color corrected.
Gee, that's wonderful =P
Not yet rendered but looks amazing, I'll be checking this one. If you got your finall proyect on the web let me know!
AbarcaRodriguez.com | @kinduff