[Bf-python] Checking where we are

[Gilbert, Joseph]

This one is tough. 
Ive thought about it a lot and can't find a satisfactory solution.
The only thing I can think of is a utility function for returning
object* parent's from a datastruct. It not top down though. 
We could pass 'data' in ob.data the pointer to object - but this may go
out of scope. That's the thing. Also can't data structs be theoretically
linked to more than one object? So setting a pointer to object might not
be exactly right.
I wonder if the DAG stuff could have an insertion point where you could
get the parent object dependencies of the data. Would be nice.

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Willian
Padovani Germano
Sent: Friday, November 04, 2005 10:20 AM
To: Blender Foundation Python list
Subject: Re: [Bf-python] Checking where we are

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
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python