Originally Posted by
Kompromaus
NXT's rendering is very strange, very much unlike the Java client or any game engine. Have you heard of a sprite batch? (If you haven't, it's a way to emit fewer draw calls for 2D things, e.g. sprites [hence the name], by batching together draws that use the same state/resources). Well, NXT uses a similar technique... for the 3D rendering. A single draw call could be rendering a dozen trees, some doors, an anvil, and some grass. Objects, like players and monsters, are rendered similar. The calls are split by textures and material properties performed by shaders (which perform operations like wrapping modes, since all textures are stored in a few giant atlases).
I generate low-detail point clouds and perform fuzzy matches for animated objects, like monsters. To detect animations, I compare the current bone transforms (models are skinned on the GPU) with captured transforms. To match static objects, like anvils, I extract material properties and perform comparisons based on the materials. This is very slow; I manage 10-20 updates per second, and it has to be done in another thread. Some GPGPU stuff could speed it up, but you'll never reach parity with whatever FPS you have (except in simple, low populated areas).
A few cool things: 1) Items are rendered on the GPU and then cached [using their drop models], so if you compare model data, you can detect items that are visually identical very efficiently. 2) The minimap is a 3D rendering of the immediate area, but without elevation data AFAIK. 3) The coordinates are persistent between areas, unlike Java (necessary due to draw distance/seamless loading). 4) The GUI is rendered in such a way that I devised a high-level "reverse sprite batch" to efficiently match GUI elements.