ender, is not only as the md5 exporter works smoother, is cause md5 anim files are incredibly small…
Kman…sorry, I'm repeating myself a bit,lately 
For cal3d exporter, I haven't made more test in a big while, as we changed the focus drastically, but I think you need to grab these versions of exporters, as a need: Usually is the only safe way, to have all them, with bones and weights formats.
http://purple.worldforge.org/cvs/forge/scratchpad/elefth/blender2cal3d_2.py
I think that above has a lot of chances of work…
http://cvs.gna.org/cvsweb/soya/cal3d/?cvsroot=soya
another.
reading the docs in the py files is very important…
but…double argh…as mentioned, I'm checking now…cal3d exporters seem really to need a keyframe per bone everytime…(bake) This will make it even heavier in ks…the first one …maybe for an older cal3d version, tho works for blender 2.41… but needs a 3d window opened in blender -no issue- and has several other things to care of (keyframe for root bone, etc)
Often, when someone says "plugin x doesn't work",at least in what is exporters, is just they don't know all the issues well, so can't overcome them…anyway, if there are too many, artist works becomes un-practical in the very day job… I dunno really with cal3d, have read many things, but they can be wrong or not well informed…We start with the limits already mentioned in the readmes, of course…
Anyway, I should be studying now for a huge exam…argh.(way too old to study)
oops.
Looks like…well…the soya one hasn't been updated for 2.41…that I read…and indeed the url should be this one :
http://cvs.gna.org/cvsweb/soya/blender2cal3d.py?cvsroot=soya
so, my first suspect looks was the right one…
use this…
http://purple.worldforge.org/cvs/forge/scratchpad/elefth/blender2cal3d_2.py
Unless a better version is included in recent Blender non release builds…
There can be more issues, you only get to know while in production, but at least, the ones already spotted ;) [from the py file, i hope is ok to paste here, for the 3.5 million artists around here. ] :
"Known issues:<br>
Animation export requires an open 3d graphics window.
Cal3d has a bug in that a cycle that doesn't have a root bone channel
will segfault cal3d. Until cal3d supports this, add a keyframe for the
root bone (should be fixed in cal3d0.9.1);<br>
When you finish an animation and run the script you can get an error
(something with KeyError). Just save your work and reload the model. This is
usually caused by deleted items hanging around;<br>
Cloth export only works reliably on a planar mesh (like a cape, or a
ribbon), not on a connected mesh (like a ball);
Temporary actions created for action export aren't deleted when the script
finishes;
Every keyframe in every action has an entry for every bone, even if the bone
isn't moving.
Notes:<br>
Objects/bones/actions whose names start by "" are not exported so call IK
and null bones LegIK, for example;<br>
Actions that start with '@' will be exported as actions, others will be
exported as cycles;<br>
Meshes whose names are prefixed with Cloth or cloth will have a spring
system created. Vertex group _cloth_weight is used to define the parts of
the mesh that act as anchors - give the 0 weight in this group. Otherwise 0.01
is a good weight. For now all springs have a coeff of 1000<br>
(The weights in _cloth_weight are stored as each included vertex's <PHYSIQUE> value.
Whatever that does);<br>
Faces with more than 3 sides are automatically split into triangles when they're
exported;<br>
Before each action is exported, the armature is reset to its resting position."
…and for now I recommend to use this plugin, as I have read in several places that the included with blender doesn't work well, and soya one is not updated for thenew bones system that 2.41 has… (those interested inm the format, that is… hiehiehie … <—terrible, evil, frightening laugh.)
probably is the same one that I just recommended, probably is another…grab it!
http://dmunition.ath.cx/blender2cal3d_2_2.py
must be a modification : "Cal3D Exporter 2 V1.1.2"
whileprevious was
Cal3D Exporter 2 V1.1
So last one, but grab the other too!
I found that none of the above exporters worked for me, and quickly hacked my way around the issues, so here's the result:
http://wwwhomes.uni-bielefeld.de/krabien/jmestuff/blender2cal3d_3.py
Use it at your own risk, I had no time to fully read and understand the parts I changed in the original code. In addition to the hacks I added, there's an option to flip the uv coordinates for your model now, which is apparently necessary to get them right in jME.
Very interesting. :) Thank you Hevee, I have not yet tested it, neither I'm gonna use cal3d unless we may have some terrible problem with md5, which I don't expect, but I thank you in the name of the whole thing, as kman needs help with the two formats :)
BTW, you'r the author of imho the best solution for vertex animation in Jme,(md2 and md3 wont allow 2 uv coords per vertex, for example...and the exporters do not allow so much control) so, lol, you're all together here...We only need carmack posting here about his md2,md3 and md5... ;) lol, now that I see...we have em all now! XD
Whoa, hold on here! I didn't write, nor plan, the jME vertex animation code, it is, together with the XML loading thing, Cep21's work. Credits go his way for those.
I merely did the blender to jME XML exporter, and some minor bugfixes for the XML loading system.
There's an updated version of the cal3d exporter, it now allows for animating single bones in an action/cycle, where previously there have been exported generated keyframes for every bone, regardless of if it had any keyframes in blender or not.
I have downloded all the cal3d exporters for Blender, also those posted in the http://www.blender.org/forum/viewtopic.php?t=7884&highlight=cal3d. Maybe one of then would like to work 
.
euh…i didn't mean the internal engine vertex animation…but I meant what only counts for an artist …the way to get well the freaking graphics into the engine… In that, we only have now, in vertex animation formats: md2, md3, your blender format. The one with less issues is your format… That i meant
BTW…
"There's an updated version of the cal3d exporter, it now allows for animating single bones in an action/cycle, where previously there have been exported generated keyframes for every bone, regardless of if it had any keyframes in blender or not."
Lol, it's a big issue for cal3d exporter I did read…good that you fixed…You know, the usual artist with a bit of python knowledge (not my case, I have a perfect ignorance of coding) is often not able to do those fixes…
I'm trying to setup the CAL3D loader from http://gamedev.kproject.gr/ but I get errors in JmeCal3dNode (setAlpha not a big issue) and JmeCal3dSubmesh (multiple errors on some buffer copying for normals/vertices). Is that the current version or should I be getting this from somewhere else now?
Good news! I tested the cal3d loader using a simple scene created in Blender 2.41.
Just a simple polygon object moved by 2 bones.
I baked the Action as you can see in the keyframes view. And to load the script that I used, the one in this post http://www.blender.org/forum/viewtopic.php?p=50640#50640 from this thread http://www.blender.org/forum/viewtopic.php?t=7884, I use any viewport except the 3D view.
The result is a smooth animation. The only trouble is the World Axes orientation. Bones, instead to flex as an arm (as you can see in the second blender screenshot), rotate along the Z axis of jME, producing a torsion.
Anyway this trouble can be probably resolved modifying the Blender script.
The little piece of code I commented (as I wrote in a previuos post) is still commented. Also I do not remember if I have changed some line of code for fix. Anyway I have not changed anything from the last post I wrote. Just tested this other Blender exporter.
The wrong rotation axis might be because you forgot to create the Armature and Bones in front view, could that be possible?
hevee said:
The wrong rotation axis might be because you forgot to create the Armature and Bones in front view, could that be possible?
No. I created it in the front viewport, the same visible in the screenshots.
I think that, as like as many other exporters, the cal3d exporter does not flip Y and Z axes coordinates when exporting the models. But this is my opinion.
Anyway, I made a reasoning and it is:
- The jME world system has X oriented from left to right, Y looking upward, and Z looking toward the user.
- The Blender world system has X oriented the same as jME, Y looking forward, and Z looking upward.
- Exporting from Blender to jME (without any flipping code) gives as a result the objects rotated about 90 degrees around X axes.
- The translation between the two system could be jME_X = BlenderX; jME_Y = BlenderZ; jME_Z = -BlenderY, or a rotation about 90 degrees around X axis.
- Can the absence of this transaltion influence in the wrong way the Keyframes Bones Transformations? Considering that the order of members in a Matrix multiplication is important.
I've been trying to find the bug via eclipse's debugger just eyeballing what happening in the back ground between both the old and new versions, haven't started toying with variables yet, but I am focusing my search on what happens when the AnimationController is called specifically, in hopes of finding the bug… "process of elimanation", best that I can do considering I'm not an expert. and as for available time…
mcbeth said:
"process of elimanation", best that I can do considering I'm not an expert. and as for available time................................................
I think that is the best way to work. At least IMHO and I am not a really expert coder too, even if in the last 2 year I studied a lot Java, becouse there are people that studied more than me :D.
Anyway, I am glad to announce that I have just modified with succes the Worldforge version of the blender2cal.py exporter (currently tested with the original Cal3D Miniviewer), that had some code error in the "Export for Soya" option.
Basically the "Export for Soya" option is responsible to rotate the system axis to fit the Soya3D engine system orientation.
Due to the fact that this rotation depends on a single variable creating a custom version for jME should be really easy.
As I predicted the correction of the rotation of the system axis resolved the strange problem that I reported some post above (object torsion instead of flex).
TODO: I have to correct the system axis rotation conversion to fit jME system orientation. And maybe adding some more customizzation to the Blender GUI of the script.
Still not tested with jME.
*****
In the previous test I used the Eternal Lands version of the blender2cal.py script. I explored the two codes with a diff utility and the interested block of code is exactly the same.
Worldforge version http://purple.worldforge.org/cvs/forge/scratchpad/elefth/blender2cal3d_2.py
Eternal Lands version http://www.eternal-lands.com/misc/blender2cal3d_3.py
Soon I will post my corrected version.
Ender, have you tried my fixed version of the cal3d exporter?
http://www.jmonkeyengine.com/jmeforum/index.php?topic=2982.msg27770#msg27770
I have fixed some isssues there, which you will likely encounter once you start testing in jME.
Anyway, just to share some experiences (I am using the cal3d code from kman as well, and it works quite nice for me in jME):
After some consideration, I decided to do the coordinate space conversion in jME, by rotating -90
hevee said:
Ender, have you tried my fixed version of the cal3d exporter?
No. Or at least I do not remember. Anyway I will get a look to it, maybe I will got some ideas to made the final modificatons to blender2cal3d.py. In particular with UV coordinates, a field that I do not know well enough.
hevee said:
[...] I decided to do the coordinate space conversion in jME, by rotating -90
I tested the animation with the original Cal3D viewer from the Cal3D Home Page. The result is the same both with the DirectX viewer and the OpenGL viewer.
So it is confirmed that the problem resides in the export script or, in the worst perspective, in Blender.
for the tests I made did seem to me md5 Blender exported worked perfect.
But yup, is usual that of the z instead of Y prob.
snaga said:
for the tests I made did seem to me md5 Blender exported worked perfect.
But yup, is usual that of the z instead of Y prob.
Yes that is true. But maybe Blender exporters can be fixed.
Also I still have not been able to make the kman MD5 Loader to work.
And mcbeth got a different bug with the chaosdeathfish MD5 reader and I verified it. He sent me the really latest version (i think) of chaos' loader and after some little fix I got it to work with jME CVS. The only trouble is that, for some unknown reason, the root bone or node (I still do not know which one of them), if animated to move along Z (in jME) for example, it moves along X axis, when importer in jME. And this did not appen with a model exported from Blender but appened with the "marine" model and "walk" animation released with the original chaos' loader.
modification
:// I must apologise.
The unsuccessfull test reported below is not valid, becouse the failure is caused by my fault.
I erroneously copyed the parameters values for the xml definition file from an old (and wrong) cfg definition file, generated by one not working Blender exporter.
I discovered the problem changing some code inside the kman’s Loader to understand the cause of the absence of any animation.
The good news is that the file exported with my modified Blender exporter works. Animations works and the object is oriented the right way. This means that Soya3D axis system is oriented like the jME axis system (I did not chage the default conversion for Soya3D) and that the Cal3D miniviewer instead has a different one orientation.
modification end
I tested with kman’s Cal3D Loader the same animation that I run successfully with the original Cal3D miniviewer from Cal3D site.
The kman’s Loader does not play animation anymore. Considering that Cal3D miniviewer is the reference application, and works, now it is clear to me that the big problem is still in the kman’s Loader.
Unfortunatelly gamedev.kproject.gr seams to be down so I cannot chek if any change have been made to the code.
***************************************************************************************************************************************************
Just to report a problem (not exactly a problem) that comes in my mind this moment, I should notice that if, for any reason a file is missed the loader throws a NullPointerException and kill the application. The code responsible for this action is this method, member of the CalLoader class:
public static InputStream getResourceURL(String resourceName) throws IOException{
URL res = CalLoader.class.getClassLoader().getResource(resourceName);
if(res==null){
File file = new File(resourceName);
if(file.exists()){
try {
res = file.toURL();
} catch (MalformedURLException ex) {
ex.printStackTrace();
}
}
}
return res.openStream();
}
this way the task to handle this exception is leaved to the Game Developer. IHMO this problem can be resolved with documentation, with the example handling code in the JmeTestCal class or with built in handling.