Updated Blender Import Python script imports animations from G3D!

[softcoder]

Get it while its hot:

http://megaglest.svn.sourceforge.net/viewvc/megaglest/trunk/source/tools/glexemel/g3d_support.py?revision=1531

[-Archmage-]

Omega will murder you and take your awesomeness Softcoder! You are da man, man!!!

Only one thing, HOW? g3d's have no armature..........

[Coldfusionstorm]

oh, it have, instead of thinking of it as a amature, you should instead try to realise the truth, there is no amature only animation.

[softcoder]

Think of the G3d format like a customized MD2 (which has no armature or bones but simply frames)

[John.d.h]

So does it import them as shape keys in sequence or what?

[softcoder]

Yes shape keys per frame (as it does for MD2)

[Omega]

Omega will murder you and take your awesomeness Softcoder!

I don't have to murder him for his awesomeness... Simply knocking him unconscious will more than suffice.

At any rate, excellent work Softcoder! I must wonder though, how can we use these animations? I would have assumed the exporter could handle these shape keys, but it appears it cannot...

[softcoder]

Will take a look at the exporter to see what is missing. I know that it currently doesn't specifically look for armatures, but i need some time to decipher it.

Thanks

[-Archmage-]

This isn't OT, this relates...

I had a brief skype chat with silnarm about eventual plant physics(reactions to units, based on physics, yes FAR AWAY but feasible in the distant future). I proposed the idea of giving plants armatures, which would mean the g3d format would need major upgrades of course, and the mesh of the unit would have collision detection with armatures. The parent-child system of the Blender bone structure would tell the physics engine which part of the plant is in the ground. The relation is that if armatures were included in g3d's, importing armatures/key-frames aka:animations would certainly be a lot nicer.

[softcoder]

While not perfect I just confirmed with ElimNator you can edit and re-export these key frame animations, using Relative Keys

[John.d.h]

I suppose the next logical step would be to automatically generate bones through the vertex groups, but that's probably beyond the scope of what we need.

[ElimiNator]

I suppose the next logical step would be to automatically generate bones through the vertex groups, but that's probably beyond the scope of what we need.

It would be useful though.

[will]

Armatures and Bones would be very nice.

In this thread ?topic=6260.msg63877#msg63877 the g3d_stats.py https://github.com/williame/GlestTools/blob/master/g3d_stats.py script does go looking for immutable sub-parts of meshes and such.  Its not exhaustive, but its a start.

Being able to represent immutable meshes that rotate/transform in terms of rotate/transform would avoid wobbly wheels in interpolated frames.

Being able to work out the immutable sub-meshes and then, for those vertices that move, work out how they are glued to the adjacent parts of the immutable sub-meshes would give you an inferred bone-system.

If there is a difficulty, its that the meshes in many models have 'holes' in in the sense that they have points aligned on the edges of other triangles rather than sharing corners.  Throw in some float imprecision and it can be challenging just working out what is attached to what.

So two things:

1) do we not have the original blender files that many models were generated from?  Exporting models with bones/armatures, and preferably with multiple animation sequences in one file so they can share data rather than duplicate it, would be very cool (and a new version of the format, or adopting support for a new format)

2) an export that avoids a separate xml exe processing step would have saved Mr War a lot of trouble recently.

[Omega]

1) do we not have the original blender files that many models were generated from?  Exporting models with bones/armatures, and preferably with multiple animation sequences in one file so they can share data rather than duplicate it, would be very cool (and a new version of the format, or adopting support for a new format)

2) an export that avoids a separate xml exe processing step would have saved Mr War a lot of trouble recently.

I was just about to say this.

Having the exporter store bone data (that can later be imported by the importer) as well as having the exporter directly export to G3D would be very nice and more efficient. Since exporters and importers are just opposites, changes done to one just have to be reversed to the other (ie: exporting bones to G3D; importing bones from G3D).

[softcoder]

As we all can see, the community has many good ideas, but very few implementers. Hopefully someone who knows how to do this will step in and do it