yea the merge xml does not have the skeletonlink. If compared to ninja, ninja has 2 submeshes, but my merge xml has 1 submesh only. I also tried to copy and paste in all the xml to merge it to one, but it has "<boneassignments>" in each mesh xml and I have no idea what key is used to group them tgt (they are not in ninja xml though). I think it's still incorrect when exporting.

Or worst case, is it possible if we merge them using raft source code manually instead?

No option for export as submesh. The attachment is the screenshot of blender2orge settings.

I read abit of the blender2orge readme and it says this in FAQ:

QuoteQ: I have hundres of objects, is there a way i can merge them on export only?
A: Yes, just add them to a group named starting with "merge", or link the group.

So I tried to put the 2 objects into a merge group. It still exports 2 mesh xml and 2 skeleton xml, but with addition merge.mesh.xml. I use that file to convert to raft bones, it shows another error:

Exception in thread "main" java.lang.IllegalArgumentException: No controller found in OgreEntityNode. Means there is no skeleton or pose animation!
        at raft.jpct.bones.BonesImporter.importOgre(BonesImporter.java:135)
        at raft.jpct.bones.util.JMEOgreImporter.loadGroup(JMEOgreImporter.java:112)
        at raft.jpct.bones.util.JMEOgreImporter.loadGroup(JMEOgreImporter.java:88)
        at raft.jpct.bones.util.JMEOgreImporter.run(JMEOgreImporter.java:69)
        at raft.jpct.bones.util.JMEOgreImporter.main(JMEOgreImporter.java:170)


Does it have anything similar like that in OrgeMax?

At the same time, but it creates 2 mesh xml and 2 skeleton xml instead. How do you export it from OrgeMax? Maybe I can imitate some similar settings from OrgeMax to blender2orge.

Quotepossibly this is not what you want, you want objects merged into a group, not animations merged.

Yup, you are right. I just want the 2 objects to be in one AnimationGroup but share the same skeleton. I'm able to export 2 objects out of Blender, 2 mesh xml and 2 skeleton xml respectively (the number of bones for the 2 skeleton xml are the same). How do we make the 2 objects merged into 1 AnimationGroup? Not by using the script with multiple input files? Or should we do it manually in code instead?

Quoteso this additional vertices end up as well in JPCT ?

As far as I remember, yes.

Quotecould you tell me why sometimes models exports fine and sometimes the geometry get mess up??

This sometimes happen when some of vertices are not assigned with armature bones in Blender. You need to make sure every vertex is assigned to at least one bone.

Sure. Here's the stack trace:


Exception in thread "main" java.lang.IllegalArgumentException: Number of vertices differ!
        at raft.jpct.bones.SkinData.checkAlmostEqual(SkinData.java:63)
        at raft.jpct.bones.Animated3D.mergeAnimations(Animated3D.java:607)
        at raft.jpct.bones.AnimatedGroup.mergeAnimations(AnimatedGroup.java:368)
        at raft.jpct.bones.util.JMEOgreImporter.loadGroup(JMEOgreImporter.java:95)
        at raft.jpct.bones.util.JMEOgreImporter.run(JMEOgreImporter.java:69)
        at raft.jpct.bones.util.JMEOgreImporter.main(JMEOgreImporter.java:170)


Hi raft,

I got this error message when converting ogre xml to bones. The 2 objects in Blender and the objects are sharing the same skeleton. What actually caused this error, since 2 objects are suppose to be different in their number of vertices and sharing the same skeleton? Did I miss anything when i separate the object into 2 with sharing skeleton?

Due to some reason on setting normals, texture coordinate and etc, additional vertices will be added when exporting using ogre3D. Here's the link for the info: http://www.ogre3d.org/forums/viewtopic.php?f=8&t=61485&start=800

To fix that, I guess we have to customize the blender ogre exported instead, but it's too much of learning curve and I didn't finish it.

Hi egon, thanks for your support. Hope you like it. Thank you for helping along the way ; )

Dive into the beautiful and breathtaking deep blue ocean with a glimpse of lively underwater sea life. The sunlight high above from crystal clear ocean surface beams through the depth of the blue ocean, together with animated coral that swing along with the sea current, and a school of fish swimming past the plankton, creates a magnificent scene that you would never forget.

Ocean Blue 3D is a 3D live wallpaper that mimics the real life diving experience. Many customizations and options such as sea turtle, percula clown fish and the magnificent manta ray ,are available to make Ocean Blue 3D live wallpaper much lively and exciting. Ocean Blue 3D is also designed to adapt to your device background, so the tones of color match to your icons and homescreen. Thus, Ocean Blue 3D features silky smooth animation, while conserving your device battery at the same time.


Optional pack, Sea Life Pack, is also available for in-app purchase to make Ocean Blue 3D much more exciting with more sea life and customization such as butterfly fish, tomato clown fish, manta ray, sea turtle and many more. Try it out now!

Download Ocean Blue 3D Now!

Ocean Blue 3D demo on YouTube

I think for now I'll just disable most setSortOffset. Seems like not much different as the object that fills up most screen is using simple fragment shader.

Thanks alot for your help ; )

QuoteIn Config, there's a switch called stateOrientedSorting

What will actually happen if I disable this, other than it's sorting by depth? If enabled, in what state it will sort?

QuoteHave you tried not to do this deferred thingy at all? I don't think that it will help on anything but Tegra chips anyway.

Last time I had a custom fragment shader which process alot of stuff (opaque object) and it's at the background. For some reason, it is drawn first rather than other objects at the front and performance seems to slow down alot. Then I tried setSortOffset and it helps improve by 5-8fps. Tested on samsung s4, I think it's octa core with PowerVR chip.

Just something we discussed earlier http://www.jpct.net/forum2/index.php/topic,3956.msg27790.html#msg27790. CMIIW, if one opaque object A overlaps another object B, the part of B overlapped by A can be deferred and not required to be rendered. So this way we can save more fill rate. That's what I intended to do by using setSoftOffset(). Does it mess up with rendering? Maybe I have overlooked other factors?

Yes I'm using setSortOffset. I tried to disable all setSortOffset and strangely, it has cut off for first few frames, then it becomes ok after that. But if I disable setSortOffset, it would tend to draw object further away from camera first, in which it does not take advantage of deferred rendering. If we are to take advantage and reduce overdrawing, we should draw the front object first, then follows the back objects, right? That's how I use setSortOffset to achieve that.

col=max(col, vec4(0.0, 0.0, 0.0, 0.0));
Tried and it's still have the same issue.

I tried to reorder the way of adding objects to world. By adding the transparent object (suppose to be in background, further away from camera), then adding the blue objects (closer to camera) after that, and it works now! I'm just curious if the order of adding object to world will affect the rendering. Do you have any idea what's going there?