... how are textures handled. are they loaded into the gpu and if that doesnt fit to the cpu, or how doe this work??
if i have for example 11 mdls which have each a texture of 2048x2048 (~12MB) i have a nice bunch of data here. what happens with it ??

btw, lets not start a debate wether i should split my mdl's into many parts. if i did that i had around 1000 mdls to place manually so that isnt a good solution

Textures go into video memory. If not enough video memory is available, I think it uses regular RAM. As far as computing it, that I don't know, but I suspect it's the GPU (graphics processing unit) as the CPU isn't entirely designed (for speed anyway) for this sort of thing.

As for the "many parts" thing, you could make use of the multi-texture feature in the new MED for this and still only use one model.

yes, but that would require the same memory ammount as one single big texture as there are no parts which are textured the same

You should probably know that huge textures like that may not work in older video cards. Sticking with a maximum of 1024x1024 (the suggested maximum for compatibility) is better. With multi-texturing, you can split that 2048x2048 texture in 4 1024x1024's and add more compatibility for older systems. Of course, it'll still take up the same amount of memory, but it's the greater compatibility that makes it more important. Just a suggestion though.

Large textures can be automatically mip mapped down for older cards.

Textures are created in D3D usually using the default memory pool. This means they are loaded into video memory. But if there is not enough vid mem, they go into system mem... and then paging is quite fast also because of AGP .. so in general, unless you are using wayyyy too many textures, using a number of large textures is fine. you may get some slight jerks, but make sure that not all 11 2048 textures are visible at the same time...then you will get massive framerate slowdown even on fast cards.

thanks, that was the info i needed:)
too bad that they are going to be visible all at one time, but partly (if that counts)
i am building a very large city and have all houses on mdl, all streets and sidewalks one mdl, all skyscrapers one mdl. because if i use single mdls i would place them till i die

maybe i have to try another aproach. but i wanted to use baked texture and thus the placement must be 100% accurate

Hmm.. yes this seems to be a bad idea.. A better way: use tiling for the normal color skins, and and make seperate clones of the building model for the baked on texture, then make them almost the same size as the normal buildings, and just blend over the old buildings with the new building.. see what i am saying? This save your from having to make tons of huge textures, and if you want baked lightmaps for instance, they can be much lower resolution...

ok, well, i dont have a normal color skin, i have a very nice looking dirt filter applied to the whole szene combined with ambient occlusion and some unregular noise-textures mixed to that. so there is a lot of details in the texture which cant be reproduced this simple. and if i use a shader to reproduce it (would be possible) but i think that it wouldn't be faster in the end because of those multiple lookups i'd have to do

maybe i will try to do something like what octree would do and split my big city into a bunch of parts (say 8 subparts which would by themself be built up of those 11 parts) thus i could gain speed and go down to a size of 1024x1024. sounds fair??

Samller is often better ^^

i wrote a tool for jetpack_monkey which takes a multiple group multiple texture mdl7 and splits it into separate models per group and also generates a wmp file with all the models in it. could that help in your case?