[vtk-developers] Triangular patch interpolation

[Lin M]

Hi Dr. Thompson,

I have some questions about the test.
1. About simplicial interpolation. Should I test some simple cases (hard
coded simple shape) or some shapes like the motorcycle? If it is the latter
one, how to convert the rectangular patch to simpicial patch?

2. About point inversion. How to test it for the simpicial patch? I only
implemented the point inversion for NURBS patch

3. About derivative computation. Should I just test them numerically? For
example, given a shape and a parametric coordinate, test the result of our
implementation with ground truth.

Best,
Lin

On Sun, Aug 16, 2015 at 12:11 AM, David Thompson <david.thompson at kitware.com
> wrote:

> Hi Lin,
>
> You are correct; most of the surfaces in those models that look strange
> just need to be trimmed by their neighbors. Trimming is an operation
> closely related to isocontouring (which would be the next step); it cuts a
> patch where the distance to another patch becomes 0. Isocontouring is more
> general in that the function specifying the location of the cut does not
> need to be the distance to another curve or surface.
>
> The motorcycle would make a good image-based test of both the
> interpolation and reader classes!
>
>     David
>
> On Aug 15, 2015, at 09:51, Lin M <majcjc at gmail.com> wrote:
>
> Hi Dr. Thompson,
>
> I have found some surfaces model in brep format from
> http://www.opencascade.org/showroom/shapegallery/gal5/ and I think the
> motorcycle is correct. The reason why it looks odd in the seat area is
> because those surfaces need some bool operation which we haven't
> implemented yet.
>
> I try to load the model of suitcase, boat and F1 and all of them displayed
> correctly, I suppose. :-)
>
> P.S.
>
> Best,
> Lin
>
> On Sat, Aug 15, 2015 at 2:45 PM, Lin M <majcjc at gmail.com> wrote:
>
>> Hi Dr. Thompson,
>>
>> I finally make the vtkBrepReader work (partially, it can only load
>> surface patches). The problem is that I can not find enough data source.
>> None of the files in CGM/test contains nurbs surface and the only one with
>> Bezier surface is moto.brep. It looks like this
>> As you can see, the seats area looks strange in the rendered shape. So I
>> really need some mroe simpler nurbs shape to test my implementation. Can
>> you give some advice where I should look for? Thanks!
>>
>> Best,
>> Lin
>> ​
>>
>>
>> On Wed, Aug 12, 2015 at 11:07 PM, <majcjc at gmail.com> wrote:
>>
>>> Thank you for your suggestions!
>>>
>>> I will polish the code and make them throughly tested before merged to
>>> VTK.
>>>
>>> Best,
>>> Lin
>>>
>>>
>>>
>>> On Wed, Aug 12, 2015 at 7:48 AM -0700, "David Thompson" <
>>> david.thompson at kitware.com> wrote:
>>>
>>> Hi Lin,
>>>
>>> > I have finished the point inversion and projection algorithm for both
>>> 1-d, 2-d and 3-d NURBS.
>>> > We can turn to more dedicated algorithms now.
>>>
>>> I think that a better use of the remaining time would be to clean up and
>>> merge your work into VTK. You have made great progress and it looks really
>>> good. It would be better to polish it so it is easy to maintain and get it
>>> accepted than to push for contouring and be left with something that is not
>>> tested well enough to be maintained as VTK changes. That way you or another
>>> GSoC student can continue things next summer.
>>>
>>> It has been my experience that the only way to ensure it is maintained
>>> is to make sure it is extensively tested so that when a change to VTK is
>>> proposed, the developer making the change gets immediate feedback that the
>>> change requires work on the spline classes. So, I propose doing the
>>> following:
>>>
>>> 1. There are some style changes that need to be made. I'll push some
>>> changes off your branch to sampling/vtk, but to get started:
>>>    a. There is trailing whitespace at the ends of lines in many files
>>> which are disallowed by our pre-merge scripts.
>>>    b. Method names should be spelled out, so "Curv," "Surf," and "Volm"
>>> should become "Curve," "Surface," and "Volume." I know it is nice for names
>>> to have the same length, but it is nicer for other developers to be able to
>>> predict the names of methods across the entire toolkit. :-)
>>>
>>> 2. Testing should be more exhaustive testing to make sure that changes
>>> to VTK don't break things. Right now only interpolation is tested at all
>>> (and there is a lot of commented-out code in that test which should
>>> probably be removed). Other tests should include, for example,
>>>   a. simplicial (triangular and tetrahedral) patch interpolation (you
>>> can do this with an image-based test and/or by checking that numeric values
>>> are within a tolerance of an analytical solution,
>>>   b. point inversion for rectangular and simplicial patches
>>>   c. derivative computation
>>>   d. the NURBS adaptor should be tested with several shapes whose
>>> patches can be computed
>>>
>>> 3. Every class should have documentation that covers its purpose, its
>>> intended lifecycle (how should it be used, what methods must be called
>>> before others, etc.). The way field data is used to hold NURBS knot vectors
>>> should be documented and should have an example data file (which should be
>>> used in an image test to verify that it continues to work).
>>>
>>>         Thanks,
>>>         David
>>>
>>> > On Sun, Aug 9, 2015 at 2:47 PM, Lin M <majcjc at gmail.com> wrote:
>>> > Hi Dr. Thompson,
>>> >
>>> > I have pushed new methods to compute point inversion and projection to
>>> gitlab.
>>> > It took longer time than I expected. It would be really helpful if you
>>> could review the code a little bit. Thanks!
>>> >
>>> > Best,
>>> > Lin
>>> >
>>> > On Mon, Aug 3, 2015 at 10:50 AM, David Thompson <
>>> david.thompson at kitware.com> wrote:
>>> > Hi Lin,
>>> >
>>> > Yes, that is correct. Inserting knot values does not change the
>>> polynomial degree or shape, it just adds control points so that the weights
>>> are uniform (as required by the Bézier basis). So, the underlying
>>> parameterization is unchanged... it just has more piecewise segments.
>>> >
>>> >     David
>>> >
>>> >
>>> >
>>> > On Aug 2, 2015, at 22:38, Lin M <majcjc at gmail.com> wrote:
>>> >
>>> >> Hi Dr. Thompson,
>>> >>
>>> >> I have a question about the inversion and projection. Currently, we
>>> evaluate the NURBS by inserting knots and making it into Bezier forms. My
>>> question is that if I evaluate u = 0.2 in original knot vector [0,1,2,3],
>>> would it be the same to evaluate u = 0.2 in the new knot vector which is a
>>> bezier form?
>>> >>
>>> >> Best,
>>> >> Lin
>>> >>
>>> >> On Mon, Jul 27, 2015 at 1:26 AM, Lin M <majcjc at gmail.com> wrote:
>>> >> Hi Dr. Thompson,
>>> >>
>>> >> I have added new method
>>> vtkPatachInterpolation::InterpolateOnSimplicialPatch() and pushed to gitlab.
>>> >>
>>> >> I'm now working on the point inversion part.
>>> >>
>>> >> Best,
>>> >> Lin
>>> >>
>>> >> On Sun, Jul 26, 2015 at 8:05 PM, David Thompson <
>>> david.thompson at kitware.com> wrote:
>>> >> Hi Lin,
>>> >>
>>> >> How is triangular/tetrahedral patch interpolation going? They will be
>>> a basic building block of the contouring and cutting algorithms. By
>>> identifying points on edges, edges on surfaces, and surfaces in volumes
>>> that take on a single value, a single patch can be decomposed into sections
>>> that are inside, outside, or on an isosurface. Not all of these pieces can
>>> be expressed as brick patches, but they can be expressed as simplicial
>>> patches.
>>> >>
>>> >>     David
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150817/854b9582/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.PNG
Type: image/png
Size: 357636 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150817/854b9582/attachment-0001.png>