Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon


Home > Design >

4. February 2014

 

In my head this part of the process of creating a dynamically equipped character in 3D and rendering it to 2D was going to be a breeze.  Conceptually it went something like this...

 

  • Create a named bone in parent object where the weapon could attach.
  • Create a named bone in the child object where the weapon starts.
  • Find bone one, attach bone two.
  • Go enjoy a beer in smug satisfaction.

 

Sadly it doesn’t quite work like that.

 

There are a couple problems here.

1- LibGDX doesn’t have a SceneGraph.  A Scene Graph is basically a data structure that holds relationships in the world.  Essentially this is what scene2D actually is.  Well, LibGDX sorta has a SceneGraph in the form of Model, which is a graph of nodes that compose the model.  There however isn’t a layer above this for creating relationships between models.  This sadly means I can’t (out of the box) do something like myTank.attachObjectAt(turrent,(3,3,3));

 

2- Modifying bones in LibGDX doesn’t actually seem to do anything.  My first though was… well this is easy enough then, Ill just set the GlobalTransform of the child bone to the location of the parent bone.  This however doesn’t do anything.  I might be missing something here, in fact I probably am.  But I couldn’t get changes to a bone to propagate to the attached model.  This one is likely user error, but after playing around with it for a few days, I am still no further ahead.

 

3- Bones don’t have direction.  Well, that’s not accurate, bones don’t point in a direction.  Here for example is a sample hierarchy of bones exported in text readable format:

{"id": "Armature",
   "rotation": [-0.497507, 0.502480, -0.502480, 0.497507],
   "scale": [ 1.000000, 1.000000, 1.000000],
   "translation": [ 0.066099, 0.006002, -0.045762],
   

   "children": [
      {"id": "Bone_Torso",
      "rotation": [-0.498947, 0.501051, -0.501042, -0.498955],
      "scale": [ 1.000000, 1.000000, 1.000000],
   

      "children": [
         { "id": "Bone_UpArm",
        "rotation": [ 0.007421, -0.000071, -0.009516, 0.999927],
        "scale": [ 1.000000, 1.000000, 1.000000],
        "translation": [ 1.728194, 0.000000, -0.000000],

      "children": [
         {"id": "Bone_LowArm",
         "rotation": [ 0.999846, 0.012394, -0.000030, 0.012397],
         "scale": [ 1.000000, 1.000000, 1.000000],
         "translation": [ 1.663039, 0.000000, 0.000000],

      "children": [
         {"id": "Bone_Hand",
         "rotation": [ 0.999737, -0.016222, -0.000425, 0.016225],
         "scale": [ 1.000000, 1.000000, 1.000000],
         "translation": [ 1.676268, 0.000000, -0.000000]}
      ]}
   ]}
]}

As you can see, you have the Armature, which is basically the root of the skeleton.  It’s translation is the start location of the bones in local space ( of the model ).  Each bone within is therefore offset from the bone above it in the hierarchy.  What is lacking ( for me ), is a direction.  As an aside, I can actually confer the direction using the distance between (in this example) Bone_Hand and Bone_LowArm.  This of course requires two bones on both the parent and child models.

 

Consider this bad drawing.

 

You have a tank and a turret like so, with the red dots representing bone positions:

 

Tankexample1

 

So long as your tank and turret are modelled with consistent coordinate systems ( aka, both same scale, same facings, etc ), you can simply locate the tank bone and offset the turret relative, like so:

Tankexample2

 

In this simple example, it works perfectly!

 

Let’s consider a slightly more advanced situation however. Lets say we are diehard Warhammer fans and want to add sponsons to the side of our tank.

Once again, by modelling consistently with the tank and sponson, we can get:

TankExample3

 

Yay future tank now looks a hell of a lot like the world’s first tank…  but this is pretty much what we want.  Now lets mount one to the other side of the tank.

 

TankExample4

 

Ah shi… that’s not right.  Our second gun is INSIDE the tank.

 

The problem here is, we can’t depend on the coordinates of the both models matching up anymore.  We need to figure out direction when mounting the new weapon to the tank.  This means we need a facing direction for the bone, and this is something we don’t have.

 

Again, this problem has proven trickier then expected.  I will share some of my failed approaches shortly as this post got pretty long.

Design

blog comments powered by Disqus

Month List

Popular Comments