MegaTexturing

Carmaks up to that "innovation" thing again..

http://www.gamerwithin.com/?view=art...cle=1319&cat=2

Sounds great, will make games like quake wars look great, now mabe oceans in games wont be the spammed texture fests that they are.

I have attempted something similar to this but for different purposes. Would be interested to see the end result.

My issue was I didn't like swapping or setting textures all the time so I created a large texture and then picked and choosed the portions I needed at run-time. Works good for terrain engines because you can set the detail level by simply changing the u,v coordinates. As the poly gets closer to the camera you increment or decrement the u,v or even just the u or v and you pretty much get a smooth transition from low detail to high since you are essentially using a sliding u,v texture window. This also eliminates the need for a lot of mip-mapping because this process is inherent in the texture design.

For instance if the top portion of the texture starts at low res and then moves down into high res you would increment the u coord as the poly gets closer to the camera. Since you are incrementing totally independent of cell sizes or texture size, etc, you can control the detail very precisely. In other words you could have a poly with the more distant portion using the lower res section and the nearer portion using the higher res. Quite nice.

I'm not exactly sure this is the same process he is talking about but it sounds similar.

I'm also very surprised that Carmack states that using a static vertex and index buffer and static terrain mesh is better than using geo-morphing. In my own trials a static vertex buffer with little or no LOD algos, morph algos, and/or culling algos actually performed better than using all that stuff. I'm not saying there is no use for Rottgers or other algos, but the hardware likes really large vertex buffers and is VERY good at hardware culling. A simple quad tree for culling and basic chunk-LOD is pretty much all I've ever needed.

Another company, Garage Games, came up with a chunk-LOD method which many engines use. I attempted this as well in my quad-tree renderer. You first decide how large each chunk is and then create a quad tree based on that decision. Each 'chunk' is it's own static vertex buffer. Note that each chunk has several detail levels of itself stored in memory. Each chunk differs from the next by a power of 2. I never solved the issue of T junctions and cracks but was close to doing so. Garage games has solved the problem as well as the 'popping' issue.

The chunk-LOD method works extremely well because it is well suited to modern hardware which loves to work with chunks of vertex data. It also fits very well into a regular grid which is much easier to work with than an irregular one. Levels of detail between each chunk can be used in calculations to fix the cracks and T junctions. The chunk-LOD is extremely efficient and works very well with quad-tree's which are better at representing terrain than BSP's and octrees.

I'm still working on the entire system but it's interesting to see that when you face a common problem, no matter who you are, you come up with a common solution.

Terrain rendering is a favourite subject of mine, so i'm just going to chuck in my 2c worth.

Good batching is the most important criteria for graphics cards performance, followed by efficient use of the bus. If you can load all your terrain geometry into one huge buffer once and never change it you can start to take advantage of the full vertex pushing ability of the hardware.

This was true 4 years ago and is more so now. In fact, 4 years ago one of the speakers at GDC discussed how low the throughput of most games were and challenged the industry to come up with a game that actually pushed 5Mverts a frame, which was about half the best case hardware limit at the time I think.

Today, cards with presampled texture reading and fast tessalator units are starting to become commonplace in the general market, so new games may do away with conventional LOD entirely. For example, you can presample a height map offline, including samples for tesselated (n-patch) verts, and then render high detail terrain from a handful of verts by cranking up the N-patch level online.

Texture mip-mapping is done in hardware, so i'd say you have to be quick about it if you want to scroll uvs on the cpu and come out on top. I've not tried it for that purpose myself though. Of course if fits into a vertex shader somehow your away.

If you have static terrain, try looking into the UVAtlas functions in DirectX. Using UVAtlas can do a lot to get rid of the stretch on the slope of hills you get by draping terrain with a simple texture.

Interesting article, thank you for posting that.

I find that when reading articles second-hand the content being written about comes across as a lot fancier/more complicated than it really is.

The comments to the article were interesting as well :)

Scrolling UV's is natively supported in DirectX and can be done without accessing the vertex buffer via texture transform flags. DirectX basically scrolls the texture for you which is quite nice for doing moving clouds, fog, etc. You could use this as well for the technique I mentioned.