Team Render Q&A

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

REPLY TO THREAD
 
Thread Tools Search this Thread Display Modes
  07 July 2013
Originally Posted by mism: Do you have to pay for the command line version of C4D?


+1 to your +1

From my last query I believe it was about 1K USD. Best to talk to Maxon though.

We could (maybe should) be using a dedicated render manager. But even the guys here who also use Maya prefer NET for its simplicity over back burner.

NET definitely needed a tune up, don't get me wrong--there were missing features that would have helped a lot as well as a few bugs, however it was easy to use and overall worked very well.
 
  07 July 2013
Originally Posted by dann_stubbs: you apparently have not seen the CPU monitor of a NET Server machine and lots of render clients getting 32 bit EXIF 4k or larger renders pounding it.

some of us need a dedicated machine, individual users i suppose may not.


I could be mistaken, but I was under the impression that the machine that sets up the RT render doesn't necessarily have to contribute cores to the render.

Quote: and what happens with C4D crashes? do the Team Viewer clients keep rendering and then reconnect and send in their data like it does under NET Server?

what happens when NET Clients crash? do they go offline but stay connected in TR? so what is the procedure to get them back online? restart the TR client and it comes back online where it was? or do you have to manually go back and add the remote client again?

dann


Good questions.
 
  07 July 2013
Originally Posted by JoelOtron: No disrespect Adam, but that seems to be the overarching problem.

In a production environment there are work flows in place for a reason. Im not going to explain them all, but Im sure Im not the only one who will be concerned with this new approach to render farm management once others find out about it.


No disrespect here either, but if you won't articulate your concerns they can't be addressed.
 
  07 July 2013
Originally Posted by AdamT: No disrespect here either, but if you won't articulate your concerns they can't be addressed.


My concerns are stated. Simply put, I do not want to put our render manger hub on a workstation that is already being used for production by someone else. We have a system in place for rendering, and it is separate from the production team's workstations.
 
  07 July 2013
Originally Posted by JoelOtron: My concerns are stated. Simply put, I do not want to put our render manger hub on a workstation that is already being used for production by someone else. We have a system in place for rendering, and it is separate from the production team's workstations.


Yeah, I get that, and hopefully Maxon will come up with some solution that allows you to keep exactly the same workflow.

Short of that, instead of uploading the ready-to-render file to the network drive where it would be picked up by the render manager and then distributed, you can send the file to the RT Queue directly. RT can distribute the render to your render clients and not use your workstation, or any other production workstation, unless you want it to. You can specify where you want the files to be saved. I guess a potential issue might be ... who is going to monitor the queue to make sure it's all working? Can anyone with any license manage the queue? Maybe Maxon can provide a free version of the program that can ONLY manage the render queue -- like the old NET manager?

Not trying to minimize your concerns ... just trying to help.
 
  07 July 2013
Originally Posted by AdamT: Not trying to minimize your concerns ... just trying to help.


Thanks Adam
 
  07 July 2013
Originally Posted by Srek: This workflow is not supported by TR, it is not a drop in replacement for Net but a competley new paradigm on sharing computational ressources for rendering.


Ugh! This is exactly how we do it also as we could be at various points in the country. That means you'd have to set up some kind of VPN system to get this kind of workflow with TR. :(
__________________
2014 Reel
Company website
Behance Portfolio
HyperactiveVR
I reject your reality and substitute my own
 
  07 July 2013
Originally Posted by mism: Team Render sounds great for small teams for whom Net Render was too involved...


Right, so there is no disrespect here intended toward anyone, but I just have to wonder for whom NET was too involved? One of the things that was great about it was just how uncomplicated it was.

I'm a little worried about this TR concept, especially as I too have run my share of jobs through Render King, and I'm sincerely hoping this doesn't screw that whole thing up. Personally, I feel that render farms are a crucial part of the 3D workflow, and I can simply not imagine why Dann wasn't asked to be on the beta team for this release, as his input while designing a whole new DR system would have been invaluable.
__________________
Mac Pro 12 x 2.6 GHz 64GB Quadro K5000
OSX 10.10.4
MacBook Pro 4 x 2.3GHz 16GB GeForce GT 750M
OSX 10.10.5
C4D R18 Studio/CC/VizRT
Will's Works
 
  07 July 2013
I'm sure that things will work out fine once people get a chance to explore the workflow. Hope so, anyway. For me, personally, I'm thrilled with RT. NET wasn't too complicated, but it was annoying for my little render garden. It forced me to assign a static IP to my manager machine, which I don't like. It was stupid about assigning and reassigning frames when I have machines of vastly different speeds. It provided poor feedback. It couldn't split up single frames without me having to jump through hoops. It couldn't distribute caching duties. In general I often found it more trouble than it was worth. I think I'll get a lot more use out of RT.
 
  07 July 2013
Originally Posted by AdamT: I could be mistaken, but I was under the impression that the machine that sets up the RT render doesn't necessarily have to contribute cores to the render.


on OSX at least the CPU's are PEGGED to max when it is doing the conversion from b3d to output format... and it does not even need to be 32 bit massive res EXIF for that to happen either... when files are streaming in fast the CPU's are overloaded, some of this seems to be dependent on the output file type but still i see it all the time, next time i'll screen grab the CPU monitor and show it

then add in the sending out of say a very typical gig or two project file and texures to 32+ render clients as well as the receiving of the data files back and it's not really a light load CPU issue at all...

most users i guess don't see that level of load in their NET use, but i do and i know many studios of a handful of people or larger that have in house NET Servers who abuse NET Server the way i do. (RK is often an overflow use for these studios if they need more then their in house farm can do depending on their workloads)

