Team Render Q&A


#21

-TR Clients don’t run as a service. The same workarounds that work with Net should work with TR as well, but they are not officialy supported
-Renderfarms: I have no idea how the different providers do things. If they use 3rd party rendermanagers they can still do so with R15, nothing changed in that regard. If they used Net they can now use the Renderqueue
-Remote Rendering: A HTML web interface might not be available anymore, but there are many remote desktop solutions that allow control of a system from afar. We routinely used this during beta phase, if you don’t try to do 3D work via remote CINEMA 4D is working fine via remote.

You already have to purchase a Studio Version to get unlimited Net Render so nothing ha schanged here

Prime does not include TR. Viz and Broadcast support up to three clients, Studio unlimited.


#22

With NET, users are simply running the supplied NET render app on a separate dedicated machine (thats how I work at least).

With Team Render you suggest that the “Team Render Manager” ie the box running TR can be accessed via a remote desktop app. But what machine would that be on? I wouldnt want that running on someones workstation–who would? We would ideally have it running on a dedicated machine that PC and MAc users alike could access. But unlike NET, it sounds like a full working version of C4D would need to be running on that machine, hence the need to purchase an extra license just for that.

So with this new system, rather than introducing new functionality to a solution that worked, you are removing that solution, replacing it with a new solution that helps freelancers and small boutiques who may not normally rely on a render farm at all. Then you are putting bigger studios who do rely on a render farm on a daily basis in a situation where they may need to re think their setup completely as well as possibly needing to spend more money beyond what they’ve already paid for with their MSA. So now we may be needing to look at paying for the command line version or buying an extra version of c4d.

Distributed rendering looks great. Innovation, efficiency and speedups are always great. I just wonder if the team putting this together was thinking about studios when they developed this. Maybe it was to push more people towards the command line/3rd party route. Maybe it was just an oversight.

if I am wrong then great.

Please dont take this as a bitch session–seeing those kind of beta-centric comments flying around elsewhere. We are customers trying to get our jobs done. I am just trying to work out how we will need to proceed come September. Thanks


#23

it does if you have to purchase another copy of Studio to set up a stand alone render manager box that supports unlimited clients.

dann


#24

I don’t see the problem. In your case you can simply eliminate the dedicated machine and anyone can set up a net render from their individual workstation. In Dann’s case, if he’s using a dedicated machine to manage his farm, he could instead run a remote app on that machine, connected to the machine on his farm that’s running the Studio version, and set up renders via the render que. Or in the alternative, have the studio version installed on the control machine and have all the nodes set up as clients.


#25

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.


#26

does TR dynamically compress data when transferring? or is it native uncompressed data being sent back and forth?

(i see what i think is an encrypt checkbox in the TR video which is cool)

dann


#27

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’m just trying to think out the coming changes… but it’s the same reason many pro users do not run a NET Server concurrently on their workstation - so team viewer is cool for tests yeah for sure being able to one click and DR to all those boxes will be awesome… but to then queue up some massive renders while needing to keep working… eh… not so much.

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


#28

We’re repeat clients of RenderKing and love how it works. This is a brief workflow description:

(1) Setup project and Save with Assets;
(2) Upload to RK via FTP;
(3) Unzip uploaded file and drag to root client FTP directory;
(4) Net Render will automatically identify and and queue the project;
(5) Manage personal queue via Net Render web interface. (Each account can only see their render queue, not the queue for each subscribed user.);
(6) Zip complete renders;
(7) Download;
(8) Delete completed projects from FTP server.

This workflow is simple to learn and use. And it means Dann doesn’t have to give various users remote access to his Net Render server.

While it seems that Team Render is great for in-house farms and networked workstations, it doesn’t seem to provide the same functionality needed for remote, subscription based Render Farms.

Also, I tend to work on a laptop which goes home with me each night. Even when I just render locally, it’s nice to have a small machine (Mac Mini) run Net Render server so I can disconnect my personal machine from the network and return the next morning to completed render jobs. This functionality is also missing from Team Render.

I think R15 looks like a fantastic upgrade. And I think TR is great for many uses in-house. But the loss true Net Render is going to take some workflow adjustments.

Terry


#29

while i know maxon has no personal interest in RK and it’s needs which is fine - but it is not just RK, but this is exactly how most users with NET Server work right now - that is why i set up RK this way, because i wanted users to work they way they were already familiar and not have to learn a new interface or way to get things done.

the point you make about laptops is a good one - so a user who works off a laptop and takes it home now can’t do any renders or leave any renders running without leaving their C4D machine at the office… very valid point i think. (but again maybe maxon is not too concerned about this scenario either)

overall it will change the workflow for any users that use NET Server as it is now - it seems maxon developed this new team viewer with the eye solely on the guy who sits alone and works on C4D and borrows some friends computers when he needs to get a render done ; )

dann


#30

+1

It does feel like we’re paying for a downgrade, or to put it more kindly a sidegrade. With R15 the majority of my team can no longer launch renders that use the whole farm and everyone can launch renders with no regard for priority.
Team Render sounds great for small teams for whom Net Render was too involved, but for larger teams it just doesn’t do the job. I think the assumption is that larger teams will be using something like Deadline but is suspect that many of us are somewhere in the middle.

What would really help with part of the problem would be to allow Broadcast to use more than three machines as long as there is a Studio license on the network.

Do you have to pay for the command line version of C4D?


#31

+1 to your +1 :slight_smile:

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.


#32

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.

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.


#33

No disrespect here either, but if you won’t articulate your concerns they can’t be addressed.


#34

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.


#35

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. :slight_smile:


#36

Thanks Adam :slight_smile:


#37

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. :frowning:


#38

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.


#39

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.


#40

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