Brahma is a 3D game engine with a rather retrofuturistic design, intended for small studios and solo developers. It's being written from scratch in C++ using standard Windows API and no third-party libraries. This technology introduces an entirely new class of low-latency real-time engines that make special timing requirements, treating frames as video fields with a target time budget of 2-4 ms each, down from 16-33 ms frame budgets normally seen in game engines. It evolves in a different way than other modern engines, rejecting conventional BSP, Z-buffer, floating-point coordinates, and most of the lame screen-space effects in favor of innovative and efficient techniques. The engine is non-Euclidean capable to some degree; also it supports true displacement mapping for sectors as a means to virtualize geometry that affects collisions. The engine is also carefully designed to be easy and convenient to develop for, yet versatile and adaptive to any needs.
Recently I was prototyping the support for point clouds by my upcoming vector-specific BHG format.
Instead of storing explicit spatial coordinates for each point, my format will put point clouds into series of continuous strips. Each of them may contain several thousands of points filling some small area, with a constant distance step to each successive point. This enables for some differential coding of point positions by means of a lookup table of 256 unit vectors, that keeps the geometry information just to 8 bits per point, only the start point being left explicit. Dither of coordinates helps cancel out any accumulation of quantization error.
The normal vectors for each point could also be implicit, based on directions toward several adjacent points and some global hints to put a normal into the correct hemisphere. To ensure enough local path tortuosity, the points within a strip may follow a space-filling curve pattern such as the Hilbert curve.
The currently unresolved problems are efficient gap filling (including gaps between adjacent strips), back face culling, correct handling of overdraw without Z-buffer, automatized LOD management, convenient UV mapping, and reasonably quick collision detection.