Real-time 3D terrain engines using C ++ and DX9 translation 7

Model Resources
The cmodelresource class may be the most important class we will use. It is of course the most frequently used resource. This resource class is a complete container Based on the d3dxframe Hierarchy Tree. Because composite nodes can carry these objects, cmodelresource can represent more than one physical object in the game. For example, a combat character may contain a complete animated skeleton, a masked skin and a clothing mesh, and a static model of each weapon or shield. Each mesh maintains a connection to the crendermethods and csurfacematerial objects at a time, so that the cmodelresource object is a complete entity in our engine, not just a ry.
As mentioned earlier, we use the d3dxframe hierarchy to complete this storage. These objects are described in Chapter 2 "Fundamental 3D objects" and can be used as an ideal storage method for skeleton animation and skin mesh. A major feature of d3dx's implementation of these structures is that they are user-scalable. By deriving from d3dxframe and d3dxmeshcontainer, we can add our own platform-specific data to the top of the accumulated data.
This is important because it allows us to mount our custom resources, ceffectfile and csurfacematerial. This converts the mesh of the simple single-texture packaging provided by d3dx into a HLSL-colored, texture-compliant database. To use these extended classes, you need to create a d3dx interface to manage nodes at the frame level. However, the first step is to declare our new data type. Listing 4.6 shows our extensions for d3dxframe and d3dxmeshcontainer.

 

The addition of the d3dxframe base class is minimized. The build layer level d3dxframe_derived object is allocated to a fixed array. Therefore, even if we use a tree structure to use this data, we can naturally use it to identify each node with a unique index in a linear array. We can do this because we can assume that our d3dxframe_derived tree cannot dynamically change the size and order. Once a hierarchy is loaded, it maintains the same structure for the rest of its life.
To provide more family maintenance information than d3dxframe, we can use index values in the array where they are stored to identify any possible parent and root objects. Frameindex is the root node of the entire tree. Prentindex points to the previous parent node of the node. Use-1 (the word value is 0 xFFFF) to identify unused index values.
Why not use pointers? The data is intended to be referenced. The conformity examples of this course model can be put in our world, and each has its own d3dxframe_derived structure set. These unique structures will contain the transformation matrix of each instance of the frame node. It is easier to create a new instance for this model by storing the family information instead of the pointer as the index value, just assign a new array to the Framework object and copy the data. Negotiation is not allowed because the index value is related to the root of the array storing data.
The d3dxmeshcontainer_derived structure is more complex. At the top of the d3dxmeshcontainer base class, we added all the data unique to our engine. This includes the crendermethods and csurfacematerials linked lists used by a grid, the grid skin information and the grid itself. We store our own d3dmehsdate structure separately from the one contained in the base class, in this way, we can separate the models in the system memory from the maintenance of the models that our rendering method will use and load into the memory.
In addition to allowing us to expand the accumulation, the d3dx function that provides file I/O for the Framework tree can also be extended to provide our custom data. This will create an interface that extends the format of the direct3d X file to meet our needs. This requires that we create three key interface classes: one responsible for allocating and destroying our data structures, one responsible for storing these structures in X files, and the other responsible for loading the data from X Files.
These three interfaces are provided in d3dx id3dxallocatehierarchy, id3dxloaduserdate, and d3dxsaveuserdate. To increase our own data, we simply derive our classes from these interfaces and provide implementation for the pure virtual functions defined in each base class. The d3dx_frame_manager source file on the CD shows these functions. These files show details about allocation, clearing, and file I/O better than we want to use text.