D3DXLoadMeshHierarchyFromX issues

D3DXLoadMeshHierarchyFromX issues

• Jimig

  I'm not calling the functions in the ID3DXAllocateHierarchy object myself. I let D3DXLoadMeshHierarchyFromX do all the job. What I'm saying is that before the D3DXLoadMeshHierarchyFromX function starts using the ID3DXAlloaceHierarchy object I give it there's a huge memory spike. So internally in D3DXLoadMeshHierarchy code somewhere there's something that causes a 400MB temporary jump in memory, while it should be only about 20-30. The reason I know it's like this is because it hasn't started using the ID3DXAllocateHierarchy object. This I've verified through both using the visual c++ debugger as well as simple debug output. If you want to see this 20-30MB jump for yourself simply run the MultiAnimation.exe file in the sdk, but make sure you turn on fast update in your Windows Task Manager because in that example it happens really fast and if the update is too slow it won't even show.

  It runs perfectly fine on one computer with the same type of behavior in memory leaps as in similar directx sample code, yet on one computer the memory leap is just incredibly high. So it does kind of look like there's a bug inside D3DXLoadMeshHierarchyFromX function or this is a symptom of a what's really a different problem...But closer than this I can't really get since I don't have access to the code inside D3DXLoadMeshHierarchyFromX.

  /Thomas

  
  

• Johnny P

  Your call to D3DXLoadMeshHierarchyFromX tell the function to call the Allocation class function to open the necessary space for Frame and MeshContainer,
  Your call to this function will use this class allocation by itself you don't need to call it after...there is no preparation period, you never call yourself the allocator class
  The function will do this for you...Once you defined the allocator class the call to D3DXLoadMeshHierarchyFromX will do all the job, there is nothing to do after this call...
  
  
  ================== taken on the net :

  Now that we have the more fleshed out structures lets look at the pAlloc parameter of the D3DXLoadMeshHierarchyFromX function. As I said earlier this is a pointer to an allocation class that handles all the creation and deletion of frames and mesh containers. The only problem here is that LPD3DXALLOCATEHIERARCHY points to an abstract class that is not defined only prototyped. The good thing is that we do not need to call any of the allocation class’ functions in our code. The functions that use the allocation class will call them all for us. So, let us derive off the ID3DXALLOCATEHIERARCHY object and create the class for ourselves. The allocation class should look like this.

  http://www.gamedev.net/reference/articles/article2079.asp

  
  

• antonioa - msft

  I am currently experimenting using Tiny_anim.x, but the jump in memory isn't only restricted to my code, it happens in the MultiAnimation.exe with exactly the same jumps in memory as my program does on the 'good' computer. Only difference is that the MultiAnimation.exe program also works fine on the 'bad' computer without getting 400MB worth of memory jumps.

  I may have been a bit unclear about the memory jumps so allow me explain it a bit further. When the function D3DXLoadMeshHierarchyFromX( ... ) is called in my program it starts up a whole .x file loading process behind the scenes. Once the loading process is complete it will start making use of the derived ID3DXAllocateHierarchy object I supplied and starts calling the CreateFrame() and CreateMeshContainer() functions based on what the .x file contains. For reference lets call the period between D3DXLoadMeshHierarchyFromX( ... ) is started and until it starts making use of the derived ID3DXAllocateHierarchy object the 'preparation period'. It's during this preparation period that the jump AND reduction of memory occurs. This jump is roughly 20-30MB on the 'good' machine and 400MB on the 'bad' machine. Since I don't have access to see what goes on behind the scenes I can only guess at what exactly is done. I would assume some temporary buffers are created for various manipulations and preparation of the data read from the .x file that then get released once complete and the process is ready to start using the functions in the derived ID3DXAllocateHierarchy object.

  Currently I'm in the process of comparing differences with some of the directx project example code to see if there's anything to find there and I'll most likely try to just paste in microsoft example code to see if that makes any difference.

  /Thomas

  
  

• Cha Chunchadatharn

  If you can find the SDK 9c of october 2005 there is a utility source code for mviewer.exe
  
  This utility contain the function you use to load your skinmesh
  and describe in detail all the loading function
  
  Allocate will be call recursively for each frame and those contain simply one small matrix (frame=bone=matrix, and your skeleton should have like about 40 of them)
  Your skinmesh mesh, material and effect are actually in only one of those frame
  Maybe you open a huge mesh for each frame
  
  It seems very exessive to use 400 Meg of memory, even 30 meg

  Tiny_anim.x is 2.5 meg, and it contain 4 animationset
  And normal skinmesh only open one texture in memory
  
  If you open a huge size of memory with a bad ''new'' call
  at each of the bone/frame you might use too much memory
  

  
  

  
  
• D3DXLoadMeshHierarchyFromX issues