Project D3D11Client Development

Pietrogramma

New member
Joined
Jun 3, 2013
Messages
6
Reaction score
0
Points
1
Hallo, where I can found the heightmaps for terrain 3d client? I wrote a PM at Asmi but hi don't reply me. Some of you can send me a PM with link?
Thanks and sorry my bad enlgish language
 

pbar1469

New member
Joined
Mar 3, 2013
Messages
8
Reaction score
0
Points
1
Hallo, where I can found the heightmaps for terrain 3d client? I wrote a PM at Asmi but hi don't reply me. Some of you can send me a PM with link?
Thanks and sorry my bad enlgish language

I second that request! :eek:)
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,406
Reaction score
588
Points
153
Location
Vienna
Asmi did not work on D3D11 since quite some time now, so chances are he is just busy with real life ATM or even abandoned work on it. You can either wait for him to re-appear on his own, or you can try to contact Glider, who might reply earlier and could possess the height-maps, too.

In general I view all content that is neither in a repository nor on a public download spot as non-existent, exactly for this reasons, especially in an open-source project.
 

WelshGit

New member
Joined
Jun 13, 2013
Messages
12
Reaction score
0
Points
0
Tho I cant say I've read all 50 pages of this thread I have searched the term "Horizon haze" and got no results (Tho I'm not sure the search function is in full working order at the mo) So sorry if i'm going over something well known. I too had problems getting the dx11 client to run, had constant ctd with no common factor in the orbiter log. It was stopping my graphics driver (Nvidia gt520 Driver version 311.06) I realise this is not completely finished and looks to have caused some head/screen meetings!
Any way I went through the whole fresh install/update, no addons, All options off/at minimum procedure and on my machine the problem is caused by the horizon haze setting in visual effects. I now have it running with all other options on/ maxed out (nearly) and most of my addons. As long as I leave that one off its beautiful. Your nearly there guys!

Hope this is of use to someone else.
 

dumbo2007

Crazy about real time sims
Joined
Nov 29, 2009
Messages
675
Reaction score
0
Points
0
Location
India
Hi,

I am trying to figure out the D3D11 renderer code. I have a few questions :

1. Is ROAM used to render the planets or another algorithm ?

2. What is the basis of the creation of the Tiles in the renderer. Is a tile simply the intersection of 2 sets of latitude and longitude lines ? What are subtiles ? How many subtiles within a tile ?

2. I see that TileLoader::LoadTexture() loads the textures along with a few other Loading functions for other maps. Does it load the .tex files or the .dds files ?

3. What is the format for .tex files. Does it have information about which part of the texture goes to which tile ?

Thanks for any information that you guys can help with :tiphat:
 

Glider

Addon Developer
Addon Developer
Joined
Apr 12, 2008
Messages
226
Reaction score
0
Points
16
Location
Saint-Petersburg
Not sure I still remember everything correctly since I was working with another terrain code recently with different projection but answer should be close enough.
Hi,

I am trying to figure out the D3D11 renderer code. I have a few questions :

1. Is ROAM used to render the planets or another algorithm ?
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.

2. What is the basis of the creation of the Tiles in the renderer. Is a tile simply the intersection of 2 sets of latitude and longitude lines ? What are subtiles ? How many subtiles within a tile ?
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.
So levels 1-4 are spheres textured with one preloaded during planet creation 256x256 texture for each level, levels 5-8 are also preloaded and created at the same time as 1-4 but they r divided into patches according to NLAT(number of latitude rows from 0 to 90), NLNG(number of tiles in one latitude row). level 9 is level 8 patches divided into 4 subtiles and so on.

2. I see that TileLoader::LoadTexture() loads the textures along with a few other Loading functions for other maps. Does it load the .tex files or the .dds files ?
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.

3. What is the format for .tex files. Does it have information about which part of the texture goes to which tile ?
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.

PS. You want to make another attempt to add terrain into Orbiter or its for another project ? if its for another I'd suggest - don't use orbiter's cylindrical projection. It complicates almost everything when u try to do anything more advanced than a very simple terrain without tesselation and with static mesh. The best way IMO is based on cube quadtree terrain. A bit more work at converting textures from sources but so much simplier code almost everywhere if compared to cylindrical.
 

