[Bf-python] Checking where we are

[Willian Padovani Germano]

Ken Hughes wrote:
> One thing I'm coming to appreciate (and might even more if I look really 
> closely at the BPy code) is the "top-down approach" that Stephen has 
> pointed out more than once to me.

Yes, Stephen is surely right about it.

I didn't realize that there are a few
> places where you can't do something to one piece of data unless you also 
> know what other pieces of data link to it.  Three examples I've seen in 
> the last month:
> (a) mesh vertex data is actually stored in the object linked to the mesh

Deform groups, yes. As you know we had to tackle this when Joseph came 
in with dvert methods. Putting them in Blender.Object would go against 
the intention of only adding general object level access there, but to 
put it in NMesh we needed a way to link to a parent object.

> It seems cleaner to do
>     ob.effect[0].getParticleLoc(time)
> as opposed to
>     Effect.getParticleLoc(obj,0,time)
> 
> or to do
>     ob.data.addVertexGroup(name)
> as opposed to
>     Mesh.AddVertexGroup(ob,mesh,name)

Surely, and it's also the recommended way, since

nmesh = NMesh.GetRaw(meshname)
nmesh.addVertexGroup(groupname)

doesn't work: the script needs to "link" (even if they are already 
linked in Blender) the nmesh to an object, first, so we know which one 
to add the vgroup to. Getting from ob.data tells bpython which object a 
script refers to, no need for the extra step.

> I'm wondering if there are other places in the API where this problem 
> exists that I haven't thought of, and if so it is a problem that should 
> be tackled while we're looking at things?

You stated the problem clearly. Even refering to some specific obdata 
type, some operations work on data stored in objects themselves. This is 
a good feature in Blender, it allows for example a single mesh to have 
different colors or vertex deform groups for each object it is linked 
to. But it doesn't integrate cleanly with the current API.

One "solution" would be to remove .Get() functions from all obdata 
modules: e.g. to get a mesh you'd have to use ob.data and not 
NMesh.GetRaw() or Mesh.Get().

But this would not be a good idea, specially because the .Get() 
functions in obdata modules allow users to access obdata that is not 
linked to any object, so they are necessary.

Currently we provide both ways and orient users via our docs to prefer 
ob.data. That's not bad, though we could document it better, in a faq, 
for example. Of course, if someone has a suggestion, the API is open for 
discussions.

BTW, Ken (and others), remember to tell what you're working on right now 
and how busy you are. That'll help us make short term decisions.

--
Willian