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

[Roger Wickes From IPhone]

There's actual pixel data which is 0-1.0 for rgba. But all the other bastardizations of 'image' really should use a different structure entirely like for displacement maps, z-depth/distance, masks, vector-pixel data and even intermediate compo results (even if saved in a exr container) even though the currrent rgba grid container has been handy, it has been pertubated way too much imho.but that would be a recode...perhaps force exr as an internal format that could support all the above?

Sent from my iPhone

On Dec 14, 2010, at 1: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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers