Models with articulated sub-parts

General Discussion
1

Background: my present art path uses Wavefront OBJ/MTL files.



My game has battleships, and my present way of supporting a ship that (say) has 4 turrets with two guns each is to have three .obj files:


  1. A hull with no turrets or guns
  2. A turret (without guns), whose center of rotation is at the workplace origin
  3. A gun barrel, whose trunnion (the axis of elevation) is at the workplace origin



    My code then loads up one Geometry with file 1, and then four child Geometries of file 2 which it translates into the proper position on the hull geometry so they can train about the Y axis. Each of these four turrets has two child geometries of the gun barrel, again translated to the proper place within the turret so they can elevate about X axis. This gives me a ship in the game that is 13 geometries from 3 meshes.



    My question is: is this the proper, editor-independent way to do this?



    The upside I see in my present approach may be that I have 25% as much mesh data for the turrets and 12.5% as much for the guns as I would think I’d have if these were in a single model file, and I do not have to investigate and learn how I would reach “into” a single Mesh asset and find the submeshes. Also, even if I can do that, would two sister ships in the game then be unable to use the same meshes?



    The downside is that the positioning and manipulation of these components becomes divorced from the art editing and intermingled with code. Artists aren’t really all that comfortable with their editor window now showing the asset components as they will be assembled in the game.



    Can anyone comment on the preferred method for doing this in JME3?



    tone
2

Damn. I saw articulated sub-parts and expected something else…

3

So let me get this straight the gun has turrets that spin right and you want to animate it? why go through all that, just have the turret be 1 piece and animate the barrels using either bones, or mesh deformations then you can play back that animation when the turrets are firing. That way its a lot cleaner, a lot less code, and may actually be more manageable.

4

I’m trying to keep away from animation for such purposes for the following reasons:


  1. I don’t know how to use it yet, and it does nothing that rotation and translation can do, both of which I use ubiquitously


  2. It seems to suggest that these behaviors (how parts move) are within the realm of study of the artists, which will not be the case.


  3. Asset-wise, It does not offer a solution where several classes of ship (different hulls) share the same type of turret. Which model file has the turret within it?


  4. My understanding of the asset storage and engine allocation of these meshes and geometry is that the turrets whose meshes are identical will be multiply represented in memory at runtime


  5. The more I ask of my art pipeline, the more I will find that some tools work and others do not. Art pipelines tend to be the most frail part of these projects. I’d really like not to say, “well, guys – we’re stuck until someone can fix this bug for us”.



    That said, I of course intend to use animation for avatars who walk about. In my view, that is precisely where nothing else will work and is the place where the above issues either do not apply (#s 1 through 4) or must be tolerated (as in #5).
5

If you just have a turret and cannon mesh and put both in a BatchNode you can move the turret “manually” by using setLocalXXX…