• Advertisement
Sign in to follow this  

Using 3d models to store additional "non-visual" information

This topic is 2104 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I started using skinned meshes of .x-format a while ago. Now I understand I can use skeleton-bones for other purposes than just animating the mesh - like marking transformations for attaching child-objects or where the camera should be centered/positioned inside the model etc.

Now I'd really like to know how far I can take this. 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. Does that sound ridiculous?...

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
[quote name='Max Power' timestamp='1334492113' post='4931410']
Does that sound ridiculous?...
[/quote]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.

Share this post


Link to post
Share on other sites
[quote name='Max Power' timestamp='1334492113' post='4931410']
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.
[/quote]
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Thanks for all replies. Using bone-names to match the names of placeable objects was what I had in mind, too. But I guess, being a hobbyist, I might as well wirte my own editing tool for loading a mesh and adding all the extra data to avoid limitations. Out of interest though: are there any notable formats that are meant to store extra data and aren't too uncommon. I read about collada-files storing physical information, for example. I thought about using it for my PhysX-engine, only the graphics engine can't read the skeleton from it, so I will probably write my own "physical-properties" editor for meshes.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement