<div dir="ltr">I didn't separate the homogenous coordinate with point coordinates but stored them all in a vtkDataArray with 4 components per tuple just as you suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. The current API is like<div><br></div><div>void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum)<br></div><div>the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold information and data of nurbs control points,</div><div>and the vtkSturcturedGrid only holds knot vectors and length.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 12:59 PM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I forgot one thing, the vtkPoints can not hold a 4-dimension vtkDataArray so I cannot store the control points in the vtkStructuredGrid. Currently I stored it separately in a vtkDataArray for test. Do I need to implement a vtkPoints subclass likt vtkControlPoints to allow it store 4-dimension coordinates?<br>
<br>
</span>Hi Lin,<br>
<br>
I would not create a new class. There are two alternatives and different spline software packages use them both:<br>
<br>
+ Do as you have done, keeping point coordinates separate from the homogenous coordinate. This approach increases the number of things that have to get passed around between functions.<br>
<br>
+ Pass the points around as just a vtkDataArray with 4 components per tuple. This approach makes it hard to use just the first three coordinates as points when you know the homogeneous coordinate is 1 for all of the values you are dealing with.<br>
<br>
My mild preference is the latter (i.e., make the arguments to your functions take a vtkDataArray with 4 components per tuple), but either will be fine.<br>
<br>
I want to avoid writing a 4-D point subclass because then algorithms that generate patches as output will need a new dataset type and it will be hard to use existing filters (such as the vtkArrayCalculator) on them.<br>
<span class="HOEnZb"><font color="#888888"><br>
        David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> On Tue, Jun 30, 2015 at 12:42 PM, David Thompson <<a href="mailto:david.thompson@kitware.com">david.thompson@kitware.com</a>> wrote:<br>
> Hi Lin,<br>
><br>
> > I have finished the conversion from NURBS patch to Bezier patch and generation of surface meshes.<br>
> ><br>
> > Now we can load some real nurbs shapes to test. :-)<br>
><br>
> Great! I'm working on 2 sources of data.<br>
><br>
> + [CGM](<a href="https://bitbucket.org/fathomteam/cgm" rel="noreferrer" target="_blank">https://bitbucket.org/fathomteam/cgm</a>) provides a nice interface to OpenCascade's surface definitions, including these methods:<br>
><br>
> <a href="https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Surface.hpp?at=master#cl-370" rel="noreferrer" target="_blank">https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Surface.hpp?at=master#cl-370</a><br>
> <a href="https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Curve.hpp?at=master#cl-364" rel="noreferrer" target="_blank">https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Curve.hpp?at=master#cl-364</a><br>
><br>
> CGM has a few CAD models for testing in the "test" directory of the source repo.<br>
><br>
> + [PetIGA](<a href="https://bitbucket.org/dalcinl/petiga" rel="noreferrer" target="_blank">https://bitbucket.org/dalcinl/petiga</a>) has 3D NURBS including simulation results but is in a binary file format that is undocumented (except in the source).<br>
><br>
>         David<br>
><br>
<br>
</div></div></blockquote></div><br></div>