MD5Importer [Concurrent version 1.1 released on 05/11/09]

I've found different solutions on the net to MD5 GPU skinning. One solution sorted the weights, subdivided geometry and sent the weights in shader uniforms, this is a complicated solution, also slow. Another is to put weights related to each vertex into attributes, this results in 100+ bytes for each vertex.



What i meant by "rendered multiple times", is multiple times for each frame (reflections, shadows), but your approach is valid. Its just the question of availible RAM to precompute all the keyframes.



The MD5 format has the following:

vertex+weight index

weight bias+weight position+bone index

bones



The GPU can do skinning efficiently if it has the following:

vertex position+bone indices+bone weights

bones




i think what he meat is the accumulation buffer.  :smiley:



but again, my knowledge on shader is way too limited to implement something like that. but if anyone is interested, ill certainly be very happy to work with u.

@neakor

I do not know about vear, but I do not meant Accumulation Buffer. Though for my knowledge it is adressed to composite images.



@vear

Then, converting from MD5 to GPU should not be so diffucult.

I can precompute vertices positions (as MD5 Reader already does) and retrive per vertex bone indices from weights bone indices.



About the amount of RAM needed for precacheing, yes, it is a doubt I have already had.



Though this is a feature still in planning.

i found users r actually downloading the source code instead of checking it out from the svn.



i just wanna remind u that it is better to check out the source code from the svn if u want the newest version. since i sometimes make small changes like adding a getter method and i forget to update the download section.



i posted a detailed instruction on how to set up svn check out in eclipse. hope this helps

http://code.google.com/p/md5importer/wiki/Checkout_Instruction

added in animation speed and animation repeat mode control.



added in 1 known issue.

Hi!



I'm really interested on this importer because you said that supports Skeletal animation. So I download it and I do all the test, but i don't found how to animate by code the bones on my MD5. Anyone knows how to do this?



Thanks a lot :slight_smile:

Tekkai said:

Hi!

I'm really interested on this importer because you said that supports Skeletal animation. So I download it and I do all the test, but i don't found how to animate by code the bones on my MD5. Anyone knows how to do this?

Thanks a lot :)


animating ur character by code is very difficult. u will have to provide all the frame data to the JointAnimation class.

this is an importer for importing animated md5 models. the model should be animated with a 3d editing tool like 3d max then exported to md5 format.

@neakor have u ever tried having an animation play on a specific set of bones while ignoring others on the same skeleton , doom 3 uses something called bone channels to achieve this, but their is very little info…"that can understand " on how its done.



I'm still kind of looking at both loaders and figuring stuff out.

Yeah, for example, playing animation "attack" on the hands+upperbody and "walk" on the legs.

Also, I noticed that you're using an object for each vertex and face, in scenes with many characters it could use a lot of memory and garbage when the models are removed.

Momoko_Fan said:

Yeah, for example, playing animation "attack" on the hands+upperbody and "walk" on the legs.
Also, I noticed that you're using an object for each vertex and face, in scenes with many characters it could use a lot of memory and garbage when the models are removed.


Before to be sure of that we should test it. Though almost all the MD5 importers developed till now (kman's MD5 Loader, neakor's MD5 Importer and mine MD5 Reader 2 Refactor) have a class to handle triangles separatedly. I think it is a matter of well designed code. Though, if the situation require it, changing it in to another kind of data type (for example a integer array as a field of the class handling meshes, or a integers buffer) can be something really trivial. Using lists or collections would lead to exactly the same problem you adressed.
Momoko_Fan said:

Yeah, for example, playing animation "attack" on the hands+upperbody and "walk" on the legs.
Also, I noticed that you're using an object for each vertex and face, in scenes with many characters it could use a lot of memory and garbage when the models are removed.


this is design/performance tradeoff thing. at the moment, design is on the upper hand since i havent found any cases that this will result in a performance problem.

from what ive heard, GC now can handle alot of small objects at the same time without bringing down the performance.
mcbeth said:

@neakor have u ever tried having an animation play on a specific set of bones while ignoring others on the same skeleton , doom 3 uses something called bone channels to achieve this, but their is very little info.........."that can understand " on how its done.

I'm still kind of looking at both loaders and figuring stuff out.


this shouldnt be too hard to implement as long as u can provide the indices/names of bones that should not be affected by the new animation.

ill give it a try when i get some time.

currently im trying to push the EnvironmentSystem so all my free time is on that~ :D

Hi neakor,



Thanks for the reply. The problem I have, is that I'm not programming a videogame, and my personage "it's moved by some sensors that the player haves" and obviously I can't do a lot of animations predicting all the movements the player can do.



So referring to the importer, I understand that is not implemented but I can "recover" the bones I set in the 3DMax, and with a lot of work it could be possible to move my human with this bones by code. Did I understand it well??



Sorry for my English.

that is indeed possible as long as u can retrieve all the bones position in joint space every frame. a prediction could be possible.



in terms of using the importer, just set the frames in a JoinAnimation class, u should be fine.



please let me know if theres anything that i can change or add to make ur life easier. after all, the whole point of developing an importer is to make developers lives easy  :wink:

What's your plan about jme 2.0 upgrade? :slight_smile:

timong said:

What's your plan about jme 2.0 upgrade? :)


em...i dont know. since i know nothing about jme 2.0 yet. from what i heard a few weeks ago, its not going to be released any time soon as in within 2 months. so i guess we'll have to wait and c.

alpha is out and public. :slight_smile: see release announcements. I'm trying to fire it up but no md5 importer for it is available, so i'll have to stick to 1.0 CVS till someone will make a port…hmmm, probably I'll try to do it if it's not above my knowledge (i'll try to do it for md5reader2 maybe, as I'm using it already.)

IMHO there are a few things that have to be changed…AlphaState -> BlendState, and instead of static ids there are now nicer classes for informations like Image types -> Format class instead of type id. (and probably some other things, but it doesnt seem to be a too big task)

Well, I've decided to give a try to your md5importer with alpha… bad luck! 2.0 is removing TriangleBatch and SceneElement too. So it's not an easy task with my poor knowledge of such details. :S But as this is a final decision in jme 2.0, it's worthy to take a look at this new way of how jme handles meshes! (On the long run it's a must for any importers who want to keep up with jme development.)

All the core importers were ported to jME 2.0, so you could take a peek at those to see what was done there.  It is actually very simple though…  TriangleBatch -> TriMesh and if you were using TriMesh to hold multiple batches, make that a Node instead.