<div dir="ltr">Hi Dr. Thompson,<div><br></div><div>I have added one commit which contains a vtkMappedDataArray subclass but I'm not sure I totally get the idea about the in-situ data structures. Can you take a look at it please? (<a href="https://gitlab.kitware.com/splines/vtk/merge_requests/4">https://gitlab.kitware.com/splines/vtk/merge_requests/4</a>)</div><div><br></div><div>Best,</div><div>Lin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 10:47 AM, 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">Hi Lin,<br>
<span class=""><br>
> From some examples I saw, usually we put some points in vtkPoints, store the connectivity in cellArray and add them to a dataset (vtkPolyData, vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control point of multiple patches in the vtkPoints where we replace the vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we store all the points for all patches together but we overwrite how to iterate the array.<br>
<br>
</span>That is nearly correct. We will accept<br>
<br>
    vtkDataObject* ControlPointData;<br>
<br>
from the user. For the case we will implement first, ControlPointData's actual type will be the vtkStructuredGrid subclass of vtkDataObject. The vtkStructuredGrid instance can hold many user-supplied vtkDataArray instances:<br>
<br>
    vtkStructuredGrid* structuredControlPoints =<br>
      vtkStructuredGrid::SafeDownCast(ControlPointData);<br>
<br>
    // Control points to map from parameter-space to world coordinates:<br>
    vtkDataArray* geometricControlPoints =<br>
      structuredControlPoints->GetPoints()->GetData();<br>
<br>
    // Control points to map from paramter-space to scalar fields:<br>
    vtkDataSetAttributes* scalarFields = structuredControlPoints->GetPointData();<br>
    vtkIdType numScalarFields = scalarFields->GetNumberOfArrays();<br>
    for (vtkIdType i = 0; i < numScalarFields; ++i)<br>
      { // scalarFieldControlPoints will hold things like temperature, pressure, etc.:<br>
      vtkDataArray* scalarFieldControlPoints = scalarFields->GetArray(i);<br>
      }<br>
<br>
Because the user supplies these arrays, we cannot force them to be vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that owns a reference to one of the arrays above and only returns one patch's values from the user-supplied array (which holds the values for all patches in the spline).<br>
<br>
The BezierPatchAdaptor below would return instances of our vtkMappedDataArray when its GetPatchPoints method is called. Now that I've written some more out, it looks like the API should be changed a little bit so that users can ask for a particular array (geometricControlPoints or scalarFieldControlPoints):<br>
<span class=""><br>
class vtkBezierPatchAdaptor : public vtkObject<br>
{<br>
public:<br>
  virtual void SetControlPointData(vtkDataObject* controlPointData);<br>
  vtkGetObjectMacro(vtkDataObject,ControlPointData);<br>
<br>
  // Methods to iterate over patches:<br>
</span>  // ... same as below ...<br>
<span class=""><br>
  // Methods to access the current patch:<br>
</span>  // ...<br>
  virtual vtkSmartPointer<vtkMappedArray> GetPatchPoints(int scalarField) const = 0;<br>
  // ...<br>
};<br>
<br>
This way, GetPatchPoints() could return the vtkMappedDataArray for geometricControlPoints when the "int scalarField" argument is negative value and a vtkMappedDataArray for one of the scalarFieldControlPoints arrays when scalarField is positive.<br>
<br>
Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray subclass would also get around the issue that vtkPoints expects its vtkDataArray to have 3 components per tuple (where ours will have 4 for geometricControlPoints or an arbitrary number for scalarFieldControlPoints).<br>
<br>
The vtkMappedDataArray instances would own a weak reference back the vtkBezierPatchAdaptor which created them and a weak reference to the geometricControlPoints or scalarFieldControlPoints array it draws values from. When vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate over all of the vtkMappedDataArray instances it owns and change an internal variable so they would return values for the proper patch. That way the vtkMappedDataArray instances only have to be created once for each spline dataset, not once per patch.<br>
<br>
Is that clear enough, or should I sketch out a header file for our vtkMappedDataArray subclass?<br>
<span class="HOEnZb"><font color="#888888"><br>
        David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Wed, Jun 17, 2015 at 10:22 PM, David Thompson <<a href="mailto:david.thompson@kitware.com">david.thompson@kitware.com</a>> wrote:<br>
> Hi Lin,<br>
><br>
>> Sorry for late reply. Since the midterm is coming, I'll definitely speed up the development from now on.<br>
><br>
> We both need to do a little more work. I have been looking at how to read data from PetIGA so we can show some actual simulation data and have some 3-D volumetric examples.<br>
><br>
> It would be nice to have a patch ready to merge into VTK's master branch at the midterm that provides spline interpolation and tests it for all 3 parametric dimensions (curves, surfaces, and volumes). The means producing triangles and tetrahedra, not just polylines.<br>
><br>
>> I have a question about the class design in your last email. To my understanding, control points for one patch is stored in a vtkDataArray.<br>
><br>
> Close. I think that we should use the vtkMappedDataArray class to hold control points for multiple patches but program it to appear as if points for each individual patch are stored in patch-order.<br>
><br>
>> Do you mean store multiple vtkDataArray regarding to multiple patches in the vtkDataObject?<br>
><br>
> There would be one data array to hold point coordinates, but other arrays would hold simulation variables like temperature, pressure, velocity, and so on.<br>
><br>
>> If so, what class do I need to use for vtkDataObject?<br>
><br>
> The class outline below is an abstract class. A concrete implementation for NURBs would require   the base class's ControlPointData to be an instance of vtkStructuredGrid. A T-spline implementation might expect ControlPointData to be a vtkUnstructuredGrid. I think all we should do this summer is the NURBs case.<br>
><br>
>     David<br>
><br>
>><br>
>> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson <<a href="mailto:david.thompson@kitware.com">david.thompson@kitware.com</a>> wrote:<br>
>> Hi Lin,<br>
>><br>
>> > I have made it support 3D ellipse with function ...<br>
>><br>
>> Great!<br>
>><br>
>> > As you can see in the python test, I call this function 4 times for each quadrant to generate the entire ellipse. Since we need to support multiple patches, I think it's better to define a new dataset class for bezier patches as you mentioned before about  creating a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate.<br>
>><br>
>> Rather than create new dataset types, I would like to use existing datatypes to store the data and make an adaptor to iterate over them. That way existing pipelines could modify scalar values defined on control points (and perhaps even patches). For instance, B-splines could be represented as a vtkStructuredGrid whose FieldData contains a special knot array (special in the sense that the array must be of the proper size and with a fixed name like "_vtkKnotVector").<br>
>><br>
>> The adaptor would take a vtkDataObject as input and provide iterator-style access to each patch defined by the dataset. Specific subclasses of the adaptor would be B-splines (which expect the vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a vtkUniformGridAMR) or even point-based splines (PB-splines as defined in Sederberg's T-spline paper, which could expect any dataset derived vtkPointSet).<br>
>><br>
>> class vtkBezierPatchAdaptor : public vtkObject<br>
>> {<br>
>> public:<br>
>>   virtual void SetControlPointData(vtkDataObject* controlPointData);<br>
>>   vtkGetObjectMacro(vtkDataObject,ControlPointData);<br>
>><br>
>>   // Methods to iterate over patches:<br>
>>   virtual void Begin() = 0;<br>
>>   virtual bool IsAtEnd() = 0;<br>
>>   virtual bool GoToPatch(vtkIdType patchId) = 0; // random access iteration<br>
>>   virtual bool Next() = 0;<br>
>><br>
>>   // Methods to access the current patch:<br>
>>   virtual int GetPatchDimension() const = 0;<br>
>>   virtual void GetPatchShape() const = 0;<br>
>>     // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2,<br>
>>     // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3<br>
>>   virtual void GetPatchDegree(int* degreeOut) const = 0;<br>
>>   virtual void GetPatchParameterRange(double* paramsOut) const = 0;<br>
>>   virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0;<br>
>><br>
>>   // Some helper methods that would make Python wrappings usable:<br>
>>   int GetPatchDegree(int dim) const<br>
>>     {<br>
>>     std::vector<int> degree(this->GetPatchDimension());<br>
>>     this->GetPatchDegree(&degree[0]);<br>
>>     return degree[dim];<br>
>>     }<br>
>>   void GetPatchParameterRange(int dim, double paramRange[2])<br>
>>     {<br>
>>     std::vector<double> range(2 * this->GetPatchDimension());<br>
>>     this->GetPatchDegree(&range[0]);<br>
>>     paramRange[0] = [2 * dim];<br>
>>     paramRange[1] = [2 * dim + 1];<br>
>>     }<br>
>><br>
>> protected:<br>
>>   vtkDataObject* ControlPointData;<br>
>> };<br>
>><br>
>> The B-spline subclass could then iterate over patches by keeping a current "cell ID," which would be incremented by calling Next(). When asked for the *patch* points (not the input points), the adaptor would create a vtkMappedDataArray (see <a href="http://www.vtk.org/Wiki/VTK/InSituDataStructure" rel="noreferrer" target="_blank">http://www.vtk.org/Wiki/VTK/InSituDataStructure</a> for more information) that did not copy control point coordinates from its ControlPointData->GetPoints() but instead used the implicit connectivity to provide access to underlying B-spline points.<br>
>><br>
>> For example, consider the simple case of a rectangular B-spline with degree 1 (bi-linear). We might be given a 5x6 grid of control points as input and asked to iterate over all the patches. Each patch is simply a quadrilateral, and there are (5-1)*(6-1) = 20 of them.<br>
>><br>
>>   adaptor->Begin(); // would initialize an internal "cell ID" to 0<br>
>>   adaptor->IsAtEnd(); // would return false for "cell ID" values in [0,19] and true otherwise.<br>
>>   adaptor->GetPatchDimension(); // would return 2<br>
>>   adaptor->GetPatchShape(); // would return VTK_QUAD<br>
>>   adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with [1,1]<br>
>>   adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with a vtkMappedDataArray.<br>
>><br>
>> The vtkMappedDataArray would report having 4 tuples (one for each corner of the quad... when the degree is higher, is would report the product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual points reported would depend on the "cell ID" in the adaptor.<br>
>><br>
>> I have not figured out yet how the "w" homogeneous coordinate would work with vtkPoints. A different adaptor API might work better (keeping the "w" coordinate separate from the other points).<br>
>><br>
>> > Another question is that currently the domain of parameter coordinate is [0, 1] for each patch. Do you think it's better to make the domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the second quadrant, etc?<br>
>><br>
>> If we focus on the B-spline adaptor above, we get that for free since the returned knot vector could be normalized to the range [0,1].<br>
>><br>
>>         David<br>
>><br>
><br>
<br>
</div></div></blockquote></div><br></div>