[Bf-python] Object module things

[Michel Selten]

On Thu, 2003-05-22 at 01:32, Willian Padovani Germano wrote:
> On Wed, 2003-05-21 at 16:55, Michel Selten wrote:
> (...)
> > * getDeformData
> >   from the api docs: Returns the Datablock object containing the 
> >                      object's deformed data Currently, this is only 
> >                      supported for a Mesh
> 
> This looks like something for FUTURE, that define about what they were
> preparing to substitute 2.25.  From what I know, deformdata for a mesh
> is this:  you have a list of vertices in a mesh, all with their (x,y,z)
> coords., what you may call local coords.  But the Object("Mesh") has
> attributes like .loc, .rot and all in one, the .matrix.  Deform data is
> what you get after applying all these changes to the list of vertices,
> getting global coords. for the mesh vertices.  Got it?  For example: if
> you create a point with coords. (0,0,0) then move it to (1,0,0) the
> vertice won't be updated automatically.  The change will be saved in the
> .loc and .matrix of the object.  But if you get its deform data, then
> the vertice will be multiplied by the matrix and will have the final
> coords. in itself.

Okay, I get the idea! Thanks.
Are the attributes like .loc, .matrix. .rot and such reset after the
calculation?
Any example where I can find such a deform execution in the sources?

> > * getDrawMode
> >   from the api docs: Returns the Object draw modes as a list of strings
> > 
> >   This is different from what's in 2.25. In 2.25, an integer is 
> >   returned. Should I follow the api doc, or the implementation in 2.25?
> 
> A list of strings makes much more sense to a script writer.

I just asked on #blenderchat. The users there wanted to have it return
an integer. So I'm going to keep that for now.

> > * getLocation (also applies to setLocation)
> >   from the api docs: Returns the object's location (x, y, z). For the 
> >                      moment, relative has no effect.
> >   What would he have meant by relative? I guess relative to some other
> >   coordinate. For now I ignore the entire argument.
> 
> Maybe an argument to getLocation choosing whether the user wants the
> local (relative) or "deformed" (global) info ?

Could be. At least it isn't implemented in 2.25 and the documents are
vague about it. So we don't have any compatibility problem here :)
For now I ignore the argument (as described in the documentation).

With regards,
	Michel