On Jan 12, 2011, at 7:43 AM, Tom Browder wrote:
> In the draft "BRL-CAD Database Format" there is mention of perhaps
> having a registry of attributes so as to declare publicly use of
> certain key words, e.g., 'MUVES_component' which is being used in the
> AJEM community.
>
> Has there been any work in that direction, or is that not feasible or
> desired now?
The only work that comes to mind was efforts over just last year to
try and consolidate much of the default attribute getting/setting
presently in BRL-CAD, so that it goes through a common set of
routines. There hasn't otherwise been any more work in that
direction though there are common sets of attributes in use both by
BRL-CAD, MUVES, and a few other packages.
> We had a discussion some time ago about air codes, region IDs and such
> and I don't remember what the final resolution was, but I notice
> "default" attributes in the output files from g2asc on old TGMs show
> something different than red on the same TGM in .g form. In
> particular, in the old TGMs air is zero by default. In asc form {air}
> doesn't show at all for those old TGMs without an air code explicitly
> set but edcodes still shows that value as zero while red shows null
> for air.
>
> By referring to the asc form (and confirmed by red) It looks like the
> current "standard" attributes (those shown by attr) are:
>
> region
> region_id
> material_id
> los
This list seems incomplete. A few more that immediately come to mind
are:
air
color
oshader
inherit
Those are listed in db5_is_standard_attribute() in src/librt/
db5_types.c along with the companion db5_standardize_attribute()
which takes care of the slew of aliases several attributes have
(e.g., material_id, MATERIAL_ID, GIFTmater, GIFT_MATERIAL, and mat
all refer to the same thing).
> I guess for old TGMs I can still interrogate the hard-wired struct
> region variables:
True, but probably a brittle approach (at least for v5 files).
> But I have to say I like the ease of using attr these days--much
> easier than the original methods. And on new TGMs I am making good
> use of attr--hence the question about a standard registry for those of
> us who are in the business of exchanging TGMs.
What I'd like to see is *ahem* namespaces for attributes even if in
naming convention only, so that we can put them to greater use
without developers worrying about their attribute name getting
stomped on. Something like cad::material_id.
There'd obviously need to be an API established for setting/getting
attributes so that namespaces get respected correctly as well as a
way to upgrade attribute names.
Cheers!
Sean
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
