Maniphest T41495

Now impossible to make negative volumes :(
Closed, Archived
Actions

Assigned To
Sergey Sharybin (sergey)
Authored By
Kitt Zwovic (gandalf3)
Aug 19 2014, 10:34 PM
Tags
  • BF Blender
  • Cycles
Subscribers
Adam Friesen (ace_dragon)
Bastien Montagne (mont29)
Brecht Van Lommel (brecht)
Campbell Barton (campbellbarton)
Kitt Zwovic (gandalf3)
Sergey Sharybin (sergey)
Thomas Dinges (dingto)

Description

System Information
Archlinux
GTX 460

Blender Version
Broken: 2.71
Worked: 2.70

Short description of error
The intent of the fix to T39284 seems to have been to make it harder to accidentally make a potentially confusing light-emitting volume, which makes sense.
However, it now seems impossible to get such an effect. Using negative colors as suggested doesn't seem to work, as they are now clamped as well (rB77f815f67a99404a6c5d78108e4cc93336f388cf). Using a negative value node also doesn't seem to work.

This is a cool effect, and IMO it's fine to allow negative/unusual values if they are explicitly typed in (as opposed to sliding with the mouse, where it's easy to do something accidentally).

In most places, Blender seems to go by the philosophy that the user knows what they are doing,
with well-placed exceptions for dangerous/non-reversible actions like opening a new file and losing changes to the current one, where it asks for confirmation.
Since setting a volume to be negative is easily reversible, IMO the user doesn't need as much "stupidity protection" :)

This is allowed with lamps, so I don't see the reason for disabling this on volumes.

Exact steps for others to reproduce the error

  1. Open
    negative_volume.blend508 KBDownload
    in 2.71, and compare to 2.70

Related Objects

Event Timeline

Kitt Zwovic (gandalf3) created this task.Aug 19 2014, 10:34 PM
Kitt Zwovic (gandalf3) raised the priority of this task from to 90.
Kitt Zwovic (gandalf3) updated the task description.
Kitt Zwovic (gandalf3) added projects: BF Blender, Cycles.
Kitt Zwovic (gandalf3) edited a custom field.
Kitt Zwovic (gandalf3) added a subscriber: Kitt Zwovic (gandalf3).
Adam Friesen (ace_dragon) added a subscriber: Adam Friesen (ace_dragon).Aug 20 2014, 1:00 AM

1). This isn't really a 'bug'.

2). If you use a value node hooked into a color mix node, you can still get negative color values.

3). I'm not so sure of 'stupidity protection' as it is to make sure that it's not so easy to get completely unintended, error-prone results by accident (which someone else might see as a bug). This way you have such results only present when the user intends it.

Kitt Zwovic (gandalf3) added a comment.EditedAug 20 2014, 1:49 AM

@Adam Friesen (ace_dragon)

  1. It depends on whether you think of negative volumes as a feature or not. Negative lamps seem to be a feature, so why not negative volumes? If negative volumes are a feature, then as a missing feature, they could be classified as a bug. Anyway, if this is off-topic here, where should I ask? (the mailing list?)
  2. Ah, thanks. That's a nice trick, but I still can't seem to use it to create a negative volume.. Am I missing something?
  3. Well.. What you said is pretty much what I meant by "stupidity protection", but perhaps that was a rather strong choice of words.. What I mean is: It should be pretty hard to type a minus sign by accident, but if by some chance the user does, then it should be pretty easy to remove it. On the extreme outside chance that they don't know to remove it or notice it that it's there, then hopefully google can help them.. In other words, IMO only allowing negative numbers to be entered by typing should be enough.

This seems to be working fine for lamps, so why all the clamping on volumes?

Thomas Dinges (dingto) lowered the priority of this task from 90 to Low.Aug 20 2014, 12:06 PM
Thomas Dinges (dingto) added a subscriber: Thomas Dinges (dingto).
Thomas Dinges (dingto) added a comment.Aug 22 2014, 3:30 AM

It should still be possible with OSL?

Thomas Dinges (dingto) added a subscriber: Sergey Sharybin (sergey).Aug 27 2014, 2:46 PM

Sergey, any strong opinion here?

Imho, the negative volume effect can be nice, but is too unpredictable to allow per default. If you want it, you can write a custom OSL shader which does not limit the color or density.

Campbell Barton (campbellbarton) added a subscriber: Campbell Barton (campbellbarton).Aug 27 2014, 2:48 PM

We can allow be explicitly setting limits so for some colors negative values are supported.

The reason I added this check is many colors could be set to negative values and really didn't do anything useful, or they gave some strange, accidental result.

So on a case-by-case basis this can be added back, but first check the math that deals with the color handles this correct.

Bastien Montagne (mont29) assigned this task to Sergey Sharybin (sergey).Oct 10 2014, 7:41 PM
Bastien Montagne (mont29) added a subscriber: Bastien Montagne (mont29).
Brecht Van Lommel (brecht) changed the task status from Unknown Status to Archived.Nov 9 2014, 4:10 AM
Brecht Van Lommel (brecht) added a subscriber: Brecht Van Lommel (brecht).

There's no reason to keep this bug open, the fix in T39284 intentionally disabled this "feature" which the volume integrator really can't handle correctly and will cause all kinds of bugs in multiple importance sampling, render passes and so on. Negative density is non-sensical and I don't believe any user actually knows what they are doing when using negative density. We can't keep around render bugs just because they look interesting.