Assembling a Rig for Cinema 4d

Cinema 4d is an established bigwig in the motion graphics and VFX industries today, and with its ever growing popularity it isn’t surprising for the ideal configuration of hardware for this program to be a frequent topic among aficionados and professionals alike. In truth, a rig that would be ideal for Cinema 4d would be a perfect rig for any other 3d application. Here are a few things to consider: Any 3d program needs to have a CPU with a high base clock value. The base clock value indicates how many clock cycles or calculations a processing unit can complete in one second. If you’re a 3d user assembling a rig for the first time, the number of cores in a processing unit might seem like the determining factor for the investment. The more cores you have, the sooner your renders complete, but as Alex from CGDirector explains, the quickest response time while working on a project is far more critical. Working on complex projects under the best possible circumstances outweigh the benefits of slower feedback but more cores, mainly because most of Cinema 4d production makes use of only one core. The i7 770K has a single core cinebench score of 197, topping the eight core Ryzen 7 1700X, for example. Besides, these days delegating projects to a render farm is, more often than not, a better way to go for projects that can’t wait. Many Cinema 4d render farms are generous with starting credit, and going this route will free up your workstation for other projects, maximizing productivity, and saving you from the overhead costs of maintaining several machines. Alex recommends an Intel i7 8700K, and Maxon recommends a 2 CPU machine with the highest possible base clock and number of cores (for rendering) within budget. Investing in RAM is also beneficial. The more RAM you have, the more complex scenes your workstation will be capable of handling. Dealing with multiple subdivisions, displacement and working with Cineware, is almost inevitable for the Cinema 4d user, but the specific nature of your work determines how much RAM you’d actually need. Maxon recommends at least 4 GB worth of RAM, but 32GB for the average user, and 64GB for the power user. A good graphics card determines the quality of Cinema 4d’s OpenGL viewport, and the speed of third-party GPU renderers such as OTOY’s Octane renderer (keep in mind there are Cinema 4d render farms that provide support for GPU renderers as well). While lower tier cards can still preview detailed scenes, a better card allows previews that are closer to the final render, and higher frame rates for playing back animation. A good budget range would be in between the Nvidia GeForce GTX 680 and a Quadro K4000. That should cover the essential components of a decent to ideal workstation rig for Cinema 4d. The greatest consideration should be how well a workstation meets your needs, allowing some margin for a cutback on rendering capability, keeping in mind the ready availability of Cinema 4d render farms for CPU and GPU rendering.

10 Render Optimisation Tips for V-Ray in 3ds MAX

In writing this article, I would like to offer a number of useful, easy-to-apply tips to help you significantly speed rendering, while avoiding certain common pitfalls. Though the analysis builds on processes as they occur in V-Ray, some points are common to all rendering programs and are therefore applicable in the general sense.

1. Draft and test renders should be done in “good enough” quality!

One mistake I frequently encounter is that draft render quality is not set with the specific job in mind – e.g. is left at a particular level by habit – and multiple sequential test renders are conducted at a quality higher than necessary.

Before rendering, think through what information you hope to extract from the test and adjust the sampling level accordingly. If, for instance, you wish to examine the effects of natural lighting, then a high-noise image will do just fine. If, on the other hand, it is the grain of the woodwork that interests you, then you will obviously be forced to enhance the quality level.


2. Simplify the rendering of glass!

Glass both refracts, and reflects light. Though transparent, in reality, it does not permit 100% of the light that hits it to pass through. On a rendered image, however, and particularly where the glass in question is a simple pane, little of this effect will be visible. I recommend excluding all glass panes both from global illumination (in V-Ray, this option is found in the parameters menu), and from shadow-casting.

This can even be done with minor props found in the background of an image. If, for example, one has a restaurant with some glasses lying around on tables, it is highly unlikely that the results of this simplification will be noticeable, but it will prevent the buckets in question from getting bogged down in those particular computations.

This method is particularly useful in improving render times when GI/refractive caustics and affect shadows for the material of the glass are both switched on.


3. If possible, switch bitmap filtering off!

