The Design of Model (Part 1)

The Design of Model (Part 1)

For personal use only, do not reprint, do not use for any commercial purposes.

 

 

 

The engine has been designed for the past period of time, but it has some small achievements and will be sorted out in a few days. Let's start with an introduction today. ^_^

The first step is to define the model data. With the model, subsequent development is convenient. To put it simply, you need to create a model class. Maybe you will say that xNa or DirectX already has a built-in model. Why do you need to write it by yourself? If you have a little experience, you will find that the xNa built-in model function is very limited, and it is a sealed class and cannot be expanded. Almost all commercial engines have custom model classes (unfortunately, there are few articles about how to build an easy-to-use model class ). The built-in models of xNa and DirectX are only used to facilitate the writing of small games. This is not because Ms is not lazy and does not want to write a better model. As we will soon see, when writing such a class, there are too many choices and it is difficult to write a general template. Therefore, the solution designed below is not necessarily the best or most suitable for you (of course, hope is not the worst ), I just want to inspire you to design your own model. :)

To facilitate the discussion, we will first introduce some basic concepts and terms. A model is a logical unit composed of a series of ry, such as a person or a car. Most of the models we use modeling software such as Maya or 3DS MAX. When modelers build models, they do not create a complete model at once, instead, the entire model is divided into independent small units, which are created separately and finally assembled together. For example, you can divide a character into several parts: trunk, limbs, Head, and hands and feet. The smallest unit of this model is called a mesh part. It seems that such a subdivision is unnecessary at first, but if you want each part to be able to exercise independently, for example, the wheel must be independent of the body rotation, then you must perform such a subdivision, objects of different materials must also be separated. For example, the tires and internal metal rings must be divided into different mesh parts. When the modeling software exports model data, each mesh part stores vertices with its own local coordinates. For example, the trunk uses the center of the trunk as the origin to locate the coordinates of all points, the arm also uses the arm center as the origin to locate the vertex coordinates. This is why many people have loaded models and found that the models are stacked together. Therefore, in addition to the mesh part, you must use the bone to express the positional relationship between the model structure and the mesh part. In short, the skeleton stores the displacement or rotation relative to its parent node. Obviously, a single skeleton is rarely used. It is common to use a skeleton tree to describe the structural relationship between MESH parts. Taking the human body as an example, the trunk is the root node of the tree. The four branches represent the limbs. The upper arm has a subnode connected to the forearm, and the forearm connects to the palm and fingers. Obviously, to obtain the coordinates of the palm, you must add the coordinates of the upper arm and the forearm offset from the trunk. Of course, for some very simple models, such as a box, a mesh part can represent a model, and naturally no skeleton is needed.

When creating your model, consider at least the following:
1. How to save model data, vertex array, vertex buffer or vertex buffer + index buffer, drawindexprimitive for plotting, or drawprimitive
2. How to organize data, Triangle List, triangle strip, Or ???
3. The mesh parts that constitute the same model have their own vertex buffer, or are all the mesh Part Data packaged into a large vertex buffer, and each mesh part is differentiated by indexing?
4 are shared vertex data still separated for different instances of the same model?
5. Is it supported? If it is supported, in what way can we obtain the level of details, such as runtime computing or preprocessing? How can we achieve the transition of a single dashboard and how to save the data with a single dashboard? Can we use different dashboard of the same model as an independent model or encapsulate it as one? How can we control the level of detail?
6. What types of animations will the model support: Bone animation, key frame animation, and morphing? Does animation work on CPU or GPU?
7. Whether the model requires bones or deformation.
8. How to Handle Material information.
9. How to Deal with the box.
10. Is instancing supported? What type of instancing is supported?
..............................

When you really write an engine, there are more questions to consider, such as how to integrate it into the scene graph, how to crop it, how to render it, etc. If you ignore these important elements, there will inevitably be many problems in future development. Of course, it doesn't mean that you have to carefully consider the design of scene management, Renderer, and other systems from now on, but have a general understanding of how advanced systems use low-level classes in the future, this is exactly the Dependency inversion principle in OOP. All the problems in the previous section are implementation details. Here, we consider abstraction.
Here is an ideal Renderer example:

Foreach renderableobject in scene
If (renderableobject is visible)
Renderer. addobjecttorenderqueue (renderableobject)

Renderer. sortallopaqueobjectbydistance ();
Renderer. sortallopaqueobjectbymaterial ();
Renderer. sortalltransparentobjectbydistance ();
Render. sortallalltransparentobjectbymaterial ();

Foreach material in render. materalqueue
Material. Begin ();
Foreach opaquerenderableobject in render. renderqueue
Renderableobject. Draw ();
Material. End ();

Foreach material in render. materalqueue
Material. Begin ();
Foreach transparentrenderableobject in render. renderqueue
Renderableobject. Draw ();
Material. End ();

This is almost the simplest rendering process. For the convenience of discussion, I omitted most of the details. First, we get the object to be rendered from the cropping system. Next, in order to make full use of the benefits of early-Z cull, sort the solid objects in the order from the front to the back. In order to minimize the rendering status changes, sort the objects in the order of material security. For transparent objects, in order to get the correct rendering effect, they need to be sorted in the order from the back to the front.

Although this code is simple, it also shows some core concepts. First, all the rendered objects must have the same interface draw. Second, material should be encapsulated into independent material objects.
(To be continue ..............)

Er... no, no. Sleep, sleep, and the sky is almost bright. First sleep + _ + zzzz ......