Surfels - Point Sample Rendering

Started by
5 comments, last by Carlito Brigante 18 years, 7 months ago
Hi I'd like to know what you think about this methods of rendering 3d scenes in real time: Surface elements as rendering primitives and PSR (Point sample rendering). From the docs i've read they seems to be more accurate than conventional tecniques. Has anyone ever tried to make something in real time? There's a noticeable difference in speed? Thanks for your time. [Edited by - Carlito Brigante on September 10, 2005 10:10:53 AM]
Advertisement
psr? I think most every method of rendering uses point sampling. I don't know what method you refer, can you point a link? most every technique for rendering digital 3d images relies on point sampling. from video games(scanline/projection) to expensive photorealistic(ray-traced, ect).. every technique is descretizing continuous signals to digital via point sampling.

Quote:Original post by timw
psr? I think most every method of rendering uses point sampling. I don't know what method you refer, can you point a link? most every technique for rendering digital 3d images relies on point sampling. from video games(scanline/projection) to expensive photorealistic(ray-traced, ect).. every technique is descretizing continuous signals to digital via point sampling.


Not exactly. We are speaking of *3d* point sampling. Every 3d model is represented by a collection of isolated points (not vertices!). Rendering is performed in 3 phases:
1) classical rendering of 3d points,
2) holes detection
3) filtering (in order to fill the holes).

The key word is "surfels".

Basically, we exploit the fact that we are going to sample the model sooner or later so surfels perform sampling before the rendering phase.
Look at some models in QSplat to get an idea about the speed.

It's probably an very useful technique to simplify complex algorithms (like LOD or deformations with changes in topology). Getting data from 3d scanners should also be a lot easier. But unless you need to do such (currently rather exotic) things I doubt its usefulness for common in-game scenarios.
___________________________Buggrit, millennium hand and shrimp!
Quote:Original post by samv
Look at some models in QSplat to get an idea about the speed.

It's probably an very useful technique to simplify complex algorithms (like LOD or deformations with changes in topology). Getting data from 3d scanners should also be a lot easier. But unless you need to do such (currently rather exotic) things I doubt its usefulness for common in-game scenarios.


QSplat does not represent the state of the art and, besides, we need dedicated hardware.
Quote:Original post by Anonymous Poster
QSplat does not represent the state of the art and, besides, we need dedicated hardware.


Excuse me, but who is "we"?

The OP asked for "make something in real time". QSplat is realtime. I can't see where the OP asked for (nor where I claimed QSplat was) "state of the art".

So, basically, what's your point?
___________________________Buggrit, millennium hand and shrimp!
Quote:Original post by samv
Look at some models in QSplat to get an idea about the speed.

It's probably an very useful technique to simplify complex algorithms (like LOD or deformations with changes in topology). Getting data from 3d scanners should also be a lot easier. But unless you need to do such (currently rather exotic) things I doubt its usefulness for common in-game scenarios.


Thanks, this looks nice. I really was expecting something more power hungry and I've seen not so much differences in redering (time & quality) between Opengl vs software (G6800GT vs A64 FX53). Qsplat might give me an idea of what a surfel renderer could be (about processing power) even if they're rather different.
BTW I agree with you when you say that this won't be useful for games (at least for the near future), there's a lot of work to be done with the existing tecniques used to make large detailed meshes more simplier.

This topic is closed to new replies.

Advertisement