Luxrender at it again.

The scene should be changed so that you can see the caustics of the sphere in the mirror too. i’m sure only the vertex connecting algorithm shows them.

@Qha changed so its visible in mirror.
Hoping there are some testers (Octane @mib?)

That BiDir VCM result looks fantastic, I could almost see the use of Luxrender’s Photon-based algorithms falling by the wayside from a user perspective because of how the path-based methods are catching up in terms of speed.

Now I wonder, what are the chances that storm_st will drop everything related to implementing traditional Bi-Dir sampling in Cycles in favor of implementing this new method? I wonder if the quality of these algorithms will even bring out a look from Brecht due to how they would potentially allow the same unbiased quality for both stills and animations and thus benefit everyone.

Are you talking about Bidirectional VCM? You are aware that it’s a biased technique, right?

I’m pretty sure that will be the case (read on lux forum). SPPM from Lux can render the scene correctly, but it has firefly issues that I find occur a fair bit. BiDIr VCM will be the way to go :slight_smile:

by the way, i didn’t see this in the first page of that thread, but then realized that there are 17 PAGES of that thread - there’s a lot of discussion going on, and i found some SLG3 Windows binaries on page 14 or so.

i’ve also compiled the source for Linux, though i don’t suppose you’ll have any luck getting it to run without compiling the dependencies yourself first, since it’s dynamically linked… and if you go through that trouble, you might as well compile the LuxRays source yourself too since it should compile flawlessly.

but anyway, if anyone wants to try my Linux binaries, i could try to upload them somewhere. i’ve also modified the blender SLG exporter so that it at least exports to SLG3, but so far it’s just hard-coded to default to CPU path tracing.

Demo video! :open_mouth:

@Above: Insane…!

THat is pretty amazing :smiley: I wish I had that CPU though :stuck_out_tongue:

Awesome!!
Is there any benchmark of OpenCL cards and SmallLuxGPU?

Noticing the instant caustics here :eek:

Too bad it might take a while for this to wind up in the big Luxrender app. The Bidir VCM would be an excellent way to help speed up difficult lighting situations as well as help with the convergence rate of scenes containing glass and volumetrics.

http://www.luxrender.net/luxmark/

The results for LuxMark are comparable as it uses SLG(2) as the engine.

Edit: J_the_Ninja beat me to it :stuck_out_tongue:

http://www.luxrender.net/luxmark/

HEre is a GPU only result list: http://www.luxrender.net/luxmark/top/top20/Sala/GPU

My latest weekly LuxRender builds for Windows includes SLG3 with the updated SLG3 exporter for Blender. Right now they’re only in the OpenCL builds, but since most of the fun stuff in SLG3 is currently CPU-only, I’m in the process of updating the non-OpenCL builds to include them. Should happen within a day or two.

Keep in mind you don’t need a spiffy GPU to use OpenCL! If you got an AMD CPU, install their AMD APP SDK, otherwise you can install the Intel OpenCL SDK. Then you can use the OpenCL stuff on your CPU.

Thank you J_the_Ninja and zeealpal.

It is already on its way, maybe before the end of the year…

Great, because I tried before to render interior scenes containing glass and such in Luxrender and I found it quite slow to render.

Heck in those cases I even found Cycles giving better results that were easier to clean up (and it just has generic pathtracing). The Bidir VCM combined with the noise-aware sampling will make for a very interesting combination that might finally make Luxrender a good choice for mainstream artists (and by that I mean those who aren’t so invested in wanting to just play with the physics of light).

I’m confused why Lux is advancing so well with OpenCl, particularily with Radeon AMD graphics cards.

Isnt this branch stalled in Blender? { wasnt everybody blaming the AMD drivers? }

the kernels of SLG and Cycles are very different. SLG uses very simple materials with no mixing of any kind, and doesn’t have any production level features needed in an animation renderer. It’s hard to explain without a background in programming, but rest assured, Cycles is much more complex in its code base than SLG is.

thanks for info.

The one thing this SLG project seems to have, however, is one: Speed. { and two: wide range
of hardware } And that speed makes it very attractive for animation, imho. Not sure about the materials. Is there a page/ database describing what materials are available?