HottBJ Exporter released, formerly Blender=>jME Exporter

User Code & Projects
1

With this beta release, 0.3a, The Blender => jME Exporter is rebranded to HottBJ Exporter:  Handy Object Transfer Tool, Blender to jME.



UPDATE:  Version 0.3b just adds documentation fixes, and support for Blender layers.

  Blender layers make it easy to model your character with weapons, but export with just the Mountpoints and no weapons.

http://pub.admc.com/misc/jme/hottbj-0.3a.zip

http://pub.admc.com/misc/jme/hottbj-0.3b.zip



UPDATE: I should have mentioned that users upgrading from blenderjme need to manually remove blenderjme* from their Blender scripts directory.  I just don’t have time to write an upgrade script.



Much work has gone into this release.  Here are bullets for what I think are the most significant changes.



  • Object orientations accurately reproduce the coordinate systems used in Blender, with or without automatic axis-flip to +Z-forward.  This facilitates intuitive coding of manual transformations and use of controllers on the jME side.

  • Allow usage of a Blender game property to cause the exporter to write any Blender Object so that it will be reconstituted on the jME side as the specified, custom Node subclass.  (Just create a Blender String game property named jme.implClass).

  • All Blender Game properties get saved as typed UserData.  This feature requires jME-side presence of the provided Savable maps.  This dependency will go away when and if these Savable Map classes get migrated to the jME trunk.  The distro contains a sample file, AppAttrNode.java, that shows how to access the data from jME.

  • Finally, as a consequence of faithful transfer of all sorts of object nesting, we've created the concept of Mountpoints.  This allows you to jME-runtime-swap non-deforming objects on skin&bone animated models, as exhibited below, and in Ashton's forthcoming video.





The hat here is puposefully offset and at an angle, to test proper transferral and behavior with complex transforms.  The hat is mounted directly to the head bone to prevent unnecessary skinning and to easily remove and don it.  (If you planned on swapping to other hats, you should use mount points as done here for the weapon).  The eyes are also mounted directly to a bone (could be used to aim the eyes).  The MountLHand node selected in the Tree is a mount point, which is just an Empty created in Blender in the exact position in which the left hand should hold a weapon.  The mount point position was set in Blender by parenting a weapon to it, but that weapon was not exported with the model, to allow for runtime control of weapon mounting.  (The Plane in the background is just because I used this same export to test other objects in the scene).


Here I am using the right-click menu of Modeler to attach another model, spear-jme.xml, to the mount point, while an animation (with both rotational and translational motion) is loaded.


The spear is loaded.  Note that the Tree shows it as a child of the mount point.  The protuberance on the spear is to show proper orientation.


Finally, I used DEL key to delete the spear, then mounted an axe in its place, in the same way that I mounted the spear.  Note in the tree that the axe is itself a nested model.
2
sbook said:

Great work though, this exporter is coming along nicely.. it motivates me much more to do some work with Blender so i can finally try this out


