LuxCoreRender v2.4

Anyone know what the LuxCore calculation is for absorption parameter in various material shaders? The one I’ve setup in Cycles for myself is likely not correct. I’d rather have it with the simple one parameter (depth) that Lux does.

Amazing news!

The CUDA support has introduced in LuxCoreRender the possibility to support any Computing API (you can find the detail of the idea here:

Said that, Vulkan is not a computing API according Khronos Group itself and doesn’t offer anything not currently accessible with OpenCL or CUDA (i.e. if someone want to add Vulkan support, sure, it is welcome but I don’t plan to do it).

At moment, it would be more useful to add Metal support than Vulkan (i.e. it would be useful for MacOS users because the OpenCL/CUDA support is “fading” away).

1 Like

Thanks for the explanation.
Do you have any plans to support Metal?
Do you have any experience to compare Metal vs CUDA/OpenCL from 3D/raytacing developer point of view?

I don’t have a Mac nor I have used a Mac in something like 25 years so I don’t plan to do it. We would need a MacOS/Metal experienced developer for this task … willing to work for free … good luck :thinking:

Metal has already been used in a couple of rendering engines (previously using OpenCL or CUDA) so I assume it is doable and it is like OpenGL/DirectX/Vulkan/whatever, just another API.

1 Like

Could you add this to the dailybuilds? for people like me who can’t compile source code if there life depended on it :stuck_out_tongue:

1 Like

We’re working on it.


Why sss so hard and artist unfriendly? It requires a lot of nodes. homogenous/heterogenous interior/exterior. i have no idea what is that.

Nobody knows? Link to a source file I can look at?

Maybe this?

1 Like

You need a surface material that lets light pass through, e.g. glossy translucent, glass, null.
For the scattering you need an interior volume with scattering, e.g. a homogeneous volume.
Plus output node that’s 3 nodes.

Maybe this also helps to understand it:

You will need to go into more detail about how exactly the current system is artist unfriendly and how a better system would look like. Best place to do that would be a github issue.
However, it might be relevant to you that it is already planned to implement the 2015 version of the disney principled shader, which includes SSS.


I do wonder, is there not a way to implement a tile rendering method as the one of Cycles in Luxcore? I mean a method where the user can have an idea about the quality of the result from the very first tile of the rendering (so that he may stop the render in its very first steps, in the case he sees that the quality is not satisfying).

LuxCore currently has a tiled rendering method for both CPU and GPU:

1 Like

Ok, thanks. I’ll have a look.

I know it. It is not the same however. In Cycles’ method every tile finishes the samples work that corresponds to it and after that the renderer proceeds to another tile. So, the user has the opportunity to see from the very first tiles what, approximately, the final result’s noise amount will be. In Luxcore’s method you see the tiles working but you can not have some idea about the final result.

If you turn of multi pass, then you cans et the AA samples to a value that you choose, the final samples will be a square of that, E.g. 400spp = AA 20.

It’s not quite the same but it does behave how you asked. Newer tile based sampling is coming in v2.5, but I’m not sure if that will render each tile only once or will be multipass again.

We have two new example scenes. Thanks to @ibotpl and DEBIHOOD.
You can download them here:


Anyone have a physically accurate example of nested IORs? I.e. glass with water, but in the water is an ice cube floating halfway, that also has air bubbles inside it. So some bubbles get a variety of different interface scenarios:
Air - ice - bubbles.
Air - water - ice - bubbles.
Air - glass - ice - bubbles.
Air - glass - water - ice - bubbles.
Preferably with a closeup photo reference that shows the expected response. Unlike the juice example above, any volume calculations should be weak enough to not cause any significant visual degradation of what’s happening inside.


Oh well, one the fruit juice is over 150 mb compressed and the other over 70mb … I don’t download them. Is exaggerate.

Or you can download them, see if it’s possible to optimize the content, and share them back :slight_smile: