On Jul 7, 2012, at 12:57 PM, Clifford Yapp wrote: > hf is a deprecated primitive - I'd suggest the best way to deal with > it is to implement (if it doesn't exist already, not sure) a routine > to take a hf primitive and convert it to a dsp, then have hf_brep.cpp > call that routine and pass the dsp along (much like cline). Sean > would know better than I if dsp has enough expressive power to handle > the hf geometry, but my initial thought is that it does.
It does, but I'd suggest just returning NULL or nothing. Our dbupgrade command will convert hf primitives to dsp already (via rt_hf_to_dsp()), so it's not worth even five minutes attention. > pnts is a tricky one. Nominally, they aren't really solid in and of > themselves (a bit like sketch in that regard.) From a point cloud, > you can do several things - the "best" one is probably to fit one or > more NURBS surfaces around the cloud to define a volume, but that's > also quite difficult - there are a fair number of papers dealing with > it. Our pnts support still needs a lot of work even without NURBS > conversion, so personally I wouldn't rate this as a high importance > problem. They are solid if they have a size set (pnts can have color, be oriented (have normal), and have size). In that case, they are considered spheres and could go through the existing ell-to-brep routine. The only tricky part would be combining spheres that overlap. For that, it's probably be easiest to union them all and then let surface-surface intersections figure out and trim the interior portions. You could convert a pnt set to brep spheres and then try to implement a librt function that calculates the surface-surface intersections. Might be a good relatively stable first step towards a generalized surface-surface intersection function. I think asserting or assuming a point cloud represents some solid volume would be wrong at that API level. That's certainly one common high-level use case (among many) for point clouds but certainly not the only one. I wouldn't think it appropriate at this low primitive definition level. For surface wrapping or merging/healing, that would make more sense for a higher-level librt function or even a libged-level command that leveraged PCL or implemented the bits needed. A "pnt" object has a very succinct and specific definition. Converting to brep/nurbs should adhere to that definition -- which does not involve any sort of implicit assumption that the point set represents anything other than a set of 3D points that may or may not have volume. If they have volume (i.e., scale is set), then conversion to brep makes sense (but then also begs for surface-surface intersections). > openNURBS gives us an > informational text dump of the contents of objects, but it's not clear > that's the preferred asc representation for importing and exporting a > brep. It's most certainly not... the asc format is intentionally a (tcl) *command* transcript so it would entail encoding the brep in some form similar to sketches, nmg, or bots. The rt_*_describe() callback already uses the openNURBS textual description. What is needed are the rt_*_get() and rt_*_adjust() callbacks. Definitely a good task too. Cheers! Sean ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
