Luxrender observations – part I

As previously announced, here is my report on the use of luxrender during my project ‘The other day in the forest’.

This is more a description of the things noticed and done during the process than a real tutorial. I have come to recognize, that I still have a lot lot to learn and explore before I am entitled to do a real howto/tutorial.

Using the forest project, I will try to highlight some of the areas and give some general thoughts and examples.

At the time of this writing I a referring to the actual CVS version both of luxrender and luxblend, which will closely resemble the upcoming 0.6 release.

So lets start with some introductory statements.

As lux is a standalone renderer with its own scene description language, BDRF based material system and light setup, it obvious, that you need an converter/exporter to be able to use the blender generated scene and render it with lux. In this case that’s what LuxBlend is doing.

The one thing I learned, was (although luxblend tries hard to convert your materials and lights) to completely ignore the automatic conversion done and build all the materials from scratch. Blender’s and lux’s materials are fundamentally different, so a conversion can be a compromise at best, with a lot of manual tweaking, which in the end gives you more work to adapt the converted material than if you built it from scratch.

Data Management

External Libraries

What is not immediately obvious (and will eventually be fixed in upcoming releases, both blender and lux) are some obstacles concerning the way you decide to organize your project.

My intention was to explore the possibilities external libraries provide. So I had the main objects – snail, mushrooms and moss – modelled and textured in separate blend files. The main project file linked to those objects. All references to external data in the libraries and the main file itself were set to use relative paths, so I was able to move the whole project without hassle.

Now Luxblend stores its settings inside the blend file itself, using something called an ID system. As I am not really familiar with this system, my guess is, that you are able to attach extra data to already exitsing data sets using separate IDs and fetch them again later. So e.g. luxblend can store the lux material settings for the blender material ‘mushroom’ in the data set for mushroom.

Unfortunately this doesn’t work with materials linked from external libraries. You can setup all the material, but after loading the file again you have lost all the work done. I have already reported this as bug.

This forced me to make all the external references (objects/objects data) local copies, which triggered another bug – this time in blender. Making data local from an external library, which uses relative paths, results in the same relative paths used in the local copy, which woks if the library file is in the smae directory, but fails miserably if not – which was the case in my project. (This bug is reported too – and already confirmed)

Conclusion: to use lux with a distributed project, you first have to make all external data references absolute and than make complete copies of the referenced objects/data in the main project file.

Luxblend and relative paths

In the current version luxblend has no support for the blender type relative paths where ‘//’ denotes the blend file’s directory. All paths have to be made absolute. The automatic conversion of materials will use the relative pathname and thus invalidate the material setting.

Conclusion: convert all external references to absolute paths.

Modelling

Scale

Being a physically correct renderer, lux has to know about the scale of objects. And it has to know it in physical units. To accomplish this Luxblend maps 1 blender unit to 1 m. This is important if you plan to use lamps with IES description files and want a real lighting setup.

There is a global scaling parameter which can be used to get the scale to a physically correct dimension if you did not pay attention in the beginning.

Subdivision / Displacement

I think it is better to let lux handle the subdivision and displacement, as this significantly reduces the size of the resulting mesh data file and thus the export and load process. If you want to have more control over the shape – using the Median Crease value in the edit properties box – you still have to use the blender subdivision.

Particle System

In my project I did not use hair, but only used a particle system to duplicate tree needle objects around the mossy floor. As I know, hair is not supported in lux for the moment.

My findings with a particle system for duplicating objects are, that luxblend does not generate all the instances but only the source object itself.

A simple particle system setup ( duplicating a sphere across a plane)

results in the following

Conclusion: Convert the particle system to real objects before exporting with luxblend.

Lights

Lux supports 3 types of blender lights – point light spot and sun. But what is true for materials is maybe more so with the light setup. Taking a tweaked blender light setup will surely not result in a working setup with lux. Even if you adopted a linear workflow, blender’s light handling is so different, that you cannot have a working conversion.

Additionally tweaks like the ambient light type or (A)AO is used inside blender to get GI like lighting, which is inherent to how lux is handling light.

Any mesh object in lux can be a light source, either by using the base material type light, or setting a emmissive property on the mesh’s material. This gives a tremendous advantage in defining complex lighting scenarios. Complex light objects come with a price though – rendertime.

Conclusion: you are far better off, setting the lighting up completely from scratch.

In my forest project I used one sun in combination with an angular environment map as single light setup. Lux uses a sun modell where you additionally can specify the turbidity of the sky. My pure blender setup involved one spot light, 2 ambient lights and I used AAO in sub mode.

this concludes the first part and will be continued soon ….