LuxCoreRender v2.1

We have released another stable version of LuxCoreRender, after 8 months of work and 9 alpha/beta releases.
Download the software and example scenes:
Take a look at our gallery to see what’s possible:
Release notes of v2.1:

You can support our project with donations.
To give back some reward to donors, we have created a new forum rank.
The details are explained in this post.

Sharlybg created a new tutorial on how to use the direct light sampling cache introduced in v2.1:

Dade has already started the work on the next version, with the first addition being a new photon GI cache to accelerate the rendering of indirect light and caustics:


I’ve been following the development of LuxRender/LuxCore from the beginning. During that time I didn’t have an easy time getting anything decent out of it and stuck to Cycles and playing with the (for me) more easy to control free version of IndigoRenderer. But now I must say LuxCore is getting better and better and I left Indigo Renderer for what it is (even removed it from Blender!). I’ve been working with the new LuxCore for a couple of months and there’s still a lot to learn. Thanks to the excellent Blender integration, that is something I look forward to. I’d love to see more documentation, though; getting things done by trial and error is not very efficient… Also: a basic Cycles to LuxCore material converter would be a great addition. Even if it just converterd textures and basic material attributes initially, that would save a lot of time and increase productivity.

1 Like

One thing I am noticing from Dade’s leadership is that Luxcore is going in the very unusual direction of introducing caching techniques and pre-processing steps, while the vast majority of engines are moving away from them. Is there any reason for it?

I’m sure it would be faster, but that is only if it’s done in a very smart way. Otherwise, the time saved is going to be canceled out by the forest of settings that this type of rendering tech. will bring (ie. trading render time for setup time/trial and error). Even more so, it may bring a higher chance of new feature A not working fully with feature B, something that was a pain with Blender’s old internal engine.

I know that these features will probably be completely optional, but path-based sampling techniques get better and better every year.

1 Like

You are certainly right with your observation. One reason is that the LuxCore team made a feature poll, asking users to name the 6 most wanted features which they wish to be implemented. And the result was that caching for indirect light, caching for direct light and a Disney type principled shader won the ranking (see link)

If this is a good strategy to decide on new features is debatable. It is certainly listening closely to the users and their wishes. One drawback I see is that most users (not all) know current features from commercial engines but may not be up to date with the newest developments or trends in rendering technology and research, providing potentially better solutions than the ones they know.

epilectrolytics is making some great animations with caustics:
One of his recent videos

When will 2.8 be supported?

There’s no ETA yet. I have started the work on it, but it’s not in a usable state so far.


Humm Vray / Corona / Redshift are changing what made them so fast ???
Which renderer using theses method are moving away ? with wich method ?
AI ?
I’m supprise seriously !


where can i find the optix denoise setting for Viewport?
i have no checkbox for activate

i use BlendLuxCore-v2.1-win64-opencl

You need this experimental release of BlendLuxCore:
I have not merged the optix integration into the master branch, see


We will soon release the first alpha of v2.2, with two new main features:

  • PhotonGI cache for indirect light and caustics
  • Integration of Intel’s OpenImageDenoise

PhotonGI Cache

An example of the PhotonGI cache (still work in progress, currently only available on CPU):
15 Samples, no cache:

15 Samples, with indirect light cache:

Building the cache took about 6 seconds.

OIDN Integration

Compared to the existing denoiser in LuxCore (BCD), OIDN is much faster, uses less RAM and gives better results. Since the performance is so much better, I will also integrate it into the viewport like I did in my experiment with Optix.



Just did a little test with Bidir and Sobol, with the new oidn denoiser.



a little thing, Auto brightness setting (tonemapping) as default is misleading(bug?).i was reducing light gain, but the object render color was not reducing correspondingly.after disabling auto brightness and setting linear gain to 1.0 it was working as expected.

Autobrightness is actually a feature, not bug.
I do agree it shouldn’t be on by default cause I’ve seen few people already having trouble when first trying luxcore.

I agree that it can be an annoyance, and actually I think it should be turned off by default.
The reason why I did not do this so far has been that the sun and sky light sources in LuxCore use realistic brightness, which means they are a lot brigther than all other lights (which are around the brightness of normal household light sources).
I have two choices:

  • Turn off auto-brightness and leave light sources like they are now: The user will see a correct image with most lights, but only white with sun/sky. Or correct image with sun/sky, but black image with other lights
  • Turn off auto-brighness and modify sun/sky brightness: This would be the most user-friendly solution, but sun/sky brightness would no longer be physically based by default. Or: I could make all other light sources much brighter by default.

There’s also the problem of changing a default value in an addon: it will screw up all old files where the default was not changed (this is Blender behaviour).
Currently I’m considering to implement the second choice when I finish the 2.8 port of the addon.

1 Like

Maybe use camera settings by default with something around realistic outdoor settings:

When the user goes to tonemapper if his lights are too dim, he might see actual camera settings and understand right away what is going on.

This is of course me, assuming users interested in luxcore also understand camera setup.

A test of the new PhotonGI cache.

PhotonGI OFF, 64 samples, 5 min rendertime + 1 s init time

PhotonGI ON, 64 samples, 2 min 30 s rendertime + 19 s init time
Scene by lacilaci.


Why did the color of the light shift from a bluish tint to stark white?

One thing to note about introducing Photons is that you’re going back to the day when you would need a ton of them at small sizes to get accurate lighting on small details, that’s not to mention the potential difficulty in using them for expansive outdoor scenes. Then there’s the introduction of the need for thick walls unless the implementation does some sort of anisotropic clipping.

I do have some experience with Photons via experimental Blender builds that tried to add them to Blender internal and SPPM with old versions of Luxrender, getting the right resolution for smooth lighting and no leaks is no easy feat.

Pathtracing has problems getting enough sunlight there, bidir does work better but is slow, caching seems to give proper lighting while being also fast.

Also there were light leaks/bleeding but now is there a workaround(check luxcore forum thread if you’re interested)

And lastly, this is first attempt at gi and also caustics caching for luxcore. If it should fail, there are other possibilities how to approach the problem.

It is more accurate.
Here’s a 500 samples Bidir render, with denoised version, as something like a ground truth.