That’s Ad Populum.
The reason the industry is using old rendering appraoch (from the nineties) with small cosmetic changes over time is because it worked once and then everyone has been trying to do the same. That’s “chicken and egg” problem.
However, flat polygonal data is ill-suited for 3d representation in general (destruction and csg turns into fairly complex problem, which is not the case when you switch to voxels or even simplex data), so at this point this appraoch has been pushed to the limit, pretty much, and there were steps away from it (parallax mapping is one of those examples, since it is pretty much volume display).
So, it would be wise to start researching the alternatives right now.
Also, I’d like to point out that “realtime GI solution” is fundamentally different (and more difficult) problem that requires more resources than simple volumetric data display, so it is not a good argument against non-polygonal data. The issue with GI is that any one point in scene can potentially affect infinite number of other points in scene. That is not the case with simple volumetric data display which requires simple rasterization approach switch and can use the same kind of algorithms that are used right now for polygonal display.
Speaking of realtime raytracing, this kind of demo was done about 10 years ago and could run on CPU. Now we have more computing power.
Once again, “realtime raytracing” also does not really apply to apply to the issue of volumetric data, because realtime raytracing of scene that involves dynamically moving volumes is, once again, a different problem that would require a way to quickly rebuild scene octrees(or alternative) while dynamic object passes through it. You do not need this kind of thing when you’re simply switching away from polygonal approach to non-polygonal approach. Because once object is in scene, regardless of the way it was visualized, you can use same kind of tricks on it as you used on polygons. Meaning fake reflections and all that stuff.
I believe my initial assumption about point cloud data is relatively safe, because unless someone literally goes nuts, in most of the scenarios, point cloud will have high-frequency data around surface, and low-frequency detail inside the interior, simply because most people won’t be seeing the interior. That’s a great compression potential, similar to DXT/Jpeg/whatever.
Now, I consider those things to be obvious.
Either way, my initial comment was caused by annoyance I feel every time people try to shoot down potentially useful approach “just because it ain’t polygons”. I would appreciate if people wouldn’t be doing that and were a bit more open-minded about it.
That’s all there is to it, pretty much.