[sqrt[-1]]

Sorry if this is a repost:

I was wondering what you guys think about this "point cloud rendering" technology:

http://www.tkarena.com/Articles/tabi...e-Know-It.aspx

Some of the screenshots are impressive:
http://www.tkarena.com/Articles/tabi...1/Default.aspx
but I wish there was a frame-rate counter.

[Pressure]

This is definitely interesting and should be for everyone playing games.

Whether or not investors jump on the bandwagon will determine if this is going to be vapourware or a real deal.

Hopefully they will consider a PC, Mac and Console versions of the editor.

[Demirug]

I would not sell myself to this.

It sounds like the typical “Ray tracing could handle more geometry in the same time as rasterisation.” But I am missing a statement about the amount of memory that is needed to store this “better” geometry. Additional I could not find a useful word how texturing and shading works with this. But the biggest problem isn’t even mention. How this technique does handles skinning. Most accelerated raytracing technologies breaks apart when it comes to modify the geometry in real time.

[Andrew Lauritzen]

Hehe all this voxel stuff lately is giving me flashbacks to my elementary school science fair project (a voxel terrain renderer)... back then voxels were very cool, but they haven't really moved a long way in the last decade compared to polygons. That said, I'm willing to revisit the idea and indeed voxels still do have several desirable characteristics.

Let me respond to a few points in the article though. The guy did admit that he wasn't a graphics guy though so I'll cut him some slack

When displaying a forest, for example, it makes a tree and then puts another tree in front.

It has been a while since we rendered using the painter's algorithm

their system has unlimited power.

Ooh, so all that remains is to formulate the halting problem, or even TSP/3SAT/etc. in terms of voxel ray casting and I've put a lot of CS people out of their jobs, not to mention solved a lot of terribly hard problems. Reminds me of this fun paper .

Point cloud data is much more efficient then polygon data. That’s not in dispute. It’s more accurate and models can be hand made or laser scanned in, but either way the result is that it looks better.

Meh... that's kind of what you're trying to prove one way or another - you can't just "declare" it to be true. Particularly absurd considering no performance figures are given, which means you can't really draw any "efficiency" conclusions whatsoever. The whole conclusions is actually pretty simplified and misleading, but I appreciate what they were trying to say.

They're also falling into the ray tracing trap of making claims like "we can render a bazillion peta-tera-bytes of data!" where such a measure is completely irrelevant and misleading. I can render a bazillion polygons too, if the majority are occluded, offscreen or at lower LOD/tessellation

Anyways there is one, big, huge argument for using voxels in my opinion: easy, efficient, scalable LOD. They mention it briefly in the article, but really this is entirely the motivation for using such a data structure IMHO. Certainly doing good LOD with polygons isn't impossible (and it can be done without popping contrary to what the article says - check out the skydive from Crysis!), but it's also pretty complicated.

I'm interested to see where this stuff goes, and I can understand Carmack's interest in that the design elegantly flows together with virtual texturing (although arguably with voxels you could represent the texture data right in your data set as well, without needing parameterization... maybe that's what he's planning).

Thanks for the link!

[liolio]

It could be interesting if a mod try to invite Bruce Dell on this board, no?
It seems he is reachable on the tkarena forum

[Simon F]

This all looks very similar to something someone was trying to sell to us. I never thought it looked very good.

[TimothyFarrar]

Originally Posted by liolio

It could be interesting if a mod try to invite Bruce Dell on this board, no?
It seems he is reachable on the tkarena forum

Definitely invite him to this thread. I'd be very interested to hear about the technology.

BTW, anyone have a link to download the demo?

[HAL-10K]

Originally Posted by Demirug

I would not sell myself to this.

It sounds like the typical “Ray tracing could handle more geometry in the same time as rasterisation.”

Yes and No.

The by far most significant point of ray tracing is that it is much more efficient in rendering geometric detail that has greater resolution than the rendertarget.
But the real strong point of this approach compared to triangle meshes is that you can solve the issue of oversampling with voxels very easily and that you can compress them much more efficiently (like pixels).
Ray tracing adaptively compressed voxels is definitely very promising.

But I am missing a statement about the amount of memory that is needed to store this “better” geometry.

