ID Software's new technology, MegaTexture

The way they describe it, it sounds like some sort of fancy procedural texture, possibly based off of artist created ones? (Don't quote me on that, just theorizing.)

It's probably not nearly as big as they make it sound, but I would be interested in knowing more about it... Wonder if JC will update his blog any time soon.

EDIT: Direct Link to Screenie I personally don't see anything overly impressive about the landscape.

The texturing as well as the terrain geometry management seems to be innovative so i'm quite excited and upset at the same time. Why upset? Well i want to know how they're doing whatever they are doing :)

Edit:

No the landscape isn't at all impressive, it's their new technology and the promise of what to come that is.

It was released to probably hype their site so that folks would keep them in their minds. Actually to tell you the truth, the tiling problems appear only when you're flying above the terrain. When you're close down the detail texture takes care of it. Plus, you put vegetation on the terrain and nobody is going to notice any tiling that you might have. Then again who wants to play a game on desolate place like mars? I wouldn't. They need to take a lesson from far cry and other outdoor engines imo. I would go with far cry engine with some doom3 tech for indoor scenes. You got to have the whole texture layering system in the editor as well as special tools to build the terrain. You need to have deep bottoms so you can take a sub and go hunting in the ocean as well as fairly tall hills to get lost in as well as flat ground for driving and stuff. Where's the water in that pic?

Quote:

Where's the water in that pic?

What are you talking about? Those soldiers are 70% water.

MegaTexture is referenced in the doom 3 SDK, but it's not really used anywhere, there is just a pointer to a MegaTexture object in one of the shader stage structures.

My guess of what MegaTexture is, based on the 'giga' size and since it's used for terrain, is clip-mapping or something similar to it. Then again I could be so far off base it's not even funny. :) I really don't know a whole lot about clip-maps yet, but from what I remember reading a while back I think this is what MegaTexture _might_ be, dunno.


-SirKnight

Actually, that sounds very feasible. I think you hit it right on the nose.

Clip-Mapping paper (PDF)

Its an interesting concept, and looking through it I think that it may be used for parts of Unreal Engine 3, but I have to wonder how many situations it would REALLY be useful in. Not to mention it would be a nightmare to work with textures that large in photoshop.

So what exactly am I suppose to be looking at? The terrain or the army guys?
Where's this new technology in this screenshot?

http://www.bluesnews.com/screenshots/games/etqw/20050516/

If it's the terrain, well, you can't exactly see very far in the distance.
The view is blocked off with hills.

70% water and 30% air? :)

I'm far from impressed of the terrain in this screen. If you don't pay attention to the foreground and to the sky, but only the terrain.. it looks quite blurry and ugly. I've seen many amateur terrain engines that looked better. Don't fall for it, this "megatexture" technology screams "marketing hype".

However i do like the sky, the characters and the vehicles, even if they're not at the UE3 level. The lighting is also very coherent.

Y.

I feel the same way. I was looking at shugashack's (gaming site) past 6 days with E3 and all its goings, and I noticed screenies of an rpg game I don't know what it was called though maybe legia or something like that. Anyways, really stunning non-photo realistic but game like gfx and it just goes to show you that you don't need to have super duper gfx card, just need to develop a good style and color. Upon seeing that game I want to play it eventhough I'm not too much into rpg games, there is something about it that brings me back to nes/snes days. I'll try to find it and post a link here.

Ok, here it is: http://www.shacknews.com/screens.x/larian

That reminds me, AlphaPrime game is looking like my cup of tea.

Okay, guys and gals, that was one screenshot of experimental? technology. And yes, the terrain looks awfull and is anything but impressive in the screenshot but that's not what's important. What's important is how the technology works, is it going to replace ordinary splatting/detail texturing that for example far cry uses?

Now that Instancing and such technologies are coming out, technologies that help remove draw calls and just push more work on the gpu that was cpu bound before. This technology, will it be the one that, as i said, replaces splatting/detail texturing? Maybe they're using a merger of both technologies?