dumbo2007

Crazy about real time sims
Joined
Nov 29, 2009
Messages
675
Reaction score
0
Points
0
Location
India
Thanks for the reply.

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

Whats the difference between sphere meshes and patches ? Arent they both the same as:

sphere-mesh.png


Also I noticed that a Planet.tex file like Earth.tex has multiple DDS files. I am assuming there will be 8 such DDS files corresponding to each of the 8 levels. So if I want to display at Level 2, I pick the 2nd DDS file and texture the sphere mesh with it ? Are the sizes specified for the DDS files inside the .tex files, just wondering how D3D11Client reads them out ?

PS. You want to make another attempt to add terrain into Orbiter or its for another project ? if its for another I'd suggest - don't use orbiter's cylindrical projection. It complicates almost everything when u try to do anything more advanced than a very simple terrain without tesselation and with static mesh. The best way IMO is based on cube quadtree terrain. A bit more work at converting textures from sources but so much simplier code almost everywhere if compared to cylindrical.

Yes, the ultimate aim is to add terrain support to the D3D11Client. But thats some time away for now :). 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
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 ?

I got some info here, though its for quad trees, not cube quad trees : http://rastertek.com/tertut05.html
 
Last edited:

orb

New member
News Reporter
Joined
Oct 30, 2009
Messages
14,020
Reaction score
4
Points
0
Also I noticed that a Planet.tex file like Earth.tex has multiple DDS files. I am assuming there will be 8 such DDS files corresponding to each of the 8 levels. So if I want to display at Level 2, I pick the 2nd DDS file and texture the sphere mesh with it ? Are the sizes specified for the DDS files inside the .tex files, just wondering how D3D11Client reads them out ?

No. Only levels 1-3 are done this way and use single DDS per level. Level 4 uses 2 textures (they can be applied on 2 west-east hemisphere meshes), level 5 has 8 texture patches, level 6 has 24 patches, level 7 100 patches, and level 8 364 patches (separate DDS entries in the .tex file). Levels 9+ use quadtree based on level 8.

For level 1-8 all the DDS entries are loaded sequentially. The size of a separate patch is stored inside its DDS record.

Whats the difference between sphere meshes and patches ? Arent they both the same as:

sphere-mesh.png
No. The image presents a sphere mesh. Sphere patches would use different number of longitudinal segments between different latitudes.

I got some info here, though its for quad trees, not cube quad trees

I think cube quad tree means using this:
[ame="http://en.wikipedia.org/wiki/Quadrilateralized_spherical_cube"]Quadrilateralized spherical cube - Wikipedia, the free encyclopedia[/ame]
 

Glider

Addon Developer
Addon Developer
Joined
Apr 12, 2008
Messages
226
Reaction score
0
Points
16
Location
Saint-Petersburg
Thanks for the reply.
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.

Also I noticed that a Planet.tex file like Earth.tex has multiple DDS files. I am assuming there will be 8 such DDS files corresponding to each of the 8 levels. So if I want to display at Level 2, I pick the 2nd DDS file and texture the sphere mesh with it ? Are the sizes specified for the DDS files inside the .tex files, just wondering how D3D11Client reads them out ?
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.

Yes, the ultimate aim is to add terrain support to the D3D11Client. But thats some time away for now :). 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
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 ?
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/

But, if u want to make this terrain for Orbiter u can't use cube to sphere terrain because all resources are in cylindrical projection and the next version of orbiter will have some changed cylindrical projection as well (according to http://orbiter-forum.com/showthread.php?t=31942), so any collision meshes/height fields will be required to be cylindrical. :) So u can't really use cube to sphere terrain in this case.
 
Last edited:

dumbo2007

Crazy about real time sims
Joined
Nov 29, 2009
Messages
675
Reaction score
0
Points
0
Location
India
ok, thanks for the detailed replies guys. I am currently looking at