Adaptive 3D space partitioning can bring down the amount of data very significantly.
You can decide the maximum resolution dependent on resources and desired quality. Think about clip maps in 3D space.

Additional I could not find a useful word how texturing and shading works with this.

You could do it just like with normal surface fragments.

But the biggest problem isn’t even mention. How this technique does handles skinning. Most accelerated raytracing technologies breaks apart when it comes to modify the geometry in real time.

That is the most complicated part of course, but I am confident that good enough solutions for this will emerge.

[Demirug]

Originally Posted by HAL-10K

Yes and No.

The by far most significant point of ray tracing is that it is much more efficient in rendering geometric detail that has greater resolution than the rendertarget.
But the real strong point of this approach compared to triangle meshes is that you can solve the issue of oversampling with voxels very easily and that you can compress them much more efficiently (like pixels).
Ray tracing adaptively compressed voxels is definitely very promising.

At least it seems a better approach then raytracing the geometry that we have today.

Originally Posted by HAL-10K

Adaptive 3D space partitioning can bring down the amount of data very significantly.
You can decide the maximum resolution dependent on resources and desired quality. Think about clip maps in 3D space.

I know. But I am still curios how much memory the objects in the example shots needs.

Originally Posted by HAL-10K

You could do it just like with normal surface fragments.

My fault. I was thought about sphere voxels instead of cubic ones.

[Panajev2001a]

Originally Posted by Andrew Lauritzen

Hehe all this voxel stuff lately is giving me flashbacks to my elementary school science fair project (a voxel terrain renderer)...

You were coding a voxel terrain renderer when you were enrolled in elementary school ?!?

[Davros]

There was a 3D mark demo some years ago of a point cloud horse that spun around to test the maths processor of your machine. That horse was roughly 384 000 points where as this model is roughly 1.5 million points.

that demo was labeled as point sprites - is this what this cloud data is ?

ps: how is it better to store a triangle as lots of points rather than 3 points(or vertexs) like we do today ?

[Andrew Lauritzen]

Originally Posted by HAL-10K

The by far most significant point of ray tracing is that it is much more efficient in rendering geometric detail that has greater resolution than the rendertarget.
But the real strong point of this approach compared to triangle meshes is that you can solve the issue of oversampling with voxels very easily and that you can compress them much more efficiently (like pixels).

Yes indeed ray tracers' ability to turn "slow" into "aliasing hell" isn't of particular interest to me, but I am very interested in how this sort of voxel approach lends itself very nicely to simple, dynamic LOD in a very similar manner to texture filtering. Slap on some paging on top of it and it's not so surprising to see this as a natural development on the MegaTexture idea...

I'd certainly be interested in seeing some demos of this in action, although it seems to introduce its share of issues as well - efficiently handling data structure updates being one of them.

Originally Posted by Panajev2001a

You were coding a voxel terrain renderer when you were enrolled in elementary school ?!?

It's not really as impressive as it sounds... in the simple case of 2D height fields, voxel terrain rendering simplifies to jsut marching along your height-field and comparing heights, while drawing vertical scan-lines up the screen. Come to think of it, it may have actually been Grade 9 that I did the project, but it was many years ago in any case.

[sqrt[-1]]

I should also mention that this company (Unlimited Detail) are giving a presentation at our company in early April. So I can probably give some more details on any non-NDA stuff then.

They also mention that at this time they are only looking at a "hybrid" solution of using this point cloud technology for game backgrounds and using traditional polygons for game characters.

I think they are presenting at a few game companies, so if you work at a game company you may be able to request a presentation.

[Cal]

Isn't "Image Based Rendering" a better way to render those kinds of objects showed in the screenshots? For game background, an IBR based algorithm would be much more efficient, like Concentric Mosaic, Lumigraph, etc.

Also, point cloud rendering is not anything new, it has already been used for massive rendering like huge amount of crowd. Those kinds of things just come and go, never reached to a full fledged stage.

[Panajev2001a]

Originally Posted by Andrew Lauritzen

Yes indeed ray tracers' ability to turn "slow" into "aliasing hell" isn't of particular interest to me, but I am very interested in how this sort of voxel approach lends itself very nicely to simple, dynamic LOD in a very similar manner to texture filtering. Slap on some paging on top of it and it's not so surprising to see this as a natural development on the MegaTexture idea...

I think that being reminded of http://www.pcper.com/article.php?aid=532 (id Tech 6) upon visiting this thread was something many people here felt naturally occurring .

[Bruce Dell]

Hi every one , I’m Bruce Dell (though I’m not entirely sure how I prove that on a forum)

Any way: firstly the system isn’t ray tracing at all or anything like ray tracing. Ray tracing uses up lots of nasty multiplication and divide operators and so isn’t very fast or friendly.
Unlimited Detail is a sorting algorithm that retrieves only the 3d atoms (I wont say voxels any more it seems that word doesn’t have the prestige in the games industry that it enjoys in medicine and the sciences) that are needed, exactly one for each pixel on the screen, it displays them using a very different procedure from individual 3d to 2d conversion, instead we use a mass 3d to 2d conversion that shares the common elements of the 2d positions of all the dots combined. And so we get lots of geometry and lots of speed, speed isn’t fantastic yet compared to hardware, but its very good for a software application that’s not written for dual core. We get about 24-30 fps 1024*768 for that demo of the pyramids of monsters. The media is hyping up the death of polygons but really that’s just not practical, this will probably be released as “backgrounds only” for the next few years, until we have made a lot more tools to work with.

SQRT may I ask what company you are from, all appointments in America where pushed till May.
Please contact me unlimited_detail@hotmail.com

Kindest Regards
Bruce Dell

[Simon F]

Originally Posted by Simon F

This all looks very similar to something someone was trying to sell to us. I never thought it looked very good.

Originally Posted by Bruce Dell

Hi every one , I’m Bruce Dell (though I’m not entirely sure how I prove that on a forum)

That's easy. Just answer "Where did the government suggest that Bruce Dell take a trip to for a trade mission?"

Seriously though, you seem to be the same person who contacted us in 2005. What struck me was, to be honest, that it didn't actually look that good.

Any way: firstly the system isn’t ray tracing at all or anything like ray tracing. Ray tracing uses up lots of nasty multiplication and divide operators and so isn’t very fast or friendly.
Unlimited Detail is a sorting algorithm that retrieves only the 3d atoms (I wont say voxels any more it seems that word doesn’t have the prestige in the games industry that it enjoys in medicine and the sciences) that are needed, exactly one for each pixel on the screen, it displays them using a very different procedure from individual 3d to 2d conversion,

So how does this differ from algorithms of ~20 years ago that modelled objects with a multitude of spheres and then had a fast "blatting" algorithm?

If this is a point-based modelling system, how does it compare to the work that has been presented recently at, say, SIGGRAPH? It seems to me that research in this area looks far better.

[TimothyFarrar]

Impressive when you consider that each pixel on the screen gets probably under 80 cycles of CPU time. Of course if the code is vectorized then the effective number of cycles/pix increases.

I wonder how GPUable this algorithm is? If it was on the GPU I'm sure you could solve the aliasing issues with filtering. Problem is that I would guess this algorithm is a re-projection and hole filling style algorithm which only adds a small number of new points (searched in the data structure) per frame, and point scatter simply isn't very GPU friendly. If you were going to do a GPU version of point splatting, you would only want to draw a small subset of the points per frame and then have an image space algorithm hole fill and "search" for the proper pixels (which is SIMD + TEX cache friendly).

[MfA]

Originally Posted by HAL-10K

The by far most significant point of ray tracing is that it is much more efficient in rendering geometric detail that has greater resolution than the rendertarget.

Just because object order renderers don't generally perform hierarchical culling of primitives which don't intersect rays doesn't mean they can't. It's just not a very good idea most of the time.

As for compressing octree representations of geometry, what's so special about it? For a small thought experiment lets take a triangle, what is the more efficient way to describe it? Voxels or an explicit surface description?

Hierarchical voxel/points will compress well enough in general and inherently give you LODs but but their main advantage over explicit surface descriptions (which can be hierarchical too, with inherent LODs) is ease of use and not efficiency.

[sqrt[-1]]

Originally Posted by Bruce Dell

SQRT may I ask what company you are from, all appointments in America where pushed till May.

I don't work in America, I work for THQ in Australia.

[sqrt[-1]]