On another note, i just want to hop into that aircraft(looks alot like the apache with jets) and fly around. Tanks and other models looks nice, but hey, what doesn't with the right texture maps ^_~

Yes, I realize that it's only one screen of an unfinished project. The point is that after making such a big deal about this "new technology" they certainly could have chosen a better way to showcase it.

Quote:

Original post by Cybrosys Now that Instancing and such technologies are coming out

Instancing is largely redundant in OpenGL anyway.

Quote:

Original post by python_regious Instancing is largely redundant in OpenGL anyway.

The nVidia paper on "OpenGL Pseudo-instancing" seemed to suggest that it gives mad performance gains on older hardware (gf fx) and slight performance gains on a 6800.

Interesting... Quote from the OpenGL ARB Meeting at the end of last year:

Quote:

# # Instancing geometry - no need, GL immediate mode rendering calls support this. Khronos may want to engage on this, though, since they don't have finegrained immediate mode calls.

Plus I've read in many other places that's it's not really worth it in GL. I'll take a look at that paper though, cheers.

I was refering to instancing using d3d. Let's say we want to render a sphere at 100 different locations. That would normally require us to:

#1 - Set sphere streams, vb && ib
#2 - Set eventual texture
#3 - Do a loop, for each sphere object
: Set the world matrix to the spheres trs(translation, rotation and scale) matrix.
: Make a draw call

Now as you see that's alot of draw calls, plus the need to set a new matrix each draw call. What we have here is a waste of cpu cycles.

What intancing enables is that you create a vertexbuffer, or InstancingBuffer whatever you want to call it, fill it with positioning data packed into vertex declarations via ie : TEXCOORD1-4 for the 4 rows of the matrix data.

Set the sphere's vb && ib, set the InstancingBuffer stream using a special Freq. call and call draw Once. Your object + texture will be cached on the graphics card and pumped out so many times you told it to be drawn.

Quote:

Original post by Toji Yes, I realize that it's only one screen of an unfinished project. The point is that after making such a big deal about this "new technology" they certainly could have chosen a better way to showcase it.

Yes, i agree with that. The terrain certainly wasn't impressive in any way which is kind of disturbing seeing as the main "big" news was about their MegaTexture technology.

Quote:

Original post by Cybrosys I was refering to instancing using d3d. Let's say we want to render a sphere at 100 different locations. That would normally require us to: #1 - Set sphere streams, vb && ib #2 - Set eventual texture #3 - Do a loop, for each sphere object : Set the world matrix to the spheres trs(translation, rotation and scale) matrix. : Make a draw call Now as you see that's alot of draw calls, plus the need to set a new matrix each draw call. What we have here is a waste of cpu cycles. What intancing enables is that you create a vertexbuffer, or InstancingBuffer whatever you want to call it, fill it with positioning data packed into vertex declarations via ie : TEXCOORD1-4 for the 4 rows of the matrix data. Set the sphere's vb && ib, set the InstancingBuffer stream using a special Freq. call and call draw Once. Your object + texture will be cached on the graphics card and pumped out so many times you told it to be drawn.

Seems pretty sweet. I think the ARB must have been talking about something else: I don't think OpenGL can do this, although perhaps the thought is that OpenGL's overhead for manually transforming the matrix between each instance is low enough that there aren't any significant speed gains to be had. That seems fairly unlikely, though.

From an OpenGL perspective, instancing works above the level of the vertex pipeline. I guess to implement it you'd need another set of vertex arrays for the instance data, and glDrawInstances(int type, int first_instance, int instance_count, int vertex_count, int first_vertex).

But perhaps a better general-purpose solution would be to add "geometry programs" which, unlike vertex or fragment programs, could access the buffer objects, generate geometry, and be executed directly by the OpenGL program. It might then be possible to render ROAM terrain or metashapes in a single call, offloading the work to the GPU.

Quote:

Original post by Nathan Baum I think the ARB must have been talking about something else: I don't think OpenGL can do this

It kind of all ready does, I suggest you read the ARB meeting notes, and some extension papers ( can't remember the ones ) - they explain why it isn't necessary in OpenGL.