Frequently Asked Questions - LuxRender Wiki
Luxrender GPL Physically Based Renderer

Frequently Asked Questions

Personal tools

From LuxRender Wiki

Revision as of 23:52, 15 May 2016 by Ocutux (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Contents

LuxRender FAQ

Understanding LuxRender

Where is the finished image saved?

LuxRender will periodically save the output image in the same folder that the .lxs file is located in. The interval this happens at can be configured in your exporter. You can save the render manually by selecting File > Export to Image. You can also click the GUI's clipboard button to copy the framebuffer to the clipboard.

When is my rendering complete? Does LuxRender ever stop?

LuxRender is a spectral-progressive renderer. By default, it will keep on improving your image until you are satisfied and stop it. If you would like it to stop after a certain amount of samples per pixel, for instance when rendering an animation, use the "haltspp" or "haltime" parameters. (See your exporter's manual for more information on configuring render settings)

This goes for the biased rendering modes as well!

Why is LuxRender slower than <other render engine>?

This is largely due to the nature of the algorithms involved. LuxRender is designed as a physics simulator, essentially. It generates images entirely via raytracing, and performs these calculations using the actual spectrum of the ray, rather than an RGB color. By default, LuxRender will also use an "unbiased" rendering method (metropolis light transport). Unbiased methods are by nature slower than biased methods, since they must indiscriminatly account for everything the scene. LuxRender has biased rendering options as well, which can be signifcantly faster.

The upside of all this slowness is that LuxRender produces extremely realistic images, with almost no fussing with settings. It's always a trade-off with 3D rendering, there is no perfect rendering method. If there was, everyone would be using it, and we wouldn't have countless rendering engines in the world.

Which of LuxRender's modes are biased and which are unbiased?

This is actually somewhat dependent on settings used in some cases, but generally: Direct, Instant Global Illumination, Ex Photon Map, and Distributed Path are biased, Path and Bidirectional are unbiased.

Why does LuxRender leave bright spots in my image? <other render engine> doesn't do this

By default, LuxRender uses a metropolis-hastings sampler. It is, in a sense, attracted to bright objects. As a result, it has an occasional habit of leaving clumps of "fireflies" or bright pixels in the image. These will dissapear over time as the image gathers more samples. The metropolis sampler is extremely helpful in finding difficult light paths, such as caustics.

If you still find this behavior undesireable, you can use the lowdiscrepancy sampler instead. This sampler will distribute samples in a quasi-random pattern across the image, which should keep the noise even as it clears up. This can be useful for animation frames, where consistency of noise is more important than overall clarity.

What does the "eff" statistic mean, and why is it above 100%?

The "eff" statistic stands for Efficiency, and essentially measures how easy it is for LuxRender to "find the light". Currently it measures how many light contributions each sample has, on average. Due to how LuxRender's rendering algorthms work, it is very common to see an efficiency rating of over 100%. For example, while the bidirectional path tracer spends more time per sample (the Samples/sec count is lower), it has usually a much higher efficiency rating than the regular path tracer. In other words, you get more bang for the buck with the bidirectional path tracer.

In fact, your efficiency should always be over well 100%, except with the Ex Photon Map integrator (that one is a bit different from the others as far what efficiency means.) Efficiencies at or below 100% with path tracing algorithms (path or bidirectional modes) indicates a mis-configured sampler or a very difficult scene. See My scene has very low efficiency for more info.

Features

Is LuxRender GPU-accelerated?

LuxRender supports GPU-acceleration for some rendering methods. Specifically, the Path integrator has an "evil twin" that will use GPU-acceleration. For more information, see the GPU acceleration documentation

Does LuxRender support caustics?

Absolutely! Caustics are a natural phenomenon from the direction changes that happen to light that reflects or refracts, so no special effort is required to support them with the unbiased modes. Several of LuxRender's biased modes can support caustics as well, in fact, they will by nature unless specifically set not to.

Does LuxRender support any kind of "passes"?

Since version 1.4, LuxRender supports passes through the new LuxCore API: Wiki Page
For older versions or if you don't use LuxCore, the old answer to this question is still valid:

Not really. In the traditional sense, passes involve saving the seperate steps in render computation to seperate files. Such as a "shadows only" pass, for example. LuxRender cannot do this, as it does not use multiple steps to build the final image in the first place! It simply fires rays into the scene until told to stop. For example, there is no shadow pass, shadows are simply places where less rays landed, so they came out darker.

One thing LuxRender does have is light groups. It keeps track of which lights contributed what to the final image, so it is possible to selectively disable certain lights. This can allow for additional output images containing only a subset of lights, such as the car headlights in a "night city" scene.

Is there SSS (Subsurface Scattering) support in LuxRender?

Yes, it is available via the "homogeneous" medium type. Homogeneous offers a physically correct simulation of the optical phenomena behind subsurface scattering, rather than the fake SSS effect used in many biased renderers. Some background on subsurface scattering:

Subsurface scattering is a process of light transmission through non-homogeneous mediums, mostly consisting of low density, but there are exceptions like pearl or amber. (Note: the "homogenous" medium type is named for the even distribution of its "particles". Strictly speaking, it simulates an evenly-distributed, non-homogeneous medium) Light photons do not transmit through these mediums in a straight line like they do with glass, however, they also do not reflect instantly from the surface layer like a diffuse material. Rather, due to interaction with microscopic inclusions while transmitting into the medium, the photons can lose part of their energy and change trajectory considerably. The process of subsurface scattering has two components and different materials exhibit them in different proportions: 1) Subsurface transmission -- whereby a light photon will transmit through a medium but the axis of entry will often be very different from the exit axis. 2) Subsurface reflection whereby the photon will go through a series of subsurface interactions and then leave the medium from generally the same direction it entered, but far from the point at which it entered.

