Thread: Re: [brlcad-devel] difference between group and region
Open Source Solid Modeling CAD
Brought to you by:
brlcad
From: Christopher S. M. <br...@ma...> - 2009-03-20 20:48:50
|
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" <dan...@go...> 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 >brl...@li... >https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > |
From: Christopher S. M. <br...@ma...> - 2009-03-20 20:57:32
|
Oh yeah, I'd also add that from a design perspective, there point of the attribute system is to be able to apply any application-specific data onto any database objects as an intrinsic property of all objects. So from an OO perspective, every database object has a potential hash of attribute names to string values, a std::map<std::pair<std::string, std::string>> of sorts. At present, we're claiming part of this global attribute namespace by using a handful of attribute names and having our own application tools use them and expect them to be there with various values that are valid (e.g. that material id (i.e., GIFTmater) is non-negative). From librt's perspective, though, it's just a bunch of properties with the exception of some that haven't been fully converted over to only existing as attributes. Clear as mud, I hope! Cheers! Sean On Friday, March 20, 2009, at 04:48PM, "Christopher Sean Morrison" <br...@ma...> wrote: > >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" <dan...@go...> 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 >>brl...@li... >>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 >brl...@li... >https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > |