Bug with NURBS Knots

Pipeline
1

It’s me again )
This time the problem with NURBS. More precisely - with knots vector.
I exported NURBS curve from Blender My looks like this:

<Knots> { 0.00 0.09 0.18 0.27 0.36 0.45 0.55 0.64 0.73 0.82 0.91 1.00 }

When i load it into the pview and press the Shift+L keys i see:

      PandaNode NurbsCurve.001 T:m(pos -0.723248 0.958224 0)
        NurbsCurve, order 4, 8 CV's.  t ranges from 0 to 0.73.
        CV's:
        0) -1.5 1.83082 0, weight 1
        1) -1 1 0, weight 1
        2) 1 1 0, weight 1
        3) 1.5 0 0, weight 1
        4) 3.01688 -0.918108 0, weight 1
        5) 5.23231 -0.139712 0, weight 1
        6) 4.59363 2.61461 0, weight 1
        7) 1.08086 3.89198 0, weight 1
        Knots:  0 0 0 0 0.36 0.45 0.55 0.64 0.73 0.73 0.73 0.73

When I load my curve through a loader and use ls() I get the same result.
The Knots is different from what i seen in the egg file.
Well, i tried “egg-load-old-curves 0” to see my curve. It looks as it should. And when i tried to replace the Knots values in the file on the values from pview, curve looks different.

Looks like a bug, or may be it’s a feature :).

2

Yeah, I think this is a bug, Ive encountered a similar issue.
I think the workaround was to have the curve start and end at the same point.

3

Yes, but in “visible” mode it’s looks similar as original in Blender, i.e. in “visible” mode knots are not changing, but in “visible” ls() not output information to verify this.

4

Can you paste the entire egg file?

5 
<CoordinateSystem> { Z-up } 
  <Group> NurbsCurve {
    <Transform> {
      <Matrix4> {
        1.000000 0.000000 0.000000 0.000000
        0.000000 1.000000 0.000000 0.000000
        0.000000 0.000000 1.000000 0.000000
        -0.989243 -2.149168 0.000000 1.000000
      }
    }
    <VertexPool> NurbsCurve {
      <Vertex> 0 {
        -2.489244 -2.149168 0.000000 1.000000
      }
      <Vertex> 1 {
        -1.989243 -1.149168 0.000000 1.000000
      }
      <Vertex> 2 {
        0.010757 -1.149168 0.000000 1.000000
      }
      <Vertex> 3 {
        0.510757 -2.149168 0.000000 1.000000
      }
      <Vertex> 4 {
        2.027631 -3.067276 0.000000 1.000000
      }
      <Vertex> 5 {
        4.243067 -2.288880 0.000000 1.000000
      }
      <Vertex> 6 {
        3.604383 0.465445 0.000000 1.000000
      }
      <Vertex> 7 {
        0.091620 1.742813 0.000000 1.000000
      }
    }
    <NURBSCurve> {
      <Scalar> subdiv { 56 }
      <Order> { 4 }
      <Knots> { 0.00 0.09 0.18 0.27 0.36 0.45 0.55 0.64 0.73 0.82 0.91 1.00 }
      <VertexRef> {
        0 1 2 3 4 5 6 7
        <Ref> { NurbsCurve } 
      }
    }
  }
6

OK, so the problem is with the older NurbsCurve interface in Panda, which supports only nurbs curves that begin and end exactly at their endpoints. This requires that the initial and final 4 knot values all have the same value, so it quietly enforces this.

The good news is that the newer NurbsCurveInterface (and its companion RopeNode) interface in Panda supports fully-general nurbs curves, such as this one. To use the newer interface instead of the old one, set:

egg-load-old-curves 0

and be sure to empty your model-cache so it reloads the egg file. You’ll find that the RopeNode contains a NurbsCurveInterface object that actually has all of the specified knot values.

The only downside to the newer interface is that it doesn’t integrate with the Mopath interface, so you’ll have to write your own task or LerpFunctionInterval if you want to fly an object along this curve.

David

7

um, why?
I mean its not like its hard to write a task, it’s just convenience (like working with Sequences/Parallels), we don’t need any intervals since we have task, but its nicer.

8

Hm… another bug under the Panda 1.7.2 for Windows:
egg-load-old-curves 0

Through the loader and ls()
First time loading (egg not cached):

ModelRoot curve.egg
  PandaNode
    PandaNode NurbsCurve T:m(pos -0.989243 -2.14917 0)
      RopeNode  NurbsCurve, 12 knots.
      NurbsCurve, 12 knots.

All seems Ok.

Second time (egg cached):

ModelRoot curve.egg
  PandaNode
    PandaNode NurbsCurve T:m(pos -0.989243 -2.14917 0)
      RopeNode  NurbsCurve, 4 knots.
      NurbsCurve, 4 knots.

wtf O_o? Also i’m not seen the curve visualisation at second time.

At second time with the pview i’m got a standart windows error.

For linux not testing yet.

9

Hmm, you’re right, looks like something about RopeNode doesn’t work with the cache. I’ll fix it, but for the meantime you can use loader.loadModel(‘curve.egg’, noCache=True).

Right, it’s not at all difficult to make Mopath support RopeNode, but no one has volunteered to do it yet. Would you like to be the person who does it?

David

10

You know, Im not a C++ user. I think this is the things the original devs should add when they get the time, as most people don’t know of this issue to begin with.

11

Mopath is entirely written in Python.

12

What about the mopath interval?
Never coded curves. I think you should look for a better candidate.

13

MopathInterval is also entirely Python.

OK. Let me know when you see one.

David

14

Sorry that I couldnt help.

15

Well, may be i’ll try to (re)write it, if i’ll understood the curves )

16

But if I remove this attribute or set to 0, then the curve is still displayed with automatic subdividing. So it should be?

17

I suspect that parameter is no longer respected with the RopeNode interface. Perhaps it should be, but it isn’t.

18

Not quite - if I’ll specify the correct number of subdividing (> = number of control points), then the visualisation of the rope will changing respectively.

19

Is this parameter not supported too?

added:
setHpr, setPos, setScale, e.t.c. not work for Rope?

20

That parameter doesn’t really have any meaning, except as a hint to Mopath. In the old NurbsCurve days it was preserved through the egg loader and available as a parameter on NurbsCurve for Mopath to find and read. Maybe today it should become a tag on the node.

setPos, setHpr, etc. should certainly work on RopeNode; it’s a node like anything else.

David