This is not generally done in this manner. A level editor allows artists/designers to place objects at locations of their choosing. Restricting those locations to bones is not the way to go, since adding a bone and re-exporting the level for every object in it is definitely a waste of time.

You have basically reached the limitation for the usefulness of bones.


L. Spiro

Does that sound ridiculous?...

not at all. I've been working on quite some games that were also storing non-visual data in the mesh file to hint for further processing. Although it's a little bit abusive, it also has quite some advantages:
- artist have a stable tool that they're used to and they rather set a bone in their tools than starting up a custom tool to set the 'bones'
- you save the time to create a redundant tool
- better work flow, as artist can load and change a visual mesh, that contains that extra data, if you have a custom tool, you either need to implement a way to merge new visual data with old setups in your tool, or artist need to setup a mesh from scratch every time they make a change (which will lead to a lot of hated redundant work and also consideration if something should be 'fixed' or 'improved' at all, considering the time it costs).
- at our company artist came up with the idea, that objects could be skinned once in software and baked into the new position. that opened a lot of new possibilities, e.g. there were parts of walls that were modeled several times, you skinned or removed them when you instanced an object, that way you had a lot of visually differently looking meshes, out of just a few basic blocks (with full artist control). And we could attach more data, e.g. terrain deformation to a fence that was placed on the terrain.

and even some of those big, famous engines use that kind of work flow, so it can't be that bad.

For example I thought I might attach bone-nodes (parent = root node) to a whole static level mesh to store information about object-placement and game-logic.

You often add objects as links to your game world,i.e. to place some objects. These objects are often just empties (no mesh) when you want to incoperate it into a static mesh and bones only when you want to add links to a animated skeleton.

Simple examples:
In a level (=static mesh) you place empty objects for light sources, particle emitters etc., either you write a specialised exporter to transfer this objects into game specific entities or you use some kind of naming convention or other available attributes to identify them as game entities (depends on modelling tool and game engine).

An animated game character will often include a specific weapon-bone which is animated (i.e. when killed, the weapon drops in a specific way to the ground, independently from other bones) and does not deform the mesh at all.

When you say "empty objects", what sort of primitives are you talking about? I've tried doing something like this for bones in the OBJ format, (which doesn't support bones) by creating small cubes centered on where I need pivot points. My engine matches up these pivots to the objects they control by the naming system, ie: "B_Head" and "Head".

While I thought it was a good idea at the time, I really don't like it anymore and I've been looking at other ideas, but haven't gotten very far on this.