theres no ROAM there. The way it renders planets is similar to what other orbiter graphics clients do - on levels 1-3 its sphere mesh, on 4-8 its sphere patches which then on levels 9-14 get divided into subtiles using quad-tree algorithm. The only difference in case of dx11 is that these tiles are getting a bit tesselated using hardware tesselator.
There're always 4 subtiles in 1 tile of level >= 8. Subtiles are tiles of more detailed level that cover together same area that covers one tile of less detailed level.For example theres 364 (not sure I still remember it correctly though) L8 tiles that have 1456 L9 subtiles that cover same area but 2 times more detailed than L8 ones. L9 is divided into L10, L10 into L11, and so on. Since u need 1456 L9, 5824 L10, 23296 L11 tiles needed to cover entire sphere, highly detailed tiles are being loaded only when its needed while L1-8 are static.
It loads .tex files which are a collection of .dds files for many tiles written one after another into one .tex file for easier reading.
there're 3 types of planet texture files - Planet.tex (levels 1-8), Planet_tile.tex (levels 9 and above) and Planet_tile.bin(information about which texture in PLanet_tile.tex goes into which tile. Planet.tex has textures in the same order in which tiles are created for these levels during planet creation.
. I am trying to clearly understand what the client does for now. Yes, I will have a look at cube quadtree terrain. My main reference is http://www.amazon.com/Introduction-3D-Game-Programming-DirectX/dp/1936420228
No. The image presents a sphere mesh. Sphere patches would use different number of longitudinal segments between different latitudes.Whats the difference between sphere meshes and patches ? Arent they both the same as:
sphere mesh is entire sphere, sphere patch is a part of sphere mesh defined by level, ilat, ilng coordinates.
one texture can only be used on one tile. they have dxt1 compression(for color textures) so their size is always same(dxt1/dxt5 have constant compression ratio, 0.5 byte per pixel for dxt1 and 1.0 bpp for dxt5 ) and since they r stored sequentially in file, the client reads them one after another in a loop and stores pointers to textures in the tile array (of 1+1+1+2+8+24+100+364=501 elements) which have same sequence of tiles that we have in .tex file.
Good luck with trying to add terrain to orbiter (especially with trying to make collisions with it without anything except AddForce() and attachments or another buggy hacks). Cube quadtree is indeed means using this [ame="http://en.wikipedia.org/wiki/Quadrilateralized_spherical_cube"]Quadrilateralized spherical cube - Wikipedia, the free encyclopedia[/ame] to divide sphere into 6 same tiles that cover same area and deformed in the same way, and then dividing these 6 main tiles when u need more details in the same way its done in http://rastertek.com/tertut05.html. Theres some info about this kind of terrain here - http://proland.inrialpes.fr/doc/proland-4.0/core/html/index.html ("spherical deformation" part of that page shows also how to compute positions of vertices in shader without any static meshes along with many other interesting ideas implemented there) also if u try to google "cube to sphere terrain" u will get some links like http://acko.net/blog/making-worlds-1-of-spheres-and-cubes/Yes, the ultimate aim is to add terrain support to the D3D11Client. But thats some time away for now
The book shows a way to implement terrain, though I am not sure if it uses quad trees. Do you have any reference for cube quad tree terrains ?
So u can't really use cube to sphere terrain in this case.
No it actually loads levels 1-8 at 623 into texbuff sequentially and then preloads level9+ if preload option was enabled (which is a useless feature - makes loading of client a lot longer and consumes lots of memory while its much better to load tile only when u need it and then delete it after it wasn't used for some time... but that how it was in other orbiter graphics clients so its in dx11 too) and because levels 9+ are using quadtree based on level 8 tiles it passes pointer to first lvl8 tile into preload function.
Both. Tilerendermgr was probably a place to put all direct3d stuff related to terrain tile rendering, while render function was doing LOD calculations.
Yes, for terrain. It was required for rendering terrain on cascaded shadow map, if I remember correctly. Anyway there should be somewhere a place where tiles are being rendered to shadow map.
TextureMgr is probably for 2D only. Vessels and bases have textures that have no such manager, and terrain textures are probably managed in CachedTexture class.
Projection is done when u create resources for terrain. textures, heightmaps and meshes. Its the way how spherical mesh is divided into tiles.
Yes, all of them r specific for terrain, TerrainCollisionMgr was a worthless attempt to add some sort of collisions using addforce() and touchdownpoints. Other 3 were working.
yep
Terrain doen't use gdipad because its only for 2D stuff in addons.
number of meshes there is equal to number of latitude rows, except for level4 where its just 2 hemispheres. all tiles in the same row can be rendered using some rotation and a mesh at 0 (or was it 180... :hmm
longtitude around y axis. In a similar way it renders south hemisphere using same meshes but adds 180 deg rotation around z axis (or maybe it was x... :hmm.yep.:yes:
TBH none. I wasn't working on it for about a year already so maybe asmi will help u.
If not, theres D3D9Client which was already completed.
yep L4 probably has east and west hemispheres, because L4 tiles use 2 256x256 textures which if placed one after another will form earth sphere texture in cylindrical projection. and NLAT is number of latitude rows from 0 N to 90 N because south hemisphere on levels 5-14 is rendered by rotating north hemisphere tiles. so if NLAT is 2 it means that from 0 to 90 deg there will be 2 rows and 4 rows from south to north pole. and if NLAT = 1, then u have 2 rows of tiles from south to north pole. picture for L6 is correct.
yep, the last element there is for L8. NLAT for L9, 10 etc. is just NLAT[8] multiplied by 2,4,8 and so on.
TBH none. I wasn't working on it for about a year already so maybe asmi will help u.
?? All kidding aside I do like the d3d11 client and would like get it to a point where it is playable. It appears Asmi hasn't been on this thread since late 2012 so I'm not sure I can reach him. I'm currently using 111105 and opv_terrain. . Every class is a friend of nearly every class. For performance reasons, easier to directly access private members than make accessor
Probably yes, but I think this struct isn't being used anywhere. Probably its one of pieces of useless code that doesn't actually work.
For performance reasons all this stuff with friend classes and reinventing STL containers everywhere in the code doesn't make any sense. But this code was written more than 3 years ago and slightly changed since then(at least that part in vObject.h) so it has a bad quality because I've written my first program about 4-5 years ago :lol:. Feel free to replace this bad code with something better or just use D3D9 code and convert it to D3D11 again if u want.I have been wondering why there are so many friend classes all over
I was using it for decoding heightmap and landcover tile textures because PNG has lossless compression which is important for heightmaps and land cover data.
land cover map is a texture that defines land class for a point on surface - useful for things like placing trees where they should be or other vegetation. It has 8bit UINT value which is just id of land class at some point on surface (like water, city, some type of forest, grassland etc.)
Yep its only for terrain. It was the first attempt to add some noise generator in the client. It is also a piece of not-working code...