It is usually better if bitmap filtering is switched off. In this way, V-Ray, rather than 3ds Max, performs the filtering, resulting in a sharper, more detailed image and, in most cases, shorter texture calculations and therefore, shorter render times. This difference will be particularly conspicuous for Opacity Maps.

(Sometimes, turning off filtering will produce strange effects, especially where bump and displacement mapping are used. Where this is the case, it is a good idea to switch it back on and increase sharpness by selecting lower blur values, instead.)


4. Use materials of reasonable complexity!

It sometimes happens, especially with high quality models imported from purchased sets, that an accessory incorporates materials that are radically overcomplicated for an object of that size and significance. This is not necessarily a problem, but if you notice your buckets slowing or stalling at these points, it is expedient to review the models in question and, where possible, simplify.

It may be unnecessary, for example, to apply the SSS effect to a tiny houseplant. You may also wish to set reflections to specularity only. Such measures produce visible changes only very infrequently, but may have a considerable effect on render times.

In addition, you might review your own materials for unnecessarily complex solutions that are good candidates for simplification. If, for example, you have a large number of materials masked over one another using V-Ray Blend, it can sometimes slow rendering spectacularly.


5. Hide everything that isn’t visible!

It may seem self-evident, but in the heat of the job, this point is one that is easy to forget. Before initiating rendering, it is an excellent idea to hide as many things not needed by a given camera as possible. I recommend configuring layers separately, indicating which cameras do not require them on each, and hiding all that are unnecessary. A classic example would be an interior with several rooms, where each room is rendered individually.


6. Avoid high-intensity lighting!

If a given light source – such as a strip light – is small by nature, then achieving the desired intensity will require increasing the multiplier. In this situation, it could easily happen that the scene will contain a large number of tiny, high-intensity light sources, which can significantly slow computation.

In such a case, it is a good idea to contemplate increasing the size of the source slightly, while simultaneously reducing intensity, in order to optimise computing time.

If, for example, you use a disk light as a spot with a high direction value, the size of the diameter – 2 centimetres or 5 – matters. Where there is no perceptible difference, a larger size is better for small intensities. (Lights that are too large can also cause problems, but in this case, I wanted only to point out the expedience of avoiding lights that are too small and too intense.)


7. Use fewer light sources

Beyond lights of exaggerated intensity, your scenes may also suffer if the total number of light sources is too high. Though the situation has improved greatly since the advent of probabilistic lighting, to avoid a hangup in computations in older versions, it is worth limiting the number of lights to as few as are absolutely necessary. Of course, as the number of sources to be included in a particular scene is more or less fixed, there are no miracles to be worked here; at the same time, a few basic simplifications are usually possible.

For a series of individual fluorescent tubes, for instance, it matters little from a visual standpoint if the solution is replaced with a single V-Ray light. Or where a lighting fixture consisting of a multitude of tiny bulbs is used, you might consider having an equivalently scaled V-Ray sphere fulfil the same purpose.


8. DR is not always your best option

Though there is no doubt that Distributed Render speeds the rendering process, prior to creating a draft, you should think through carefully whether it is really worth using it. If the aim is to render the entire image, and the rendering can begin promptly on all nodes, then, naturally, DR will get the job done quicker.

If, however, you are testing just one small region (even one that requires nearly all the resources of the given work station), then not only is the use of DR unnecessary, but given the time it takes to save and load the scene, it will also slow the test. In such cases, do not forget to turn it off.


9. Conduct processes in parallel!

If a scene is to be tested using more than one camera and everything within the scene is set for that to happen, then it is a good idea to send out each camera view as a batch render – using Backburner (or any render job manager) – so that machines will compute them individually.

Though this will not optimise the render itself, it will reduce time spent in front of the computer by eliminating the need of sitting at a work station, waiting for each frame to complete.

10. Control the quality of your models!

Because the rendering process images what we model, it is important that we think through precisely where and to what level of detail the things we work on will appear. Models of things that are small or that appear in the background should not be overly detailed, not only because of the time spent working on them, but also because excessive detail will encumber the rendering process.

This is particularly true if you use Turbosmooth where it might otherwise be avoided (e.g. using autosmooth), or where you wish to apply displacement to a feature it would, on the whole, take less work to model (keeping in mind that the opposite could also be the case).