i suppose if the testing and development of NET was just some individual guys working alone as the "target focus" they would easily miss the need for multiple users access, job re-ordering from those same multiple users

sometimes priority IS SO important as you know "that guy" yeah you all know that guy who runs massive test after test tying up all the farm render clients with full resolution and every feature checkbox turned on... even to just look at camera movements etc... and then makes silly mistakes over and over cause they are focusing more on the latest facebook posting rather then their render settings - so they run the same job back to back 2, 3, 5 or 10 or more times as they keep catching mistake after mistake... yeah you know him - at times you need the ability to bump his farm hogging down so jobs can actually get done

as well as the ability to keep working full speed on your workstation on massive files while a different box handles the render load etc...

so it's nothing to do with rendering load at all

i mean the TR is awesome for the DR aspect - so cool... and SO needed of a feature - just the other things now taken away and missing from network rendering with C4D will definitely be noticed by more then just RK

looking forward to hearing more info about TR! : )

dann
__________________
-
Dann Stubbs - dann@darkskydigital.com
http://www.RenderKing.com Value Priced C4D, VRAY, Cycles4D Render Farm
-

Last edited by dann_stubbs : 07 July 2013 at 12:18 AM.
 
  07 July 2013
Originally Posted by GruvDOne: Right, so there is no disrespect here intended toward anyone, but I just have to wonder for whom NET was too involved? One of the things that was great about it was just how uncomplicated it was.

I'm a little worried about this TR concept, especially as I too have run my share of jobs through Render King, and I'm sincerely hoping this doesn't screw that whole thing up. Personally, I feel that render farms are a crucial part of the 3D workflow, and I can simply not imagine why Dann wasn't asked to be on the beta team for this release, as his input while designing a whole new DR system would have been invaluable.



to be fair, years ago i was on the beta team for a while, it was a nice thought and i appreciated the gesture.

but honestly i was not all that much help - back then NET Server and NET Client did not output crash reports or hard type info to provide so i could only explain what was happening and nobody really seemed to look into that (example the 2+GB net client bug that we mentioned by myself and others who saw it happen for a couple years, in these very forums was recently dismissed as being even possible to exist since the C4D app can open 2+GB files just fine so NET can too, then grudgingly looked at, and silently, never acknowledged as being real, reported as fixed)

but the main reason is the real use and abuse i could report on was RK, which as we know is PUBLIC use, so i couldn't really test the beta stuff that did not match the public release in the real world, couldn't test beta stuff that may be buggy and disrupt REAL work by users who need stability cause it's their butt on the line not just some play file to see if it something works, and could not run NET beta even if was made to hide it's beta version, as it would not match public releases for features (and often newly accidentally created or new features bugs)

plus to be completely honest i did not feel all that comfortable in the often US vs. THEM viewpoint i felt existed with a few in the beta program, so it made little incentive to get deeper involved. (DISCLAIMER: this was a long time ago so i have no view, knowledge or statement on how the beta program is run or operated now)

but sometimes that sort of side is exposed by the "wall of beta tester denial and arguers" who surface at times in the forum posts etc... which i don't think does any value to the feedback trying to be presented to maxon by it's users on the forums.

so i totally understand while i was not on the recent beta team. it's just sad that nobody during the development of TR said "hey, what about all these features we've had since the beginning that many users obviously use and nobody ever complained about that we are tossing away"

hopefully maxon has some time to implement some changes that can alleviate some of the concerns being posted. i truly believe that srek cares deeply about C4D and hopefully that will pay some sort of dividend for us NET users.

have a great evening!

dann
__________________
-
Dann Stubbs - dann@darkskydigital.com
http://www.RenderKing.com Value Priced C4D, VRAY, Cycles4D Render Farm
-
 
  07 July 2013
I don't think that was directed at me, but FWIW, I'm not currently on the beta team and I'm not trying to defend anything. I have no personal experience with R15. Just thinking out loud about possible workarounds to the concerns being expressed.
 
  07 July 2013
Originally Posted by AdamT: I don't think that was directed at me, but FWIW, I'm not currently on the beta team and I'm not trying to defend anything. I have no personal experience with R15. Just thinking out loud about possible workarounds to the concerns being expressed.


no not at all...

and we dependent on existing net features NET users are just thinking out loud too, because it's easy to see some features we used and depend on are now poof gone and since we can't always wait and see when productions, money, budgets, future plans are all in play - we are trying to ask questions and find out what we really are dealing with here.

for instance - maybe it's just the time zone differences, but the silence is deafening to me about the "what if C4D crashes, or the render client crashes questions"

i would have expected dozens of replies, because well we were told it was used in some big productions - and well didn't they have any crashes? so wouldn't someone be able to easily give some sort of answer as to what happens? (hopefully i'm just being over concerned, but it sure would be comforting to hear more about that)

hopefully we will, just crashes are all too common in the file sizes and project i deal with so naturally i expect there will more in my future

dann
__________________
-
Dann Stubbs - dann@darkskydigital.com
http://www.RenderKing.com Value Priced C4D, VRAY, Cycles4D Render Farm
-
 
  07 July 2013
Yeah, that's definitely a concern. You don't want to wake up in the morning -- especially Monday morning -- only to discover that your render went bye-bye 20 minutes after you locked the door.
 
  07 July 2013
If a client was in the list of active nodes at the start of a render, it will connect back and resume its tasks automatically.
Now for the bad news: if the server crashes, all clients will stop their renders, so these partial renders will be lost.
Any finished frames should be taken into account, though, and the render resumed normally when the server comes back online and the queue is resumed by the admin.
__________________
One on one Online Instructor for Cinema4D | Visit www.Fluffy4D.com for more info.
 
reply share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 08:02 AM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.