LuxRender Bug Tracker - Issues

0001005: OpenCL local work group size is not calculated correctly

Sun, 19 May 2013 06:16:48 -0700

At pathgpu.cpp:957, the benchmark queries the OpenCL sdk for the CL_KERNEL_WORK_GROUP_SIZE for this kernel. Later on, the returned value is used ("as is") as input to NDRange localworkgroupsize parameter. This is not right. because the benchmark needs to to provide as LocalWorkGroupSize a value which is divisible by the GlobalWorkSize, and it doesn't validate that whatever was returned by the SDK does divide the GlobalWorkSize.

In a good scenario, the benchmark needs to take the returned value X from the query CL_KERNEL_WORK_GROUP_SIZE, and calculate a new value Y such that:
((Y <= X) and (GLOBAL_WORK_SIZE % Y = 0) )

0001393: File->Open starts render from scratch even if previous render attempt exists

Sun, 19 May 2013 01:06:42 -0700

File->Open should detect whether a scene has already been rendering. It doesn't. Instead, it currently assumes to start the scene from scratch whether or not there was a previous render in progress. This behavior overwrites whatever was previously out there for that scene. This is an easy mistake to make that's irreversible.. especially if the scene has already been rendering for a long time.

Yes, there is a Resume FLM.. menu option and this should be used, but this option shouldn't even be necessary. Instead, File->Open should replace Resume FLM entirely and detect if the scene has already had a rendering attempt. File->Open should prompt the user to A) continue a rendering in progress or B) start the render from scratch if this scene already has the necessary resume information. If the scene has never had a rendering attempt, it should proceed to start it from scratch without prompting.

0001392: Strand length info/mask texture

Sat, 18 May 2013 22:52:27 -0700

Currently, there is no way to affect the appearance of hairfileshape strands along their length, only their base can be affected, and this is carried down the entire strand.

Cycles' hair primitive comes with a "hair info" texture that can output a float value/mask based along the length of the strand. Rays hitting the bottom of the strand return 0, rays hitting the tip return 1.

Adding something similar to Lux would allow blending with mix/band textures and the mix material based on length, allowing for color changes along the strand (seen in several animals, such as wolves), or for fading the strands transparent at their tips.

0001356: Hang during scene file parse computing subdivision on included .ply file

Sat, 18 May 2013 15:53:45 -0700

The attached minimal scene hangs LuxRender during scene file parse. The GUI is responsive, but if you try to close Lux, it will never end, since it's waiting for the subdivision calculation to complete, so you have to forcefully kill Lux. When lux is started with debug messages enabled, nothing shows in the log file. Lux memory footprint remains stable, with it pegging out one CPU core once it starts on the subdivision calculation.

0001334: Basic logic error in SDFace::vnum() does not abort and causes Lux to rapidly consume all system memory

Sat, 18 May 2013 15:52:41 -0700

I have a plymesh file that when subdivision is applied, triggers this error in SDFace::vnum(). When this error occurs, whatever is calling this function doesn't deal with the error result, and instead keeps retrying. The log fills up with 1000s of entries of this error message as Lux proceeds to rapidly consume all system memory. (It blew through 24GB of RAM in less than a minute.)

0000823: Add instancing support for meshlights

Fri, 17 May 2013 02:14:42 -0700

Currently meshlights can't be instanced, thus making them incompatible with motion blur (except moving a camera relative to lights, but this is not always possible). I think at least "move" and "rotate" transformations should be supported with meshlights instances. This will already cover 90%+ of usecases, and scaling could be added later when someone will actually request it.

0001384: Make Double Sided material to preserve energy

Fri, 17 May 2013 01:35:53 -0700

The introduction of Double Sided material provided a way to create complex scenarios (especially using nodes material editor) as well as made possible to ditch some ad-hoc hooks put in place earlier, specifically backface option of Glossy Translucent material. The only issue is Double Sided material doesn't preserve energy for transmissive materials, so a not too adept user could end up in situation with magnified energy throughput.

Thus i propose to cap a sum of transmission channels of component materials to 1.

0001299: Sampling maps must be sent on slave connect/re-connect

Fri, 17 May 2013 01:29:22 -0700

Sampling maps are only sent to slaves at the time the sampling map is applied. If a slave is unavailable (e.g., due to network failure, etc.), the map will not be delivered to it once the slave is reconnected. Additionally, the sampling map is not set to new slaves connected after the sampling map was applied. The slave connect/re-connect logic needs to ensure the slave has current maps.

0001298: Noise Aware map calculation should occur only on master nodes and be pushed to slaves

Fri, 17 May 2013 01:28:52 -0700

Currently, all nodes calculate their own noise map. This is a problem for slave nodes, as they reset their film buffers each time the master fetches their progress. Since the noise map is generated from the current film, this means the noise map generated on slaves will always be representative of a started-from-scratch render. To properly do network noise aware rendering, only the master should calculate the noise map, as only it has the complete sample history, and then push the noise map to all slaves.

0001314: Lux writes the "image saved to..." even if the write actually failed

Thu, 16 May 2013 14:25:09 -0700

If you try and save an image and it fails for some reason, Lux will print the sucessful message anyway. For example, saving light groups to a directory without write permissions results in:

[2012-11-09 22:31:37 Severe error: 14] Unable to write image file '/Volumes/Scratch/Projects/Last-light/Render/last-lightv2-sky.exr': Cannot open image file "/Volumes/Scratch/Projects/Last-light/Render/last-lightv2-sky.exr". Permission denied.
[2012-11-09 22:31:37 Info: 0] Light group HDR image saved to '/Volumes/Scratch/Projects/Last-light/Render/last-lightv2-sky.exr'

0001388: Crash when opening material tab

Wed, 15 May 2013 12:32:54 -0700

Each time i open the material tab, blender crashes.

Opening Blender with the terminal, it display this:
[Lux 2013-May-09 21:22:04] Rendering material preview: Material.001
Writing: /tmp/blender.crash.txt

And this is the blender.crash.txt file:
# Blender 2.67 (sub 0), Revision: unknown
bpy.context.scene.render.engine = 'LUXRENDER_RENDER' # Property

# backtrace
blender() [0xb81648]
/usr/lib/libc.so.6(+0x35240) [0x7f6de854e240]
/usr/lib/libboost_thread.so.1.53.0(_ZN5boost6detail16thread_data_baseD2Ev+0x38) [0x7f6ded6b6b08]
/usr/share/blender/2.67/scripts/addons/luxrender/liblux.so(+0x41b573) [0x7f6dc058c573]
/usr/lib/libboost_thread.so.1.53.0(_ZN5boost6thread6detachEv+0x99) [0x7f6ded6b5d69]
/usr/share/blender/2.67/scripts/addons/luxrender/liblux.so(_ZN5boost6threadD1Ev+0x16) [0x7f6dc07ec6d6]
/usr/share/blender/2.67/scripts/addons/luxrender/liblux.so(+0x41ea29) [0x7f6dc058fa29]
/usr/share/blender/2.67/scripts/addons/luxrender/liblux.so(_ZN3lux7Context8WorldEndEv+0x5cb) [0x7f6dc02f86db]
/usr/share/blender/2.67/scripts/addons/luxrender/liblux.so(+0x67bc64) [0x7f6dc07ecc64]
/usr/lib/libpthread.so.0(+0x7dd2) [0x7f6dee771dd2]
/usr/lib/libc.so.6(clone+0x6d) [0x7f6de85feced]

0001391: Add command line option to write image files after merging films

Mon, 13 May 2013 09:19:17 -0700

Currently, the LuxMerger command only merges film files. One then has to load the resulting film in the LuxRender GUI to export the film to an image file. This is a manual step that takes extra time to reload the film buffers (which may be several hundred MB and take a while to load) that LuxMerger already has a resulting copy of in memory after it finishes merging films. There is also no automated way to convert to image file using luxconsole, either, so this step cannot be scripted, either.

For the most flexibility, LuxMerger should take separate options for writepng, writetga, writeexr, etc to support the different workflows people use.

0001390: Add support for nested instances to OpenCL modes

Sun, 12 May 2013 11:53:37 -0700

Full/Big Lux supports nested instances, and these are quite useful, as they provide object-local transforms to the multiple parts of a complex instance object. However, the OpenCL Renderer modes (hybrid and SLG) do not recognize nested instances. Lux should flatten all nested instances during scene prep stage so the OpenCL modes can also render them.

0001389: luxconsole terninates when using --threads 0

Sun, 12 May 2013 11:45:05 -0700

When running luxconsole using the --threads 0 parameter, the application terminates ("Killed") following tesselation of primitives.

Zero threads, when used in conjunction with the -u parameter is a valid use case.

Also, a zero thread and zero node condition should be dealt with more gracefully than "Killed".

0001251: SPPM will not compute caustics.

Thu, 09 May 2013 12:57:45 -0700

