ok. so i’ll try to explain the idea to everyone.
the given problems are large ,detailed 3d worlds which have to run on older hardware. simmilar to a 2d-tilemap -> 3d-tilemesh solution. and the storage of these maps.
(cause of the old hardware and missing or limited multitexturing ,terrains generated from heighmaps are not a good solution)
saving large worlds (10x10km for example will result in lots of data ( about 800mb for terrain itself with 0.5m horizontal ground resolution) if saved directly into a bam file
so the idea was to use small 3d-tiles which can be used over and over. small spieces of ground,terrain,whatever. these tiles saves a lot of memory, several thousand unique tiles of around 4x4m only cost few MB disk space.
so you need a 3d-mesh tileset and a 2d-texture-tileset to texture them. textures can be exchanged of course.
to make it more panda-friendly its good to build a little larger world blocks with these tiles. 8x8 tiles with each 4+1x4+1 vertices flattened together at runtime should do the job(depending on the hardware.
the new thing about this idea was to save the position of the meshes in png files. since panda has good acces to images. to the pixel position makes the horizontal position the color gives the vertical position,texture and rotation,and the mesh-tile number.
having 2 png textures gives us between 48 and 64 bit’s to store stuff.
48bit are fineso 2x24bit in textures:
-2 for rotation (enough since sqares can be rotated only in 90degree steps to still fit together)
-15 for the texture-number ( allows 32768 different textures)
-15 for the mesh-tile-number (allows 32768 different 3d-tiles)
-15 for the vertical position (allow 32768 vertival positions)
-1 left for anything else. perhaps a non-collision-object atribute or something.
of you need more just add more files or use 32bit textures to store the extra information.(having a vegetation map could be useful, or store stuff like ore recources or someting like that)
having several layers above each other is no problem since you can just add more textures and give them a layer-count in the filename. since png is a lossless compressed format you will have small files if you have just a few blocks you want to store. cliffs are therfore no real problem.
so in the end you have for example a 256x256 png image. used to create 32x32 world blocks, each world block consists of 8x8 3d-tiles, each world block consists of 5x5 vertives which make 4x4 quads.
a fully textured 1000x1000meters (with 1m horizontal resolution) map with “worst-compression” would end up in 2x~200kB images = ~400kb +(the textures and 3d-meshes which both can be used over again)
all in one bam files would be around 8mB + textures
in a heighmap perhaps 200kB + textures + 100-200kB blendmaps
objects like buildings,players,vehicles,water,special world parts or such still would require “a normal” way to store them since the dont really fit into the 4x4x0,1 m raster (or whatever rastersize you choose). but they are fewer objects than the world consists of and shouldn’t eat up the harddisk.
this shure is a little bit abstract and simmilar results could be archieved using and storing simple lists in python (the python files again would need to be compressed). but i think png’s are fine since it’s quite easy to store and access them and they are already compressed (not all to bad even with this kind of data)
additional advantages are:
-posibility to stream new maps over the internet. a few kB png’s wont even hurt a dial-up connection too much.
-allow the user to edit his world during playing (designated region where users,or chosen editors are allowed to edit). a admin or supervisor would just have to approve it.
-extendable to insane scale
"recentering the world"alows infinitive worlds and avoids precition problems (using lots of png’s, not one huuuge;) ;only limited by the disk space)
-the larger the world the more efficient
-tons of details and high freedom in map design.
-possible to self-tune it for every end-user with a small test-application (depending on the hardware to get the best vertex count per object, viewing distance, nuber of displayed objects etc)
drawback:
-smaller light bugs between the 3d-tiles can be seen depending on the way they are lit.
-no terrain-optimisation (only viewing distance and hide objects are possible)
-more work to create the textures (compared to multitextured terrain)
-more work to create a 3d-mesh tileset (compared to multitextured terrain). well once this work is done its easy…
-needs some extra work on a scene editor to add this all. (well not too hard)
if there are any questions regarding how this should work i’ll try to explain or to create a small illustration of it =)
ps: damn… just wrote another endless post… bad habbit of mine
. but i hope you find it at least useful