[Bf-python] A few notes

Willian Padovani Germano wgermano at ig.com.br
Fri Sep 19 05:13:43 CEST 2003


From: <models at paposo.com>
> Just a suggestion about the object pointer...:

You've been researching : ).  Let me congratulate the two new bpython
developers, you Joseph and Stephen, great work, guys!

Today I added nmesh.get/setMode methods, to set things like SubSurf,
AutoSmooth, TwoSided, etc.  About the changes to make NMesh behave better,
possibly the tests will show we need to handle user count properly (create
meshes with us=0 and only incref it when linking to an object).  Let's
see...

BTW, Stephen: I'll wrap makeDispList as a new object method, there are a few
calls in bpython that will benefit from it.

> There are 3 ways of getting a new NMesh from inside of the nmesh module:
> 1.New
>     a) calls new_NMesh
> 2.GetRaw
>     a) calls new_NMesh
> 3.GetRawFromObject
>    a) calls new_NMesh_internal for displists
>    b) or calls new_NMesh for no displists

Yes, but the user doesn't in principle know if there's a displist or not.
Neither do I -- in what situations will one be available or not?  Maybe in
editmode it was freed, but then we'll have EMesh for editmeshes.

> Right now the object pointer is set in new_NMesh_internal. Right now you
> have New, GetRaw, and GetRawFromObject all setting nmesh->object to NULL.
> This is good for New because there's no object.
> 1) For GetRaw you could be getting a mesh datablock that is linked to 1 or
> more objects. You could test to see if the usercounts = 1 and find the
> object it's linked to, else set as NULL.

You're right, when we know the 'owner', we can set the pointer.

> 2) For GetRawFromObject the mesh might not use displists, in which case it
> calls new_NMesh instead of new_NMesh_internal.  Here you could pass the
> object as a parameter to new_NMesh if there is no displist.

As written above, this can be confusing for users, since they might not know
when there's a link or not.  Besides, there are those problems with dl
meshes, so I still think it is better to document this properly and force
users to create and link a new mesh if they want to change the data in a dl
mesh.  Remember that users don't need GetRawFromObject at all, if all they
want is to know the parent object, they simply can use object.getData()
then.  Dl meshes have other specific uses.

> So I was thinking maybe new_NMesh could take a Object* pointer.

Maybe, but if only for the GetRaw() with us=1, then nmesh->object can be set
in GetRaw, after the nmesh is created.

If we do the rest, like you propose, then we'll need to make this internal
ptr to object be exposed, with an nmesh.isLinked() method, for example.  But
if this is unneeded, we should avoid it.

--
Willian, wgermano at ig.com.br




More information about the Bf-python mailing list