Daniel, What Dave said is pretty much correct. The definition of a group is simply a combination that composes only non-overlapping combination objects and only using union operators. Groups are conventionally above or at the region level in the hierarchy, although there is no technical limitation from using them to compose union collections of primitives, for example, below the region level.
A region is simply a (valid) combination object with the region flag set. Regions are intended to imply a homogeneous physical instantiation of some shape. That's where the story about their differences definition-wise terminate, and you probably already knew all of that. So on to the issue of attributes.. As you might recall, in v4, the GIFT values, material ids, region identifiers, and other 'properties' of a given region were stored directly as part of the database format and were intimately tied to the struct and objects themselves. With the move to v5, there was specific intent to stop that pollution of data encapsulation. Objects are simply what they are -- those properties are application- and domain-specific data (particularly V/L specific, of course) with the exception of the region flag. The intent was (and still is) to move all of them over to only being attributes eventually. That means they certainly shouldn't be propagated forward to any new API including the GE as geometry data. There needs to be a separation of the domain-specific data. As for those attributes you noticed being ignored -- they shouldn't be, unless you mean they are ignored if the region flag is *not* set? They are stashed during rt_comb_form(), for example, during tcl serialization for .asc conversion where they (region id, air code, los, GIFTmater, and rgb) are still tightly coupled instead of being stored as generic attributes. If you found somewhere else where they are being ignored when the region_flag *is* set, then they're either being written out elsewhere (perhaps as part of the generic attribute system) or you maybe found a bug. Ah! Also .. note that there are two places where those values reside. That could be the issue. There's the in-memory values that are stashed in the struct and there is the "database attributes" (db5_get_attributes). That's part of the migration I was speaking of. Ideally what is supposed to happen is that the in-memory struct values are serialized out to disk and then read back via db5_get_attributes() to refill the struct. Later, if we were to remove the entries from the struct, they then would only reside in the AVS hash. Hope that helps? Cheers! Sean On Thursday, March 12, 2009, at 11:12AM, "Daniel Roßberg" <[email protected]> wrote: >Dave, > >> Code wise, the only real difference is a single region flag. >I think, this is not the whole story. When I've looked in the code I >got the impression that the attributes > - is_fastgen > - region_id > - aircode > - GIFTmater > - los >(and only these attributes) are ignored during import/export/TCL etc. >if region_flag is set. > > >Szia, > Daniel > >------------------------------------------------------------------------------ >Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >easily build your RIAs with Flex Builder, the Eclipse(TM)based development >software that enables intelligent coding and step-through debugging. >Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >_______________________________________________ >BRL-CAD Developer mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
