Sign in to follow this  

ID Software's new technology, MegaTexture

This topic is 4588 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

http://www.bluesnews.com/cgi-bin/board.pl?action=viewthread&threadid=56993&boardid=1&id=&view=flatnew&start=0 A new game from ID Software and Activision. I just know it's going to be great but regardless of it's future fame and glory, i'm extremely interrested in their new technology, MegaTexture. The technology was present in the Doom 3 engine, just not used and i don't know if it's even fully functional in the Doom 3 engine. Does anyone know anything about this new technology? [Edited by - Cybrosys on May 17, 2005 8:46:11 AM]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ^_~

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
It's not nessicary (according to hte ARB) because the way immediate mode functions in OpenGL is very similar to how instancing works anyways. Phantom explained it really well at one point, but I can't seem to find it ATM.

In any case, the logic goes something like this: When doing instancting in DirectX, you set several constant values (usually the mesh/texture/etc) and then use that static information multiple times with a small amount of instance information (translation/rotation) to avoid swapping the more memory heavy elements in and out multiple times. The state-machine nature of OGL makes it a very close parallel to this behavior already, in that you can set, say, a texture once, and the driver doesn't have to touch it again until you change it.

Bleah, that was kinda jumbled. Anyone willing to correct me?

Share this post


Link to post
Share on other sites
As I understand it, since OpenGL has persistent attributes, you can do set the color once for 1000 objects which are drawn at once, then switch colors again, and draw 1000 more objects.

Also, due to the low overhead, this is very close to the speed of instance, for this specific sort of example.

However, this doesn't handle everything that instancing can do.

For instance, in d3d, you could have 7 colors and 37 rotations, and instance 1000 trees. Each tree would have color = index % 7 and rotation = index % 37. This would give very good variety with a single draw call.

So, you can instance multiple streams simultaneously, which can't be simulated using persistent attributes.

Share this post


Link to post
Share on other sites
I don't buy the claim that OpenGL psuedo instancing is competent with D3D instancing. Real instancing is certainly not needed as desperately in OpenGL, but to claim that it's wholly unnecessary is foolish.

D3D can, with instancing and shaders, use a single draw call to draw 10,000 trees, all with slight variations in them if you'd like.

OpenGL still requires 10,000 draw calls, it's just that they're 10,000 "low overhead" calls. But 10k draw calls is probably coming close to flooding your CPU alone. D3D doesn't have this problem. I had a prolonged discussion with Phantom about this, I don't remember ever coming to an agreement, but my stance is that "OpenGL pseudo instancing" is a lame cop out due to some inexplicable reluctance to implement real instancing.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by JD
Ok, here it is: http://www.shacknews.com/screens.x/larian

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


The engien looks alot like "Elder Scrolls".

Share this post


Link to post
Share on other sites

This topic is 4588 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this