I find this an exciting build to say the least, due to these three major things.
For a long time users who wanted very high GI quality without artifacts such as splotches had to contend with slow methods such as the path-based methods, which would make for a really slow render especially if you had glass objects. Thanks to the relentless work on improving and polishing the new SPPM (stochastic progressive photon mapping) implementation, the frustration of waiting days to weeks for a complex image to clear up is soon to be left behind. Thanks to this new feature, Luxrender 0.9 can render out scenes with highly complex materials like glass in a much shorter timeframe than Bidirectional path tracing or regular path tracing.
If you still need to use a path-based method, but need it fast, Hybrid mode now has support for GPU-based bi-directional path-tracing, allowing significant improvements to the quality you get when using the GPU (and Lux uses OpenCL so ATI users can use it too).
The final thing that some people might find to be a critical thing, is the initial support for normal mapping, now Luxrender will properly render your normal maps created either from a generator or from baking off of a sculpted model. There still is a few issues for some cases, but it seems for other cases they are already usable.
The latest Luxblend25 can be easily obtained from the mercurial repository and the newest revisions should work in 2.58, this also being a release that may keep you busy rendering things out until a bit more polish makes it way into the new Cycles engine, so download and enjoy.
I was always fascinated by the speed of Luxrender’s development. If you compare Luxrender e.g.to the Yafaray, it seems that Yafaray is a dead project. Thanks and keep it up.
But focussing only on luxrender I must say that is one of the main reasons I upgraded my videocard as the OpenCL stuff is just fantastic. I even prefer it over cycles but that is mainly because that is CUDA only.
Keep in mind, Lux is also used with 3ds Max, Softimage, Poser, DAZ, among others. Dedicated Lux builds are usually just the standalone renderer as a result.
Sorry Ninja, I don’t get how what you say is related to the lack of 2.58 builds.
If someone takes the hassle of making 2.49 builds he could as well make 2.58 ones.
I can’t imagine an individual interested in cutting edge Luxrender that wouldn’t be using cutting edge Blender, too.
If you can copy and move folders about you really don’t need bundled builds, I know the are convenient and I also download them when I am feeling extremely lazy.
When the are no builds available you just need to download the vanilla version of blender, the latest luxblend and a weekly build of luxrender and you can set it up in 2 minutes tops.
Monkey, are you referring to this procedure over at Luxrender wiki?
While I agree that is not that hard and that we are speaking about development software, I don’t consider it user-friedly.
It does look like a wall of text, probably due to the fact that it detailed in explaining things. But once you do it and know where every thing needs to go than its really simple. And the plus is you are not waiting for people to post bundled builds which some times can take a few days give or take so five minutes versus 24hours or 48hours of waiting is a good trade off.
p.s. are the any special steps you need to take to get SPPM working. I got hybrid bi directional working but SPPM I get lux going but only a black render I can see it tucking over and calculating but no pic.
The thing I never worked out, was where to get a build of pylux, those instructions seem to assume you have it already, and I couldn’t seem to find out where it came from at the time.
pylux is inside the luxrender folder, so just download the build you need for your system unzip and look inside for a python 3 folder its in that folder. You can than copy pylux to where it needs to go. pylux needs to be there for material previews and hybrid rendering IIRC
Funny thing, I’ve used LuxRender before without much problems. Downloading the files and installing them and setting up blender is pretty painless for me. I downloaded the files yesterday and installed everything for blender 2.58 and blender wouldn’t start LuxRender. I know I had all the settings right, as I’ve fooled around with LuxRender since blender 2.56. I’m sure I could have started LuxRender separately and loaded the files manually and rendered the image, but it’s so nicer when it’s automatically started by blender. I’ll try it again in a week or so…
I just got it working after almost 30 minutes, performing three downloads from three different locations (Blender, Luxrender and Luxblend), exploding them in folders and copying files around (following instructions from the wiki page above) and finally messing a render settings in Blender to actually make GPU hybrid mode work.
I am running kubuntu 11.04, but have to admit that I do not use the bundled nvidia drivers but the ones directly from nvidia’s site.
With those ( currently 275.19 ) I have no problems running slg or lux in opencl mode.
Its just a bit of a pain thoughto reinstall the driver every time the kernel changes …
Well, it doesn’t show an image until you get through the first pass (usually 10-60 seconds, depending on the scene and your hardware). And it’s pretty easy to run out of RAM with SPPM at this point, and if you do, usually that results in it just calculating really slowly.
thanks j, so the are memory issuse I did even think of that as the cause as I was able to run the yafaray SPPM without too many problems. I drastically cut my resolution and I finally got something out.
Yeah, I’ve been sticking with the classic Lux mode because of SPPM’s RAM use. Atm, it renders once pass while it lights (traces photons) for the previous pass. (SPPM usually works backwards compared to traditional photon mapping, meaning it does the eye-pass first, stores that, then lights it, rather then light the scene then rendering it. Although some researchers have proven you can do it photon-first and it still works).
The problem with overlapping the passes is you have to store the entire hitpoint data structure TWICE, since one pass is being traced while another gets lit. So you have two different passes in RAM at any given time. Since the eye pass data is tied to the pixel count, the higher the res, the bigger the hitpoint set. And that footprint is automatically doubled by this “double-buffer”. IMO, it should just be removed.
One of the SPPM devs said he tried removing it and it only slowed things down 3%, so who knows. Lux’s SPPM has been changing week to week, almost. (the guys working on this are practically winging it off 2-3 academic papers, so it’s been a bit of a wild ride)
