LuxRender vs. Cycles speed

[B.Y.O.B.]

By the way, you keep coming back to that "simple scene". But as described in PBRT (the rendering system LuxRender is based on) physically based rendering systems are built with the idea in mind that they will be mostly used to render rather complex scenes, including many light sources, much indirect lighting, various textures etc. pp.

So you should compare Cycles with Lux with a more challenging scene - Lux has way better algorithms than Cycles at the moment.
For a start you could use the example scenes that come with Lux (freejack's watch and my school corridor (in the school corridor scene you will have to remove the portal meshes in front of the windows for Cycles, Cycles is not capable of using portals right now)).

edit: ah, and Carbonflux: the appearance of the final render is not everything, a very important role also plays the workflow (this is why I prefer Lux over Cycles: better workflow).

[Paapaa]

Yes, I wanted to specifically point out that it was a very simple scene with most light directly from a big lightsource etc. I pointed it out as I thought things might be totally different using real complex scenes. This was a very isolated case that just made me curious.

But I understand that most things I see boils down to physical models being used. Cycles also seems to use (or at least used in December) just plain path tracing as opposed to bidirectional (+ Metropolis). This might make it faster in simple scenes but slower in complex. However, Changing the integrator in LuxRender didn't change things that much.

But really, I was just curious and as an old Pov-Ray user I think this whole unbiased thing is the best thing that has happened to ray tracing in long time. Keep up the good work!

[Carbonflux]

I think the complex scene and workflow arguments B.Y.O.B makes are very important and also SATva's spectral point.

Most of all when you get into scenes with hidden and indirect lights, bidirectional is much better at dealing with complex paths, which means most of the time interior scenes. SPPM can handle a lot of the same problems as bidir for the same kind of scene, cycles does not support any of this. Try hiding a light source behind a corner etc or passing it thru glass.

The problem for me is I don't like to be forced into a position where I have to say negative things about Cycles. This goes beyond apples and oranges, its like the difference between a Prius and a Lamborghini in city traffic, in a city a Prius is much faster.

For some reason the cgafaq.info site that has a good page on bias in rendering is a gone but here is a paper that goes into a bit...
http://multires.caltech.edu/~keenan/bias.pdf

[SATtva]

The problem for me is I don't like to be forced into a position where I have to say negative things about Cycles. This goes beyond apples and oranges, its like the difference between a Prius and a Lamborghini in city traffic, in a city a Prius is much faster.

+1.

The real issue at hand is to properly choose a tool for a given task.

[Pilchard123]

The real issue at hand is to properly choose a tool for a given task.

When all you have is a hammer, every task looks like a thumb.

I'm sorry, all I've done on this thread is complain about posting styles. I'll go do something useful now.

[jeanphi]

Hi,

Also try LuxRender in path tracing mode with the lowdiscrepancy sampler and you'll probably find it to be as fast as Cycles. LuxRender is a toolbox with lots of stuff, the default configuration will give correct results in most situations, but if you know what you're doing you can get much more. The default LuxRender settings will work nicely even on very complex lighting setups where Cycles will completely fail, that requires more complex algorithms which comes with a speed hit.
I don't completely agree with CarbonFlux on the speed argument, because eventhough we try to do our best to have efficient algorithm, we might miss important optimizations opportunities, like has been proved by the introduction of QBVH, then SQBVH, by the optimization of the film contributions splatting, then the tiling of the buffers, ... OpenSource doesn't mean it's perfect, it's just that it can be challenged by anybody and that anybody can try and improve it, not just a single individual.

Jeanphi

[Paapaa]

Also try LuxRender in path tracing mode with the lowdiscrepancy sampler and you'll probably find it to be as fast as Cycles.

Tried that already but the impact was actually quite minimal. Still takes "a lot" of time to get smooth results. Only "Direct lighting" gave me a biggish speed boost. I want to point out that I'm not using GPUs at all.

[Carbonflux]

I don't completely agree with CarbonFlux on the speed argument, because eventhough we try to do our best to have efficient algorithm, we might miss important optimizations opportunities...

I admit I tend to over generalize in this regard, to be specific I see it as a continuum expressed as a curve where lux hovers at the top 10% of the graph in terms of speed, I really do think over a long window open source will be faster in general even though its clear that at times some closed source applications might create a "bump" or applications like Cycles that leverage a vertical technology.

I submit that sometimes we need to go back to go forward, a pure massively parallel generic x86 implementation might over the long term leverage new hardware even better than a gpu optimization which will be faster in the short term for leveraging gaming technology.

Intel's introduction of a 50 core minimal x86 computing array is a good example of this trend, which imo is actually more cost effective than gpu technology and will also lead to advances in gaming such as real time ray tracing which is of course what intel is hoping with their hunt for a gpu killer, but in this case I think they are right.

In the end I really do think it is too soon to judge how "fast" luxrender is.

[zeealpal]

Well here is my Simple Scene test.

For comparison, the attached scene was rendered with Cycles to 250 passes (what I thought was reasonably clear) and rendered for the same time with LuxRender (57 samples/pixel). The render time ended up as 200 seconds. Both Cycles and LuxRender used the CPU Only implementations. I don't have a nVidia GPU in my desktop (7970) and my laptop only has a 540M.

The scene consists of Suzanne [plain matte (default)], with RGB [0,0,0] world and a plane for the floor, [plain matte (default)]. The lamp was a plane, with emission values of default for both LuxRender and Cycles. I've adjusted the LuxRender output via the Linear Tonemapper to approximate the same brightness as the Cycles image.

The system used to render was a Sandy Bridge i7 2670QM Laptop, was plugged in for the renders. The CPU speed was 2.5 GHz. 16GB DDR3 RAM (Speed unknown, but the same obviously )

Cycles render:

LuxRender render:

Both still have some noise in the shadows, but the in light surfaces of the Cycles one seem clearer (looking for opinions)

Obviously Cycles can make use of GPU rendering, but I would like to make a complex scene (or someone can) with indirect lighting only (maybe through a portal) with some reflected/refracted caustics (not too complicated)? Then render that scene untill it is clear in LuxRender, and see how long Cycles takes in CPU mode to reach the same clarity. Also test the GPU mode for someone who has an nVidia one, to see if that allows Cycles to be able to brute force it.

Edit: Here is the simple scene -

Simple_Scene.zip

(873.42 KiB) Downloaded 23 times

[B.Y.O.B.]

You could test with the pool scene, too: viewtopic.php?f=14&t=5092
It contains much more complex light paths.