Software Point Cloud Renderer

http://bit.do/dMphP Extenua secret sale page.
Wrote this about 2 years ago - back when Unlimited Detail was all the rage. Really simple software rendering a Octree. Traverse Down the tree until Node size is roughly one Pixel (approx or Size/z for this) - render node. Just storing normals in the octree - no colours as such. Uses a huge amount of memory - can probably be compressed in a variety of different ways ( reuse Tree nodes/rle compression, run length reuse, variations on ezw compression e.t.c.). Looking at the earlier UD stuff - seems they had colour compression issues - you can see very limited colours - probably a compressed colour palette system on there earlier videos? ( I noticed the very latest vid they've done - has really vibrant colours - so I guess they've sorted the colour encoding). In this demo the Mouse uses 16mb of raw octree data ( 14 Node levels I think - could be wrong because I can't really remember) - it doesn't look very detailed - but it is, that's just the sparse polygon model. Think I'm rendering 128x128 grid of mice - each one with 14 levels = 16384x16384x16384 node grid? I'm renderering the Mice individually and not part of a tree. It's deceptive since you'd think rendering 128x128 mice would be dead slow - but because of the LODind nature of the octree render only the near mice are detailed - the distanced ones are extremely quick to draw. Running on a 2.4ghz core duo - 1 thread 1280x720 - 60 fps. I didn't bother scaling the nodes if they have no children - hence the gaps if you get too close. Did some thinking and you can store a "conic normal" in each node - which is basically a mipped normal - it's a normal and a scalar representing the total angle coverage of all the child node normals. This can be used to backface cull nodes - and get the draw time faster - it works really well, very cheap calculation in the render loop. The algorithm is completely memory speed/cache bound - needs a lot of work to get the octrees access patterns cache coherent. Needs a lot of work to get the Colour encoding compression reasonable, and tree compression fast. These two things make it quite a bit of R&D work. It's completely static, Adding objects directly into the Octree as it stands is a complete no no, there is some research work out there on this but it requires a different tree structure. Animating the tree is possible using standard matrix bone weights - there's a paper/vid out there on this - I think it could fit into the integer nature of the renderer, but would be limited on how far you could deform nodes. No demo for this at the moment, and I'm not working on it nor will I pursue it further- because of the static nature of the thing along with lack of lighting - I kind of think it's dead end tech really. The cost of a GPU which could totally floor (in terms of lighting) this tech is peanuts - compared to the cost of the CPU required to software render it, with very limited lighting, along with the memory issues e.t.c. This tech does have one major advantage over polygons and that is the Data set required is Screen Resolution dependent. Meaning the lower the display resolution the less deep the octree needs to be. This in turn means for different platforms you can use the same base data set down to the required level. No more platform munging e.t.c. Just cut the tree data off at the point you need for the render resolution.