On Tue, Aug 20, 2013 at 2:00 PM, Christopher Sean Morrison
<[email protected]> wrote:
> I think the issue right now is that the
> conversion happens at too low a level, in an attempt to catch most commands,
> and that will likely need to change.
I can confirm that - I was trying to make rgb and color transparently
equivalent.
> I think this is still the path forward. Using a more generalized "color"
> attribute should be supported and we should support multiple color
> definition methods via convention such as by name, rgb, hsv, cmyk, etc.
I agree that would certainly be preferable.
> What we do not have written down is a proposed convention for how that might
> be specified. It would be nice to make every place that supports a color
> definition work with the same convention.
>
> I suggest we use something like this: [format:][valuestring] where
> valuestring is interpreted by a format handler. The default format would be
> rgb and valuestring is {0-255}?{0-255}?{0-255} where ? is any non-numeric
> single-character separator (most of our examples use '/'). This makes it so
> no changes would be needed to be compatible with our existing interface, but
> opens a world of possibilities like:
>
> "128/128/128"
> "rgb:128/255/134"
> "hsv:100,30,0"
> "purple"
> "pantone:A4120-0"
> "obj:my_shader_object"
> "obj:some_other_object"
>
> Comments? Hate it, love it?
That looks very good to me.
> There is a simplicity and familiarity with other CAD systems to consider. I
> think setting a color on the object is a good property to retain to get
> started, but then put anything that doesn't evaluate to a simple RGB into
> shader object infrastructure.
That makes sense.
> Nick and I brainstormed the overarching issue of attribute management for a
> while and I've written up some of those thoughts into the TODO file, in the
> new ATTRIBUTES section. Comments welcome!
>
> The changes proposed involve introducing a version number to the attribute
> system and an interface for upgrading/downgrading attributes so we can make
> changes like "rgb" to "color" back to "rgb" or "cad:color" without the user
> really caring (other than to run our upgrade command when told). This
> intentionally mirrors the "svn upgrade" interface if you're familiar with
> that simple interface. It also sets the stage for making all attribute
> access go through the same API while asserting the "convention" used matches
> assumptions being made.
I think that sounds good - so to "downgrade" the attributes it would
be something like "attr upgrade -v3" ? Part of me wonders if that
would set up an expectation for dbupgrade supporting a similar
capability...
CY
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
