Recently I made a 3D dashboard with four forks. As we all know, the existing well-known dashboardAlgorithmIncluding clod and roam, but these algorithms are generally abnormal in that each frame must change the vertex data. For direct3d, the locks are inevitable. Although dynamic memory can be used to increase the speed of the locks, the dynamic rendering speed is relatively slow. In a word, these algorithms are not suitable for the current hardware architecture, that is, the bottleneck lies in the architecture of the AGP memory, or, more specifically, the bottleneck is the architecture of the lock and memory.
The interlockingtiles algorithm provides a simple implementation. The essence of this algorithm is to fill in vertex data at the beginning, and then stop moving. The change is only the index data. For example, if 9x9 is used as a tile at the beginning, the vertex data of a tile is 81. Then, 9x9 has four levels of dashboard: The 9x9 is painted as one. 9x9 is painted at intervals of 5x5, followed by 2x2 and 1x1. In this way, you can create an index table for each of the levels. However, since we know what it is, we can also compile an index table for the connection part.
In this way, all vertex and index will be established at the very beginning, without the need to lock the memory and perform vertex operations.
More about this algorithm in gems2, which will be provided laterCodeAnd 9x9tile, 17x17, and 33x33tile are used. For more information, see.
Interlocking tiles part of the code --
Only the relevant part of the code can be read as pseudo code.
The management part of the quad-tree is a little poorly written, so you just need to check the part of the dashboard.
Http://noslopforever.blogchina.com/inc/code.rar