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

Brecht Van Lommel brechtvanlommel at pandora.be
Tue Dec 14 17:02:18 CET 2010


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.


More information about the Bf-committers mailing list