I saw the (non-NDA) demo presentation a few days ago and have a few mixed feelings about it.

He showed a lot of videos and one real time demo (that he apologized for it being a little bit broken as it had some bad artifacts)

I would have preferred to see some of the more game-like levels in real time. Some of the videos seemed game like and impressive. (Also, some of the videos were a bit old and you can see he has come a long way over the years.)

And if I could get actual mouse/keyboard control of a game scene demo would have convinced me much more - as being able to fly around and get up close to geometry to look for artifacts is the real test for me. (It is not like anyone could steal anything by providing an interactive demo)

The developer admitted that he has been working in a vacuum for the last 10+ years - so he knows very little about how current renderer's work.
(Which was very apparent during a Q&A) It appeared that the demos used DX8 to do blitting to the screen. It was also stated that the demos were single core and written in plain non-optimized C, so someone who knew what they were doing could make it run much, much faster. (was a bit distressing to learn he did not know what a memory cache was however)

The main claim is that he has found an efficient way to extract point data in an octree without doing ray-casts into the data structure. The octrees were compressed and supported instancing of objects through-out the level.
(I really do not know a great deal about octrees to really comment on this)

I don't think it was a "smoke an mirrors" presentation, but without seeing some better real time demos I am not 100% convinced. (demos that I can actually control - and display task manager to see mem usage etc)

[Simon F]

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)

Point-Based Graphics 2008 - Call for Papers

Los Angeles, CA, USA - August 9-10, 2008 http://www.point-graphics.org

Submission Deadline: April 30, 2008

Co-sponsored by Eurographics and the IEEE-CS Visualization and Graphics Technical Committee (VGTC)

The drive for increasingly complex 3D geometric models, especially those scanned from the real-world, has brought about a growing interest in methods that build on point primitives. Following the highly successful 2004, 2005, 2006, and 2007 Symposia on Point-Based Graphics, the 5th symposium of its series, PBG08, aims to further demonstrate the applicability of point-based methods in modeling, rendering, and simulation, and in a wide range of application domains. PBG08 will take place in in Los Angeles, CA, USA, from August 9-10, 2008, co-located with ACM SIGGRAPH 2008 and co-organized with the International Symposium on Volume Graphics (VG08).


We invite your original contributions in areas including, but not limited to, the following:

- Data acquisition and surface reconstruction
- Geometric modeling using point primitives
- Sampling, approximation, and interpolation
- Transmission and compression of point-sampled geometry
- Rendering algorithms for point primitives
- Geometry processing of point models
- Topological properties of point clouds
- Hardware architectures for point primitives
- Animation and morphing of point-sampled geometry
- Hybrid representations and algorithms
- Use of point-based methods in real-world applications


PBG was established do develop and leverage the newly created field of point based graphics and to establish a community of its own. With the 5.
symposium of this kind in 2008 and the broad spectrum of scientific publications on the subject, we believe that our initial mission is accomplished. At the same time we observe a natural evolution and confluence of point graphics and volume graphics into the broader field of "Sample Based Graphics". In order to address this development VG'08 and PBG'08 will organize a joint track on the topic to evaluate its suitability as new direction into which both symposia might evolve in the years to come.

For more information about submission, please visit http://point-graphics.org


Important Dates:
Paper submission deadline: Apr 30, 2008
Notification of acceptance: Jun 4, 2008
Camera-ready copy: Jun 18, 2008
Symposium: Aug 9-10, 2008



General Chairs:
Mario Botsch, ETH Zurich
Matthias Zwicker, University of California, San Diego

Papers Chairs:
Renato Pajarola, University of Zurich
Oliver Staadt, University of Rostock

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.

[TimothyFarrar]

Originally Posted by sqrt[-1]

The developer admitted that he has been working in a vacuum for the last 10+ years - so he knows very little about how current renderer's work. (Which was very apparent during a Q&A) It appeared that the demos used DX8 to do blitting to the screen. It was also stated that the demos were single core and written in plain non-optimized C, so someone who knew what they were doing could make it run much, much faster. (was a bit distressing to learn he did not know what a memory cache was however)

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.

[Bruce Dell]

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

[Bruce Dell]

what factor of speed would knowledge of this subject give?

P.S there are advantages to working in a vacuum