[Bf-python] Vertex Influence for no-armatured objs

[Stephen Swaney]

models at paposo.com wrote:
> 
> 
> Sorry I'm not always clear when i have too much caffine. @ @ Heres my point:

No problem.  After reading what you wrote below, I think we are
pretty much on the same page.  Comments below.

> Many of the modules in blender represent 'datablocks'. These really are
> representations of methods and variables of structures that are just blocks
> of data. Then comes the object module. By linking a datablock to an object
> you get a 'realworld' representation of the datablock. Something that can be
> seen and felt in the 3d world. object module should really only be for
> generic object manipulation.  I AGREE!!completely.
> 
> My problem is that there are a number of functions that deal with
> type-specific objects.  Vertex groups are just 1 example. By this I mean
> that there are functions in blender which deal with an object only in the
> context of a specific datablock type. In this case vertex groups don't
> pertain to nmesh because you can't add non-existant groups to the mesh data,
> but don't want them to be in object because object is for generic object
> manipulation.
> 
> A good solution would be to subclass the object module into type-specifc
> objects.  They would all inherit the methods from the parent generic python
> object but would have methods and variables specific to the datablock linked

Actually, we have already done this.  It's harder to see because it's
done in C ( poetry! ) rather than in a language that supports Object
Oriented programming directly like python or C++.  Our Object struct has
a ID that tells us what it is and gives us a primitive run-time type
identification.

You can think of it like this:

ObjectBase
   |
----------------------------
   |       |          |
MeshObj  CameraObj   LampObj

The way it gets implemented in C we have

struct Object
{
	TypeId
	GenericObjectStuff like Size,Loc,Rot,Material, etc.
	TypeSpecificDataBlock ( implemented as void* pointer )
}
	



> object. Right now all modules are inside of Blender but you could subclass
> Object into meshObject, latticeObject, armatureObject, etc. The subclasses
> of Object would inherit the methods/vars of the parent module.
> 
> This would also have application to the emesh module as editing a mesh
> object is one of several type-specific object things that can be done with
> an object linked to mesh data.
> 

Exactly.  The way we get there is add more interesting stuff to our
subclasses.  Since the compiler won't do it , we do it ourselves like
this:

struct Object
{
	TypeId
	GenericObjectStuff like Size,Loc,Rot,Material, etc.
	TypeSpecificDataBlock
	TypeSpecificMemberStuff ( another void* pointer )
}

This keeps all our Object structs a constant size, but lets us
use the TypeSpecificMemberStuff to hold whatever we need for our
derived types.

In the case of our Mesh, we define a new struct with our extra goodies
in it:

struct ExtraMeshStuff
{
	TypeID
	EMesh* emesh;
	more fancy mesh specif stuff;
	maybe a function pointer or two;
}

Except for adding the TypeSpecificMemberStuff pointer and a
GetExtraData() func, we don't have to touch Object again.  Any new
clever stuff we think up goes into the ExtraMeshStuff or ExtraLampStuff,
or whatever.

It is possible to build Object Oriented software in C, you just have to
work harder at it. ( and do more casting! ).
-- 
Stephen Swaney			
sswaney at swbell.net