>> So, what about this approach (the link above)? I think it's probably the >> most direct way of degree reduction on Bezier surfaces.
Wu, I see in your progress report that the initial attempt at reduction produced a surface with some significant deviations? My eventual idea for dsp surface fitting (assuming the approaches already suggested didn't work out) was to use the point-distance-minimization code from Thomas Moerwald (http://www.pointclouds.org/blog/trcs/moerwald/index.php) to fit the top dsp surface. That code is in place in librt (in opennurbs_fit.cpp and opennurbs_fit.h) but it's not currently activated since there is more work to do before it is usable. I'm currently working that problem as part of another task, so it's OK to leave dsp where it is for now if none of the other prospects look promising. Looking over the original list of primitives, a couple of suggestions come to mind for things to work on next: For half, it might be a good idea to add the logic to return a brep with a single plane depicting the half plane even if it is commented out for now. That seems to me to be the most correct NURBS representation of a halfspace, and if our raytracer isn't up to dealing with it we'll need to think about that on the raytracing end. 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. metaball we've already discussed - that's also probably going to require what I'm working on now, so it's not something to worry about. 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. It's not an implicit to nurbs conversion issue as such, but one of the things we are missing for the brep primitive is an ascii text representation that we can export and import. If you look at the tools asc2g and g2asc, you will see that most primitives can be represented by ascii text strings. 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. So the task would involve a) figuring out how to represent breps in a format appropriate for our asc files and b) implementing the routines to import and export such a description as part of the asc2g and g2asc process. Cheers, CY ------------------------------------------------------------------------------ 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
