Re: [brlcad-devel] Tessellation of NURBS surface

[Clifford Y. <cli...@gm...>]

On Tue, Jun 28, 2016 at 11:19 PM, Bojian Wu <ust...@gm...> wrote:
> Hi everyone,
>
>     Because I have already drafted a rough implementation of plate mode
> NURBS ray tracing, and it works well for me now, I also put all the tests on
> my blog, please check it, if you have any issues, please let me know and I
> will make proper refinement, it will be much grateful. :-)

So the first test of accuracy to make on a plate mode nurbs raytrace
is to take the portion of the sphere that you are raytracing plate
mode, calculate mathematically what the volume should be for a "slice"
of a spherical shell with your assigned thickness, and use a tool such
as gqa to verify that the volume defined by the solid according to
raytracing is a close match for the the mathematically expected
volume.

>     So, recently, I want to shift my attention to the tessellation of NURBS,
> it is much more challenging. Because after my research, I find that there
> are several related methods that can be used for the purpose. There also
> exists an old implementation in BRL-CAD(nurb_tess.c), it is a kind of
> mapping from triangulation of 2D parameter space to 3D surface space within
> given approximation errors bound(I have summerized this method on my
> blog.:-) ), it is a simple and effective method.

Before you do, make sure you and your mentor agree that the plate mode
NURBS work is actually done.  That said, there is indeed quite a lot
of useful work that can be done with our tessellation routines.

There is actually quite a bit more work that has been done with NURBS
tessellation - our "modern" tessellation code for NURBS uses the
poly2tri code for generating triangles (see src/other/poly2tri and the
places in librt where that library is used.)  The most significant
lack for our current poly2tri tessellation is the inability to
generate "watertight" tessellations - each surface is separately
tessellated, but those tessellations are not properly joined at the
edges to form closed solids.  We would also like to explore the work
done by the bitfighter devs to use clipper's logic as a "clean-up"
pre-processing step before generating triangles with poly2tri:
https://github.com/raptor/clip2tri - this has the possibility to
increase the robustness of our tessellations.

A "warm-up" to those more difficult tasks might be to translate the
poly2tri logic from its current src/other code into our data
structures and data types in libbg.

Cheers,
CY