REQUEST: info on attribute inheritance language/protocol

Our group here at UNC is working on applications of immersive (virtual
reality) interfaces to architectual applications. My current project is
developing an external file to describe the 3D models we create. We would
like to be able to assign every object we make a name, which will have an
associated entry in the table. In that entry we would like to store
information about the object, in the form of attributes. Simple attributes
include color, texture, and rendering style; each of these attributes
might in turn imply another collection of attributes such as textureFile,
textureType, textureScale and so on. Eventually we will want to allow more
complex attributes such as interactivity (collision off/on, gravity
off/on, containment, etc). We want the whole affair to be hierarchical by
name, so that, say, chair3.seat.cushion will inherit attributes set in
chair3.seat, which in turn inherits from chair3.


I'd put a lot of thought into this, and was struggling to develop a good
form for the entries in the object description table, when I realized that
what I really needed was a language. This isn't a graphics problem--it's a
general attribute inheritance problem. If I could implement this objdesc
table using a language or protocol that someone else has spent hundreds of
man-hours hammering out, it'd save me and the people (future modelers) who
eventually have to use my format a lot of grief.


SO...I'm hoping that the folks on comp.compilers and comp.lang.misc
can give me some pointers. Where has this type of work been done before?
My first thought was to pattern the objdesc langauge after C++, which just
about everybody here knows and uses, but after looking into it I decided
that there wasn't enough structural similarity between C++ and what I'd
like to do to make the effort worthwhile. Here are the features I'd like to
see for an attribute inheritance language/protocol to use:
- Attributes should possess a functional hierarchy. For example, the
base attribute 'Material' might be set to 'solid'. 'Solid', in turn,
would expand into several secondary attributes such as 'specular',
'diffuse','shininess', and 'transparency'. If 'chair3' defines
'Material' this way but 'chair3.seat' sets 'Material' to 'texture',
then the slots associated with 'solid' would automatically be
invalidated, replaced with slots like 'textureFile', etc.
- It should be hierarchical in the strict sense that attributes
specified in one name (such as 'chair3') are inherited by objects
associated with that name (such as 'chair3.seat').
- Multiple inheritance would be nice. For example, in our current
modeling software it is possible to group objects and assign a name
to the group rather than to each individual polyhedron. I'd like to
assign priorities, so that if a polyhedron doesn't have its own name
it will inherit the attributes of the group it is assigned to. The
flexibility to implement several such layers of inheritance would
help.
- It would be nice to be able to pull in entire blocks of attributes.
For example if chair3.casters is brass, I'd like to be able to
inherit a global METAL.BRASS attribute group (attGroup). As the name
METAL.BRASS implies, it would also be nice if attGroups themselves
could inherit attributes, though this is less crucial.
- It should be flexible. I don't want to have to specify a complete
list of ALL possible attributes because our needs might (will) change.
For example, right now our textures are procedural. When we implement
image textures a whole new set of texture-specific attributes will
come into play. At the very least a list of possible attributes should
be separate from the parser, rather than hard-coded into it.


This is such a general problem that I can't believe someone hasn't already
worked out a solution, better and more general than I'm likely to come up
with, that fits our needs. Any pointers to literature, more appropriate
newgroups, in fact any advice at all, would be greatly apprecatied. Thanks
for your time and bandwidth,


David Luebke
luebke@cs.unc.edu
--

Return to the comp.compilers page.
Search the comp.compilers archives again.