Definitely give yourself a few days to go through some Blender tutorials and get familiar with it.  While it's rather intimidating at first, once you start to understand how it works and what keys do what in specific modes, it's actually quite easy.  The learning curve to intuitive use is somewhat like that of Vi or EMACS (if you've ever dealt with those text editors).  And, once you've done that then you will have the base tool necessary to use jME's only export/import system that takes mount-points into account up front and features a slew of many other handy functions that you will be impressed with. 

**Unattached and Reattached hats to Blaine!!!***
3

Here is a demo vid showing the mountpoints in action (pardon the untextured model).



http://www.youtube.com/watch?v=u8f5_2fZQWw



What you are seeing is:


  1. Some animations without a weapon


  2. Attachment of a weapon in the right hand mountpoint


  3. Animations with the weapon in hand that show rotations and translations


  4. The "sheathing" of the weapon and the changing of mountpoints from right hand to left hip


  5. Animations that show that the sword has been transferred and that it has a new parent to follow


  6. Variations on 1-5
4

Quite positively awesume.

5

Nice  :smiley:

6

oh boy, I wonder how many false hits "HottBJ" is going to get from youtube :wink:



Great work though, this exporter is coming along nicely… it motivates me much more to do some work with Blender so i can finally try this out

7

http://pub.admc.com/misc/mpplay01.jnlp



(ASIDE for 0.3a users:  See the “UPDATE version…” paragraph in the original announcement post below.  0.3b is available now).



Requires Java 1.6.

You don’t need to enter any user name or password.



This is a bare bones model.  I don’t have time to spiff up the demo.

There is only one mountpoint, and I am supplying only two weapons.

You can mount your own weapon models, but they have to be modeled (or wrapped) according to my own orientation , positioning, and scale convention.

Click the “dirs” toggle to see little directional arrows (X=blue, Y=red, Z=green).  Click in background and / (slash key) if you want to compare to game world coordinates.



You can mount my weapon models in 2 ways.


  • Download the files to a local directory, then use the mount button to open a file chooser.

  • Click the "net" toggle, then use the mount button and paste a URL



Weapon models:

  • http://pub.admc.com/misc/jme/mountpoints/spear-jme.xml

  • http://pub.admc.com/misc/jme/mountpoints/axe-jme.xml



Notice that the model is reconstituted as a custom AnimalNode class.  As explained in the release announcement, the only extra Blender-side work was setting game property values.  (One property to specify the implementation class, one other for a game-specific setting).

Use the Tree widget to see how the weapons attach under the mount point.

You don't need to explicitly "unmount" unless you want the avatar empty-handed.  If a weapons is already mounted, a new mount will just replace the first.

Static poses works like crap.  com.jme.animation was never intended to support static poses.  I want to work on that, but I also have about 30 other things I want to work on.

You will see that the blade of the battle axe slides.  As documented in the hottbj online help, this is most likely due to a com.jme.animation bug.  I could have joined the parts into a single axe object and avoided the problem, but wanted to show that, though jME has a problem, the exporter exports the sub-nested object properly.
8

I re-did the frame number management in BoneAnimation, for purposes not directly related to this topic.  Nevertheless, with this fix, the static poses that I complained about in this Topic work great.



Static poses will work correctly in the Webstart distro of Modeler the next time I publish an update of it.

9

Just saw this cool announcement announcing a really neat model released under CC license:

http://www.blendernation.com/2009/07/17/george-rig-10/



Hope it might be of use.

10

See http://www.jmonkeyengine.com/forum/index.php?topic=11700.msg89310#msg89310 for updated version.





Demo has been updated, benefitting from several jME fixes and enhancements I’ve made recently.  The demo now also demonstrates some newer features which you can read about in later announcement topic(s).



http://pub.admc.com/misc/mpplay02.jnlp



Please read the earlier post in this topic about how to run the demo and swap weapons.  All the different animation repeat types, and static poses should work reliably now.  Unfortunate, the axe-head slippage is still there, and is even more annoying when everything else is working so nicely.

11

Hi…  (been a while since last time here)

this is mostly a kudos, encouraging post.  :slight_smile:

i think is the way to go: blender is evolving at crazy speed, becoming really solid. I know the tool quite well, and have some experience rigging and animating with it (and with max and other tools)



But been to your project depot and found there a 0.4 version. Was able to read some parts of the doc for the exporter. Is very well detailed, but I see a problem. By statistic, even very experienced artists, you loose them when they need to aply too many constraints. (not blender rig "constraints" but the general specs you mention) . That is, while most ppl wth some experience (as I have) needing to export with a last ctrl+a hit, will do ok. But when is needing not scaling the bones, and several bunch other constraints…besides certain level of flexibility in art production is caused, a lot of artists start to have too many probs -and thing is, of many, you wont even know, as they just will abandone it- and that's a problem.



Also, an issue not of the exporter, but seems, the engine, is , interpolation. have read that due to engine limitation, it only can be linear… And unless (heavy memory in both disk and cpu/ram if done so) one adds loads of keyframes, like one per joing and every 2 frames, the interpolation, hard worked if animation person is any good, and so key thing in any 2d or 3d animation, is not taken in account. the export of IPO curves, interpolation exact data, is key for , ie, keeping natural, realistic human motion. (already very hard to get in the artistic side)



The non allowed scale of a bone can be a prob: I may have understood terribly for thelanguage barrier, but every time you start an armature you start actually scaling. Not being able to scale a bone, and needing to play with its pivot or center to produce the thing…



I had a quite pleasant ,simple workflow experience just exporting as md5, in the very old past. True that who knows which version and branch of md5 importer was… And if engine probably did not support other than linear interpolation, it wasn't there, either…



But all in all, I say, is some comments because while I have no project on JME, not probably either in the future, I think the Blender route is a very safe bet, for many reasons…

Its UI issues with a percentage of 3D users, is gonna keep continuously reduced, specially with 2.5 and later iterations. I already have few issues handling full projects with it, even using it for texturing, to rigging, uvmapping, animation, export or render.



Hope am not attaching here too many critics, I do as would like to see it as smooth in a real pipeline as it desrves to be…



I know most are blender related issues, and that is pretty sure quite hard to code right now anything for it (they're improving APIs and stuff, also) , so probably what i suggest is some code tricks to polish as much as possible the user factor in dealing with the issues… am kindda freak kind of artist, and deal more or less well (but tend to use the exporter that offers less probs, at the end of the day) , but have the experience of supporting large numbers of almost noobs modelers, or veterans that actually como from comercial tools and  will not be able to deal with this kind of nitty gritties. the majority of the artists out there, imo, are not blender aces,  but ppl from Max, Maya, and Blender but not so savy (not in a big number)



Other than that, I think this and md5, collada, are the 3 main routes… (besides keep support for OBJ)

12
snaga said:

...  but I see a problem. By statistic, even very experienced artists, you loose them when they need to aply too many constraints. (not blender rig "constraints" but the general specs you mention) . That is, while most ppl wth some experience (as I have) needing to export with a last ctrl+a hit, will do ok.

Most of the constraints are gone.  Docs need to be updated.


But when is needing not scaling the bones, and several bunch other constraints...besides certain level of flexibility in art production is caused, a lot of artists start to have too many probs -and thing is, of many, you wont even know, as they just will abandone it- and that's a problem.


Blender chose to implement bones entirely differently from their other scene objects.  Consequently, scaling of bones is incompatible with jME scenes because transform inheritance does not work with them as transform inheritance must apply to all jME scene objects.  As there is no use case not accommodated just as easily by portable Blender features, I lose no sleep over it.


Also, an issue not of the exporter, but seems, the engine, is , interpolation. have read that due to engine limitation, it only can be linear.... And unless (heavy memory in both disk and cpu/ram if done so) one adds loads of keyframes, like one per joing and every 2 frames, the interpolation, hard worked if animation person is any good, and so key thing in any 2d or 3d animation, is not taken in account. the export of IPO curves, interpolation exact data, is key for , ie, keeping natural, realistic human motion. (already very hard to get in the artistic side)


You've convinced me.  Go ahead and complete the Bezier implementation in the com.jme.animation package.


The non allowed scale of a bone can be a prob: I may have understood terribly for thelanguage barrier, but every time you start an armature you start actually scaling. Not being able to scale a bone, and needing to play with its pivot or center to produce the thing...

You don't understand armatures very well.  Your beginning assertion and the consequent deductions are wrong.
13
blaine said:

Most of the constraints are gone.  Docs need to be updated.


Great to know. I suspected that as a possibility.

You've convinced me.  Go ahead and complete the Bezier implementation in the com.jme.animation package.


You should not expect that as much as I don't expect a coder to create models and textures of better quality than Unreal Tournament 3 ones, or Arkhan Asylum's.  I expect 'em produce some terrible programmer art, as much, (while there are very few brilliant exceptions), and I would never blame them for that.


The non allowed scale of a bone can be a prob: I may have understood terribly for thelanguage barrier, but every time you start an armature you start actually scaling. Not being able to scale a bone, and needing to play with its pivot or center to produce the thing...

You don't understand armatures very well.  Your beginning assertion and the consequent deductions are wrong.


That I don't.... what?
LoL. Have produced (I need to be a bit arrogant here) quite nice commercial quality models and its anims with blender, for shareware, commercial games. And worked several years in game companies (using Max, Maya, etc). I may not know sth bout armatures in an internals way, or coding aspect, but that definitely never got in the way to produce all needed, at good quality.

Bye.