Lux rener vs cycles

Just curious is luxrender faster than cycles? And why would you use one or the other?

In very short:Luxrender is a very advanced renderengine mimicking the accurate processes of physics in light when it is rendering. You get a very accurate photorealistic image but it can be very slow in complex scenes.
Cycles focus is animation: producing lots of frames relatively fast with with what is called “bias” (shortcuts to make faster rendering with a little loss of the ohysical accuracy).

You use Cycles if you do not care about caustics and absolutely photorealism or you are into animation.
You use luxrender if you want the sbsolute most photorealistic image (ie. an interior architectural vizualisation, and then you wait or buy a very powerful computer)

That is very short and not intirely correct, but gives a good picture.
Many on this forum can elaborate on it but there has been written a lot about it and I am very sure you can search your way to some deeper information.

Actually, if you render with the same number of bounces with both you’ll find lux is not that much slower than cycles. It has defaults that are pretty excessive, but if you dial them down, it’s pretty comparable speed-wise. Especially in interiors you may find it’s actually faster sometimes. It also has many different integrators that will all still converge to the same image over time, so it’s pretty flexible and you can use the exact settings you need for a given scene if you know what you’re doing. That also makes it a bit fiddly.

The really attractive thing about Cycles is not the speed though, it’s the nodal shading system, which is just awesome and allows for a lot of tricks. And then there are the render passes, motion blur, gpu support, osl and various other features that make it great for animation.

The Lux devs are working on their own nodes, but it will probably take a while before it’s up to par. Actually, I haven’t checked how that’s going for a while, so maybe they got better recently.

Depends what case what sceen. There are sytuations where Lux is faster.

For the record: Cycles is unbiased. :wink:

You can enable some things (like Filter Glossy) which will add bias, but the engine itself per default is unbiased.

Not to mention that you need to do some serious research to sort out some of Lux’s various and poorly named settings. Many will hopefully not be exposed to the user in the future.

I would use Cycles over Lux because Cycles supports fantasy lighting and Lux does not. In Cycles you can have a light that does not have geometry thus the light will not appear in the scene but still add light to the scene. In Lux you can not. I have asked the Lux developers to add this “feature” but being purists they refuse. This limitation also exists in the Mitsuba renderer. I also asked the Mitsuba developer to allow this simple feature but he refused as well.

I just don’t get this purist attitude with a render system. After all we are in the business of “faking” it.

Not sure what you mean here. In Lux point lights, spotlights, area lights etc all work fine without their geometry showing. SLG doesn’t support them so far, but I imagine it’s coming one day.

Correct, Lux 2.0 (based off SLG, but with all of Lux’s features being ported) also has support for spot, point with ies lamps as well.

Luxrender default is bidirectional MLT, 16 bounces, rr off. That is approximately 8x more calculations per pixel than default cycles ( 4 bounces, obviously no bidir/mlt). On some scenes that extra calculations will help a lot, more then 100x times in case of some caustic, but most direct light scenes that make it waste samples. Luxrender update screen less frequent, that add feel like it slower. You can try Luxrender in same settings, Path trace intagrator, Sobol QMC, 4 bounces max, and keep in mind it update screen not every sample. I think are almost same, minus tiny C++/spectral overhead in Lux.

But keep in mind, Luxrender have bidir with real camera aperture, and can sample paths that just not possible in Cycles, for example inner reflection in glass from point light. You need insane number of samples to hit camera, but at least it work.

Edit: Actually RR is on by default , thanks @J_the_Ninja for correction.

Lux also has noise-adaptive sampling, works either alongside MLT or with the QMC sampler. It also supports volumes, and has a few extra motion blur controls (relating to frame timing, no deformation support either). It also supports adaptive tessellation for hair, although no line-segment mode like Cycles has. Also no “hair info” texture or similar, so you can’t texture along the strand length.

It doesn’t support render passes though (yet, the SLG-ification stuff is bringing them). And since the exporter is python-based, it’s slower on heavy scenes, and lacks a few functions. (for example, there would be a ColorRamp node and node-groups if there was a simple way to add that through python).

Lux has RR turned on by default, the “RR threshold” property is actually a (mostly useless) russian roulette mode control. This is why adjusting the path depth doesn’t have as big of an affect as you might think.

Could you elaborate a bit on this? I can go in and change a few things…

Moved from “General Forums > Blender and CG Discussions” to “Support > Other Software”

I see both “Eye RR Treshold” and “Light RR Treshold” 0.0 by default in Blender plugin, isnt it mean RR turned off by default?

No, that value is an override to the minimum threshold. 0.0 = normal RR, 1.0 = no RR, anything between is a weird partial RR. Like I said, it’s a mode switch of sorts that isn’t all that useful, that’s why it defaults to 0.0 and is hidden/not exported by default.


Thanks, my bad , i had to check it before posting.

eyeV.rr = min(1.f, max(lightThreshold, ef.Filter(sw) * eyeV.coso / (ecosi * epdf)));

Just to troll luxrender gyus a bit more, if they are still around :slight_smile:

9 hours, just point light, scene is mix of two scenes from luxrender forum

@storm_st have you that scene .blend somewhere? :stuck_out_tongue:

Here is scene, it mix of original “psorcube” file from Luxrender forum, and other one from other luxrender forum thread about caustics, light changed to point. I use it almost daily to tweak that “dispersion”, as that scene have two important hard parts for MCMC - that far dark gradient at top, and caustic from left objedct, very hard to make them both converging in same speed.

Oh @storm_st, you ruined all the fun lol :stuck_out_tongue:

The scene was already setup for LuxRender as well :frowning:

Edit: Just to note, tere was a small (0.03 radius) sphere being used for the luxrender lamp, while the Cycles lamp was infinitly small. There is a huge difference in the clarity of the scene for LuxRender when the lamp has a size compared to not.

The 0.003 on the image is wrong, its 0.03

Edit edit: There also needs to be a cauchy world texture assigned to your Glass volume, for dispersion to function correctly IIRC :slight_smile: I used IoR 1.52, with the B value set to 0.015000

Luxrender OpenCL GPU rendeing can be quite nice & fast (especially if you have a AMD GPU).
Here’s one modified MikePan test render, rendered for 2 mins on two 7850 (mid range) GPUs. Glass has real thickness etc…

Zeealpal’s image doesn’t seem to make any sense, how is a really small lamp noisier than one that’s infinitely small, you’d think making the lamp have an actual size would benefit the bidirectional sampling algorithm because it’s a little easier to find and sample(which I why it seems surprising that it would be that noisy).