Hi, I have been creating an environment for my game and I know from previous experience that megatexturing is best for this type of thing for great results (or at least with other game engines). With blender, there is a problem. My terrain needs to be 1 by 1 kilometres. squared. That is 1 000 000 squared metres. That is 512 000 000 pixels :eek:. That is one massive PNG file (2560GB with GIMP compression). Creating this would mean I would need to edit the uncompressed texture. I would need over 12 terabytes of RAM :no:. This is impossible, though I could use smaller textures, the game would still require ~6GB RAM just for 1 texture (and that’s only the terrain). Other game engines like which have Bethesda used for games like Skyrim, Brink, and RAGE all use megatextures for a more organic feel, and do it by loading only certain textures at certain distances and at view points (almost like occlusion culling) and manage to keep texture sizes low using great compression.

Could someone please explain to me how I can achieve this using Blender’s Game Engine?

To be honest, megatexturing is great, but has it’s limits. To be honest, for your game I would look into dynamically creating terrain. Whether this is from image maps created with perlin noise (or Simplex :)) or random chunks using a random function, i beleive if would be a better solution.

I completely agree that it’s a good method to use, but I prefer to have a controlled environment when developing a game, especially this one, which needs the detail for such an environment. Also, random generation leads to glitches.

somehow I doubt that all GPUs support such large textures. In my eyes it makes no sense at all. It is hard for designers to manage such textures as you already discovered. And it is hard for the GPU to manage such a large file.

I think a good option to manage a large terrain is to split it into several patches.

Just my opinion.

I would go with Monster’s method of splitting the terrain into several patches, and loading those patches when you need them. Rather than having a huge amount of large textures, you could have less textures, and even, like agoose77 said, dynamically edit textures to achieve the look that you’re going for (i.e. dynamically change a stencil map texture to appear a certain way).

If you want to go really, really out there:

Procedural generation is really advancing at the moment, and really interesting. However, if you want to maintain an artist-designed level, but with the sizes you’re suggesting:
If you were to create a rule, in code, which could create a map chunk from some giving input, you’d create maps using special seeds, which could be extracted from the map. in other words:

Generate the map texture.
use a special custom algorithm to convert the image into pattens of code.
These pattens can be converted back into images later on, but limited in how they can be different …
I can’t think how i can describe it better, but maybe someone else can help me think about it.

Only Id Tech 5 supports MegaTextures, and that was it’s groundbreaking feature, so it will be a while before it’s seen in other engines. Furthermore, I think they had to have multiple server handling terabytes of data to create the megatextures for Rage, so it’s not something we’ll be seeing at the hobbyist level for a while. And lastly, you don’t need megatextures. While they can offer some benefits, people have been making great looking games long before megatextures were available. It’s the artists more than the tools that make a great looking game.

Hm… I think I will have to split the texture up. Maybe into chunks about 1024x1024px? But I don’t know how I can get only textures that are in visible range to load (like occlusion culling). Would it be easier to just split up the terrain with the textures and then occlude the separate terrain objects?

LibLoad and LibFree? They can load meshes, so maybe it’d work for textures, too. Splitting the terrain up into chunks is probably easier, and you’d have to do that anyway to use LibLoad and LibFree (since they can load meshes, but not textures).