1. What is a scene object? What is the game scene?
All objects with spatial attributes in the game are scene objects.
The collection of all scene objects becomes the game scene.
2. In general, which content belongs to the scene object, and which does not belong to the scene object?
** Scene objects: players, NPCs, scene buildings, terrain, particle effects, props (weapons, etc.) in the scene, and some invisible objects such as volumes, cameras, etc.
** Non-scene objects: UI, on the UI Props, player (NPC) skills, player (NPC) status, collision box, object material
Personally feel that non-scene objects do not have a strict concept. Excluding all scene objects, everything else is non-scene objects. Or strictly speaking, they are not objects that we usually recognize, but pure game logic objects. For example, the player's state, he has no entity in the scene, but we can create a class object for the state to represent the state of a certain character.
3. The significance of scene management
- a. It is convenient for players to quickly locate objects in the scene
- b. Properly handle the memory overhead caused by huge scenes
- c. Dealing with rendering efficiency problems caused by huge scenes
- d. Dealing with the efficiency of collision detection for a large number of objects
Does 4.2D game need scene management?
Most of the games we come into contact with have a virtual game world, and players can change this world through manipulation. This world is a little more complicated, it can be like various large-scale MMO games (3D), this world is a bit simpler, it may be like Go in the video (2D, or like Super Mario). So no matter what kind of game, there is always a scene space (or a game world) to store game objects, this space needs us to unified management. In this way, we can easily and quickly find the objects we need during the game, and then do further processing. If there are a large number of objects in the 2D space, certain strategies can also be used for optimization.
Therefore, 2D games also need scene management.
5.2 The difference between D scene management and 3D scene management?
The problems faced are different: Compared with 3D scenes, 2D scenes generally have much smaller rendering costs and memory costs.
6. Questions about non-physical collision detection and optimization schemes
** Question: ** For a non-physics engine-based collision detection, we generally need to traverse the positions of all objects in the scene and judge the distance between them (assuming that the objects are all balls Type) in order to detect whether the two collide. Once the number of objects increases, the CPU simply cannot afford it.
** Optimization: ** Actually, we know that two objects that are far apart will not collide within a certain period of time. In order to reduce the cost of collision detection, we can divide the scene into N*N blocks, and then divide all objects into different blocks, so that objects between different blocks (and not adjacent) will not collide, so This reduces the cost of collision detection.
** Note: ** In fact, the logic overhead of a general physics engine is much more complicated than our unoptimized one, because it may have more and more detailed detection logic, but the physX engine will also use the GPU when detecting To improve efficiency.
7. Quadtree and octree
Two-dimensional space management and object detection can be processed using quadtrees.
The management of three-dimensional space and object detection can be processed by using an octree.
However, the relative cost of an octree is much higher than that of a quadtree.
These two concepts are actually not so advanced, and are no different from the data structure we usually learn, except that there are four/eight subtrees under each node. This kind of processing is entirely because these two structures conform to our logical detection ideas.
8. The optimization ideas for collision detection.
In fact, this is similar to our approach to search and sorting. N^2 is definitely not the optimal solution. At least we will think of data structures similar to binary trees and binary heaps. If we combine the actual situation of the spatial distribution in our game, it is not difficult to think of a quadtree solution. Of course, there should be other optimization ideas in theory, and bloggers have not studied in depth for the time being.
9. About the optimization of field of view rendering
Similar to the real world, we cannot see things that are wirelessly far away, or things that are infinitely far away are almost invisible. Therefore, the players in the game world are similar, each player's field of view is limited to a viewing cone. This is very important for game optimization
- a. In terms of rendering, because things are not in the field of view, we can completely skip rendering, that is, rendering culling
- b. In game logic, because the player's field of view is limited, scene data that is too far away can be completely omitted, that is, the scene is dynamically loaded
- c. For things that are in the field of view but far away, we can change him to a model with lower accuracy, namely LOD
10. Entrance management
For games in some rooms (the scene is relatively small), the player's field of vision is limited to only one room. At this time, anything outside the room does not need to be loaded and processed (if it has nothing to do with the current game logic). In
this way, we can load other room scenes when the player switches rooms (such as opening the door). This is optimized for the game Very helpful.
11. Realization of game sky
** Sky box: Use a complete enclosed space to surround the entire game scene, and paste the sky effect texture on the surface of this space. Generally very large, larger than the actual game field, close to the limit of the player's field of vision.
** Sky box composition:
- Atmospheric color layer
- Clouds
- Celestial body
- Vision
12.
As mentioned earlier in LOD , players can't see the details of things in the far field of vision, so there is no need to render such complicated models (textures, etc.) for them. LOD is based on this principle to dynamically switch resources (high-precision resources and low-precision resources) based on the distance from the camera position, which is a commonly used rendering optimization method in games
13. Terrain processing The terrain in the
game scene can be said to be second only to the size of the sky box. Unlike the sky box, the distance between the player and the terrain is very close, so in general, the performance details of the terrain should be rich enough. But the problem is that if you give enough accuracy to all terrains, you need to take up a lot of memory, which is unrealistic, so the terrain should also have LOD processing, and the remote terrain does not need to be too fine. In addition, the large terrain in the game does not have a spherical shape. In fact, the terrain is just a patch, and the player only moves on the patch.
** Terrain production: ** Generally, the art is performed on the client side, and after the construction is completed, it will be stored in the map data information in the form of a height map.
** Height map: In fact, it is a two-dimensional table that records the height value (Z value) of each coordinate
** The processing method of terrain LOD: According to the distance, the visual contribution (the contribution of the slope is higher than the plane) is assigned different Accurate LOD model
14. Surface texture processing
Due to the large terrain area, under normal circumstances, a large number of textures need to be provided to show different effects at different locations. In order to save the memory space occupied by texture resources, and at the same time want to express a rich landform effect, it is necessary to use multi-layer texture blending technology. Only a few textures are needed, and a variety of different effects can be achieved by mixing with different weights.
15. Water The
previous rendering lesson briefly mentioned that water rendering is generally achieved through UV animation (normal map), but more realistic water also needs to consider reflection and refraction, and even
the interaction with the player . This requires further in-depth processing such as reflection mapping.
16. Vegetation
** Implementation method 1: **Record the position, texture, material and other information of each grass, generate a model of the grass when running, and merge the grass with the same texture into several groups.
** Implementation method 2: ** Record vegetation area, record vegetation map, material and other information in the area, set the density and variation factor of the area vegetation, and run to generate several sets of random vegetation.
Reprinted from the original link (please indicate if reprinted): http://blog.csdn.net/u012999985/article/details/79090524