Hey guys. Just question - how to automatically generate LP positions?
i have HUGE levels...
1) regular grid + tetrahedral tessellations - out of memory
2) adaptive octrees like inside ATI'S paper - too slow building for g_dwMaxOctreeSubdivision > 6
dunno what to do...
You could try using some heuristic to place more probes where it matters. For example you could use navmesh or height above ground.
You could try using some heuristic to place more probes where it matters. For example you could use navmesh or height above ground.
what if my player can fly ?
i would not want to be in any constraints because of LP..
i guess i have to throw LP away and perform raytracing with sky on CPU (just rays - top/left/right/forward/backward) for every object that is moving , to learn if object is under indirect lighting or not..
just occlusion factor = 5results/5 = 0...1
The initial voxel cone tracing stuff had realtime generation of sparse voxel octrees as a necessity, take a look at that stuff for hopefully much faster octree generation: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&es_th=1&ie=UTF-8#q=sparse%20voxel%20octree
Sparse octrees are close to suiting light probe placement, thought not perfect. Some hacks would probably get you there, or hopefully just give you an idea for speeding up AMD's technique. You could also LOD out lightprobes to the bigger voxel sizes as your player gets farther away, a kind of cascaded detail for light probes. Probably have to be careful how you blend in new, smaller voxel/higher detail probes though to avoid light popping.
i guess i have to throw LP away and perform raytracing with sky on CPU (just rays - top/left/right/forward/backward) for every object that is moving , to learn if object is under indirect lighting or not..
just occlusion factor = 5results/5 = 0...1
My appologize for going OT here - but this one needs a comment
Note that this will be quite slow unless you have some kind of hierarchy in which you store your scene (and you're back to beginning - it can be Octree, KDtree, BVH, BIH, etc. - you will still have to build it (or pre-compute it for static scenes). Also note that you will get your results per object, which looks acceptable only for small objects.
E.g., you might be able to test 5 rays for some higher number of complex objects in scene without hierarchy but it will look bad (you could accumulate occlusion over time - but moving objects would blink) - e.g. you will need more rays (more samples), and so your performance will drop (a lot) - which implies the need of hierarchy for scene (this can accelerate the ray tracing process).
Hint. You could use short rays for computing occlusion (even though it won't be global then), with good hierarchy (read SAH KD-tree, Split-BVH, etc.) this gives you ability to compute tens of milions or even hundreds of milions rays per second on todays hardware.
