On Jul 7, 2012, at 1:49 PM, phoenix wrote: > > 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.
I'd love to know what Rhino exports if the only entity in your scene is an infinite plane (if they even allow that construct). I'd be surprised if the pack it into an ON_Brep, though, as that should make the ON_Brep->isValid() fail. Until someone tests to see what Rhino actually does, I'd still skip halfspaces like you're doing. When someone starts working on a surface-surface intersection function, they can make it deal with ON_Brep and halfspace planes then without introducing the notion of infinite/non-solid/invalid ON_Brep objects.. That said, given the pnts discussion, that might be something you're interested in tackling too. ;-) > 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. Zero-scale pnts should be treated like half as they have no volume. pnts with size are another matter, but beg for surface-surface booleans so you can union them all together if they overlap. > > 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. If surface-surface intersections is at all interesting and you think you might be able to tackle it, that would be considerably more valuable. Just about anyone could implement the get()/adjust() callbacks as that's just printing values to strings and reading them back. Both useful, but calculating surface-surface intersections for combining two ON_Brep objects into one is the (hard) hot-topic of the year. :) 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
