Resending as plain text for Bojain. If I reply from a web-based e-mail client, it unfortunately sends replies html-encoded and there’s no way to change it. Curious that you can’t read it, though. What e-mail client are you using?
Cheers! Sean > Begin forwarded message: > > From: Christopher Sean Morrison <[email protected]> > Subject: [brlcad-devel] Re: Designing data structure for B-rep primitives > Date: May 24, 2016 at 4:44:19 PM EDT > To: BRL-CAD Developer Mailing List <[email protected]> > Reply-To: BRL-CAD Developer Mailing List <[email protected]> > > On May 24, 2016, at 12:21 PM, Bojian Wu <[email protected]> wrote: > >> Hi all, I want to seek some suggestions for designing the basic data >> structure for B-rep primitives. > > Great! > >> If we want to integrate 'plate mode' into NURBS, the first step is about how >> to store these data, like thickness value array etc implemented in BoT >> primitives, into the internal NURBS data structure. Presently, the already >> defined data structure is *rt_brep_internal* (about line 298 in geom.h), >> which includes a magic number and brep pointer defined with openNURBS >> built-in class. > > Does the openNURBS API provide any means for attaching additional > metadata/attributes/properties to either ON_Brep or individual surfaces? It > could be useful to store the actual thicknesses with the geometry. > >> Similar to BoT (*rt_bot_internal*), I want to add some extra information >> like BoT mode(unsigned char mode), thickness value array(fastf_t >> *thickness), face mode flag(struct bu_bitv *face_mode) into >> *rt_brep_internal* as follows: >> >> /* modes for brep */ >> #define RT_BREP_SURFACE 1 >> #define RT_BREP_SOLID 2 >> #define RT_BREP_PLATE 3 >> #define RT_BREP_PLATE_NOCOS 4 >> >> /* flags for bot_flags: reusing similar definitions for BoT */ >> >> /* ID_BREP */ >> struct rt_brep_internal >> { >> uint32_t magic; >> >> ////////////////////////////////////////////////// >> /* additional information I want to add here! */ >> unsigned char mode; >> unsigned char bot_flags; >> fastf_t *thickness; >> struct bu_bitv *face_mode; >> ////////////////////////////////////////////////// >> >> ON_Brep *brep; >> }; > > I think we have several lessons learned from the BoT implementation and don't > need to repeat them here. > Other than 'bot_flags' (not a bot), thickness looks fine iff openNURBS > doesn't have a way to store the thickness data. > > I don't think face_mode is needed at all any more (probably not for BoT > either...), but could be wrong -- still suggest starting without it. > > Thickness probably tells us everything we need to know about the mode > (NULL==SOLID, 0==SURFACE, >0==PLATE). If we need to add NOCOS behavior later > (doubtful), that could be an application-specific attribute. > > It also would be good to have a way to store a default/global thickness > applied to all surfaces and stored as a single value, along with the > capability of having per-surface thickness as needed. Whether this is > encapsulated with one field where [0] is all surfaces and [N] is thickness > for 1-indexed surfaces, or as two separate fields (default all + per surface > array) probably doesn't matter much. > >> Besides, another data structure related to BoT is *bot_specific*(about line >> 57 in bot.h), similarly, there is a *brep_specific* (about line 32 in >> brep_local.h), what I think is to map all the extra information defined in >> the *rt_brep_internal* directly into this category specific data structure. >> Is this acceptable? > > The _internal form is how it's read from disk. The _specific form is usually > what you actually work with during raytracing. Care must be taken to make > sure you don't fully duplicate the geometry when you do that -- I think BoT > does it wrong (using 2x memory). > > Good start to the project! > > Cheers, > Sean ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