Glass objects render correctly, but do not transmit light. This image was made using bidirectional ( http://ompldr.org/vZjBsMA/Heart.png [^] ) , while this was made using SPPM. ( http://ompldr.org/vZjBsZw/Heart.png [^] ). Just in case SPPM works anywhere else, here's the scene I used: http://www.mediafire.com/?baxxisiotdcsw41 [^]

Reproduced on Linux and Windows. RC3 in Windows, latest sources (August 7, 2012) in Linux.

0000797: Image with ERPT sampler is much darker

Thu, 09 May 2013 12:44:37 -0700

The image rendered with ERPT sampler and linear tonemapping is much darker compared to every other sampler (approx. factor 300).

0000952: Exphotonmap ignores light groups.

Thu, 09 May 2013 12:42:25 -0700

When using exphotonmap, it ignores light groups and the first listed light group controls all simultaneously.

0001361: Keep sun power constant regardless of sun disk size

Thu, 09 May 2013 12:40:54 -0700

There is a discrepancy in logic in how lightsources power is handled between meshlights and and the sun. With meshlights the power output is constant regardless the meshlight size -- when a user makes the size bigger, the lightsource gets dimmer because the output power is preserved.

However with the sun it's backwards: if a user changes the relative sun disk size, so changes the light power proportionally to the disk size, making it to overblow the scene. What's worse, the skydome power remains the same, and if the user doesn't compensate the sunlight power (after splitting the sun and the sky lightsources), the tonemapping could make the sky just black. Moreover it's doesn't clear for some users that power is proportional to the sun disk area, so, for example, if the size is set to 20, the gain must be divided by 400.

I think the core must keep the sun power constant regardless of its size to stay in accordance with other lightsource types.

0001374: Lux Marble texture is color type instead of float

Thu, 09 May 2013 12:03:21 -0700

Lux native Marble procedural texture is color type and can't be used to modulate other textures and material properties. This doesn't seem right. For instance, Blender Marble texture is float.

0001387: Create plymesh files for network slaves when shapes are declared in-line in the scene file

Tue, 07 May 2013 20:17:57 -0700

Some exporters only generate in-line shape definitions rather than saving shapes as a plymesh file (as they should really do). This makes sending a scene to network slaves slow, especially when used over WAN links. Ideally, when network rendering is utilized, Lux would generate a plymesh file for Shapes specified in-line so that slaves can cache the geometry definitions (which often amount to hundreds of megabytes of geometry for a full/complex scene).

0001101: CRF not restored on FLM first load

Tue, 30 Apr 2013 23:55:06 -0700

When you first load a previously saved FLM, CRF stays disabled even if it was enabled prior to save. However, if you reload the FLM, the problem resolves. You don't even have to load the same FLM twice, you just have to load the CRF-enabled one after some other FLM after the GUI is started (some uninitialized var?).

0001385: LuxGUI limits halt time override to 24 hours

Sun, 28 Apr 2013 14:17:31 -0700

The GUI will not allow an hours number higher than 23, making the max override time 23:59:59 (or effectively 24 hours). While I understand not wanting to have the hours field expand to three digits, it should at least allow one to specify all the way to 99.

0001383: Add an option to output untonemapped exr in addition to tonemapped exr for periodic image saves

Mon, 22 Apr 2013 04:16:04 -0700

This is specially applicable to rendering with Luxconsole, but it's also relevant to renders with LuxGUI.

I'm currently experimenting with both Luxrender's internal tonemapping options and with external tonemapping tools (Luminance HDR mostly). I would find it very useful if it was possible to add a "also export untonemapped image" property to periodic exr export, contingent on the "export EXR tonemapped" property being set to TRUE.

0000930: consolidate light groups option

Mon, 22 Apr 2013 03:08:14 -0700

As discussed in this thread (http://www.luxrender.net/forum/viewtopic.php?f=16&t=3880&hilit=+light+groups [^]) long ago, I think using light groups would get significantly more convenient if one would not have to restart a rendering after adjusting light groups. Therefore I propose to incorporate the functionality to take light group settings into account when sampling the image.

This feature would need one button that could be located on the light groups tab and could be called something like "consolidate light groups". Pressing the button would have the following effect:
-the sampling process would take the current light balance into account
-the power of all light groups should be multiplied by their gain value
-all light group sliders would be reset to the value of one

Visually, the only thing that users would see happening is that the sliders of the light groups get back to their default position and gain value numbers are all set to one.

0001322: luxrender image-maps give errors when loading after export.

Sun, 21 Apr 2013 20:27:19 -0700

When a texture is defined as luxrender image map type and use as a bump map, after export luxrender will give an error. This error depends upon what type of image was defined.

If greyscale image option is selected, luxrender will throw an error "Color image not found" and conversely if color image option is selected luxrender will throw an error "Float image not found"