3D 3d characters in theory

V

Vikom

Guest
Hi!
I'm making a research and preparations for my next project.
What's a good way to make a 3d person?

An year ago, I was making a 3d project, where people were already present. I've abandoned it for a dumpload of amateur solutions. I wasn't using models, for example, so there were problems with performance.
In that game, I made a person using several primitives. Then, the person had coordinates for their arms, legs, so they were moving, depending on the coordinates. The body didn't look good and because of avoiding models, they were unccessairly slowing down the game in bigger numbers.
http://www.indiedb.com/members/vikom/images/razor-sharp-new-graphics#imagebox

Currently, I'm thinking about different solutions but I haven't came up with anything useable. Is there any way to connect a model to a skeleton? (Without using anyone else's asset. I like having my own stuff)
 
M

MishMash

Guest
So, the fundamentals behind a skeletal animation system simply boil down to the following:

- A regular 3D model where each vertex has added properties to specify weighted attachment to bones using the id of the bone and then a floated weighting. A quite common approach is to allow for a vertex to be weighted by up to 4 bones, and their total weightings per bone add up to 1.0.

- A skeleton structure which is often presented as a hierachical tree structure, where you have a root bone and each subsequent bone has a parent bone it is attached to and affected by. (So if one bone rotates, all its other subsequent bones also rotate)

- A system for storing animation key-frames. This is simply a mapping of bone ID to a given position/rotation.

- An animation system for interpolating between given animation key-frames by a % amount and determining a resultant bone rotation

- A shader for re-mapping vertices from the default position to the position of the currently interpolated animation. In this case, a vertex shader which takes in the model with a custom vertex format (using the per-vertex bone id's and corresponding weightings) and then you would also have the skeleton array passed in too, and you would then use all of this information to move a vertex to its correct position.

You would likely want to use some pre-existing model format, because manually mapping vertices to bones is a pain. I will mention that this is quite tricky to do, and especially hard to do efficiently. Depending on how much use you need out of the system, you might be better off using a more simple solution rather than going for full on skeletal animation.
 
V

Vikom

Guest
Thank you for your answer.
That really sounds quite complicated. I think I understand it in theory but I have no idea how to reach it in Game Maker. (where to start etc.)
So, what do you suggest? I don't feel like having "Minecraft characters" in my game.
 
V

Vikom

Guest
Thank you. His work is amazing.
I took a quick peek into it. It's too advanced for me. I saw some matrixes and shaders, I have no idea how to work with them in GM. I'll seek for other options. In case of no success, I'll make a research how to use this.

Also, I'm a little worried about a "licence". I make games primarily for fun and self-satisfaction but this should be something bigger, so I'd like to make it commercial. I don't know what are the condition of use. I'll eventually ask him.
 
V

Vikom

Guest
You're the man!
Thank you. In that case, I'll start the research right now.
 
E

elementbound

Guest
Another, conceptually much easier but also ( probably ) less efficient solution is to just treat your 3D characters the same way as sprites in 2D - for each frame, have a separate model. Keep in mind though, that this has several limitations:
  • Animation can be chunky[1] ( can do vertex interpolation but that also needs shaders )
  • Added loading time ( you have to load 30+ meshes instead of one + animations )
  • More space needed ( see above )
  • Can't programmatically animate limbs ( for example aim with the torso or just have his legs run and arms aim )
However, if the above are not a problem, it's a lot easier to manage. Also, it should run faster because you don't have to run that many calculations[2].

My workflow is doing the animation in Blender, batch-exporting every frame as OBJ, and then loading those on startup from GMS. Reading OBJ files also adds a lot of loading time, so I would advise using a binary format, or possibly even just exporting the created vertex buffer as-is[3].

[1] - Or you can export at a high framerate, that adds significantly more meshes to load
[2] - You can technically cache the skeleton at each frame, adding a bit of precalculation but having less to do while the game runs.
[3] - Not sure if this is cross-platform or even a good practice.
 
V

Vikom

Guest
Thank you.
Making a model for every phase also came into my mind but I don't like that idea.
I was thinking about a solution when every major body part is a separated model (torso, arm, forarm in this case). The arm keeps being drawn at the right place, relatively to the torso, and it also can rotate itself. The forarm keeps being drawn at the elbow of the arm. It shares the arm's rotation and it also can add its own.

I'm not sure about reliability of the placement and about the performance. It would probably need many caltulations.
Or... I could combine theese two ways. Now there's only torso and a combination of the arm and forarm. It behaves as the arm, mentioned before. There are two models, a straight arm and a bent arm.
It won't be too chunky, a risk of the misplacement would be much lower and the number of calculations would be more than halved, I guess.
 

Smiechu

Member
In my opinion a hibrid would be the best...
You can have one skeletal model, but the positions of the points would not be calculated but stored in an array or some ds for every frame of animation...
This way you skip heavy calculations, and have only one model...
Additionally a simple interpolation algorithm could smooth the animation...
 
V

Vikom

Guest
Yes, I also got quite happy about that solution. I'm really glad for all the suggestions that appeared in this "brainstorming".
Can you describe it more precisely, please? I was never working with ds (so I don't know how they work) and I'm not sure about the way you'd use the arrays.

My idea was something like...
The body as one "instance" rotates with the image_angle.
It is divided into 6 parts... torso, head, 2 legs and 2 arms. The legs and arms have 2 phases - straight and bent. (maybe also more interphases)
There's one main coordinate/origin - a pelvis. The torso's pelvis is always at the coordinate. The pelvis can change height (for example sitting) and the torso can change pitch (e.g. laying).
The legs have origin it their most top part. They can change pitch and phases (steps, sitting...). The arms are same as legs but their location to the torso has to be counted because of the torso's pitch. The head can rotate to the sides and its location is also defined by the torso's pitch.

The pitch would be done using "destination". For example: the leg's pitch is 0 and the destination is 90. This move should be done slowly, so for every step...

if pitch < destination then pitch += 2;
if pitch > 45 then phase = "bent";

This is quite similar to what I did year ago and I was happy with that because of no need of actual animations.
Maybe it's a bad solution of the movement.
Any opinions?
 
Top