Jump to content
  • Advertisement
Sign in to follow this  

skin mesh design need advice

This topic is 920 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

where should I store the vertex buffer, a big buffer in mesh with start offset in  submesh or 

some small buffer in submesh ? 

where should I store the skeleton, the bone? in the mesh or in the submesh?

Share this post

Link to post
Share on other sites

for static meshes i use a mesh memory pool, an array of structs with VB pointer, IB pointer, numverts, numtris, and is_active variables.


for skinned meshes i use D3DXMeshes. i turned tiny.cpp, the multiple animations demos, and parts of DXGI DXUT from the june2010 dx sdk into a stand alone turnkey skinned mesh library for dx9. i posted the code to one of my dev blogs here.




but its very common to roll-your-own solution for skinned meshes.  for example, D3DXMeshes have no easy way to share animations. You more or less end up with a copy of each animation in every controller that uses it.


when rolling your-own, you can do things like memory pools and sharing of assets, and reducing models and animations to just the data you need in your custom file format and data structures.


as for what that format should be, its up to you.  you might take a look at custom formats used in games or engines whose source is available online. or perhaps someone here might share their custom format layout and why they chose that format - what they need may not be what you need.


you could also use D3DXMeshes and AnimationControllers as a guideline. just add the capabilities you want (like animation sharing and binary file loading), and omit the stuff you don't need. note that D3DXMeshes support both text and binary files, but many tools don't support binary, just text, which loads sloooow....

Edited by Norman Barrows

Share this post

Link to post
Share on other sites

a memory pool is a chunk of memory used to store what usually amounts to some sort of list. an array or vector of structs is a typical implementation. the idea is you allocate once, then you can simply add and remove items from the list without having to reallocate (which is slow). 


so for example, i have an array of structs - a memory pool - for static meshes. each struct has an is_active boolean (true if the slot is in use), a VB pointer, and IB pointer, numverts, and num_primitives.  for sequential loads, i can track the first open slot, and just use and increment that. for non-sequential loads (IE asset paging from disk), i can simply add at first inactive. whenever i draw something, i put the index (ID) of the desired mesh into a drawinfo struct - along with all the rest of the drawing parameters like texture ID, scale, cull, alpahtest, location, orientation, etc - and send it off to the render queue, or a draw_immediate() call.


if i want to unload a mesh asset, i set the active boolean to false, and release the VB and IB. when i reuse the slot, i allocate a new VB and IB. i never have to deallocate or reallocate my list of loaded meshes, just individual VBs and IBs. and the fact is, right now i don't even have to page mesh assets, so i just do a sequential load at program start and that's it.


i use a separate memory pool for skinned meshes:

' ----------------------------------- skinned mesh pool API -------------------------------------------

st skinned_mesh_master
ID3DXAnimationController *controller;
LPD3DXFRAME headbone,rhandbone,lhandbone,urlegbone,ullegbone,lrlegbone,lllegbone,rfootbone,lfootbone,backbone;
D3DXMESHCONTAINER_DERIVED *body, *bra, *loincloth, *top, *cloak;


skinned_mesh_master skinned_mesh_pool[MAX_SKINNED_MESHES];

i num_skinned_meshes=0 

the frames for all the bones are so you can draw gear attached them - stuff like hair, clothes, armor, weapons, containers, etc.

Edited by Norman Barrows

Share this post

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

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!