Rage mods not possible, maybe.

[xav1r]

link:

http://www.gamasutra.com/php-bin/news_index.php?story=20291

From what i understand, it comes down to the amount of time and power to bake the megatexture information for a level. Since Im not very acquainted with megatexture/graphics technology, could some of the expert developers here provide their opinions on this?

thanks

[Dragonlord]

The problem is that Rage ( or Tech5 in this case ) is a pure mesh based game world. This means the entire world is modeled in a 3D application and texture with one huge texture. This means changes late in the production is a killer. Furthermore working with such huge textures is not for the feint hearted since the disk and memory consumptions ( CPU and GPU wise ) are just insane.

I checked out that mega texture myself while looking for a suitable way to deal with terrains in my engine but John's solution fell flat for me. The idea is good and his optimizations are well thought off but still it's limited and fails if you try to venture outside the boundaries of the system ( like multi-rendering, redirected rendering or seamless and giant worlds ).

For modders this is going to be tricky since it's like making one huge scene in Blender and then doing a huge texture for it. There's no room for prototyping and this is one of the huge shortcomings of this technique. This is also why I do not think MegaTextures are going to catch on. Good case study of John nevertheless.

EDIT: I need to make a little precision on the things I wrote. There is one huge mesh with one huge texture used for the terrain ( mostly height-map type terrains where small overhangs are possible ). Object meshes though can be used with conventional texturing for doing things like caves, buildings and various stage props.

[Svartalf]

Not possible isn't quite accurate. Dragonlord's telling it mostly as it probably will be. What'll end up happening is if you're doing modding, you'll need a small cluster of dual/quad/oct-core systems to do the work. It won't be the same story as it was in the past. It won't be impossible to mod, but you're going to have to be more of a nutball like myself with something like that class of hardware just kind of lying about. Moreover, the skillset's going to be a couple of notches higher up the food chain to be able to do a level or a complete conversion if this stuff catches on. As Dragonlord said- I don't see this taking off in the large anyhow.

[grantek]

Not possible isn't quite accurate.

Well, there's also the question of "if it's so difficult to mod, will id even release tools/support for modding". There's an SDK for ETQW, so without knowing anything about it I'm guessing there's Megatexture support there, but it's still a concern. I hope in the end id's philosophy wins through, they release an SDK and people prove them wrong with awesome mods

[Aradreth]

I'm sure that if iD releases the tools to mod rage it will be done in time. Where there's a will there's a way and so on.

[Dragonlord]

As mentioned you have one huge mesh with one huge mega texture. Yet though you have conventional mesh+texture support which can be done the old way. Hence for building and complex structures mega texture is not suitable ( since it works with a huge non-overlapping uv-unwrap of the huge mesh allowing for small overhangs but not complex structures ). Hence if you use mostly complex buildings instead of large land masses then you can get away without mega textures ( and you have to ).

[Thetargos]

May this boil down to the way the "world" is actually created by the tools? I mean, if in the editor you are able to build small bits independently before being "merged" into the world geometry and the textures appended into the one MegaTexture? Again, I do not understand much of how could it be feasible to do, much less the logic behind it

[Dragonlord]

No, this doesn't work like this. You use a 3D modeling application to create the mesh which is then exported to the editor ( as far as I know... not 100% sure on this step ). The mesh is uv-unwrapped in a non-overlapping fashion. The problem with non-overlapping unwrap is that the unwrapped geometry is required to not contain "stretching". Now how to explain this. If you take a plain for example and you create hills and valleys then you can look downwards on the terrain and make a snapshot and you see all the surface of the terrain. In this case you can make a non-overlapping unwrap. Now make an overhang, or a cave mouth for example. You find no angle of view anymore where you can see all surface at once. In this case the texture has to be stretched a lot to warp the surface into one which can be seen without overlap. You have then though introduced stretching into the uv-unwrap which is noticeable since some geometry seems to be texture with higher resolution others with less ( and the blend between different resolutions is what breaks afterwards ). Hopefully I could explain this a bit. You have to fiddle once with Blender and using the unwrap tool for different geometry ( use a kind of grassy plain and on the other hand the blender monkey ) and see what happens with the uv-unwrap.

[Thetargos]

No, this doesn't work like this. You use a 3D modeling application to create the mesh which is then exported to the editor ( as far as I know... not 100% sure on this step ). The mesh is uv-unwrapped in a non-overlapping fashion. The problem with non-overlapping unwrap is that the unwrapped geometry is required to not contain "stretching". Now how to explain this. If you take a plain for example and you create hills and valleys then you can look downwards on the terrain and make a snapshot and you see all the surface of the terrain. In this case you can make a non-overlapping unwrap. Now make an overhang, or a cave mouth for example. You find no angle of view anymore where you can see all surface at once. In this case the texture has to be stretched a lot to warp the surface into one which can be seen without overlap. You have then though introduced stretching into the uv-unwrap which is noticeable since some geometry seems to be texture with higher resolution others with less ( and the blend between different resolutions is what breaks afterwards ). Hopefully I could explain this a bit. You have to fiddle once with Blender and using the unwrap tool for different geometry ( use a kind of grassy plain and on the other hand the blender monkey ) and see what happens with the uv-unwrap.

That is actually quite clear. So what are the benefits of MegaTexture when it seems to be so limited? The only advantage I see to it is that you'd rather have one large texture map for stuff like purely outdoor levels, and if you have a mix in your mod/game, then the advantage of MegaTexture is rather limited (not to mention encumbered). The way I thought this worked was that if you created your level's base geometry and apply several little (or large) texture maps to form the basic look of the scene, and if you added (for example) buildings and stuff like that, the textures composing this geometry would then blend together in the MegaTexture. From your explanation, though, it would seem as if the buildings (being a protrusion, braking the plane) would introduce overlap and hence "stretch" and "distortion" to the uv-unwrapped map, in which case only the terrain texture is feasible to merge into the huge MegaTexture and the buildings would have to still rely on individual texture maps, like "objects" laying on top of the terrain (covered by MegaTexture). I suppose this technique is useful for the case of Rage and maybe other large outdoor based games with large outdoor levels, but it wouldn't be too useful for stuff like MMORPGs and other type of seamless transition worlds where this hugely immense texture map would be (I think, anyway) too much trouble to juggle around, even though the idea behind MegaTexture is to stream it to the GPU rather than loading it into memory and feeding it to the GPU... but wouldn't that cause too much I/O overhead, like in the past some games when running on tight resources had to resort to load from disk geometry/texture data, slowing things down? I guess on multicore systems it maybe possible to dedicate one CPU for I/O operations so that gameplay wouldn't slowdown, but then the rate at which data is fed into the GPU or another CPU would be critical.

At any rate, thanks for the explanation. I have used the UV map tools in Blender and it CAN be hard.

[xav1r]

As Thetargos was saying, yes, Im too failing to see the advatages of megatexture as a level building technique. So far its advantages only seem to be visual, as in "it looks more realistic, or prettier". Damn, so John Carmack's awesome megatexture creation is only making modding more difficult then.