[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.

Matt Ebb matt at mke3.net
Tue Dec 14 07:18:36 CET 2010


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


More information about the Bf-committers mailing list