[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [33650] trunk/blender/source/blender/ makesrna/intern/rna_define.c: disallow RNA color values to be set to negative values.

[Campbell Barton]

On Tue, Dec 14, 2010 at 6:18 AM, Matt Ebb <matt at mke3.net> wrote:
> On Tue, Dec 14, 2010 at 4:35 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>> On Tue, Dec 14, 2010 at 5:10 AM, Matt Ebb <matt at mke3.net> wrote:
>>> On Tue, Dec 14, 2010 at 3:44 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>>>
>>>> Log Message:
>>>> -----------
>>>> disallow RNA color values to be set to negative values. Material colors could be set to -100.0 if typed in manually, this is sure to cause bad/unpredictable behavior.
>>>
>>> If this is a problem for materials, then it should be set in the
>>> material colour's range functions. Forcing all colour properties to
>>> have these limits is too heavy handed - It's not sure to cause bad
>>> behaviour, there are plenty of cases where you might want negative
>>> values in a colour property - doing things in the compositor for
>>> example.
>>>
>>> Matt
>>
>> Hi Matt,
>> Yep, materials could have their colors clamped instead (setting value
>> ranges is enough, without having range functions).
>> However this is the sort of thing that is often overlooked when adding
>> properties - color properties like sequencer, bone, object, theme,
>> lamp shadow, render stamp, fcurve, brush, world.... etc.
>>
>> So I think its better to have negative colors opt-in.
>
> I'm really not sure why. Colours are used for all kinds of things, not
> just pixels in an image. They can be used to represent other things
> like displacements, or used as relative offsets (eg. some comp nodes),
> or all kinds of stuff. Blender uses full linear floating point colours
> internally, and there's nothing inherent in that that means they
> should only be positive. I think defining this as something that 'all
> colours should be always positive' is too great a limitation to apply
> as a blanket case across blender - to me it's a similar sort of thing
> as the idiotic 'can't make concave faces' error in mesh edit mode,
> making an arbitrary yet wide ranging limitation in order to prevent a
> few corner cases.
>
> On a practical level I also disagree since:
> * people have to willingly type negative colours into those fields to
> start with - if that's what you explicitly type in then you get what
> you get
> * the idea that things can be added back in as needed I think is
> expecting a lot, I don't think it's the sort of thing that people will
> be bothered with reporting as bugs
> * if it's to prevent bugs, better to fix it at the source, since it
> could be a deeper problem. eg. if it's a problem in materials, what
> happens when a texture with negative colours is used, or anim sys is
> used to get negative values in there, or if a node setup generates
> negative colours? Clamping RNA inputs may not be enough there.
>
> My 2c anyway.
>
> Matt

Hi, I see there are valid reasons for negative colors but you say...

 quote:
  "I think defining this as something that 'all colours should be
always positive' is too great a limitation to apply as a blanket case
across blender"

Its just setting a default that RNA colour properties wont negative, 1
line in an rna property to set the range will change it to allow
negative values.

Either way - I can revert and add in clamping where negative values
don't make sense,
or go and add in exceptions where it does.

Its just a question of opt-in or opt-out.

Any other devs have a strong opinion on this?