Re: [brlcad-devel] Enthusiastic about working with BRL-CAD in GSoC2013

[p. <284...@qq...>]

Hi, 


> When it comes to the trimming curve, both in 2D and 3D, I have a question - does the current approach being considered leave the intersection curves as high resolution polylines, or is the attempt made to fit the polyline with a parametric curve?  My concern with keeping curves as polylines is that for many intersections, it may be possible to fit a low order NURBS curve to the polyline with high accuracy (i.e., expressing the non-degenerate intersection between two spheres as a circular NURBS curve or even an ON_Circle, rather than accumulating large numbers of high-point-count polylines.)  For CSG cases in particular I would think there could be a relatively high instance of cases where the polyline points could be fitted with high accuracy by a parametric curve, perhaps recognizing points satisfy a simple curve description with high accuracy by applying fitting tests for linear, circular, etc. cases?


The current approach just leaves the intersection curves as polylines, which is designed to work for all cases. But decreasing the order of the intersection curves is a good suggestion - it can increase the performance (both speed and accuracy). Actually, only 2D intersection curves are of interest, which are used in the follow steps of NURBS evaluation, so the intersection of two spheres (the case you give above) can be even a single line in the 2D space. So I think linear fitting in the 2D space is necessary in the project (which is also a much simpler fitting test). After we fit the 2D curves into low order ones, the 3D curves can be simplified as well.
 

> When it comes to assembling breps, there is code in src/librt/test_bot2nurbs.cpp that may help illustrate how the structures can be built up.  That code isn't working yet (there are problems with fitting curves to the points, plus some boundary condition issues) but the brep structural assembly itself (curves/edges/surfaces/faces/etc.) may be helpful.


Thanks for giving such a hint. I struggled a lot when I tried to build the breps last time, and that code can be a good reference. :)


> One point to note is that joined edges of two surfaces should both reference the same 3D curve - they each describe that edge in their own parametric domain with their own 2D curve, but they (by definition) are describing the same curve in 3-space.  (That might actually be something to double check in our CSG implicit conversions, to make sure we are doing it right - maybe a good "warm up" and possible patch.)


I haven't recognize this issues yet - I used to duplicate the 3D curves in such cases. As you say, there should be two ON_BrepEdge objects, and they have the same m_c3i (so they reference the same 3D curve). You mean the CSG implicit primitive -> brep primitive conversions? It may be a good suggestion to check these conversions to make sure the generated breps have such properties.


> You may also find that the idea of converting trimmed surfaces to untrimmed proves necessary or useful as you intersect ever more complex shapes - if so Sean spotted some functionality in the older openNURBS codes (opennurbs_brep_v2valid.cpp in opennurbs 20110202 or earlier - see the svn history) that may be helpful - we can always foward-port that code into libbrep it it proves useful.
 

Converting trimmed surfaces to untrimmed ones - to simplify the representations and improve performance? I have a glance at the removed code in the svn history, it seems that it's going to deform the breps so that it can be represented as v2 3DM achieves (I'm not familiar with v2). After all, I will go to that code to get some help if I need to do that conversion.


Cheers!
Wu