by 2013-03-04 06:38on
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.
by 2012-09-16 13:56on
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.
by 2012-05-12 11:05on
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.
by 2012-01-12 01:02on
Check out the latest weekly build for improved GUI, more stability, improved SPPM support and the fix for a longstanding scattering bug.
by 2011-11-28 13:29on
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.
- 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.
by 2011-11-27 09:32on
The idea behind this page is to publish information or previews of any new LuxRender developments.