i got another problem when trying to start an animation.
this time i got a simple cannon that squashes and stretches while shooting (joint-scaling)
the mesh is loaded successfully but if i try to run the animation it says the following:
java.nio.BufferUnderflowException
at java.nio.Buffer.nextGetIndex(Unknown Source)
at java.nio.DirectFloatBufferU.get(Unknown Source)
at com.radakan.jme.mxml.anim.MeshAnimationController.softwareSkinUpdate(MeshAnimationController.java:316)
i think i got that error a time ago... don't know how i fixed it... do anyone of you have a clue?
you may download the mesh and skeletonfiles here: http://rapidshare.com/files/226139711/cannon.rar
hope you can help me, it's quite important... icq me if you want to: 158292771
just a question. Is still sensibile to keep the Ogre loader stuff in the current Radakan repository?
As far as I understand the Radakan project moved to another place/techonology and the current tree is officially discontinued.
...
regards.
I think Radakan is scaled back and under-staffed, but that the message about its demise is over-stated. You can see that there is activity in the project since the December message about its death.
Momoko_Fan has rejected the idea of merging into the jME code base in the last item of post #57 below. I don't get the points listed for the rejection, since no adjustment whatsoever is required for the Radakan ogreloader branch to build with jME 2.0 HEAD; and if a hardware rendering mode is a problem the default can be changed. But it just takes a few minutes of integration work to make a coordinated build system. To clarify in case this discussion continues: I think the idea was to merge just the ogreloader branch of Radakan, not the entire Radakan code base.
i got another problem when trying to start an animation.
this time i got a simple cannon that squashes and stretches while shooting (joint-scaling)
the mesh is loaded successfully but if i try to run the animation it says the following:
java.nio.BufferUnderflowException...
Check farther down in this Topic. "Jpm" had this problem, and "ravenhearte" suggested a work-around which worked for him/her. The work-around may only work if you don't use vertex weights though. Please report back, for the benefit of others.
UPDATE: I see that materials which specify a texture and no color still invoke readColor(), setting color.a to 0. It's an understatement to say this parser isn't very careful. I suppose this could cause problems, depending on the settings for combining colors and textures...? I have lots of other work to do and would appreciate any help testing this.
I'm going to help you to test those use cases ;^)
Please give me a few days to retrieve some free time...
just a question. Is still sensibile to keep the Ogre loader stuff in the current Radakan repository?
As far as I understand the Radakan project moved to another place/techonology and the current tree is officially discontinued.
Btw, I found a couple of glitches in the animation handling logics (for instance, I think the RT_CLAMP animation type is broken) and I'm going to try to apply a patch to address some of them.
I’ve added a JNLP that automatically loads the Ninja model and allows you to run the animations. The model loads from the Internet in less than 10 seconds over my DSL modem. http://pub.admc.com/misc/ninja.jnlp. Requires Java 6.
(Also now supports working directly with mesh and material files).
The Material scanner could be made about a hundred times more robust and fast by using JFlex and a parser like Cup or Beaver.
Yeah you're right. I was planning on porting MaterialLoader from using StreamTokenizer for Scanner, which should provide more reliability when parsing names and structures.
got it: it's a problem with the cloner. it seems that it doesn't clone the buffers always correctly. i got 2 different meshes with 2 different skeletons. in one case it works perfectly, in the other case i got that nullpointerexception.
in the first case, i use your xml-format, so sharedGeometry off, but used, in the other (not working case) i use normal sharedgeometry. maybe i find the answer
Shared geometry has not been tested as much as seperate geometry. I mostly tested the importer with Blender which doesn't support exporting as shared geometry. It's possible the MeshCloner class was written without that consideration..
i have another question... does this importer support vertex animation? maybe then it'll work...
Yes, vertex animation is supported. Make sure that the vertex animation name is the same as the bone animation name and then they will be played together.
this time i got a simple cannon that squashes and stretches while shooting (joint-scaling)
Scaling transforms are not supported right now. Though I think the error you're having is not related to this issue.
I think Radakan is scaled back and under-staffed, but that the message about its demise is over-stated. You can see that there is activity in the project since the December message about its death.
Radakan is currently maintained by a different team/group which are using Python for it's development. You're right about it being down-scaled, the game will no longer be in a 3D environment, currently it is mostly in a 2D GUI which interacts with the AI system.
Momoko_Fan has rejected the idea of merging into the jME code base in the last item of post #57 below.
Actually I did not reject merging into the jME codebase. The question was about using multi-threading to handle animation and I was saying that it won't be supported because jME's framework does not handle that kind of stuff well.
Momoko_Fan has rejected the idea of merging into the jME code base in the last item of post #57 below.
Actually I did not reject merging into the jME codebase. The question was about using multi-threading to handle animation and I was saying that it won't be supported because jME's framework does not handle that kind of stuff well.
Oops. Sorry for misunderstanding then posting mis-information. :(
UPDATE: Based on the switch of Radakan from Java to Python, it really makes a lot of sense to merge the ogreloader code base into jME, no?
UPDATE: Based on the switch of Radakan from Java to Python, it really makes a lot of sense to merge the ogreloader code base into jME, no?
+1 for this, or at least, to replace the following note from Radakan's google code page (http://code.google.com/p/radakan/) :
"NOTE: As of December 2008, this project is no longer maintained. The Radakan RPG has been taken over by Tinus, more information is available at http://www.radakan.org/"
with some info telling this repository is used only for the OgreLoader library.
If you (Momoko_Fan) want to do this, and get any needed approvals, you can assign the merge to me if you like. I'm a Subversion and build system Guru and have made some substantial improvements to these portions of jME. In any case, getting it done right does require an expert in both areas.
so i'm here again and can give an update to my cannon-problem:
i created a crossbow and it threw me the same error as the cannon (so i think…). i simply set the "maxWeightsPerVert" - variable within softwareSkinUpdater to 4 (getMaxWeightsPerVert() threw a 2 back) and everything works just fine now… dunno why, maybe there's an error within that getMaxWeightsPerVert() method?
so i'm here again and can give an update to my cannon-problem:
i created a crossbow and it threw me the same error as the cannon (so i think...). i simply set the "maxWeightsPerVert" - variable within softwareSkinUpdater to 4 (getMaxWeightsPerVert() threw a 2 back) and everything works just fine now... dunno why, maybe there's an error within that getMaxWeightsPerVert() method?
I see no such method as getMaxWeightsPerVert(). :?
int maxWeightsPerVert = mesh.getWeightBuffer().getMaxWeightsPerVert();
maybe the buffer not always returns the correct value. as i sayd, it works for big meshes with walkcycles, but simple weapon-shots with only 3 (or, in the case of my crossbor about 10) joints seem to don't work for me
FYI, I've been nudging the maintainer of the Ogre Mesh exporter. The next release will be a little more intuitive for jME users, and I'll be adding a few important points to ToM's tutorial… probably after the merge to jME is completed. One thing I have been encouraged to do if I can just come up with the time, is to add a switch to the Mesh exporter to handle non-material objects*. This feature is needed neither for the Ogre game, nor for Momoko_Fan's use cases, but IMO is very important for general jME model import usage. If we have any Python experts out there with some free time, contact me please. UPDATE: I've submitted the patch for the Ogre Mesh XML exporter to gracefully handle meshes without materials. When this gets committed to the Ogre trunk, I'll roll an exporter distro to include all of these features + both the Mesh and dotScene exporters in one zip file.
It looks like it will be some time before they release the next Mesh exporter though. If you like the leading edge, pull from their svn.
Actually, due to improvements I've made to our material parser, we can load non-material objects now. The exporter issue is that it displays tons of red error messages (error messages, not warnings), one per face, and you can't tell whether your export succeeded or not.
I've tagged the radakan ogreloader source as tag "ogreloader-final". I don't have admin privs there so don't think I can post an announcement there, so this will have to do.
Do not commit any more ogreloader code changes to the radakan source code repository.