Skinned Models in QS v0.19

Feb 27, 2008 at 3:06 PM
Hi! Great project!

I have a question about support of skinned models in QS v0.19. I've read something about a custom model class in a previous thread. Is it compatible with Skinned Sample code?

What about dynamic model class (for skinned models, with batching or similar) in any next releases?

Thanks!

Emanuele
Feb 27, 2008 at 3:35 PM
The released 0.19 version of the engine does not handle skinned models or any form of keyframed/skeletal animation. The custom model class that was mentioned is a replacement for the XNA Model class, and only handles static geometry. The next step will be the implementation of a skinned model class that will allow for skeletal keyframed animation, eventually with integration into the physics layer.

This is definitely on our to-do list and we hope to get some basic animation functionality within the next couple of releases. Unfortunately, everyone on the team is currently busy with non-XNA work, so there hasn't been much progress yet.
Mar 13, 2008 at 2:45 AM
@developers :
Don't forget to add support for separate skinning and animation, done with bvh files. You can find a working example at the idle Animation Component Library project
Mar 13, 2008 at 3:01 AM
What we need is a graphics programmer. :)
Coordinator
Mar 13, 2008 at 3:09 AM
Thought that was you Shaw :)
Mar 13, 2008 at 3:37 AM
I signed up to do physics and general performance tuning, I just kind of fell into graphics, physics, architecture, all of the above, haha.
Coordinator
Mar 13, 2008 at 5:11 AM
I hear ya, we definitely could use dedicated specialists, like a graphics programmer. It is much easier to focus on one specific sub-set of programming.
Mar 13, 2008 at 9:24 PM
The bvh file type Biovision once establishes is a little far fetched for a game engine.
Why?
Normally you get the mocap data all cleaned up from the mocap studio in whatever proprietary format you want to have it - 3dsmax, maya, lightwave whatever.
And then you start building your animation sets on top of that data within said 3d packages.
From there you export the model + uvcoordinates + animations into a file format your game engine can handle.

You 'd only need bvh support if you intend to use raw mocap data in your game. Which is not a good idea in 99% of any case.
Mar 17, 2008 at 8:05 PM
For now, i've implemented a simple DynamicEntity in QS "Core" based on fat XNA Model class and SkinningSample, not so great but it works... :P

Only a question: where is the best place for DynamicEntity rendering code and what exactly is the RenderChunk System in QS 0.19 (ok ok, two questions, i know... :P)?
Mar 17, 2008 at 8:21 PM
Cool! I'd love to take a look at it.

I think a skinned model handler would be more appropriate as a SkinnedModel class in the Graphics namespace. What I want to push for in the scene manager is a Model-View-Controller pattern (http://en.wikipedia.org/wiki/Model-view-controller). In a nutshell, scene node are no concerned with their graphical representation. A particular node may have a static model, a skinned/animated model, a particle system, or even no graphical model attached to it. For example, take the Player entity. It would contain a SkinnedModel instance that represents the player character's model and animation data, but only the graphics system (and the physics system) would be concerned with this data.

My point is: I wouldn't implement skinned animation as a scene manager component. I would implement it as a model class in the Graphics namespace. Use the StaticModel class as reference.

Regarding RenderChunks, they are renderable pieces of geometry that the GraphicsSystem processes while rendering the scene. Graphics components do not render themselves, they submit renderable chunks of data for the GraphicsSystem to render. While this may seem odd at first, it is an important concept for efficiently rendering complex scenes. A RenderChunk basically holds references to VertexBuffers, IndexBuffers, and all other information needed to render the geometry.

Once you have something put together, feel free to submit a patch!
Mar 18, 2008 at 11:11 AM
Edited Mar 18, 2008 at 11:16 AM

shawmishrak wrote:
Cool! I'd love to take a look at it.

I think a skinned model handler would be more appropriate as a SkinnedModel class in the Graphics namespace. What I want to push for in the scene manager is a Model-View-Controller pattern (http://en.wikipedia.org/wiki/Model-view-controller). In a nutshell, scene node are no concerned with their graphical representation. A particular node may have a static model, a skinned/animated model, a particle system, or even no graphical model attached to it. For example, take the Player entity. It would contain a SkinnedModel instance that represents the player character's model and animation data, but only the graphics system (and the physics system) would be concerned with this data.

My point is: I wouldn't implement skinned animation as a scene manager component. I would implement it as a model class in the Graphics namespace. Use the StaticModel class as reference.


Yes, i've followed the same idea so in DynamicEntity the XNA Model class is the replacement of StaticModel for the StaticEntity class. The best solution, of course, is to replace XNA Model class with an optimized substitute (i.e.: DynamicModel) with integrated skinning information (and management?? Encapsulated or in a separate AnimationManager?) ;)


Regarding RenderChunks, they are renderable pieces of geometry that the GraphicsSystem processes while rendering the scene. Graphics components do not render themselves, they submit renderable chunks of data for the GraphicsSystem to render. While this may seem odd at first, it is an important concept for efficiently rendering complex scenes. A RenderChunk basically holds references to VertexBuffers, IndexBuffers, and all other information needed to render the geometry.

Once you have something put together, feel free to submit a patch!


Uhm...So i must send dynamic geometry in a Render Chunk too, right?
Mar 18, 2008 at 3:25 PM
Edited Mar 18, 2008 at 3:28 PM
Everything that deals with geometry, animation, and rendering should be in the Graphics namespace. StaticEntity is kind of a misnomer, it's just a temporary test entity.

Right now, RenderChunks are designed around static geometry. I'm not exactly sure how this will be handled for skinned meshes, but there will need be a change to at least incorporate the bone matrices. If you have any implementation ideas for this, let me know.