TileManager::LoadTextures()
https://bitbucket.org/asmi/ovp/src/...1Client/TileManager.cpp?at=D3D11Client#cl-610

So I can see the logic in this function says that textures for all levels should first be loaded into texbuf (line 623). Then specifically for level 8 textures we preload tile textures at line 636.

Also in line 662 of TileManager:: PreLoadTileTextures(), we seem to be specifically adding subtile textures for level 8. Why dont we do the same for level 7 with 100 patches ? Or for level 6 with 24 patches ?
 

Glider

Addon Developer
Addon Developer
Joined
Apr 12, 2008
Messages
226
Reaction score
0
Points
16
Location
Saint-Petersburg
ok, thanks for the detailed replies guys. I am currently looking at

TileManager::LoadTextures()
https://bitbucket.org/asmi/ovp/src/...1Client/TileManager.cpp?at=D3D11Client#cl-610

So I can see the logic in this function says that textures for all levels should first be loaded into texbuf (line 623). Then specifically for level 8 textures we preload tile textures at line 636.

Also in line 662 of TileManager:: PreLoadTileTextures(), we seem to be specifically adding subtile textures for level 8. Why dont we do the same for level 7 with 100 patches ? Or for level 6 with 24 patches ?
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.
 

dumbo2007

Crazy about real time sims
Joined
Nov 29, 2009
Messages
675
Reaction score
0
Points
0
Location
India
Ok, I see that there is a TileManager::Render() and a TileRenderMgr class. Which actually takes care of rendering a tile on a sphere patch ?

Is TileShadowMgr required specifically for terrain ? I dont think tiles normally casts shadows in Orbiter.

What is TextureMgr used for ? Doesnt TileManager already manage textures for tiles ? Is TextureMgr used for the other textures, like for vessels and bases, caching stuff and moving them in or out of GPU memory as needed ?


Exactly where is the cylindrical projection calculation done ? Is it while rendering tiles on sphere patches ? So the calculation would go into TileManager::Render() ?

The following classes are specific to Terrain ? :

  1. TerrainManager
  2. TerrainManager_render
  3. TerrainManager_loading
  4. TerrainCollisionMgr

So they are not used if terrain is disabled ?

Is GDIPad used anymore ?

There is this large section from Line 29 to Line 65 in TileManager which seems pretty important in understanding how tile rendering works : https://bitbucket.org/asmi/ovp/src/...11Client/TileManager.cpp?at=D3D11Client#cl-29

patchidx{} contains the cumulative sums of the number of textures used in each level as we discussed before.

/* Tile meshes. */
TILEMESH TileManager::TPL_1;
TILEMESH TileManager::TPL_2;
TILEMESH TileManager::TPL_3;
TILEMESH TileManager::TPL_4[2];
TILEMESH TileManager::TPL_5;
TILEMESH TileManager::TPL_6[2];
TILEMESH TileManager::TPL_7[4];
TILEMESH TileManager::TPL_8[8];
TILEMESH TileManager::TPL_9[16];
TILEMESH TileManager::TPL_10[32];
TILEMESH TileManager::TPL_11[64];
TILEMESH TileManager::TPL_12[128];
TILEMESH TileManager::TPL_13[256];
TILEMESH TileManager::TPL_14[512];

TILEMESH *TileManager::TPL[15] = { NULL, &TPL_1, &TPL_2, &TPL_3, TPL_4, &TPL_5,
TPL_6, TPL_7, TPL_8,
TPL_9, TPL_10, TPL_11, TPL_12, TPL_13,
TPL_14
};

So TPL[15] contains template meshes for tiles. In each of its elements it has either a TILEMESH* or a TILEMESH
Now coming to the code above that, I can understand TILEMESH TileManager::TPL_4[2]; as level 4 requires 2 meshes, one for each west to east hemisphere. So we need 2 TILEMESHes

But then we also have TILEMESH TileManager::TPL_6[2]; So Level 6 also needs 2 meshes, one for each hemisphere ? But then why does Level 5 also not need the same and make do with only 1 TILEMESH ?

Does int TileManager::NLAT[9] = { 0, 1, 1, 1, 1, 1, 2, 4, 8 }; specify the number of latitude divisions for each level upto level 9 ?
 
Last edited:

Zamolxis

New member
Joined
Jul 28, 2009
Messages
4
Reaction score
0
Points
0
missing text in mfd and dim vc instruments...

Hello Devs and Fellow Orbinauts,

Kudos for the great work on the dx11 client thus far. The hdr features among others adds a whole other level of immersion to orbiter.

A am having a few issues with blank mfd text and dim virtual cockpit indicators (see attached) that's a game killer. I've searched the thread for similar issues with no luck so excuse me if I'm repeating something previously addressed. I'm running win7 with latest drivers and dx11.

13.12.29 23-22-16 GL-01S.jpg

13.12.29 23-22-30 GL-01S.jpg

And here's the latest log;

View attachment Orbiter.log

Any ideas what might be causing this? Thanks.
 

Glider

Addon Developer
Addon Developer
Joined
Apr 12, 2008
Messages
226
Reaction score
0
Points
16
Location
Saint-Petersburg
Ok, I see that there is a TileManager::Render() and a TileRenderMgr class. Which actually takes care of rendering a tile on a sphere patch ?
Both. Tilerendermgr was probably a place to put all direct3d stuff related to terrain tile rendering, while render function was doing LOD calculations.

Is TileShadowMgr required specifically for terrain ? I dont think tiles normally casts shadows in Orbiter.
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.

What is TextureMgr used for ? Doesnt TileManager already manage textures for tiles ? Is TextureMgr used for the other textures, like for vessels and bases, caching stuff and moving them in or out of GPU memory as needed ?
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.

Exactly where is the cylindrical projection calculation done ? Is it while rendering tiles on sphere patches ? So the calculation would go into TileManager::Render() ?
Projection is done when u create resources for terrain. textures, heightmaps and meshes. Its the way how spherical mesh is divided into tiles.

The following classes are specific to Terrain ? :
  1. TerrainManager
  2. TerrainManager_render
  3. TerrainManager_loading
  4. TerrainCollisionMgr
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.

So they are not used if terrain is disabled ?
yep

Is GDIPad used anymore ?
Terrain doen't use gdipad because its only for 2D stuff in addons.

There is this large section from Line 29 to Line 65 in TileManager which seems pretty important in understanding how tile rendering works : https://bitbucket.org/asmi/ovp/src/...11Client/TileManager.cpp?at=D3D11Client#cl-29

patchidx{} contains the cumulative sums of the number of textures used in each level as we discussed before.

So TPL[15] contains template meshes for tiles. In each of its elements it has either a TILEMESH* or a TILEMESH
Now coming to the code above that, I can understand TILEMESH TileManager::TPL_4[2]; as level 4 requires 2 meshes, one for each west to east hemisphere. So we need 2 TILEMESHes

But then we also have TILEMESH TileManager::TPL_6[2]; So Level 6 also needs 2 meshes, one for each hemisphere ? But then why does Level 5 also not need the same and make do with only 1 TILEMESH ?
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:).

Does int TileManager::NLAT[9] = { 0, 1, 1, 1, 1, 1, 2, 4, 8 }; specify the number of latitude divisions for each level upto level 9 ?
yep.:yes:

Any ideas what might be causing this? Thanks.
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.
 

dumbo2007

Crazy about real time sims
Joined
Nov 29, 2009
Messages
675
Reaction score
0
Points
0
Location
India
So I have got them all down into 4 diagrams now :
https://docs.google.com/drawings/d/1bHMuh4-6PHRBUMgQwDDDHDLe-7tqSO62bNbBARKBoro/edit?usp=sharing

Are my assumptions correct in the diagrams ?

Also a clarification.
int TileManager::NLAT[9] = { 0, 1, 1, 1, 1, 1, 2, 4, 8 }; I think this specifies the number of latitude divisions for each level upto level 8 and not 9 right ?
Level 9 onwards we have subdivisions.

