On Sun, Aug 18, 2013 at 3:52 PM, Tom Browder <[email protected]> wrote:So, what is the user to do to truly affect the color: use both rgb and colorattributes? Or does it matter since BRL-CAD may be treating 'color' and'rgb' as aliases for each other?
Instead of setting the attribute manually, users should be going through a command that knows what's best like the "mater" or "comb_color" commands.
I observe and claim that your earlier example is, however, buggy behavior and needs to be changed. Running "attr set key value" should always result in a key attribute getting set to value. It should not be doing ANY sort of implicit naming conversion. 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.
The rgb/color thing is basically a consequence of me jumping the gun
on trying to make the attributes more general and uniform - at the
time I was doing that it hadn't fully registered how gnarly all that
was and I probably just made things worse. My thought was that it was
reasonable to specify colors in ways other than RGB (CMYK, names,
etc.) so RGB was too specific, but as it turned out the rgb thing
wasn't just an attribute - it's buried deep in the data structures as
well. Arrgh.
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.
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?
Longer term, it would probably make more sense to do away with having
geometry objects directly saving any sort of color information - they
should instead link to a shader object, which would hold all of that.
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.
Cheers!
Sean
------------------------------------------------------------------------------ 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
