Latest News

Licensing change

Please note that the new code that is currently developed as part of the 2.0 code base is licensed under APL 2, the previous code was and remains GPL.

LuxRender 2.0 API

LuxRender 2.0 is on its way, a thread has been opened to follow development on the new API and features.

New optionally biased path tracing

A brand new integrator is currently being develop to help dramatically reduce rendering times at the expense of some user controlled bias in the rendering. Preliminary results look very promising.

New hair support coming

A much improved hair support is being added to LuxRender. The first results are quite promising.

SLG renderer

The SLG renderer branch has just been merged with mainline. This means from now on LuxRender has a full GPU accelerated render mode, it will be available in new development builds and in the forthcoming v1.3.

Not all features will be supported but there should be enough to fit most needs.

The "Frankenstein" project

Prepare for something huge, Dade is preparing a nice gift for you all.

New cloth material

The woven cloth model from Irawan and Marschner has been ported from Mitsuba to LuxRender. You can now enjoy hyper realistic cloth materials.

New sky model

A new sky model from Hosek and Wilkie can now be tested with LuxRender.

Noise awareness

We are currently experimenting with noise awareness both as a help condition when no visible progress is made and as a way to drive the metropolis sampler to spend more time in still noisy areas. There is a dedicated forum thread allowing you to follow the topic.

Slave caching of external files

Over the last few weeks I've been working on changing how masters send files to the slaves. It was based on this feature request. The goal has been to reduce memory and bandwidth consumption, and hopefully lead to potentially faster start-up time for slaves.

Before, the master would assemble a compressed "blob" containing essentially a copy of the LXS etc files, but also any external files. This blob was stored in memory. The reason for this was that it easily allowed for slaves to be connected after the scene was loaded, all we had to do was just feed the slave this blob. The slave would then decode it and extract any external file data.

The bad thing about this is that the master would store the same data twice in memory. If you used large textures, the PNG/EXR files would be stored in the blob as well as in decoded form for use during rendering. It also meant the master had to send all this data to each slave for every scene.

So, what I've done is the following. When the master loads the scene and it encounters an external file (ply, texture, nk etc), it will compute the a unique identifier, or hash of the file. It will then store the hash in the blob instead.

When the slave receives the blob, and the scene references an external file, the slave will look at the associated hash. If the slave doesn't already have the file, it will request it from the master. The hash is then used to verify that the file was transmitted correctly, otherwise the local file is removed and the file is resent. If the slave has the file already it does not request it, thus avoiding the additional bandwidth.

Since the files are served to the slaves on demand, the master will simply stream them from disk on demand. On the slave side they're also streamed directly to disk. The slave keeps track of which files it has by using the hash as part of the filename. Thus it simply checks if the file exists to determine if it already has the file. This means the cached files can be re-used between sessions. It also means that duplicate files will not be resent, even if they have different filenames. This can come in handy with animations for example, as static meshes should export to identical ply files.

Currently there's no cache management on the slave side. I'm planning on adding at two different behaviors in addition to the no-op, such as cleanup on-startup (on-exit is difficult to handle in case of crash) and cleanup of unused files after loading a scene.

So, to sum it up:

  • A bit drastic changes, needs a lot of testing.
  • Should save bandwidth and time sending same/similar scenes to slaves.
  • Should decrease memory usage on master, especially on scenes with large external files (ply, textures etc).
  • Currently no cache management.

We've got fresh weekly builds containing these changes, and please leave any feedback regarding this feature in this thread.

New year, new build!

Check out the latest weekly build for improved GUI, more stability, improved SPPM support and the fix for a longstanding scattering bug.

LuxRender post-0.8 development status

After LuxRender 0.8 was released, this web site has been a bit quiet. So quiet in fact that some of you even thought we had stopped developing LuxRender.

Judging by the front page, it's not hard to see how one could reach such a conclusion. Fortunately it couldn't be further from the truth. That's why we've introduced this dev blog, so that us developers can keep you guys up to date on what we're working on. In addition it's a great place for us to explain new features in more detail.

So to kick it off, I thought I'd just give a very brief summary of what we've been up to since 0.8:

- Added multi-GPUs support to Hybrid Renderer.

- Added normal mapping support.

- Introduced motion transforms, specified using new motion block. Unifies motion blur handling for cameras and instances. Allows for motion along complex paths within a single frame.

- Much improved network handshake code, preventing slaves from ending up in eternal busy state.

- Added new "layered" material, for true layered materials.

- Added new "glossycoating" material, which takes a named material "basematerial" instead of the "Kd" color. Can easily be added to any material in LuxBlend25.

- New "fresnelcolor" and "fresnelname" fresnel textures, fresnelcolor allows to define the IOR from the normal incidence reflection color.

- New "metal2" material that takes a fresnel texture instead of a file or preset name.

- New "colordepth" texture to compute absorption properties from the resulting color at a given depth.

- Added support for adding files to the Render Queue via the command-line.

In addition to the above there has been a huge number of bug fixes, introduction of hybrid bidir renderer, and SPPM has received a lot of work.The above is just "core" development. In addition there has been a lot of fantastic work on the exporters thanks to a number of dedicated volunteers.

If you feel like playing around with some of the newer features, please download a "weekly" build. We try to keep the development builds as stable as possible, so there shouldn't be too many surprises. We love feedback so don't be shy posting.

LuxRender is being developed entirely by volunteers in their spare time. I think I can safely say that us developers enjoy working on LuxRender to make it a great experience for you to use, and that looking at the awesome renderes that you folks produce using "our" LuxRender greatly inspires us. So thank you for using LuxRender and keep adding those renders to our gallery.

Welcome to the new development blog

The idea behind this page is to publish information or previews of any new LuxRender developments.

Community News More...

LuxRender v1.6 release

The final release of LuxRender v1.6 is now available for download. Please see the announcement for details and show us what you can do with it!


LuxRender v1.6RC1 Release

We have released the first RC for version 1.6 of LuxRender. Check out the announcement for details.


LuxViewer for iPad

AMC Bridge has contributed the code of LuxViewer for iPad, a free LuxRender viewer.


LuxRender 1.5.1 release

A quick fix has been made available due to a few annoying issues with glossy materials. Please see the announcement for details.