Cycles Development Updates

I am for one really glad to see it finally come. But I had other engines cover me here like Arnold and LuxCore.

Good thing it’s finally here matching other engines.

Nevermind, that was just a joke, reminding an old Madonna song/movie. I remember Mai thou

It’s definitely a nice feature, but it’s also a feature present in other renderers for years. Cycles has some catching up to do with features like this.


I’ve wanted it for god knows how long, but there’s been some small scripts doing it and it’s also been a feature in the Extra Lights add on. But it’s really great it’s now coded natively into master.

I hope one day in cycles, there will be an analogue of the light cache(vray,corona,photonGI in Lux).

Probably it will never happen; explanation from johnedwardcox:

Not a dev, but I know a bit about render engines.

Firstly, Cycles is a Unidirectional Path tracer which means it only traces from the camera, never from the light sources. What you’re describing as ‘back trace’ of rays from the light source is “Bidirectional Path Tracing”; re-architecturing Cycles to be bidirectional would be a massive job. There are other renders which do Bidir PT that work with Blender. LuxCore is one which is free and Pixar Renderman used to have a Blender addon but I think that’s dead now.

Anyway the cache of lighting points you suggest here is a commonly used algorithm known as “Photon Mapping”. The problem with it is the cache instantly becomes invalid if there is any animation in the scene. Even small object movements cause the light points to move a lot because small changes in the direction of a ray add up to bigger and bigger deflections the further that ray goes. Cycles is designed to be a renderer for animations so that’s why it was designed as Unidirectional in the first place.

That doesn’t mean you can’t do animation with Bidir – what LuxCore and Renderman do is use a dynamic cache with an algorithm called “Progressive Photon Mapping” to create the light points; then they trace rays from the camera as usual and match up camera rays with the lighting points just as you describe using a method called “Vertex Connection and Merging”; (not vertex as in a mesh, the bounce points are also called ‘vertex’ in this algorithm).

All the original research papers for these algorithms are online if you’re interested and I suggest trying out LuxCore and the renderer Cycles is based on is PBRT which you can check out at


“Light cache” and the other various names it goes by (ex, “irradiance point cloud” in Redshift) is also traced from the eye, so most of the issues in that comment don’t apply. I believe the Cycles devs have been resistant to it in the past because it requires a pre-pass and also can have some issues with flickering in animations. Most of the implementations in modern renderers avoid the flickering issue, but I don’t know how much work is involved in getting the algorithm to not flicker. It might help that its rarely used for the first GI bounce, most of these engines do full path tracing to get GI for the first hit, then use the cache for subsequent bounces.

I may have spoken too soon, but maybe it’s something they can address in the future? It has the same issue as both Extra Lights and my own attempt and others like it; it “fails” for specular reflections.

The circle area lamp on the right has 180 degree falloff, but the grid limits its path - however, the grid itself is still highly visible. Low exposure just to see what’s modeled. Here it’s an actual grid model, ideally we should be able to texture the light to use fake grids.

I’m wondering why Cycles never had an option to choose first and second bounce, similar to Corona, V-Ray and etc. If you want flicker free animation, choose brute method, if you want static render - choose whatever you want. For me as an archviz artist - caching would be really helpful and great.

The worst thing in chosing between renderers is that Luxcore doesn’t have bevel shader, ao shader, fresnel shaders (except velvet shader), path visibility, dirt shader etc. but have things like caching, caustics, autoportals, triplanar mapping, archviz glass and more - features that are missing in Cycles.

And there’s Corona and V-Ray that have most of those things but they’re only on CPU (ok, except V-Ray GPU) and most important - people are still waiting for 2.8+ compatibility :smiley:

1 Like

Presumably because it’s meant as a renderer for animation, as others have said above

There is no resistance. It’s just that nobody ever submitted a patch for one.

For Lux, isn’t fresnel covered in pretty much everything? Currently there are still too many Cycles specific things missing in Lux to make me enjoy using it - setting up complex procedural materials in particular.

Several ways to get triplanar mapping and “archviz glass” in Cycles, but they’re not built in. Box mapping (image textures only) is hard to work with since you can’t rotate the coordinates.

1 Like