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

models at paposo.com models at paposo.com
Mon Sep 8 03:17:22 CEST 2003


> Well, to test if a theory works you can use any method you like. But for
> something to be really ready for 'production code', I think it must be
> in a state where we all can say "Hey, this is indeed the best solution
> we can think of now."

I wasn't testing theories, just trying to help improve the python interface.
That's why im here. :)

>This should indeed be in a seperate module EMesh.
> So, I'm a little hesitant of incorporating the changes to cvs. Maybe
> you'd like to give a shot at trying to implement the EMesh module
> (perhaps together with Willian).
>...Otherwise, I can put a basic skeleton of the EMesh module in shape
(only)
>for your vgroup code.  Later then we could add the rest of the methods and
>member vars to it.

1)I agree. That way the Nmesh will have been translated to a real mesh
object before attempting to set groups, etc. That would avoid someone trying
to set dverts before the final mesh data is set. dGroups really only apply
to mesh objects too, so i think that really is the best idea
2)I probably am a little fuzzy on writing the entire emesh module (maybe
really fuzzy). lol I guess the only thing that i can think of that the
module would need for vertex groups would be to get a pointer to the object
the mesh is connected to. Then the code could be copy/pasted. My only
suggestion is that the EMesh not be an object/mesh IN editmode, because some
vertex group stuff depends of the fact that your not in editmode.
--------------
I guess thinking about this a little and the EMesh could be a reflection of
mesh-specific things that objects with mesh data can do; editmesh verts,
assign vertex groups, etc. Maybe when you link an object to a datablock you
could create a type-specific object.
Something like:
myMeshObject = GenericObject.link(MeshData)
this would test the MeshData being passed and return the appropriate class.
In this case an 'emesh'; or maybe a MObject. That way you could accomplish
all mesh-specific, object linked stuff, such as editing, etc.

>The methods you implemented are only applicable
>to Mesh objects, and not for example to Lamp or Camera objects.

And i think that this problem will come back too, because there are alot of
things objects can do in blender that are item specifc.  I think mesh is
only the first place that the problem has been encountered.

That's one of the reasons i think that returning a data-specific object
could be useful once linked. The object types returned would be:
OB_MESH, OB_CURVE, OB_FONT, OB_SURF, OB_MBALL, OB_CAMERA, OB_LAMP,
OB_LATTICE, OB_ARMATURE (the datablocks that can be linked to an object)
These could be object/data linked structures for type-specific manipulation
of objects, while the datablocks for lamp, lattice, mball, camera, etc.
would deal with manipulation of the data block itself.

good idea/bad idea??




More information about the Bf-python mailing list