Hi,
> I see in your progress report that the initial attempt at reduction
> produced a surface with some significant deviations?
My idea is to use a variable TOL (as a tolerance threshold) to control the
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.
You mean fitting the top surface with the original DSP data? Probably a good
idea. BTW, NURBS fitting is definitely useful in the conversion of metaball.
It's really an important feature, I think.
> 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.
Can a single plane (ON_Plane) be added to an ON_Brep object directly? The
elements in it are at least surfaces, faces and so on. But if I create a single
surface, it needs a boundary, while in half the surface should be infinite. But
just adding a line of code creating an ON_Plane and then comment it out is OK.
Sean used to tell me that we should just ignore the conversion and leave the
implicit object in the hierachy.
> 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.
Agreed. As is shown in the wiki page (
http://brlcad.org/wiki/BRL-CAD_Primitives#hf ), hf is deprecated, use dsp
instead. So if we need to deal with hf, convert it to dsp at first should be
the right routine.
> 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.
I havn't looked into pnts yet, as Sean told me that it should be treated like
half (ignored and implicit form remained). I will explore this primitive in
some time.
> 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.
This is really something interesting to work on! I'd like to start it in a few
days.
Cheers!
Wu
------------------------------------------------------------------------------
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
