Hacker News Reader

Comment by agentultra | Hacker News Reader

The cascade approach is something I've seen in other voxel engines. I'm interested in why the author was unsure whether octrees are suitable for GPUs.

I'm looking forward to the slides. This game was a very interesting project and well worth playing if you haven't yet. I love how sometimes going off into the woods yields fruits. It goes against every bit of advice you come across as a programmer these days. Yet sometimes it's just what a project needs.

View on HN

I'm not the author, but I assume they are referring to the amount of conditional branching needed to descend a standard octree. However I bet there is lots of active research into GPU-optimized spatial partition data structures.

The data structure in the article is different because it only stores high resolution data for the area near the player. An Octree handles arbitrary distributions of high resolution data, so it is more powerful than needed for this application. I like it when insights into the problem lead to simpler algorithms.

Sounds similar to the clipmaps UE4 uses for signed distance fields:

https://docs.unrealengine.com/latest/images/Engine/Rendering...

https://docs.unrealengine.com/latest/INT/Engine/Rendering/Li...

In a proper implementation, the data diverges (which is relatively fine) but the code/program counter does not diverge (which is what you want to avoid).

There is nothing bad about Octrees on the GPU, but most people use BVH trees now.

I'm interested in why the author was unsure whether octrees are suitable for GPUs.

See this Twitter thread for discussion exactly about this (with Q-Games developers and original voxel cone tracing author):

https://twitter.com/Icare3D/status/803165198530052096

Reason #1: pointer chasing on cache impaired systems too costly

Reason #2: they simply run out of time for development (instead of giving up on SVO)

Reply on news.ycombinator.com