I want to just go over the Cinema 4d Redshift Global illumination GI settings in a bit more detail and you have more of an understanding of how the different G.I. engines work in redshift.
So the first thing I’d like to see is you actually go to G.I. engines one of the primary and one for the secondary. As a few methods you could choose for each I know this might seem a little bit confusing at first unless you’ve used the Vray or Cinema 4d physical render before.
So the reason for having these is so we can use different methods for different parts of the calculation by combining these together we actually get a better solution for global illumination (GI).
Now in this article, we were really talking about two of these options Brute force and Irradiance point cloud. These are the setups I find works the best for me and these all I already a day to day for my general work either be a still image or animation.
Brute Force to (Primary and Secondary) GI Engine
Brute force is the simplest method and I just trace it to determine the GI. It is very accurate but it can be a bit slow especially with interiors.
You don’t really use the secondary GI engine because it’s not quite as accurate and essentially it just calculates very fast elimination cache over sets of points in your scene.
So let’s just talk about GI in general, the simplest method to set up GI is to set both of these to be Brute Force. That is very little setting to deal with, in fact, this is pretty much how Octane calculates GI.
Now of just captured all render into Photoshop so I can draw over the top and explain this a bit better. When we press render in redshift it’s gonna fire a load of rays into the scene basically.
Now If we simplify this and just deal with one ray for now. Let me press render you can imagine a ray comes in from my camera maybe hits the step here. So the 1st ray point is going to calculate the direct lighting from many lights in the scene.
Now if we’ve got G.I. enabled, so it can fire one or more secondary rays. From the 1st point, it bounces off. Again it’s going to calculate any direct lighting from all of the light sources. It’s going to work at the elimination here and this lighting is actually fed backward and used to calculate the G.I. for the previous point.
This can go on further. Depending on how many rays bounces you’ve got. This may bounce up to different parts of the scene where the light hits the object, and keep going. So each of these rays hits it’s gonna calculate the direct lighting for many light sources on the scene then it’s gonna calculate backward and send the lighting back up the chain, this eliminates light rays all the way back up to the starts.
How light ray bounces?
Now the more ray bounces you have, the better quality the lighting solution will be from the GI, but it will also take longer.
When the 1st bounce where it came off the objects for the first time this is what’s going to be using your Primary G.I Engine. Any subsequent bounces will be using the Secondary G.I Engine. This is a fairly simple example here, I’m just using one ray bounce to go around the scene.
Before rendering this it’s going to be typically many separate per pixels for each pixel in the scene. So while it may seem is not too much to calculate when you’re doing this lots and lots of times this can get quite slow. It is an accurate way, but Brute force is also the slowest way especially when you deal with interior scenes.
Number of GI Bounces
The number of benches for the secondary engine is set by this Number of GI Bounces. So if we were to set this to 0. You still get the from the primary GI, but there will be no more bounces after that because the Secondary GI we have set to zero. Now as I said this is a bit of a slow method when you’re dealing with the interior.
Irradiance Point Cloud
With this combination of Brute force and irradiance Point Cloud when er press renders Redshift will first create a very false lighting cache of our seen from camera view.
I actually create little samples all over a seen and quite evenly spaced as you can be seen in the above image. So we have all these discrete points that create this illumination cache and this describes the lighting all same.
Now it doesn’t take all the details of edges and little gaps into account so gaps like this and edges along here. So it’s really more of an approximation of the scene lighting. It is still accurate it just doesn’t include all the fine details. It’s because of this state it’s so fast to calculate.
This is actually fine because we’re still using a brute force method for 1st GI bands and this first bands is really gonna be visible on our render, so this is where we need to have more detail. So we quickly calculated and stored all our ray bands here as cache.
So this time when the ray (violet line) comes in from our camera and hits the step on the big sphere, it does the first G.I bands as it did before. Using brute force for this method captures the details.
When it gets this surface (orange line) rather than actually having to bands lots of other rays samples define the rest of the elimination as we did before. What is gonna do is just read a stored cache for these points. So takes its value positive back we have done.
Now additionally this method is something called a retrace value and this tells redshift when we get to more detailed areas such as these little gaps on the above image then use for the cache and switch back to using brute force calculations for this pixel.
So overall it’s a much faster setup for GI, which is still using more Brute force in the areas where more details but for the broader areas where detail isn’t important like distance area or plain surface, just use it as a stored cache.
Also see: Best Guide on Cinema 4d Deformers
Irradiance point cloud Setting
The first thing you might want to have a look at is to change the retrace threshold and this setting will work with almost all your scenes. If you’re having problems you can maybe try just upping the retrace value to maybe 4 or even 5 perhaps. And all this is doing is telling redshift on these more detailed edges to use more of the Brute force than to use the point cloud.
Now, if you’re still having problems you could try adjusting the screen radius, instead of 16 maybe try 8 well perhaps even 4, and the lower you go with this the more ram you’ll need for your graphics card. But what is actually doing is spacing the point samples on the Irradiance point cloud closer together.
So this actually more detail on the initial point cloud. So you could try that.
Actually, if you are rendering very large images say like for Poster you might find that the actual irradiance point clouds are taking a long time. I had this, and in that case, the option was to try and make the Screen Radius to the highest 64 samples.
So I think I was rendering about 6K and I just rendering with my normal settings was taking quite a long time so I set this up to 64 and it actually spiced up the points that are farther apart but because it was such a large image it was still capturing sufficient detail.
Just leave the settings to default like this. But if you do have issues, these are the sort of things you can adjust as well. That if for some reason you’re still having problems with your GI maybe you’ve tried this and you’ll still get flickering somewhere you could just go back and set your secondary GI engine to Brute force.
I’ve never really had to do this because normally an Irradiance point cloud works fine for me.
But in this mode (Brute force for both primary and secondary Engine) you’ll be working in a purely unbiased solution so you’ll definitely have no issues with flickering then. Just be aware that this method can be quite slow especially with interiors it’s not too bad for experience but if you do have particular problems with your scene you could try this as well.
Brute Force VS Irradiance point cloud
The last thing I want to talk about is if we start moving the scene in Progressive mode in Redshift IPR around our scene, we can see our render view is refreshing nice and fast. It doesn’t really look like it’s creating any kind of cache. Now the reason for this is when are rendering in progressive mode redshift automatically defaults back to using brute force for both the primary and secondary.
Now, why does this is because if you’re using an Irradiance point cloud still it would take a couple of seconds each time you move the camera to calculate the cache and then start rendering. So this wouldn’t be very good if we’re trying to get fast updates from our lighting or shading. So you don’t have to do anything but when you’re using progressive just note that redshift is automatically changed behind the scenes to keep things nice fast.
Now if we change the bucket mode you can actually see it working hard within the final renders, so when we move the camera it takes a couple of seconds just to calculate the cache and it renders (Brute force and Irradiance point cloud selected). So it’s not as good for doing work and it’s not snappy but actually is much more efficient for this to work for a final render.
So I finally as I said before this is a really good method for stills animation.
With animation, you’re probably almost never get any flickering but that’s not to say that it can’t happen. It has happened to me very rare but if you are pushing lots pretty hard or if you’ve got some very fine detail in your lighting setups it’s not to say you might not get a little flash or Flicker across and edge somewhere.
I Hope now you have the proper understanding of Redshift Global illumination and how its works in a different scene. You can adjust it accordingly depending on your workflow. If you have any suggestions definitely comment down below and if you like then share this article!