View Full Version : network rendering in combustion 2 (Mac)
10-06-2003, 01:23 PM
Okay, I have a couple questions regarding network rendering in combustion 2. First off, I know backburner isn't available for the Mac (hoping it will be in combustion 3), so the only way to do network rendering is the slightly less elegant render queue. My question concerns keeping failure rates down. Rendering a simple but dense particle workspace the other night on 8 iMacs, I had about 10 or 11 failures that required me to restart the render process on different nodes. I'm guessing this occurs when two computers end up rendering the same frame and try to write it, only to find it's already there due to timing difficulties. Is there any way to avoid this problem, minimize it, or at least have each node restart the process after failing automatically?
Of course, I haven't tried any renders aside from this particle one, so maybe straight-up composites work better. Thanks in advance.
10-06-2003, 02:53 PM
I might be way off, but one idea might be to set each slave to jump 8 frames, which means.. render 1,8,16,24 on the first machine, render 2,9,17,25 on the next etc etc. If they're somewhat equal in speed this should at least keep the machines out of their own way ;) OR of course to set the sequences to 1-20, 21-40, 41-60 etc, on each machine.
But then again, I'm not familiar enough with c*, so I dont really know if there are such options (there are in most apps tho)
10-07-2003, 01:59 AM
it shouldn't happen really, as long as you have set "skip existing files" as soon as a renderslave starts a frame, it writes a placeholder, & if another machine see's that, it moves onto the next one. You arn't rendering with hardware OpenGL or anything like that are you?
10-07-2003, 05:25 AM
It is set to skip existing frames. Why would hardware OpenGL cause difficulties? And, where would I check for that in the render queue (or render settings for the workspace; which take precedence?)
10-07-2003, 06:17 AM
I just ask about the OpenGL because a lot of Macs seem to have less than stellar OpenGL performance with the graphics cards they ship with, so it could possibly be where the problem lies (particles being pretty heavy on the OpenGL usage). The setting is in the preferences of combustion (use software OpenGL - on). Its usually best to use software opengl when network rendering anyway as sometimes even a change in video drivers from one machine to another can give different rendered results...
Other than that I cant be of much help sorry as I use backburner. It wouldnt be some kind of maximum network connection error could it? I dont know how many max connections your OS can take :shrug:
10-07-2003, 06:55 PM
I think the trick is that it's essentially unmanaged. I'll do some more tests with non-particle workspaces and see how it works out. Actually, I'm surprised there aren't more Mac combustion users here. Seems to be mostly Windows.
10-08-2003, 02:30 AM
Did a 3D comp tonight on 12 iMacs, no particles, all software rendering. The failure rate was astounding. Everytime the error was identified as "save failed - general I/O error."
The server I'm rendering to is just a Mac of some sort, the drive being HFS, or Extended HFS, whatever's standard these days. It's shared over AppleTalk.
I'm thinking that perhaps due to the filesystem structure, placeholders aren't being written. That's the only reason I can come up with where one node wouldn't see that a frame was being rendered, render it, and then see it when it went to save. The error isn't descriptive enough to confirm that this is what's happening, but I'll assume for now.
Also, without knowing which settings are dominant in a render queue network render (the settings provided by the workspace, or the render settings specified pre-workspace load), I can't assign computers to render a certain segment. And I can't find an option to skip frames anywhere.
Anyone else have ideas, or does everyone use Windows and backburner?
01-16-2006, 06:00 AM
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.
vBulletin v3.0.5, Copyright ©2000-2013, Jelsoft Enterprises Ltd.