The 0 in the 1st element is just a dummy value. So NLAT[6] = 2 represents 2 latitude rows for level 6, i.e. 2 latitude rows in 1 hemisphere only. The other hemisphere also has 2 latitude rows. See diagram above.
 

Glider

Addon Developer
Addon Developer
Joined
Apr 12, 2008
Messages
226
Reaction score
0
Points
16
Location
Saint-Petersburg
So I have got them all down into 4 diagrams now :
https://docs.google.com/drawings/d/1bHMuh4-6PHRBUMgQwDDDHDLe-7tqSO62bNbBARKBoro/edit?usp=sharing

Are my assumptions correct in the diagrams ?
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.

Also a clarification.
int TileManager::NLAT[9] = { 0, 1, 1, 1, 1, 1, 2, 4, 8 }; I think this specifies the number of latitude divisions for each level upto level 8 and not 9 right ?
Level 9 onwards we have subdivisions.
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.

EDIT: NLAT = 1 for 4 rows from south to north was wrong - should be NLAT = 2

and, yes, 0 in NLAT array is just a dummy value because its always used like this: NLAT[level], and theres no level = 0
 
Last edited:

Zamolxis

New member
Joined
Jul 28, 2009
Messages
4
Reaction score
0
Points
0
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.

Have you no faith in d3d11 that you would send me to the other dev team :blink: ;) ?? 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.

Just curious if anyone here had a similar issue and what was done to fix it. It'd be a shame not keep up with the d3d11 client since the hdr and atmosphere effects alone are worth sticking with it.

Cheers.
 

dumbo2007

Crazy about real time sims
Joined
Nov 29, 2009
Messages
675
Reaction score
0
Points
0
Location
India
Got a question regarding VObject.h:

I guess the noise members in the PlanetaryConfig struct is all related to terrain:
https://bitbucket.org/asmi/ovp/src/...ent/VObject.h?at=D3D11Client - Terrain#cl-121

In fact lines 116 in the above file right down to 149 is all specific to terrain in struct PlanetaryConfig ?

I have been wondering why there are so many friend classes all over :). Every class is a friend of nearly every class. For performance reasons, easier to directly access private members than make accessor

How essential is libpng in the include folder to the client ? I see its used in various places like :

TextureGenerator::HeightMapProc
TerrainManager::LoadL8HeightData
TileLoader::LoadLandCoverMap

I am temporarily removing the heightmap related classes for terrain. So I can get rid of the first 2 safely. What exactly is the land cover map ? Is it related to terrain too ?

Is TextureGenerator.cpp only for terrain. I see only heightmap related functions in it. I am guessing its not needed for non-terrain/heightmap textures ?
https://bitbucket.org/asmi/ovp/src/...TextureGenerator.cpp?at=D3D11Client - Terrain
 
Last edited:

Glider

Addon Developer
Addon Developer
Joined
Apr 12, 2008
Messages
226
Reaction score
0
Points
16
Location
Saint-Petersburg
Got a question regarding VObject.h:

I guess the noise members in the PlanetaryConfig struct is all related to terrain:
https://bitbucket.org/asmi/ovp/src/...ent/VObject.h?at=D3D11Client - Terrain#cl-121

In fact lines 116 in the above file right down to 149 is all specific to terrain in struct PlanetaryConfig ?
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.

I have been wondering why there are so many friend classes all over :). Every class is a friend of nearly every class. For performance reasons, easier to directly access private members than make accessor
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.

How essential is libpng in the include folder to the client ? I see its used in various places like :

TextureGenerator::HeightMapProc
TerrainManager::LoadL8HeightData
TileLoader::LoadLandCoverMap
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.

I am temporarily removing the heightmap related classes for terrain. So I can get rid of the first 2 safely. What exactly is the land cover map ? Is it related to terrain too ?
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.)

Is TextureGenerator.cpp only for terrain. I see only heightmap related functions in it. I am guessing its not needed for non-terrain/heightmap textures ?
https://bitbucket.org/asmi/ovp/src/...TextureGenerator.cpp?at=D3D11Client - Terrain
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...
 
Top