Has anyone been able to successfully port the new make human format to JME ? I was able to animate the old .mhx files in blender and port them over to JME but the new .mhx2 files animated in blender cause the SDK to crash when loading.
I’m not sure if this is a problem with 3.1 beta or the new format.
There are issues with the Animation (If you try to open a saved j3o, you have that crash).
Try right click convert to j3o instead for the model importer.
Actually there is already the pull request pending but without the page coming up we won’t be able to use the new engine version really.
Using the right click option gives me a little more detail of the crash. It loads the animations and materials. Right before it locks up a bubble appears asking me to “add triangulation in blender”. I’m a modeling noob so I have no idea what that means but I assume that has something to do with the mesh shape.
Right!
You’d need either the Triangulation Modifier as Workaround or the SDK beta2.
Still the old “homepage is down” problem 
Where is the beta 2 ? I have this link
but it only has the beta 1 snapshot which I am currently using.
That’s it, we don’t have beta 2 yet, but the fix is on master, so we have to wait for those releases.
Maybe we should temporarly up the maven server again so we can at least continue to release.
Talk about strange errors. I triangulated my model in blender then loaded it into JME. It loaded fine except my materials where transparent. I tried to create a custom jme3 material via the editor but the editor locked up. When I reloaded the SDK my bob model was gone. It vanished into digital dust.
Not specifically related to your problem, but I figure anyone using MakeHuman with Blender might want to check out the Manuel Bastioni Lab add-on for Blender. It works similar to MakeHuman as far as creating and modifying humanoid, and anime, characters except it’s all done directly in Blender.
http://www.manuelbastioni.com/manuellab.php
I’ve found it to be freakin’ awesome, and you don’t have to mess around with different formats, just .blend from start to finish.
I have that add on but I can’t seem to get it to work with .bvh files. It makes great models but no rigs. I use make human mainly for the rigs.
Hmm, dunno what to tell ya, when I create a character with Manuel bastioni lab it’s fully rigged with an armature.
Maybe you’re using an older version?
No , the latest version. I might be doing something wrong in the settings. I’m horrible at drawing and animation so I rely on tools to get the job done.
The armature is does not have x-ray on by default so it’s hidden inside the model and I think, if I’m not mistaken, it’s set to “stick” rendering mode by default so the bones only appear as fairly thin lines.
I don’t have my laptop in front of me at the moment, on my mobile.
NOT THE ISSUE.
We upload to jcenter… but the builds are all setup to ALSO upload to updates.jmokeyengine.com. So the builds will fail.
Well I found out reducing the polygons helps a lot. I didn’t realize my model had 20,000+ polygons. Not fit for gaming what so ever. Now it loads fast and seems to work properly but look kind of funny after reducing the detail so much.
jMonkeyEngine uses a short buffer to define triangles in a mesh. Each vertex has an index, where it can be found in the position buffer, UV buffer, vetex color buffer, etcetera, and this index is stored as a short, not an integer or long. This means you cannot have more than 32767 vertices.
Because that’s the maximum value of a 16 bit short.
We don’t upload jme3-jbullet to bintray it seems (at least there was a post about it), but i guess this is a Bug anyway then
Edit: yeah. You must not change the j3o or save changes as long as it has Animation and your Device Supports Hardware skinning.
The transparency issue has also been resolved partially on master.
Btw: iirc, jme uses the short buffer where possible and then uses an int buffer.
And yeah, less Data is less loading time for sure
Yeah, we can’t upload it to bintray. a) it’s not ours to do it, and b) we don’t have the source.
But frankly I’d be fine with releasing 3.1 without the Java bullet hack. We have too many dependencies in the core. I’ve always argued against but here we are.
It used to be on updates.jmonkeyengine.org though.
And as the SDK depends on it, we’d need a hack and/or Switch to native bullet anyway.
The good thing in keeping jBullet is that you have a reference when you have an issue. You can see it works in jBullet so it has to be a bug in bullet native
