addNurbsSurface possible bug?

Scripting
1

Hi there,
been trying to create creased surfaces with addNurbsSurface, in theory a 1 degree parametrization in one direction should create a single surface with a crease. That’s at least how it works in manual modeling. However passing all the required arguments to addNurbsSurface will only create a polysurface instead of a single creased surface. Am I doing something wrong, or is it a bug ? I am building up a lot of geometry and I need single surfaces instead of polys. It is very easy to replicate with code from the help file or build your own.

srftest.3dm (63.9 KB)

import rhinoscriptsyntax as rs
obj = rs.GetObject("Pick a surface", rs.filter.surface)

if obj:
    point_count = rs.SurfacePointCount(obj)
    print point_count
    points = rs.SurfacePoints(obj)
    print points
    knots = rs.SurfaceKnots(obj)
    print  knots
    degree = rs.SurfaceDegree(obj)
    print degree
    if rs.IsSurfaceRational(obj):
        weights = rs.SurfaceWeights(obj)
        print weights
        obj = rs.AddNurbsSurface(point_count, points, knots[0], knots[1], degree, weights)
    else:
        obj = rs.AddNurbsSurface(point_count, points, knots[0], knots[1], degree )
    if obj: rs.SelectObject(obj)

Any idea what is going on ? Why is it creating polys instead of a single surface ?

Need to add a bit more info. The example surface to run the example script on, was created using the rebuild surface command on a curved surface, giving it (3,4) control points and (1,3) degree - resulting in a single surface.

If I try to manually create a nurbs surface with the same parametrization as above, using SrfPtGrid, Rhino will again output a Polysurface instead of a single surface with a kink. I presume it is related to a knot vector issue.

Any help appreciated.
Cheers,
Florin

2

I think if you first set CreaseSplitting=No in Rhino before running the script, it will do what you want. You could even call that command in the script I guess… don’t forget to set it back afterwards though, otherwise you will have all of your objects coming out that way (not a really good idea).

HTH, --Mitch

3

Wow, thanks for catching that Mitch ! So clearly not a bug, however, it would be nice to be able to control this with vb/py methods instead of calling a Rhino command. The split option should be inside the addNurbsSurface method.
Thanks for the help.

4

I agree there should be some way to address this directly in a script, perhaps a general rhinoscriptsyntax method rs.EnableCreaseSplitting(bool) which would return the current state and allow toggling it. @dale ?

–Mitch

5

Hi @isvflorin, @Helvetosaur,

The default behavior of Rhino is to split kinky surfaces when they are added to the document. Most users don’t want to deal with kinky surfaces.

If you want to override this behavior, you’ll need to write a Python script that calls this version of ObjectTable.AddBrep and pass a False value for the splitKinkySurfaces parameter.

Does this help?

– Dale

6

@dale , thanks for stepping in. I’m writing something that will be packaged for distribution, with the script compiler. The final script will create a lot of geometry, possibly hundreds of thousands of objects, maybe millions.

So what I understand is that I can write my own version of addNurbsSurface using RhinoCommon code inside my Python script, in order to bypass calling a Rhino Command from the script (crease splitting).

Does it make a speed difference for hundreds of thousands of objects to use my “own” addNurbsSurface compared to having it inside the rhinocommon.dll ?
Cheers,
Florin

7

No.

If dig in the code behind rhinoscriptsyntax, all it’s doing is calling RhinoCommon for you…

– Dale

8

Thanks @dale,
thanks for clearing that up.

9

Hi Dale,
The reason I asked for a scripting function is that we actually have no way of detecting how CreaseSplitting is currently set, all we can do is run the normal Rhino command to explicitly set an option.

There is a history in Rhino 5 on both platforms (and it seems the WIP as well) of this being either inadvertently set to No, or some intermittent bug that does it without the user’s knowledge. The idea was, for example, if you had a script that absolutely needed CreaseSplitting to be enabled or disabled, that one could query the current state with the scripted method and either set it the way you need it (setting it back the way it was after), or at least throw up a warning to the user that there is a problem.

–Mitch

10

And I suspect that would also prevent a few threads like this one from popping up in the future.
Florin

11

I don’t understand why do you need to know this? If you want to add a surface without having it split at kinks, RhinoCommon has a method for this…

– Dale