[Bf-python] curve module and surfaces

[Stephen Swaney]

Fernando Serboncini wrote:
> 
> I was trying to use the curve module and I've realized that the
> getNumPoints and getControlPoints functions were returning the wrong
> number of points. They were returning only the first row of points. This
> was without notice with NURBS curves, but makse NURBS surfaces wrong.

Perhaps I misunderstand when you say 'the first row of points'.
Both getNumPoints and getControlPoints have an int argument
to specify particular curve.

Just to make sure we are all on the same page, a Blender Curve
can consist of multiple curves.  Each curve, whether of type
nurb or bezier is made of multiple points.  Personally, I 
would prefer to refer to the individual nurb or bezier entities
as splines to avoid having to say "A Curve is made up of curves",
but this has met with some resistance.

( as an aside, I notice getNumPoints does not appear in the doc.
I think this is because it escaped into CVS long ago accidentally.
I will fix this. )
 
> I don't know if this is an "already-discussed" topic, but since it's my
> first time here, here it goes: Is the curve module suposed to support
> NURBS surfaces, or only curves? My opinion is that it should support
> both since I couldn't find any clear distinction between a NURBS curves
> and surface on the code, except for the fact that NURBS curves control
> points are co-planars.

Actually, it has been discussed a couple of times before.  The
conclusion is that Curves and Surfaces should be separate.
A summary of the discussion is this:

It is true that:
1) a curve may be treated mathematically as a 1D surface.
2) blender uses the same Nurb struct internally for both.

However:
1) The blender interface and data types make a clear
   distinction between Curves and Surfaces.
2) SurfaceCurves can be skinned.  CurveCurves can not.
3) the editing panel (F9) displays different properties for each.
4) If we present the same api for Curves and Surfaces it allows
   the programmer to make changes that will not appear or be
   inconsistent in blender.

Our goal with the bpy api was to provide a programmatic interface
to blender functionality.  Since blender makes a distinction between
Curves and Surfaces, we should also.

A future blender3 is a different case and I would be quite
prepared to argue there that Curves and Surfaces should be
unified.  But that is Then and not Now.

Undeniably, there will be reuse and code sharing internally
between bpy Curves and Surfaces.  I can already see it in the 
Nurb module I created to add iterators for Curves.  But this 
does not mean the external interface should be the same.
 
> Looking into the code, it seems that those function are using only the
> pntsu field of the Nurb struct. I think the correct is to use
> pntsu*pntsv. This allows buth surfaces and curves to work with this
> module.

No, Curves and Surfaces will each have a separate module.
 
> Here's the patch that fixed those two functions.
> I've tested and got the correct results.

> +  /* check numpoint param against pntsu*pntsv */
> +  if (numpoint >= ptrnurb->pntsu * ptrnurb->pntsv)
>      return (EXPP_ReturnPyObjError (PyExc_AttributeError,

This does not work.  ptrnurb->pntsv can be zero for certain
Curve splines. 

> +  /* pntsu*pntsv is the number of points in curve */
> +  ret_val = PyInt_FromLong ((long) (ptrnurb->pntsu * ptrnurb->pntsv));

Same problem here.

This may have passed your test cases but I am looking at
an example in the debugger of a single Curve with two 
curves: a bezier and a nurb.
In one case, pntsv is 1, in the other it is 0.

This patch should not be committed.

-- 
Stephen Swaney			
sswaney at swbell.net