here is my take on this thing having also now watched the interview..

1. forget the "unlimited" bit... nothing in the universe is so just see it as just a "AWESOME AMOUNTS OF" instead, which is what he means methinks. so don't waste your energy on that, we all know its not actually unlimited. That is if you are taking the word unlimited to mean infinite.... but the two are different, unlimited could be the same as when another engine says it supports an unlimited number of lights.... which it true... the engine supports it.... your machine might just not be able to handle it (not a limit imposed by the engine but by the users computer)
either way I wouldn't get hung up on it.


2. he is the guy who came up with the technology and he was a hobby programmer, this could explain how he gets some terms wrong (level of distance??!) and why he may seem quite condescending... if he has no background in traditional graphics then that would make sense. His lack of knowledge of current methodologies is what I think lead to him going about it however he has done.

3. I am more and more thinking that this will lead somewhere and may indeed be the future of graphics (the guy who interviewed him was blown away) and from the sounds of it its only going to get better and faster

4. It still "boggles my mind"!!!

5. - 10. not included as I should really be working

I'd like to mention Unlimited Detail, a technology developed by Bruce Dell, which does in fact do exactly what he claims it does... Render incredibly detailed 3D scenes at interactive frame rates... without 3D hardware acceleration. It accomplishes this using a novel traversal of a octree style data structure. The effect is perfect occlusion without retracing tree nodes. The result is tremendous efficiency.

I have seen the system in action and I have seen the C++ source code of his inner loop. What is more impressive is that the core algorithm does not need complex math instructions like square root or trig, in fact it does not use floating point instructions or do multiplies and divides![/quote]

So it seems they are relying on some "octree like" data structure (as many supposed). What is boggling me the most is the fact their algorithm isn't using multiplies or divides or any other floating point instructions (as they say). Is there a way to traverse an octree (doing tree nodes intersection tests) only with simple instructions ? I don't see how (I only know raycasting, and it seems difficult for me to do this without divides, I know that other ways to render an octree exist but I do not know how they work).

it does not use floating point instructions or do multiplies and divides![/quote]

Integer arithmetic with shift operators?

it does not use floating point instructions or do multiplies and divides![/quote]

Power of two integer arithmetic with shift operators?

I'd like to mention Unlimited Detail, a technology developed by Bruce Dell, which does in fact do exactly what he claims it does... Render incredibly detailed 3D scenes at interactive frame rates... without 3D hardware acceleration. It accomplishes this using a novel traversal of a octree style data structure. The effect is perfect occlusion without retracing tree nodes. The result is tremendous efficiency.

I have seen the system in action and I have seen the C++ source code of his inner loop. What is more impressive is that the core algorithm does not need complex math instructions like square root or trig, in fact it does not use floating point instructions or do multiplies and divides!

So it seems they are relying on some "octree like" data structure (as many supposed). What is boggling me the most is the fact their algorithm isn't using multiplies or divides or any other floating point instructions (as they say). Is there a way to traverse an octree (doing tree nodes intersection tests) only with simple instructions ? I don't see how (I only know raycasting, and it seems difficult for me to do this without divides, I know that other ways to render an octree exist but I do not know how they work).
[/quote]

I'm not intensly familiar with SVO, but really, whoever you quoted above has no grasp of reality it seems. Not using multiplication and division does not make it impressive by itself, also note, the core algorithm. Meaning, going along a ray and traversing an octree. Going along a ray can be done using a variation http://en.wikipedia.org/wiki/Bresenham's_line_algorithm ... and holy shit! It doesn't use division and multiplication other than for precomputing some values! Bresenham's line algorithm sure is modern day rocket science it seems.

So, let's step back, and look at the problem... we have a RAY and an OCTREE, and our intention is to find the first node in the octree the ray hits, to get the pixel color... so:

1. Step along the ray using some algorithm (bresenham's line algorithm perhaps?)
2. For each step, check the corresponding octree node, if empty go to 1, exit if solid
3. Recurse one level down into the octree, go to 1

A bit simplistic yes, but unless I'm missing something, then that is the "core algorithm"... and no I don't see any unicorn in there.

Just to be clear though, this is one way of implementing it, there are likely a lot better ways, but it wouldn't suprise me if this is what they actually use, just a bit optimized.

1. Step along the ray using some algorithm (bresenham's line algorithm perhaps?)

[quote name='Syranide' timestamp='1313679140' post='4850789']
1. Step along the ray using some algorithm (bresenham's line algorithm perhaps?)

I'm not intensly familiar with SVO, but really, whoever you quoted above has no grasp of reality it seems. Not using multiplication and division does not make it impressive by itself, also note, the core algorithm. Meaning, going along a ray and traversing an octree. Going along a ray can be done using a variation http://en.wikipedia.org/wiki/Bresenham's_line_algorithm ... and holy shit! It doesn't use division and multiplication other than for precomputing some values! Bresenham's line algorithm sure is modern day rocket science it seems.

So, let's step back, and look at the problem... we have a RAY and an OCTREE, and our intention is to find the first node in the octree the ray hits, to get the pixel color... so:

1. Step along the ray using some algorithm (bresenham's line algorithm perhaps?)
2. For each step, check the corresponding octree node, if empty go to 1, exit if solid
3. Recurse one level down into the octree, go to 1

A bit simplistic yes, but unless I'm missing something, then that is the "core algorithm"... and no I don't see any unicorn in there.

Just to be clear though, this is one way of implementing it, there are likely a lot better ways, but it wouldn't suprise me if this is what they actually use, just a bit optimized.
[/quote]

I also thought about Bresenham's algorithm applied to it yesterday, but it might need a lot of (small) steps along the ray to check the octree nodes ... but why not.
For sure, if their "core algorithm" is done this way there are no unicorn here, I agree on that
Well even if they say they are not using ray casting, I begin to think that in fact they are. Maybe, they just call it differently because they are not doing it the usual way.