Unlimited Detail Technology

Started by
44 comments, last by theagentd 12 years, 2 months ago

they're sitting on a pretty hot technological breakthrough, so they can't even afford to post an executable or reveal anything that could lead others to reproduce those results.


Any well-off graphics company could EASILY reproduce the results.
[/quote]

Yep, successful middleware is almost universally based of making tools, even the big engine licenses like UE3 mostly make their sales off good tools.

Speaking of which, the demonstrations of animations have me wondering if this will indeed be the future. No need for base meshes and displacement or normal maps, and that Lionhead demonstration already shows art tools that could take advantage of such. My main question is what sort of disk space is going to be taken up by these models. Higher profit margins means digital distribution is going to be quite popular on the next generation of consoles, but few will want to download a fifty gig game.
Advertisement

they're sitting on a pretty hot technological breakthrough, so they can't even afford to post an executable or reveal anything that could lead others to reproduce those results.
Any well-off graphics company could EASILY reproduce the results.[/quote]Yep, this is one thing that makes them seem pretty removed from reality. They're completely ignoring all of the prior art and pretending that their work is unique.

[quote name='Sirisian' timestamp='1301890150' post='4794046']
[quote name='D_Tr' timestamp='1301855020' post='4793896']
The closest thing to this I've heard about is the sparse voxel octree raycasting technloogy. John Carmack has stated that he is experimenting with this technology for possible use in a future version of idTech. There is also an interesting discusion in this thread http://ompf.org/foru...t=904&hilit=svo. The main problem with these kinds of technology is dynamic geometry. The SVO techlology I referred to was to only be used for the static geometry. I watched the video you linked to and two more videos from the same guy and i didn't hear him say something about animation (did he?). Animation is vital to a really lifelike environment... But even for static geometry like buildings this kind of technology is interesting...

You can do animation with SVO data sets by using boundary objects and performing ray transformations at the boundary into the AABB space of the data set. This is quickly mentioned in Laine's Nvidia paper on SVO. It's not that dynamic geometry isn't possible, it's just that it's not researched much at all.

The Euclideon guys have videos showing off animation.
[/quote]


This guy claims to have done it.


[/quote]

I haven't looked at it, but here is the source code to it: http://bautembach.de/wordpress/
Voxels are niffty, they've been around for along time. I remember seeing voxel animated characters on the old 386 era machines running 30fps.. They just never caught on in games, because of their space requirements and the advent of affordable GPUs pushing polygon technology. Now that GPUs are programmable maybe they'll make a comeback.. They do offer some advantages over polygons.

-ddn
Wouldn't the required storage space be enormous? Lets say you have a terrain with a surface area of 2500(50*50) meters squared and lets say your screen has about 1 million pixels and is square shaped. Now if you want to view that terrain with "unlimited detail" at a minimum distance of about a meter, it would require 1 million voxels per square meter of terrain to provide that detail. That means you'll have 2,5 billion voxels making up the surface of a fairly small terrain. Even if a voxel only contains 4 bytes of color information you'll still have 10 billion bytes of data, which is about 10 gigabytes, and that just gives you the terrain...

Am I missing something here?
I think the trick is (or at least what I got from the explanation) that they use this sort of "search engine" to only process the *pixels* that gotta be shown, ignoring the "unlimited" stuff that won't get a pixel on the screen.

*makes fingers gesture when saying stuff between quotes*
[size="2"]I like the Walrus best.

Wouldn't the required storage space be enormous? Lets say you have a terrain with a surface area of 2500(50*50) meters squared and lets say it .... would require 1 million voxels per square meter of terrain to provide that detail.
To be fair, that same problem statement applies to megatexturing/SVT. DXT can reduce 24bpp colour data to 4bpp, and more aggressive methods can reduce 24bpp colour data to as low as 0.5bpp.

I honestly don't know much about applying DXT/JPEG style algorithms to voxel data though, especially if it's some kind of SVO data...

Wouldn't the required storage space be enormous?
...
Am I missing something here?