Note that due to the nature of LuxRender's volume system SSS cannot be used with planar meshes, since LuxRender will think the space between planes is actually space inside of them. You must model the thickness of the mesh so LuxRender has a volume to calculate scattering within.

Does LuxRender support high dynamic-range (HDR) rendering?

Better than that. When most renderers talk about "HDR rendering" they are referring to using 16bit or 32bit RGB values to calculate the image as opposed to the 8bit color our monitors and printers use. LuxRender is fully spectral, meaning it does not use RGB values at all while tracing rays. It uses the actual spectrum and power of the ray. Because of this, the dynamic range of brightness and color it can calculate is not limited by the precision of an RGB value. After the ray's final spectrum has been found, it is converted to [1] color on the film. RGB is only used for final output of the image.

If you prefer to follow an HDR-photography style workflow to finish your renders, LuxRender supports converting the XYZ film to 16 or 32bit RGB and saving the result to an OpenEXR file. This file will be saved without any further processing, leaving you with a file ready to be tonemapped. No multiple renders at different exposures or merging required.

Does LuxRender support blacklights?

Blacklights themselves are supported, there is even a preset for the lampspectrum texture for one. However, when most users ask this question, they are curious if setting a blacklight in LuxRender will automatically give the glowing effects. So the question they are really asking (even if they don't know it) is "does LuxRender support flouresence"? The answer to this, unfortunately, is no. It could, since the lack of it is only due to LuxRender not knowing that light hitting a material could affect that material's emission properties. But this feature has never been added, and is pretty low on the to-do list since it isn't terribly useful outside of the occasional scene involving blacklights.

Does LuxRender support lasers?

Yes! LuxRender has a laser lamp type! See this forum thread for more info.

How Do I?

How Do I Continue a Render Later?

The easiest way to continue a rendering later is as follows:

  • Stop the render in LuxRender and use File > 'Save FLM...' to save the current state of the render to the .flm file.
  • LuxRender can now be closed.
  • Later, when you wish to resume the render you can either open LuxRender and then, using File > 'Resume FLM', open the .lxs file of the scene in question, OR simply double-click the .lxs file which your operating system should have associated with LuxRender. LuxRender will automatically use the .flm file you saved earlier and continue where you left off.

NOTE: The 'Load FLM' button lets you open a .flm file in order to perform post-processing, however it will not perform any rendering.

NOTE 2: All of the above assumes you did NOT have the 'Restart/Erase' button selected in your exporter. If you did, then a resumption of the render will start all over from the beginning. To change this you need to manually modify the .lxs file of your scene. See the details for doing this in the 'NOTE' at the bottom of this section.

I want to use LuxRender for an animation. How can I do this?

Strictly speaking, you can render an animation with LuxRender regardless of the settings used. Since this can lead to long and unpredictable render times (far beyond what is feasible when you have a few hundred (or thousand) frames to do), there are few things you can do to get your render time down to something sane.

  • First of all, you should avoid the metropolis sampler. While it's useful for still renders, it does not distribute samples evenly across the image. It has a tendency to get "clumps" of bright samples which can be an issue when rendering many frames in rapid sucession. The random fireflies from metropolis can be very noticeable, as they are points that aren't consistent from frame to frame. The low discrepancy sampler should give you much more consistent results. When a single image is shown for a fraction of a second, consistency of the remaining noise is more important than trying to get rid of nearly all of it.
  • Second, you should use the Linear tonemapper for all frames. It uses a fixed exposure, wheras the Reinhard, Auto-Linear, and Contrast tonemappers will all attempt to adjust themselves to the image brightness. Using a tonemapper other than Linear will result in a flickering from frame-to-frame. It's the same reason you should never use auto-exposure on a video camera when shooting a scene for a movie, except in this case auto-exposure is recalculated from scratch for each frame.
  • You might want to consider using the exphotonmap integrator. While it can leave artifacts in places, you can tune it to keep them at bay, and these tweaks are often the same for all the frames in a particular shot. It will clear the noise much faster than the bidirectional or path integrators will.
  • You need to get LuxRender to stop somehow after each frame. You can do this with the halttime or haltspp values. Haltspp stops LuxRender when it reaches a specified quality in samples per pixel, halttime stops it after a specified amount of time.
  • Finally, you can use the queue feature of the LuxRender GUI to load all your frames for a batch render. If you are using network rendering, LuxRender will automatically send each frame to all render nodes. When a frame is finished, LuxRender will pull in all samples from the network before writing to disk and moving on, to ensure all work that was done is saved.

For more information. please see the Animation Rendering page

How do I add a (fake) background?

  • Use environmental map lighting
  • Enabled the alpha channel on the output image, and composite in a background image in post production. This method has the obvious problem that your background will not be visible in reflections.

I have a scene with complicated geometry and light sources obscured behind many obstacles. What is the best way to render such a scene?

Change your sampler to Metropolis, and set the large mutation probability value to around 0.1, and max consecutive rejections to about 150-250. You should also increase the max depth for your surface integrator. Also, the Ex Photon Map and new SPPM integrators can more easily deal with complicated light sources, although you should remember that only SPPM is unbiased.

Note that like any renderer, obscured/indirect light sources should be avoided if at all possible!

I'm thinking of buying a new computer for LuxRender rendering. Which specs are most important for this purpose?

The number of CPU cores, multiplied by single core performance -- get the best for your budget. Please take into account that rendering of images in high resolution with LuxRender requires very large amounts of physical (unswapped) memory; if you wish to produce such renderings, equip your machine with at least 4-8Gb of RAM. If you are planning to use the Hybrid rendering mode in LuxRender, a powerful OpenCL capable graphics card will also be beneficial. More features for Hybrid are planned for future releases, so it may be useful to keep an upgrade path open for a faster card.

Something's not right, what do I do?

My scene has rendered for hours, but it's still very noisy

First, please note that even on powerful machines, certain scenes might take over 12 hours to get satisfactory results (and much more with high resolutions). However, there are several things one can try in order to get satisfactory results quicker.

  • For interiors, use portals where you have windows or other openings where light can enter.
  • If your scene contains a lot of glass but you don't need the refractive effect of the glass (windows or similar), turn on the "Architectural" option in the glass material.
  • Scenes containing very bright (white) walls can lead to a noisy image. Try making them slightly darker. You can try adjusting the tone mapping parameters to compensate.
  • The glossy material is much slower than the matte material, and produces more noise. The glossier you set it, the more noise it makes. Think twice before using it, or cranking the gloss up. Matte is preferable for things like drywall or concrete.
  • Try using bidirectional path tracing with the Metropolis sampler, even if your render is an outdoor scene. Simple path tracing is often less efficient than bidirectional, even for outdoor scenes.
  • As a last resort, once you've got a very smooth sampled image with still a bit of grain in it, you can try some denoising filter in image-editing software like Adobe Photoshop or GIMP. LuxRender itself already ships with 2 such options under the Noise Reduction tab: Greyscale Restoration and Chiu.

I rendered my scene in LuxRender, but it still doesn't look realistic

Most of the time this is due to unrealistic lighting carried over from when the user was working with a biased renderer. Generally, point and spot lamps should be avoided with LuxRender, as they are not terribly realistic. To get a directional light, you should instead use an area light with either a reflecting object around it or an IES profile. Unrealistic material settings can also cause problems, you should avoid extreme color values such as 0 or 1.0 (aka 255)

LuxRender images look too dull or flat. What can I do?

By default LuxRender's light response is linear as far as color is concerned, and with brightness as well if you select the Linear tonemapper. Most digital cameras do NOT behave this way, since it can produce dull and boring images. You can use the "Film Response" function to mimic the behavior of cameras for a more varied, rich color scheme. A number of camera profiles ship with LuxRender. You can also try adjusting the contrast or saturation in post using an image editor such as GIMP or Adobe Photoshop.

I am experiencing huge memory useage when I render a scene with LuxRender. What can I do?

LuxRender is very resource intensive. As a first suggestion, install as much RAM into your computer as possible. 32-bit systems can use up to 3-4Gb, while 64-bit systems can use much more. Running LuxRender on 32bit systems or systems with less than 4GB of physical memory is generally not recommended for production use. Some tips for decreasing memory usage:

  • Lower rendered image resolution
  • Disable lightgroups if your exporter has an option for this.
  • If you're doing a "final" render, use luxconsole as it uses significantly less memory for large scenes. (See Luxconsole page for instructions)
  • Back off the subdivision levels you are using on your models. More polys increase RAM usage. As a pure raytracer, LuxRender must load ALL geometry into RAM and keep it there for the entirety of the render, so every poly you can save helps.

I have followed these instructions and do not have a material brightness set over 0.8 or 0.9. But now my white objects don't look white, they look gray. What can I do?

Our recommendation is to not have the brightness value of any colors set over 0.8 or 0.9. This is because it creates a number of problems for the renderer and your images. Among them, are a lot of extra color speckles or "fireflies" in your image and lots of additional time to de-noise your image while it is being rendered. If your whites just aren't coming out white, there are a couple of things you can do:

Adjust the tonemapping parameters prior to the rendering. Or adjust the tone mapping parameters during rendering in LuxRender's GUI on the Imaging tab. If Reinhard tonemapping algorithm is used, you can lower the Burn parameter to raise image brightness, but try not to overexpose it.

My scene has very low efficiency

If your scene gets low efficiency, it means that LuxRender has trouble hitting the light. There are a number of things you can try to improve the situation:

  • Try using the Metropolis sampler and the bidirectional path tracing integrator, both which should increase the efficiency. If you are already using the Metropolis sampler, you can try lowering the "Large mutation probability". Beware that lowering this too far can cause LuxRender to "get stuck" on a light, and your scene will be noisy despite high efficiency.
  • For interiors, use portals where you have windows or other openings where light can enter.
  • If your scene contains a lot of glass (windows or similar) where you don't need the refractive effect of the glass, turn on the "Architectural" option in the glass material.

Changing the strength of my light doesn't change the output

By default, LuxRender will use the Reinhard tonemapping operator. This tonemapper will adjust itself to the brightness of the scene, similar to how most automatic cameras will. If you add other light sources, any difference in intensity between the lights will be apparent however.

Alternatively you can use the Linear tonemapper, which is not dynamic.

I get "Illegal instruction" when launching LuxRender

Please make sure you downloaded a version which is compatible with your CPU. If in doubt, try the SSE (not SSE2) build.

I have white/black strokes effect around my lamps

If you are using the Mitchell filter (normally recommended) make sure the "supersample" option is enabled. If this doesn't fix the problem, you can use the Guassian filter instead, although this will give a somewhat softer image than Mitchell.

I've added portals to the interior scene, but rendering speed in kS/s has slowed by an order of magnitude. Is that right?

This is normal. Don't think of this value as an absolute rendering speed because different samples have different contributions to image convergence. Note the Eff (efficiency) value in the LuxRender status bar. It shows the avarage contribution of computed samples. Yes, using portals slows down the calculation of each sample significantly (portals involve very complicated math), but the efficiency of each of those samples can easily exceed 1000%. To see how things net out, take a look at the contribution rate (kC/s, kilo-contributions per second) this is calculated by combining the efficiency and sampling rate. It should be at least somewhat higher with portals, likely much higher. All in all, it's better to rely on eyeballing: Render a couple of images (one with portals and one without) for the same amount of time, and then visually compare which one has less noise.

The GPL

LuxRender is GPL software. What does this mean for me and my business?

It means you can use LuxRender for absolutely anything you want, on any machines you own. Personal art projects, commerical illustration work, product visualization renders, anything. If you want to use it to render elements for a Hollywood blockbuster, we would be honored.

The GPL does not place any restrictions on your own use of the program, period. In fact, you are not even required to agree to the GPL in order to merely run LuxRender, only to distribute it to others. (Distributing LuxRender or any other GPL application implies acceptance of the license) You can install copies on all the computers at your home or business if you want. And considering that LuxRender is cross-platform and has built in queuing and network rendering functionality, this might prove to be quite useful.

The GPL only comes into affect when you intend to distribute LuxRender or your modifications of it. In this case, you are required to provide a link to the source code and copy of the license along with the binary. The easiest way to comply with this is to just give someone the download archive you used yourself, or to send them to http://www.luxrender.net/en_GB/download to choose a copy for themselves.

For more information, please see the Free Software Foundation's GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html

Does LuxRender being GPL software require use of a copyleft license on the images I produce with it?

No.

All rendered images and film files produced by LuxRender are considered to be "program output" as defined in the GPL. The GPL does not affect the copyright of these items in any way. If the scene is your original work, you remain the sole copyright holder of the output items.

The Blender Foundation has put together a helpful guide about how using GPL software affects copyrights when used in a 3D pipeline. http://www.blender.org/education-help/faq/gpl-for-artists/

If I or my company modifies LuxRender for our own production pipeline, are we required to contribute these changes back to the project?

If the modified version of LuxRender does not leave your studio, the source code need not leave either.

If you choose to distribute your modified version of LuxRender, the GPL requires that you license the modification under the GPL as well, and provide the accompanying source code to those who wish to have it. It does not specifically require that you create a patch with your changes and submit it to the LuxRender project, although it would be appreciated by many people if you would. You are only REQUIRED to publish the source code used to build the binary you are distributing.

If you are unsure of your license obligations, you should consult with a lawyer.

Again, for more information, please see the Free Software Foundation's GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html

Background Information

Why yet another unbiased renderer?

Commercial and freeware products already exist, but there is no unbiased, production-oriented free software renderer around (note: freeware and free software don't mean the same thing).

Choosing the free software way, has, in our opinion, several advantages:

  • We hope to centralize contributions with an open-source development model: anyone can join the project and add improvements, find bugs, port the project to an unsupported platform or contribute with exporters development and testing. This could be much faster than a "one-man-band". If a lot of open source renderer developers would join forces, there could be a free rendering package with professional features, usability and support (exporters, presets, forum) very soon that could rival commercial ones. In the current state of affairs, there are a lot of small freeware and open source renderers that are used by narrow groups of enthusiasts, but don't find widespread use in the 3d mainstream world.
  • It can't disappear: freeware developers could get bored and stop development, commercial ones may get bought off by other companies following economical goals or go bankrupt, stopping maintenance or even retiring the software. There are numerous examples of such situations. With LuxRender, GPL code always remains, even if all the original developers leave it, chances are high that when it is used and needed, there will be someone to take care of the code.
  • Anyone interested can use it at no cost, without any restrictions, presently and in future versions. Free renderers are often used by Blender users. Perhaps because of the internal Blender renderer (no GI), because they love free software or just like experiments. Providing an unbiased GPL renderer allows tight integration between such tools (we hope for a full Blender integration) and guarantees that users will always have a free software choice.

What is the difference between LuxRender, SmallLuxGPU, and LuxRays?

LuxRender is the main program made by the project. It is a production-grade 3D rendering engine. It has stable releases, documentation, prebuilt binaries, and all the things you'd expect of a program that you'd use for day-to-day 3D work.

SmallLuxGPU is a development testbed app for LuxRender. It was initially designed as an experiment in GPU-accelerated rendering, and to some degree, user interface minimalism. Many people came to appreciate its fast render times and how lightweight it is, and it began to get traction as a renderer in its own right. It remains an experiment, it does not have stable releases per-se. It's features become stable by being incorporated into LuxRender. Because of this, it may not always be straightforward to find a binary of it or to install and use it. The regular LuxRender should be used when reliability and ease of setup are needed.

LuxRays is not a rendering application. It is a library used for accelerating ray-tracing applications via OpenCL. Initially, it only supported using the GPU for ray-intersections in a CPU/GPU hybrid setup, but has since been expanded with pure, GPU-only rendering. This is faster than hybrid rendering, but makes it much more difficult to implement advanced features and greatly limits the resources (such as memory) that are available to the renderer.

Why fork PBRT?

  • PBRT is a very robust foundation, so we don't have to reinvent the wheel. It has a clean, extensible design, exceptional documentation (the book) and it's used in academic environments, so a lot of students know it.
  • The goals of both project differ: PBRT is an academical research and educational tool, LuxRender is production and artist oriented: which creates differences in a lot of areas. In LuxRender speed optimization, removal of unnecessary features and adding practical ones (exporters, GUI, multithreading, file formats, MLT...) are the main goal. Design choices are made with the final user and artistic efficiency in mind.
  • Our fork is authorized by the PBRT authors.