- In this tutorial, we're going to look at two different ways to utilize Team Render from within Cinema 4D. By now, you should already have a list of machines added within the Team Render Machines dialog, and you can see I've added a few here from our previous tutorials. Whenever we do Team Rendering from within Cinema 4D, the machines list within the Team Render Machines dialog will indicate which machines can be utilized for rendering. Only machines with a checkbox next to their name will be used anytime you initiate a Team Render. So if you don't want to use a specific machine, simply uncheck the box next to its name. If you have Cinema 4D Broadcast or Studio, you'll only be able to have three machines checked at any given time. So while you can install the Team Render client on as many machines as you wish, you can only use three at any given time to render. In that case, you'll need to uncheck one in order to check a different one. So you can choose the three fastest or most appropriate machines at any given time. In this case, we have Cinema 4D Studio so we're going to take advantage of all six machines, including the local machine. If you want to take advantage of the power of the Team without utilizing your local machine, you can uncheck the local machine as well. Before we start rendering, let's take a quick look at a few key preferences. Choose the Preferences menu item from the Machines menu of the Team Render Machines dialog. This opens the general Preferences window with the Team Render Machines page already active. You can also just open the preferences. Make sure the Renderer section is unfolded, and choose the Team Render heading. On the Cinema 4D side, there's a few additional preferences that we haven't looked at yet, since they're not a part of the Team Render client. One important preference is Abort Rendering on Client Error. What this will do is stop the render job as soon as a client returns an error. That error might be that the document's not valid, or a connection error, or that a plug-in or texture is missing. Generally, you'll want to keep this unchecked, because some clients may error while others don't and you don't want to stop the entire job just because one client had an issue. A corollary option is the Exclude Client on Render Error option, and you'll typically want to leave this one checked. What that will do is just exclude one specific client if that client is missing a plug-in or a texture, for instance. Another closely related preference is Handle Warning as Error. If this is enabled, then warnings such as the warnings that appear when a plug-in is missing will be handled as a client error. Otherwise, these warnings will simply be displayed in the log without causing the job to quit or excluding that client. This often can lead to render inconsistencies, so it's usually a good idea to leave that option checked. Within the Team Render client, we already covered the Fetch Assets Always from Server option. By default, Team Render uses a peer-to-peer asset distribution scheme, where any client can provide any other client the Cinema 4D scene file and any textures. They don't have to always come from the server. If you check this option, then the local client on which this is checked will always get its assets from the server, rather than getting them from another client. This also has a corollary setting, which is Peer-to-Peer Asset Distribution. This setting is more related to the server than the client. So if you disable Peer-to-Peer Asset Distribution, none of the clients will get their assets from other clients. They will all get their assets from the server, regardless of what the Fetch Assets option is set to on each individual client. The Clients Get Assets on Demand preference allows you to specify whether the entire texture folder is transferred when the job begins, or only the textures required for the frames that are being rendered by the client. This option especially comes in handy when you're using image sequences as textures. With the option enabled, only the image sequence frames that are necessary to render the frames that are currently assigned to the client will be transferred. If this option is disabled, the entire image sequence will be transferred to all of the clients. In a similar way, if this option is disabled, textures that are assigned to materials but not actually used in the scene may be transferred to the clients as well. On the flip side, you'll want to disable this option if you're using Vray or RealFlow, or other similar plug-ins that deliver assets and may not know how to deliver them on demand. You also might disable this option if you're getting any asset-related errors in your rendering. You can also specify a rendering timeout if you wish so that if no clients respond to a job for a certain amount of time, the render will just stop. Timeouts are somewhat problematic, so I recommend leaving this option disabled. Finally, there's an option to encrypt all of the connections between the Team Render Server or Cinema 4D instance and the clients. In general, I'd recommend leaving this off, because it simply creates more networking overhead. Now, let's go ahead and do some rendering. For these tests, I'm going to be using the Cheese scene by Kingcoma, which can be found in the Cinema 4D Content Browser presets. The simplest way to use Team Render from within Cinema 4D is to use the Team Render to Picture Viewer command. When you use this command, the scene file and all of the textures are seamlessly transferred to all of the clients, and the results are seamlessly transferred back to the Picture Viewer and into the save path that you specified within the render settings. You can see here that I've already rendered this without Team Render, and it takes 2 minutes and 45 seconds. Again, we've got a network here of five machines, and we'll see how fast this Team Renders now. Within the Team Render Machines dialog, you can see the orange icon to show that all of these machines are currently working on a job. The bucket colors relate to the bucket colors that are being returned within the Picture Viewer to show which machines are actually returning which buckets. Now if we look at the Picture Viewer, you can see that this scene came through in 36 seconds with the five machines. So you can see the render time isn't exactly one-sixth of the original render time, because there is some networking overhead required. One aspect of networking overhead is the distribution of caches. This particular scene utilizes Global Illumination, and within the render settings you'll see a Team Render category where you can specify whether the caches are distributed for single image renders. By default, the Subsurface, Ambient Occlusion, Irradiance, and Light Mapping caches are distributed between the machines, meaning that all of the machines in the Team Render will work together to calculate the caches for these effects. Radiosity Map caches aren't distributed by default, simply because they're quite large and would cause an enormous amount of networking overhead. In most cases, you will want to leave the distribution of caches enabled, because this helps to ensure that the final image from a single image render is consistent between different machines. It is important to keep in mind though, that this requires additional RAM on each client and quite a bit of additional network traffic in order to negotiate the caches between the multiple machines. Let's go ahead and turn off the distribution of all of the caches in this case, and take a look at the effect on the render time. So we'll Team Render to the Picture Viewer again. Now, what you'll see now is that instead of seeing the cache calculate like you would if you were rendering normally to the Picture Viewer, you'll simply see a black frame until the buckets begin to be returned from the clients. This is because each client is calculating the cache independently, and the Picture Viewer doesn't display that calculation. Once each client finishes its own independent calculation of the cache, the buckets will begin returning from that client. You'll see in this case that it takes 43 seconds if we don't distribute the cache. So in this case, it is helpful to distribute the cache. However, if we go back to the render settings and enable Ambient Occlusion, and in this case we are using the new cached-based Ambient Occlusion, and we go back and enable all of the caches again and Team Render again, in this case the addition of the cached Ambient Occlusion is going to add some render time as well as network overhead to transfer and negotiate the Ambient Occlusion cache. If we look at the Team Render Machines dialog, you'll see that a couple of the machines have actually given up on rendering this job, most likely because the network overhead for distributing the cache has caused those clients to time out or lose their connection to the server. So once this finishes, you'll see that it now takes a minute 43 with the Ambient Occlusion. If I go back to the render settings and turn off all of the cache distribution again and render now, we won't see those machines give up this time. So we'll actually get a result much quicker than we were with distributing the caches. So in this case, the full render with Ambient Occlusion took just one minute and two seconds. So not distributing the caches in this case was faster than distributing them. Now, because we know that Ambient Occlusion happened to cause the problem in this case, we could go in and simply choose to distribute the Subsurface, Irradiance, and Light Mapping caches without distributing the Ambient Occlusion pass, and that's going to provide us the best of both worlds. We're getting the speed advantage and the consistency of distributing the GI caches and the Subsurface caches without losing machines as we did when we distributed the Ambient Occlusion cache. So in this case, our render with Ambient Occlusion completes in just 55 seconds. Now, obviously the differences here are somewhat minor. But keep in mind that I've chosen a scene that we can render in a reasonable amount of time for the tutorial, and as your scene size balloons so will these differences. But these differences are also very scene-specific and very network-specific. So in your case, distributing the Ambient Occlusion cache might be advantageous. It's really something you're going to have to experiment with yourself. Now, when you're rendering to an animation sequence, you don't need to worry about any of these single image distribution options for Team Render, because these are only a factor if Team Render is using multiple machines to work together on a single still frame. When you output an animation, such as by choosing an All Frames frame range, here in the render settings, you'll see that all of these options are grayed out. That's because the way Team Render works is to distribute specific frame ranges to each computer. Let's go ahead and start a Team Render to Picture Viewer now to see what that looks like. You'll see that when you initiate a Team Render to Picture Viewer on an animation sequence, it looks a little bit different than when you do it on the local machine. You immediately get placeholders for every frame of the animation. In this case, because each machine has been issued a specific frame range, each machine will do its own calculation of the cache and will begin returning final rendered frames as soon as it has calculated its own cache for that frame range. As frames are returned from each machine, the icon next to the placeholder will change to reflect the content of that frame. You'll see a green indicator for that frame within the Picture Viewer to show that that frame has been rendered and is loaded into the Picture Viewer memory. Just as usual with the Picture Viewer, you can scrub to each frame to see what that frame looks like in the render. Once you have multiple frames for a specific range, you can click into the range and hit the Play bar, and play just between specific frames in that range. You might want to turn off the Cycle option and just choose Simple in order to keep it from jumping into the first frame of the animation. So I can see just this sequence. But until you get quite a few frames returned, it's most effective to just drag between the frames. So rather than wait for this render to complete, let's go ahead and close the Picture Viewer, stop the rendering, and look at rendering via the Render Queue. The Render Queue is ideal if you need to batch up renders for multiple scene files, or if you need to batch multiple camera angles or render settings from the same scene file. To access the Render Queue, choose it from the Render menu. Whenever you're adding a job to the Render Queue, you need to make sure the scene is saved. Then, you can add the job either by clicking the Add Current Project icon here, choosing Add Current Project from the File menu, or choosing Add to Render Queue from the Render menu. Each queued instance will show up in list view here, and the selected instance will show its details in the bottom half of the Render Queue dialog. Within the Render Queue dialog, you can specify the render setting that will be used, as well as the camera that will be used for each render. To utilize Team Render, make sure to check the Team Render box next to each Render Queue item. Let's go ahead and duplicate this item by Ctrl dragging, and we'll render another instance of this same scene file using a different camera. We can duplicate again, and in this case we'll switch to the Animation render setting and the Morph Camera camera. When using the Render Queue, you need to specify the output path within the Render Queue itself. So here we can see that we're rendering out Cheese, and I'm going to change the output here to "Cheese, Camera". I'll change the output here to "Cheese, Close-Up", and the output here to "Cheese, Animation". Again, you'll want to make sure that Team is checked on each of these instances, and you'll want to make sure that the proper machines are checked within the Team Render Machines dialog. Once you're all set to go, simple click the Start Rendering button here within the Render Queue. The dot here in the R column will turn orange to indicate that the job is currently rendering, and the status will show whether it's in progress or in the queue. In order to view the progress of this queue item, we'll need to click it, and then we can see that this one was completed. If you want to view the results of that job, you can right-click the item and choose Open in Picture Viewer. To view the returned frame, you can right-click and choose Open in Explorer Finder, and here we can see that finished TIF file here. The Render Queue also displays the log for each job, which you can view if you choose the Log File tab with the job selected. Here you can see general information about the render settings that were used, as well as when the project was added, started, and the total amount of time taken by the render. We can see the same information here in the close-up, and if we select the in-progress animation render you can see that it's currently on frame 3, or 4 now, of 91 frames. So that's a basic look at how to batch up multiple jobs for Team Render via the Render Queue. With my entire team busy rendering this animation through the Render Queue, I can demonstrate something else that I have cautioned earlier in this tutorial series. If I create a new scene file and simply include a cube so this should be very quick to render and choose Team Render to Picture Viewer, it'll simply sit here with a black frame not doing anything. Because it's trying to utilize Team Render and all of my Team Render machines are actively working on a job. You'll also see this behavior if other computers are using the team to render. Here you can see that the icons for each of the Team Render machines show an unfilled orange dot, which means that other people are currently using those machines to render. When your computer is using the machine to render, the orange dot is filled. When other people are using it, it's unfilled. So this is where the team really comes into play with Team Render. You'll have to actually communicate with other members on your team to determine who needs to use the farm when. If your department's so large that it's difficult to communicate, it's time to jump into Team Render Server with its central queuing ability. We're going to start looking at Team Render Server in the next tutorial.