Yeah there are tricks. One of the main ones is contour information (covered in Laine's Nvidia paper). Lets say you do have 50x50 meter of voxel data. Each voxel could contain contour information describing the shape (or curve of the terrain). As you perform a ray traversal through the SVO if you hit a meter level voxel that was filled you'd traverse through that meter cube performing a countour look-up or a calculation to determine if anything is there. In effect you're procedurally generating detail. This idea of procedurally generating detail is useful in other situations. If you had a concrete surface in a game wanted to allow a player to zoom in unlimited with a sniper rifle you might define that after so much artist defined geometry that a procedural algorithm takes over. (hehe imagine connecting subtree nodes to the root node such that zooming into the game zooms into the game :unsure: voxception).

This topic isn't researched much. Remember that there are tons of different ways to encode voxel data in an octree and small changes can allow features that have never been seen before. For instance a really obvious example is a voxel representing a ray translation such that if a ray hits a certain voxel then it exits and continues in another area (this requires the ray to be generated from new at the new position unlike creating a secondary array). Instant portals which should be familiar to anyone that's written a raytracer.

This terrain conversation reminds me of quadtree displacement mapping which is like SVO's friend. It can be used in voxel data sets to use a heightmap to encode depth on a wall in case one didn't care to encode the data into a SVO.
and I tessellate the doom3 meshes ( in case you didn't see http://twitpic.com/3wozra ).[/quote]

Is that made out of voxels too?
[/quote]
this screenshot is _not_ voxel data, but I have exactly that as animated voxel, I'm just not done with the whole demo.

you know, showing once again something 'half done' will just make some ppl say 'nice' and that's it, so I want a full features demo with all the benefits you get from voxels :)




from my other screenshots at twitpic you can get some guesses , and following me on twitter might give ya more guesses :D (I'm so lousy in marketing, I know! :) )


[quote name='Mussi' timestamp='1301974885' post='4794475']
Wouldn't the required storage space be enormous? Lets say you have a terrain with a surface area of 2500(50*50) meters squared and lets say it .... would require 1 million voxels per square meter of terrain to provide that detail.
To be fair, that same problem statement applies to megatexturing/SVT. DXT can reduce 24bpp colour data to 4bpp, and more aggressive methods can reduce 24bpp colour data to as low as 0.5bpp.

I honestly don't know much about applying DXT/JPEG style algorithms to voxel data though, especially if it's some kind of SVO data...
[/quote]
that really is up to how you use voxel data and what information it contains, there are some DCT(jpeg), as well as wavelett and vector quantitization implementations (or at least I've read the paper). they compression ratio is usually way better than in 2d, but the data is still quite huge if you store raw data.




as far as download titles go, I don't think it's that much of an issue. Some time ago ppl claimed it's unpractical to sell games digitally, now it's done and ppl download games and play them. I predict, in near future, when ppl create games for pure digital distribution, nobody will really want to wait for a game to download, you pay and you start playing.


In order to do this, you have to have an online streaming, so it doesn't really matter how much storage it takes, it's rather about the caching and bandwidth... and yet again, ppl said some time ago, a movie streaming service would be unpractical on individual basis, as it would take too much bandwidth, and we have youtube now.

Yes, that's very risky to predict, but I'm somehow driven by this idea since like 10 years and I still believe, it maybe 2015, it will be all about that. and at this point, predictable streaming might be more important for gameplay, than low data with peaks like currently a lot of streaming works with meshes+textures (due to the high cost of seeks on DVD/BD).

and in case someone is curious, for testing, I've voxelized crytek's sponza (http://www.crytek.com/cryengine/cryengine3/downloads) and it's lossless compressed about 220MB with my own format (7z compresses it to 170MB, but I need about 200MB/s decoding speed, that's why I can't use it). By lossless, I mean, same texture quality, 24bit./voxel diffuse at all stages, using lossy compression it would go down way more, but then comparison would be even less objective.

This topic is closed to new replies.

Advertisement