0000929: light groups refuse to be switched off - LuxRender Bug Tracker

Mantis Bug Tracker

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

ID

Project

Category

View Status

Date Submitted

Last Update

0000929

LuxRender

Core

public

2011-02-04 13:02

2012-08-21 13:22

Reporter

abel

Assigned To

Carbonflux

Priority

normal

Severity

minor

Reproducibility

always

Status

feedback

Resolution

open

Platform

all

OS

OS Version

Product Version

0.8RC1

Target Version

Fixed in Version

Summary

0000929: light groups refuse to be switched off

Description

When switching off multiple light groups quickly after each other, only the light group that got switched off first actually gets switched off. When it is time for the next scheduled viewport update, this gets corrected. However, when playing with light groups fast feedback is desirable.

Currently, the behaviour is as follows:
(assume light groups A, B, C)
-user: switch off group C
-LuxRender: Tonemapping...
-user: switch off group B
-LuxRender: Tonemapping... (still)
-LuxRender: updates viewport with groups A and B visible
-LuxRender: scheduled update, only group A visible

I can see two possible solutions:
A. keep track of light group changes during tonemapping, start tonemapping from scratch if changes have been detected
B. finish tonemapping, then instantly check if any changes have made to light group settings, if so, start tonemapping again

I have a strong preference for option A as one gets to see the desired situation more quickly.

Tags

No tags attached.

Mercurial Changeset #

Requires Documentation Update

No

Requires Exporter Update

Relationships

Notes
(0002790) Lord Crc (administrator) 2011-03-16 21:12	Currently there is no way of aborting a tonemapping operation, and I fear it's too entrenched to easily fix before 0.8. Option B should be easy enough though.

(0002964) Carbonflux (developer) 2011-04-22 16:38	This does reflect a general problem with "tonemapping lag." I still want to take a look at the control flow as it is right now and see if I can find a short term solution. I agree however that it looks like we need to reactor how we handle tonemapping and events in the gui.

(0002968) Carbonflux (developer) 2011-04-23 18:52	After talking with LordCrc about this and going over the control flow we have decided to implement a short term fix/hack by adding a tonemap pending flag, this will trigger a second tonemapping event if applyTonemapping is called in response to a change signaled by a control while tonemapping is going on. In effect option B above. In testing this I have found I almost don't notice the second event and overall it makes the UI feel more responsive when changing settings that trigger tonemapping in general. The long term fix is going to require being able to interrupt tonemapping which will require fundamental changes in the core so I am leaving this issue open.

Issue History
Date Modified	Username	Field	Change
2011-02-04 13:02	abel	New Issue
2011-02-13 00:38	jeanphi	Target Version	0.8RC1 => 0.8RC2
2011-03-16 21:11	Lord Crc	Assigned To	=> Lord Crc
2011-03-16 21:11	Lord Crc	Status	new => assigned
2011-03-16 21:12	Lord Crc	Note Added: 0002790
2011-03-19 05:59	jeanphi	Target Version	0.8RC2 => 0.8RC3
2011-03-20 18:08	Carbonflux	Assigned To	Lord Crc => Carbonflux
2011-04-17 11:11	jeanphi	Target Version	0.8RC3 => 0.8
2011-04-22 16:38	Carbonflux	Note Added: 0002964
2011-04-23 18:52	Carbonflux	Note Added: 0002968
2011-04-23 18:54	Carbonflux	Status	assigned => feedback
2011-06-06 08:21	jeanphi	Target Version	0.8 => 1.0
2012-08-21 13:22	jeanphi	Target Version	1.0 =>

Copyright © 2000 - 2012 MantisBT Group