[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 4:02 PM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:
> Hi,
>
> I think negative colors should be opt-out. I don't think it's really
> harmful, usually it will just give black in cases where it's not
> useful, and developers will forgot to opt-in when adding new
> properties. Negative material colors may be a case where this is
> actually useful in some rare cases.
>
> With any property where you go outside of the soft limits, there's the
> chance that things will work strangely, to me that is sort of the
> point of the hard/soft limits, allowing those who know what they're
> doing to bend the rules a bit.
>
> On Tue, Dec 14, 2010 at 3:30 PM, Roger Wickes From IPhone
> <rogerwickes at yahoo.com> wrote:
>> 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?
>
> EXR has nothing to do with this, it's a file format for saving on
> disk, the internal float buffers in the compositor can store all this
> data just fine. It's only a UI issue, and not really that relevant
> here, since e.g. a displacement or depth property (not compositing
> buffer) will not be exposed as a color, and even there we do actually
> have separate buffer types for scalars, vectors and colors.
>
> Brecht.

To close the topic, thanks Brecht for 3rd opinion :)
Reverted this change and applied clamping to colors which are display
only, fcurve's & grease pencil for eg.