How Carmack did it

coldwolf

No flaming, I just wanted to show everyone how fucking awesome this tech is. At TED this guy demonstrated his product SeaDragon with PhotoSynth. SeaDragon is a zoomable environment with the super-sweet feature of rendering gigabytes of image data flawlessly and smoothly.

His technique (SeaDragon) is shear brilliance and I'm pretty sure it's similar to what Carmack is using in his new engine. Check out PhotoSynth for yourself.

I'm just sayin' that this is a monumental achievement in realtime computer graphics that is not only revolutionary for games and cg but any piece of software that needs to display an assload of data in realtime (just watch the TED demo I linked above!). I can't wait for this tech to become widely adopted and put to use everywhere (and where wouldn't we want to render massive amounts of data in realtime?). Pretty cool stuff right?

Mongrelman

<cough>
http://boards.polycount.net/showflat.php...true#Post211722
</cough>

Neo_God

Incredible!

coldwolf

When.. what... ARGH.

I got too excited and didn't bother to search... and... sorry

almighty_gir

fuck it, it's awsome enough to have two threads!

CrazyButcher

it were three, as I posted it in general as well lately also not caring to search

parasyte7

How did I know you were going to mention porn Per? Psychic I tell ya.

snap.crackle.pop

Don't worry gentlemen porn is always the relevant subject in any situation

Mongrelman

Hmm, this mixed with microsoft's hands on table technology.....could be....interesting.

coldwolf

Yeah, MS Surface looks fantastic, and with apps like PhotoSynth running on it... fucking the Christ that'd be hawt. I really want to see those multi-touch interfaces married with Wacom's pen tech. I think that would destroy the mouse as far as graphics development goes... at least I wouldn't touch one As if the Cintiq wasn't enough, blah, it's just that so few can justify the price of that thing (unless your studio pays for it).

Bad Sector

Not sure how Carmack does it (i assume you mean the having a sheer amount of data visible, no matter what), however i thought about a method some months ago which should work (unfortunatelly my gfx card isn't powerful enough for this method). The idea is break the textures in subtextures, render the geometry without texture data but with a shader that uses a specific color that identifies the subtexture for each pixel and then use that "identifier pixel" to see which textures are visible. Since the "identifier pixels" also contain depth, you can bind a mip texture directly (so you'll save video memory for far textures). Maintain a secondary render buffer where you'll store the texture coordinates. Then render a quad over the screen (or screen area if you can afford that test) for each visible texture with a shader that which binds that texture and draws only the pixels that use that texture, based on the id of the texture you draw.

As i said, i haven't tested it because my hardware is four years old. However when i described (in more detail) to the programmers i work with (i work at a gamedev company here in Greece), they said that this should work.

I hope to get new hardware soon so i can test that kind of stuff :-/

MoP

That sounds like a very good solution to me, Bad Sector.

CrazyButcher

the problem with "identifier pixels" (same as for sotring 32 bit pointers as RGBA color value in pixel based picking) is anti-aliasing. it will "mix" pixel with other ids, corrupting the id data...

another thing is that often you want more than a single texture. and have multiple uvs, I think one would saturate stuff with multiple rendertargets quickly...

mostly I think its some clever special texture packing (using a offset texture or so). But well once enemy territory is released, we all will know

Bad Sector

Well, yeah, my algorithm -much like deferred shading, which is similar to what i'm describing- won't work with antialiasing. Of course (like in deferred shading) you can do your "hand made" antialiasing by rendering in offscreen render targets which are larger than the framebuffer and downscale them.

Also yes, multiple textures with different UVs will need many render targets. On the other hand, from what i've seen in the id tech 5 video, they don't seem to use multiple textures per surface (i'm not counting normal/specular/bump/other maps there, since they can use the same UVs and can be likewise broken in submaps much like the diffuse maps).

Since this may be considered as a limitation (one diffuse, one normal, one specular, etc all with the same normalized UVs) per *pixel* you can think of it as a "limitation exchange". You put this limitation, but you get "therionmaps" (as i like to call mine :-p).

Ah, i wish i had a GF8800...

...and a SLI motherboard...

(and a CPU for that mobo, and some compatible memory too and while we're there, let's get a new hard drive too - i don't *need* that, but my disk is full... and if i'm going to buy the above stuff, getting a new disk won't make much of a difference in the total cost)

dejawolf

isn't this technology basically uploading only what it needs of the textures memory, so that no matter what, the total memory loaded remains whatever the screen resolution is?
the mipmap is dead..
this would also mean you could create heightmaps of near infinite complexity?

Bad Sector

As i said, i don't know what Carmack does. The method i thought (damn, with all this discussion i just might try to see if there is any way to implement it in my X850) loads only the "parts" of the texture (that is the subtextures) that are visible. And to make sure that no big maps are loaded, mipmaps *have* to be used (if only a few pixels from a subtexture, from a mountain long far from the camera are visible, you don't want to load a full 512x512 -or whatever the subtexture size is- image to the memory).
Heightmaps depend on the usage. For terrain geometry made by heightmaps, i think with a similar method (creating subheightmaps) it is possible. For usage with shaders (f.e. for parallax or relief mapping), it's just like other textures.

MoP

Indeed, mip-maps are an integral part of this process.

CrazyButcher

I thought megatexture was a variant of clipmapping

sgi had that in their high-end hardware in the old days
http://www.sgi.com/products/software/performer/presentations/clipmap_intro.pdf

SouL

Not having read CrazyButcher's post, but the way I understood Carmack's megatexture is that ALL the textures in the scene (in this case, let's refer to a scene as an entire outdoor environment) is taken and put together in one large texture sheet that the game then refers to to call up the necessary textures for each object in the scene.

This is great because you can have as my different texture layers, effects, multi-pass (normal, spec, bump, etc, etc) in the entire scene... but it'll only cost you one drawcall. For a console game this would not be an issue. For PC's, if I remember correctly, Windows has a limit of how many drawcalls in can process during a window of time. That's why often times videocards aren't really being used to their full potential. Simply because they're so much faster than what windows can process. They basically sit there twiddling their thumbs waiting for windows to give them something to do.

The only downside is you then run into issues of running out of texture memory. This method would literally run you into the high hundreds, even gigs of texture memory usage.

Pretty soon we'll probably have video cards the size of desks hanging off our PCs.

MoP

Well, you probably wouldn't want to put absolutely everything onto a single giant texturesheet, probably better to break it up based on shader types (ie. everything using a certain shader effect or set of passes onto one sheet, stuff using a different shader onto a different sheet) to keep the batching more optimal.

You shouldn't run out of texture memory if the scene is being sampled in screen-space, then it only streams the relevent textures from HDD into memory. Then you're talking about HDD speeds limiting the graphics quality