I’m struggling with the new Teamrender and would like to know, if I’m missing something there.
We are a small team here using C4D, for VFX and Animations, rarely stills. And therefore, I see the benefits for Stills, so no discussion 'bout that.
So, our Problems are:
When I setup a renderjob for the Farm, I have to use the Rendermanager, and for this my C4d has to be running. When the animation renders 2 days, I can’t restart my PC or even my C4d, or what happens when my c4d crashes, because I have to work further, while the animation renders on the farm?
Why isn’t there an external Rendermanager? When my Rendermanager is working, he uses quiet a bit of my ressources althoug my PC isn’t rendering for the job. A wanna have a dedicated pc which is doing that.
When someone else in the my team is rendering, I have no chance to see, who is rendering! So I have to ask. Managing priorities in our team went difficult, because I don’t see, wich projects are in renderqueue and who is rendering with which clients and so on…
When I startet my Renderjob, I can’t add or remove a renderclient for the actual Renderjob. Why not?! I have to stop it, and restart with the new selected clients. When one frame is rendering an hour, this is a big waste of time.
This is just my first impression, but it drives me crazy. How do others use this in a real production team now?
Yeah. Glad somebody noticed. The more people that bring this up, the more chance of something being done about it.
We are currently exploring other solutions for network rendering. I know the Butterfly Net render guy is working on better C4D integration right now, it may be a good cost effective solution. Although you still have to buy the license server and command line licenses. Sigh.
Personally I plan to keep using R14 net render with R15. The scenes files are compatible so long as you dont use one of the new GI methods, just quickly load it into r14 and check the gi if youre using it, then send it to render on Net 14.
Team render is nice, its a great new tool which I will certainly be using, but it should probably have been introduced alongside net for at least 1 version until all the shortcomings were addressed.
There seems to be a general consensus that although people upgrade to the latest version when it is released due to their MSA expiring, and the threat of future cost upgrades escalating if one does not upgrade, that a lot of people will still be using V14 and earlier for a considerable time ahead.
I have only really started using V14 about 4 months ago, and still use V11 at some of the practices I freelance at. I hated V12 and V13 for a variety of reasons.
maybe this time next year V15 will have matured into a useable product with the Team Render/ net render issues sorted.
Pfew, I’m glad to see that I’m not alone in this. In one of the earlier discussions Björn wrote that only 10 people complained at the Maxon site. So I was already afraid that I was one of the very few that had problems with TR. And as so few people have problems with TR it might not seem urgent to Maxon to solve these issues.
This weekend I did a test, rendering an animation. My farm was rendering, and I left my workstation out of rendering. But then, while working on another project, C4D crashed. And yes I had to render the animation all over again. When you pause TR records how much has been rendered. But not when C4D crashes.
So for me too, no production work with TR. At least it’s a relief that R14 Net can read the R15 files as long as you don’t use GI.
I’ve had the exact same problem as Arjo. Queue up a pile of renders, and then keep working. I’m not using my main machine as a render node, just using it to serve up the TR to the Mac Mini renderfarm. But I’ve had a few crashes, and Cinema 4D takes the whole queue down with it. There isn’t “calculating where it left off” with unfinished frames, since blocks of frames are distributed to eight machines. It’s a mess, and completely unprofessional. A standalone TR server is an absolute must-have. And yes, I’ve already emailed Maxon about it. Adding my completely displeased voice to the discussion.
i have additional testing to do but i have other concerns too - like what happens when a TR client is quit or crashes running an animation? does it have to wait the timeout before the frame is reassigned?
NET Server was nice in that a NET Client was quit on purpose the NET Server immediately noticed it and reassigned the frame. and if one NET Client crashed the timeout needed was usually not so long that the client eventually timed out and the frame was automatically reassigned.
the issue being that for big DR jobs you may need a decent timeout for the high network traffic (i notice default is a huge 7200 seconds - or two hours) so in a DR render - where a relatively small bucket may run in minutes it is now stuck for that long of a render time before properly timing out? - that or you have to restart the whole render to free up that bad bucket? that certainly throws out a lot of speed gain in DR potentially
and what happens if the timeout it not turned on (as default is off) does the bucket just sit forever stuck in limbo as the client has crashed? (or will it restart if the TR client is restarted?) meaning you must stop and restart the entire DR render to complete it? (and pray another does not crash or get quit?)
plus the genius of NET Server that if NET Server crashed the NET Clients would go on happily rendering what they have assigned and will simply hold and send in the completed results when the NET Server restarted…
i have more to do in testing, i don’t know if anyone will even answer these questions - but i will run some jobs and purposely crash them or turn them off and see the results hopefully this week.
I did some tests with stills and animation. Not enough yet, but production has priority over testing
Anyway wath I met so far:
I tried three still image projects on eight machines. One went fine. Two of them had problems when I added more than 4 clients. Randomly clients wouldn’t want to render. Sandro suggested that it might be a time out problem. But I had no time yet to test with time out setting turned on.
However turning on timeout could have a bad influence on render time.
One other project, rather large in terms of polygons (cad import of 700K) and quite large textures doesn’t want to render at all with TR. After starting it, I see no processor activity and I can only quit the render by force quitting C4D. I still have to send the project to support to see if they can find the problem.
In general TR for stills is not always the most efficient solution. Breaking up the image and gathering the buckets across the network means some loss in performance. In many cases you have to render different view points of the same project. So I did a test with 8 images on 8 computers. With TR it took 2,5 hours, with Net it took 2 hours. Of course this depends on network quality/speed. As TR uses peer to peer the difference migt be smaller or TR even faster. But it’s something to keep in mind.
Rendering an animation I had a crash one time, freezing C4D and the clients another time (processors stayed at full 100%). And one time a succesful render.
I’ll be testing over the next week or so, tried a still yesterday with 2 machines which worked well but I’m nervous about the animation side in production.
As a frequent NET user all this talk about losing (semi)intelligent frame assignment and hang ups when clients crash makes me seriously uneasy. I am putting my 2cents in the suggestion box over at Maxon right now regarding a render manager. Compared to all the other legacy stuff they drag along for years this cutoff feels a little abrupt.
NET was not without fault, but probably didn’t deserve the death sentence until Team Render was production ready. Using R14 sounds like a good option but also sounds like a minefield regarding plugins etc. only time will tell I guess
Once again, another frustrating night of renders that bomb out or get hung up. When TR works, it works well with my Mac Mini render farm. But when it doesn’t go well…I have to screen share into each node and force quit the spinning beach ball. It usually happens if a render node goes offline or won’t accept a render. Then I try to “restart client,” but it takes the rest of the nodes down with it.
most plugins do not serial number check under NET Server - but to run under your C4D and the render queue you have to get new R15 serial numbers for everything
many of the plugins i have are also giving errors as they are version checking the C4D app where they just happily ran under NET Client (some older plugins still work all the way to R14 despite being R12 builds or earlier)
also for those who are considering the very expensive step of purchasing a new copy of C4D just so you can run it on a dedicated computer as a central render queue - keep in mind that means you will need to purchase another new version of ALL your plugins so you can serialize it to the other copy of C4D (yet more expense)
i’ve yet to get plugins installed on my TR clients yet - still just trying to make sure they all work with R15 (most plugins i have i only use for the farm under NET Server so i’ve never needed to run them under my C4D app - some under R15 have created issues where i had to force quit C4D R15, so not sure how they will react under TR client yet)
about 15 of my 40 plugins need updates to run under R15 - certainly will be a slog to get these all worked out… : (
just more info for those looking to use Team Render and have not hit this point yet