On Wed, May 1, 2013 at 7:21 AM, phoenix <284281...@qq.com> wrote:
> > Yes, that's probably the way to go. That will probably require some
> header changes and (if I recall correctly) changes to opennurbs_basic.cpp -
> there may also be functions that are worth moving over that do some basic
> work using those types.
>
> Since there are already some incomplete functions in openNURBS like those
> in opennurbs_basic.cpp, so should we keep them and ask the user to call
> functions in libbrep explicitly, or remove them and make them extern
> functions which have implementations in libbrep? In the latter case, the
> names must remain ON_*. (Actually, something like surface trees, curve
> trees, get close point, intersections already have an implementation in
> libbrep, but the related openNURBS functions still just have a simple
> return statement.)
>
As Sean mentioned, we haven't finalized a plan on how to handle the
situation. My suggestion would be to do whatever looks like the most
straightforward thing (I'm guessing that's probably having libbrep provide
the missing pieces for openNURBS and keep the ON_ prefix, at least for now)
and stay focused on the intersection problem. I can take a look at it
after the release and see if something jumps out as a way to restructure
things, but in the meantime don't let it slow you down - we can always
rename and move functionality later.
> > The most "correct" way would probably be to use the sketch primitive,
> but that will have the drawback of not showing up in raytraced images as 3D
> geometry. For BRL-CAD in its current form the pipe is actually a decent
> solution, as long as it's not introducing too much complexity into your
> code.
>
> It seems that the sketch primitive can only represent planar curves (2D
> curves), but the intersection curves to display is in 3D form. Maybe it can
> be a good candidate to represent the 2D parametric intersection curves, and
> the pipe primitive is used for the 3D curves.
>
That should work fine. As long as you can see what you need to see! The
pipe diameter might even be useful to indicate bounding box sizes at
points, although I suspect that will result in problematically thin pipe
diameters.
Cheers,
CY
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
