Carmack Discusses "megatexture"

[OrbWeaver]

http://developers.slashdot.org/article.pl?...334234&from=rss

 

From what I can make out, the MegaTexture is just a very large texture that doesn't go into VRAM, and then some logic in the engine picks out the portions of the large image that should be rendered depending on which parts of the object are in view.

[Bukary]

http://developers.slashdot.org/article.pl?...334234&from=rss

 

From what I can make out, the MegaTexture is just a very large texture that doesn't go into VRAM, and then some logic in the engine picks out the portions of the large image that should be rendered depending on which parts of the object are in view.

 

I have to ask this question: can our great programming wizards "move" some new features (e.g. megatextures) and new-old-already-partially-implemented tricks (e.g. great looking water) from Quake Wars to TDM?

[OrbWeaver]

I have to ask this question: can our great programming wizards "move" some new features (e.g. megatextures) and new-old-already-partially-implemented tricks (e.g. great looking water) from Quake Wars to TDM?

 

Great-looking water can already be done in Doom 3. Functions like MegaTexture could probably only be implemented once Doom 3 is open-sourced, unless there was enough fledgling code already to make it work (which is unlikely).

[Bukary]

Q14: Do you think that the MegaTexture technology will be accessible to mod teams? I'm making the connection there in terms of thinking of some of the smaller teams out there.

 

Answer: It doesn't help them. In general, all the technology progress has been essentially reducing the ability of a mod team to do something significant and competitive. We've certainly seen this over the last 10 years, where, in the early days of somebody messing with DOOM or QUAKE, you could take essentially a pure concept idea, put it in, and see how the game play evolved there. But doing a mod now, if you're making new models, new animation, you essentially need to be a game studio doing something for free to do something that's going to be the significant equivalent. And almost nobody even considers doing a total conversion anymore. Anything like this that allows more media effort to be spent, probably does not help the mods.

 

Nobody even considers doing a total conversion anymore?

[OrbWeaver]

Nobody even considers doing a total conversion anymore?

 

I noticed that one as well. I think he's right in as much as modding becomes increasingly time-consuming as the standards set by the original game go up, but I hope that Carmack doesn't adopt a "it's too complex for you" attitude towards modders the way Warren Spector did with T3.

[Domarius]

Goddamn, just don't read any of the comments. I didn't realise how good we have it here with a pool of 100% intelligent and reasonable people, undiluted by the brain-dead couch (or computer chair) potatoes that make up most of the population.

 

This is a pretty cool technology. I doubt it would be possible to put it in Doom 3 engine ourselves since it works at the rendering level, and even if we could, we wouldn't because we need to get the core gameplay out there first, which will work fine (even awesome) with the current engine features.

[OrbWeaver]

I would much rather see real procedural textures, rather than huge 32,000 pixel images (how the hell are you going to edit that in GIMP/Photoshop?).

 

Imagine a fully programmable object-oriented shader programming engine, where you could define objects that generated "signals" that could be fed into other objects to mix and produce textures on the fly.

 

E.g.

 

SineModulator sm(MODULATE_SINE_2D, xscale=2, yscale=3.5);

ImageTexture it1("textures/natural/moss");
ImageTexture it2("textures/wall/brickwall2").addModulated(GL_BLEND, it1, sm);

 

Or something.

[Domarius]

I can speak from experience.

 

There are apps meant for pre-rendered 3D movie creation that let you automatically generate a huge texture to cover a landscape based on realistic landscape ... quirks (can't find the words), wear caused by erosion, grass, etc, configured by some inputs you provide.

 

You can then edit huge images in Photoshop because it knows how to swap out from RAM to HDD, the stuff you're not looking at, when you're zoomed in, so its fine.

 

Also, the way you traditionally go about plotting road and paths textures onto a terrain is either to cut poly's into the terrain to accomodate where the path goes, which is not an option if your collision engine expects a uniform grid mesh for the terrain, in which case you use the technique Carmack described, where you specify 2 overlapping repeatd texures (eg. grass and road) and then supply a low res alpha map with paths drawn on it, where the road texture shows through.

 

If it's all one big texture, you don't have to fuck around with that nonesense. Just draw anything wherever you please.

 

 

And at the moment, you can only automate texture generation so far before it becomes more worthwhile to just draw the things you want. Maybe muddy puddles on the side of the road, or pot-holes.

[OrbWeaver]

Also, the way you traditionally go about plotting road and paths textures onto a terrain is either to cut poly's into the terrain to accomodate where the path goes, which is not an option if your collision engine expects a uniform grid mesh for the terrain, in which case you use the technique Carmack described, where you specify 2 overlapping repeatd texures (eg. grass and road) and then supply a low res alpha map with paths drawn on it, where the road texture shows through.

 

I wonder if it would be possible to do something similar with the current Doom 3 material engine. As you can already blend between two textures based on the vertexcolours applied to the mesh, perhaps you could write a shader to do the same thing but based on an extra image stage in the material definition.

[Domarius]

Well I'd be surprised if you can't do it already, given the versatility of what I've seen of the engine so far, and how common place this technique is. But if they didn't, maybe they decided vertex based alpha blending was enough.

 

Traditionally you go with a low res alpha map because the extra poly's you create by having to essentially cut where the path is to go, is worth more effort for both you and the graphics engine, than the alpha map you would use. When I tried this, I still had an ok looking dirt path even though I'd sampled it down so small that the path was only one pixel wide on the alpha map but 1 meter wide on the terrain.

 

Here's my effort from last year Made in 3DS and exported into a game engine.

The dirt path is one repeating 64 x 64 texture, and the grass is also 64x64. The ENTIRE alpha map that covers the landscape, is also only 32x32, but the terrain itself is not that big, but still.. to think that path is only one pixel wide... just shows what you can get away with.

 

Here is the alpha map - check it out! SO tiny! This is full size!

 

Here is a shot of how big the map is. It was only a test, so its pretty small, but still, sort of gives you an idea what you can get away with.