Loading images from RAM to graphics card memory? (big maps problem)

Started by
10 comments, last by nb 16 years, 10 months ago
When i need really big maps for my game, i cant put all the map image data to my graphics card memory, like if the map takes over 256 megs, it wont fit to most users graphics cards. I am using pixel data, so the maps are drawn with some painting program for example. Solution to this i thought is it possible to load the images on fly from the RAM? Most people have more RAM than gfx card memory. So i would split the map into 256x256 images, and when i move in the map, i would load only the images around me which i see. Or is there some better ways? Reading from harddrive? i think thats too slow... So how this can be done?
Advertisement
In general you, the progammer, have very little control over what gets into the GPU RAM. That's all up to the driver. So if you texture your objects and terrain in typical game fashion then it'll all just work.

Now, there is a solution for giant textures called mega-texturing (or something like that). Carmack is using an id software variant in their next big engine platform.

However, at the end of the day cards don't currently support textures bigger than 4096x4096. Therefore, no matter what, your texture will have to be broken up into chunks at runtime that are at least that small before they are bound to objects in the world in the texture pipeline.

-me
Does this mean i cant load my textures from RAM to the GPU RAM on fly?

So i am limited to use 256megs textures? (i could make maps smaller by tiling them, but its not what im finding atm).
Quote:Original post by Emark
Does this mean i cant load my textures from RAM to the GPU RAM on fly?
So i am limited to use 256megs textures? (i could make maps smaller by tiling them, but its not what im finding atm).

No, not at all. As long as you are developing for PCs (rather than consoles or embedded systems which tend to be more limiting), you can use as many textures as you want, and the underlying implementation (Direct3D or OpenGL) will take care of moving the textures back-and-forth from main RAM to VRAM as needed. In addition, if you more texture space than would fit in the main RAM, the operating systems 'virtual memory' system will also come into play, and handle moving textures from the Hard Drive to main RAM as needed.

Edit: For performance reasons, you probably need to split those huge maps up anyway, so that you can cull areas that are not visible, etc.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Quote:Original post by Emark
Does this mean i cant load my textures from RAM to the GPU RAM on fly?


Well, you can but AFAIK you don't have direct control over it.

Either way you can't use textures bigger than the maximum size that the graphics card supports (different for differenct cards but almost always smaller than 4096x4096). For something to get textured it needs to be in the GPU RAM, so if you're seeing things get textured then they are in GPU memory.

Quote:Original post by Emark
So i am limited to use 256megs textures? (i could make maps smaller by tiling them, but its not what im finding atm).


No single texture can be 256 megs in size because no card will support it. At runtime you'll have to break it up into smaller chunks. You can have more than 256 MB of texture in a single scene but the GPU will have to swap from RAM; if this happens a lot per scene it may slow your application down.

-me
Oh yeah, i didnt mean to use 256 megs single texture :D As i said at the first post of this topic, i would need to split them into 256x256 chunks, but the total size of the textures should be 256 megs or less, because then there is no need to swap textures between GPU RAM, RAM and VRAM? (256megs i chose because most cards dont have more than 256 megs memory).
Just look up MegaTextures already. It's exactly what you need and the overall methods he describes using will get you on your way. Our implementation (I made a procedurally generated 4GB texture) took us 2-3 hours of coding to get working. It's not perfect but you've likely wasted more time waiting on replies after MegaTextures were mention then it would have taken to research it and implement it yourself ;-)

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

I didnt find good article about megatexture which really explains how it works. Or then i just missed it because its too simple?

Can you give me link to some good article about it?
You do have some limited control. You know that once you access a texture for rendering it is in GPU RAM. As long as the amount of GPU mem being used does not approach the maximum, the the texture should not be pulled out of GPU mem. When you want to swap something out of GPU ram you can either overwrite an old texture (if it is big enough) or delete some old textures (slower).

There are some examples online of texture managers that track the amount of GPU mem being used, and when a limit is reached it starts overwriting or deleting old textures.
Quote:Original post by Emark
I didnt find good article about megatexture which really explains how it works. Or then i just missed it because its too simple?


There's not much out there that's going to give you the full algorithm. Just google "MegaTexture" and you should be able to get enough info to throw together an algorithm.

-me

This topic is closed to new replies.

Advertisement