Voxel rendering (formerly Death of the GPU as we Know It?)

By chance I received the following in my inbox earlier this week: (In terms of "point based rendering" I would think that the state of the art would be seen there)

Incidentally, regarding the thread title "Death of the GPU as we Know It?" , at Siggraph 2007 there was a presentation on a "standard" GPU that was extended to support point based rendering.

 

That kills my idea that it might have been vectorized! Still 80 cycles/pix in something probably using the x86 float stack... and non-cache optimized? Seems like it might really help the guy to try and build a GPGPU version of this.

 

Could some one please explain to me what memory cache is and why I have never encountered it in C programming.

 

what factor of speed would knowledge of this subject give?

P.S there are advantages to working in a vacuum

 

Bruce, it is somewhat intriguing that you manged to get where you have without diving into some lower level hardware understanding involving cache issues ... well actually probably most programmers these days are not cache aware. In fact this might very well really put you into a good position to take what you are working on to the next level, ie, do yourself a favor and learn everything there is to know about modern CPU (and GPU) arch at the lowest level and modify your algorithm to take advantage of what you have learned... and don't stop a caches, learn how to vectorize your code using C hardware intrinsics...

 

or he could skip intrinsics altogether and learn how to vectorize code using the auto-vectorizer ; )

 

Occasionally, but usually the only advantage is "bliss"

I see someone else has already pointed you at links to explain caching but, in a nutshell, most of a computer's memory, ie DRAM, is (relatively) s l o w. Caching is a hardware scheme to hide that from the program[er] much of the time.

 

Humm, what's the chance that this is 99% the same as this method from a 1999 paper on sparse point rendering,

http://graphics.ethz.ch/Downloads/Seminar_Arbeiten/1999/adesboeufs.pdf

 

Since this got posted on the console boards because of videos and it's still rather interesting (lots of artifacts though in the comparison video). Lets bump this and see if there is some life in the discussion.

As for that 1999 paper, cutting up the view directions around an objects into visibility masks for subsets of the points is interesting but the way they do it I don't quite see how they can guarantee conservativeness :

What if it's visible only in between the directions they use to compute the visibility map?

I'm not a big fan of sparse point rendering any way, I don't see what's there to gain from throwing away the connectivity data of normal voxels and trying to make adhoc guesses where surfaces are.

 

It looks like as if he has no undersampling/interpolation implemented for his point volumes. At least he did not demonstrate smooth/flat surfaces, which is critical of course. But this is hard to make out with these low quality videos and maybe could be added to his algorithms.

The problem definitely is that he does not demonstrate his approach transparently enough, which makes it impossible to invest a second thought into it. He has to be very specific on all the key points that a relevant for real-time graphics if he wants someone to be interested into it. Just showing some videos with horrible quality will never lead to sucess.

On a side note: this music in the videos is annoying as hell! If you don't have background music that doesn't totally suck: don't use it! Just like his logo that could lead someone to think that he tries sell spiritual software that collects cosmic energy in order to render his "infinite details". Keep it simple and plain if you don't have resources for something.

 

It was the same problem several years ago when "a certain company" was told it was not a point cloud. Apparently it now is a point cloud. <shrug>
I've been trying to see if he has any published patents but these don't seem to have made it to a public state.

I'm sure there is some interesting technology buried in there somewhere but whether it is of practical use is another matter.

 

No wonder considering the title alone: "An improved computer graphics method and software product". Holy shit!

Yes, there is really something interesting about it if it is true that his algorithm makes it possible to render the demonstrated scenes in 30ms on a single core CPU.
Someone should try to guide him on what he needs to do to properly demonstrate his algorithm so that there is at least a chance that something fruitful can come out of this.

 

I was wondering if this would ever come up again and I must say I find the progression of the story more fascinating then the technology. If this does get further I am sure Simon would choke on his weekly doughnut if he pitched the original version over 20 years ago to Imgtec

It is all frankly a bit bizarre that someone who has seemed to previously demonstrate a lack of understanding of some important principals such as cache and how GPU's operate and what direction they are heading is teasing something like this with psychodelic imagery and explaining via search in Microsoft Word! Don't get me wrong I wish Bruce every success and I am sure Simon and others do too.

If he really has come up with something novel and he wants a middleware company from it he really needs a partner who has knowledge in technical areas he doesn't and also a business partner to stand any chance of capitalising on this. If Bruce is listening to this read up on a comparable middleware company such as 'http://www.geomerics.com/' for a good example of what you should be aiming for.

On the actual technique itself I am guessing from what Simon said about his first stab using lots of spheres (Reminds me I used to love that game Ecstatica) that part way through he perhaps just had an 'efficient' point or sphere projection system - that dealt with gaps with the oversized spheres causing bad aliasing. Where the point data cloud is stored in an octree and subdivided down to a uniform level - maybe with some LOD by throwing away points that are too small. I suspect the possibility of a novel feature could be where as he says he searches the point set.

I thought the 'animated but rigid' character model was cute - well intentioned but not quite what people would be looking for. I think large chunks of static environments of high detail with traditional skinned polygon characters for a lot of games are fine though - and so does ID from my understanding.

But this also makes me think of Cranberry Sauces Sprout technology and Animtek's Caviar technology years ago for animated characters. The latter being RLE compressed 3d sprites I believe.

It will be interesting to see how this comes out compared to the implementations of PBR's, SVO's, ADF's, and hybrids and all that OTOY stuff within the next few years. But I am pretty sure it won't be the death of the GPU and that he really wants the GPU to be helping him out with this as other experiments are already showing

This looks cooler: http://www.atomontage.com/

 

sounds like just makeing a new picture every time. i feel it is more like you color every pixel on the screen with a 3-dimensional framework "guide" that shows the computer what to color the screen. its like having a 3-d picture in the memory, then coloring the pixels to match the view from a certain distance. by using some math (i think, i cant program...) you can determin how much of your model is shown. this is like a 2-d animation colored in 3 dimensions. smart idea!, but im a skeptical person.
popsci says Bruce Dell needs to get the ip protection, so i await a awesome demo!

 

New video: http://www.youtube.com/watch?v=UKUuUvDSXk4

 

wouldnt you use geometry instancing for that ?

 

1080p version...

http://www.youtube.com/watch?v=00gAbgBu8R4