Talk:MegaTexture

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.

Untitled

MegaTexture is a id's engine technology name.

By painting a single massive texture (32000x32000 pixels) covering the entire polygon map and highly detailed terrain

this technology is a ClipMapping and Unique Texturing.

Prior Art

Seeminingly identical texture streaming techniques have been used for many years in flight simulators and other similar applications. If Mega Texture differs significantly from these, the differences should be highlighted. Otherwise, the prior art should be clearly called out and Mega Texture should be defined primarily as id's internal name for this farily common technique. - Anonymous.

Yes. It's an old, standard trick. It's not to separate the textures. Didn't we learn this lesson decades ago? If not, it's because games aren't always eloquently programmed, to shorten the hectic, chaotic development time. This article should be changed to a
texture map. Erudecorp 00:16, 22 October 2007 (UTC)[reply
]

As usual, John Carmack is credited with the discovery of something that has plenty of prior art. The levels in Bungie's "Myth: The Fallen Lords" fit the description of a megatexture. I know because I worked on that game. Ohmantics (talk) 19:38, 8 December 2010 (UTC)[reply]

Oh STFU 50.126.107.248 (talk) 22:01, 2 December 2022 (UTC)[reply]

The link to the map-editor

Quote from the page in question: "An automatic disk-paging system (A.K.A. map-tiling) that supports heightfields up to 128k × 128k pixels in size (16 gigapixels) and textures up to 4M × 4M pixels (16 terapixels). Want to make megatextures? No problem!"

If the requirement for creting (wich we have yet to see) to be able to call the 3Dmap-editor to be able to create MegaTexture on the only basis on that the texture-maxsize is 'mega'-big, then there are litterly a houndred editors out there that can make it.

The mapeditor is the least of the 'amazing thing about the technology. It's the technique to not having the maps be enourmous in size and require a lot of memory or swapping to take place.

I prupose that the entry be removed from the article 203.144.160.243 13:19, 2 May 2006 (UTC) Zarkow[reply]

  • If it offends you thus, Zarkow, I'm happy for it to be removed. 131.170.90.4 06:38, 3 May 2006 (UTC)[reply]
    • I'm seeking concensus. Since right now regarding the basic texture, Photoshop can create that too... =) Zarkow 11:34, 3 May 2006 (UTC)[reply]
      • I may as well 'fess up to this. I'm the (formerly) anonymous poster in question, and also the main developer of the software in question. I'm sensing bad karma points here, so I really don't mind if the reference goes (a tad spammish?). Anyway, that said I would like to make the point that, while Photoshop/etc can be used to make large textures, it can't to my knowledge (and correct me if I’m wrong) generate procedural textures for terrain based on slope/etc, which how id generate their mega-textures. Quoting Paul Wedgwood (lead developer at Splash Damage) from this interview: "MegaGen can automatically distribute materials such as grass, sand and rocks across the landscape, based on altitudes and the angles of incline. MegaGen makes moss grow up the steeper slopes and cling to rocks, grass grow in the flatter areas, and sand and snow gather appropriately in the crevices between rocks." That's not something Photoshop can do automatically, but it is something the aforementioned program does do automatically. Atorpy 13:38, 3 May 2006 (UTC)[reply]
        • You are correct that PS cannot make procedural textures based on heightmaps, but many other applications can. (Also a lot of inhouse apps in several indie-companies ofcourse.) The point, and it isn't to pick on you, is to stop any link-spamming/hording of apps (before it happends) that can make textures of large sizes [and so on], when the technology using it is something completely different. It's the comparison of linking a paintmixer on Da Vinci's page..=) 203.144.160.242 03:31, 20 June 2006 (UTC)Zarkow[reply]

Special

So what's special about this that it would be wrong to say that it's just one big texture made up of a lot of smaller textures? Because they're saying that all sorts of different looking surfaces are drawing off the same texture. And if that's so, what makes this better than them each having their own texture? Hackwrench 05:31, 4 May 2006 (UTC)[reply]

  • 'Using maximum 8 MB of memory on the graphics-card.' That is the main difference between this technique and for instance other games that have large outdoor-areas. For instance Battlefield1942 had several large pieces of texture (each going to the limit of texture-size as set by the graphics-cards of that day) that accummulated took up much more memory on the clients [than 8 MB]. The technology really allows map-makers to have really high-resolution textures (if they want, it still costs in space on disc) but only leaving a minor memory footprint on the clients at run-time. Zarkow 203.144.143.5 00:51, 7 August 2006 (UTC)[reply]
  • One of the main points of megatextures/clipmapping that is being missed is how it is applied. Traditional texturemapping of a set of textures involves applying each texture to the mesh, one at a time, slicing up the mesh at the texture seams. Also, mipmapping a set of textures becomes problematic -> most systems will generate maps on a per-map basis, which has aliasing artifacts, unless the process combines adjacent textures for each mip-level. If done right, you treat the megatextures/clipmap as one texture when applying UV coordinates. Then the software or hardware (in SGI's case) automates the process of tesselating the mesh at texture seams, and if required, creates the mipmaps correctly. Grimdel 15:22, 15 June 2007 (PST)

Recent vandalization of this page

I suspect that this Mojohompo who vandalized this page comes from a forum where I'm a moderator. Any chance I could be provided with the IP address Mojohompo did this from so that I can verify? (my clue is that he posted the unmodified Carmack image on the forum, with the same file name it has here.) Echo5ive 16:17, 4 May 2006 (UTC)[reply]

"gaming press"

I suppose a reference to what "Gaming press" article exactly hints at the underlying algorithm would be nice. 84.184.115.88 22:40, 27 August 2006 (UTC)[reply]

Torque

How can we say Torque uses a similar technique when we don't actually know what technique MegaTexture uses? EAi 19:50, 6 August 2007 (UTC)[reply]

One could reason that the technique is the same but what might be new here is the way it's implemented in terms of data formats. Terrain paging is nothing new, and sometimes the texturemap is paged as well. What's different here is that ID must've found a smart way of storing the texture data in such a way that it can be effectively read with at least seeks as possible for large terrain sizes. This is just an educated guess (well... for a given value of educated, that is, I've never written my own terrain code, was always someone else's job, thank god). So yeah... in that sense the technique is similar. --ShadowCode 09:56, 12 August 2007 (UTC)[reply]

Sparse Voxel Octree

Some of that information was removed, however it is directly related to mega-texturing technology as it is an evolution of it. Perhaps a better approach instead of blatantly deleting good and useful information would be to make it on its own page. JonOlick (talk) 23:31, 5 November 2009 (UTC) Jon Olick[reply]

I did not remove this paragraph, but I added a [citation needed] tag today. I think that people removed it because it is unsourced. If nobody source it, then it will be eligible for deletion. Hervegirod (talk) 15:07, 3 January 2010 (UTC)[reply]
OK, i added ref from SIGGRAPH conference, but you should not rely on others to do this. Being the first to add a paragraph, probability is that it's easier to you to add sources than for others. Hervegirod (talk) 16:41, 3 January 2010 (UTC)[reply]

Unique Texturing

Nothing about the Clip Mapping Technology is Unique Texturing only. Thats just simply how id is using it. JonOlick (talk) 03:50, 9 November 2009 (UTC)[reply]

Holy reference

Seems like ref #2 is gone, anyone still has a copy? Zoef1234 (talk) 12:44, 19 July 2011 (UTC)[reply]