I think there should be be away to build them.What should we do with the SDK Samples, the code files are in place but there's no project files to compile them ?
Should there be some easy way the compile them without compiling the Orbiter, or are the code files enough ?
CMake adds more complexity to a build process. If we have someone new with little knowledge of build processes then it could be overwhelming. I don't know CMake all that well either. Even if new VS versions comes with a high rate the old project files still opens and works. If I recall VS 2019 can open VS 2008 solutions.cmake is probably the "better" option, as VS versions tend to go out of style pretty quickly. I'm not an expert in cmake though, so someone else would have to help with that.
So we now have binaries in git???Debug Libs are now include in the "SDK" PR.
So we now have binaries in git???
But images and textures are "sources" that we can't avoid. Plus, they don't change that often, as opposed to the libs, which are one of the final products, thus change pretty much every commit.Yes, Images and textures are binary files as well. Of course, it would be better if the Git's build process could automatically include the debug-libs in a zip packages but I have no idea how to do that and I don't have time to start looking into it. I don't see problem in building them manually.
the new elevationmanager::elevation method appears to be a lot slower than before
I traced the problem to be no cache hit when elev mod is found there
so the elev mod data are read from file every time
I think elev mod is needed for nasspOk, thanks for tracking it down.
What opinions there are about the elev_mod, do we really need two elevation layers ? It's a little messy.
I think we need something like a "tile modification tree" structure in the tile folders, so there is the capability to have multiple versions of tiles, e.g., KSC thru the years. The CONTEXT scn param would control which tile modification tree gets loaded on top of the base tree.What opinions there are about the elev_mod, do we really need two elevation layers ? It's a little messy.
...
|
+ Earth
| |
| + Archive
| |
| + Surf
| |
| + Mask
| |
| + Elev
| |
| + Elev_mod
| |
| + Label
| |
| + Cloud
| |
| + Mod
| |
| + NAASP
| | |
| | + Archive
| |
| + SSV
| | |
| | + Surf
| | |
| | + Mask
| | |
| | + Elev
| | |
| | + Elev_mod
| | |
| | + Label
| |
| + Future KSC
| |
| + Surf
| |
| + Mask
| |
| + Elev
| |
| + Elev_mod
| |
| + Label
| |
| + Cloud
|
+ Mars
|
...
I encoutered performance problems while launching on cape canaveral (NASSP) with latest build
the new elevationmanager::elevation method appears to be a lot slower than before
I traced the problem to be no cache hit when elev mod is found there
so the elev mod data are read from file every time
Can't you just flatten the main elevation under the launchpad ? (in the furute)I think elev mod is needed for nassp
the saturn rocket needs a perfectly horizontal lanch pad
maybe a local cache for elev mod data can be added ?
I have been watching the code trying to find the problem but no much so-far. In a cache, Elev_mod information is applied to a main tile and then cached. So, evev_mod doesn't require a separate cache.
I noticed that "LoadElevationTile_mod (lvl+4, ilat, ilng, elev_res, t->data);" was applied twice and it's fixed now. So, could you see if the problem is fixed from PR #450
If not then, since you are able to reproduce the issue, could you inspect the cache more closely why it doesn't get a hit ? First thing would likely be commenting out the "quadrant |= HasElevationTile" lines. If there is a problem that gives a false positive in ZTreeManager, it might keep trying to load a tile that doesn't exists.
I tried to add the following test and it solves the performance problem
if (reqlvl>= (qlvl + 4))
{
t->quadrants |= DWORD(HasElevationTile(qlvl + 4, qlat + 0, qlng + 0)) << 0; // NW
t->quadrants |= DWORD(HasElevationTile(qlvl + 4, qlat + 0, qlng + 1)) << 1; // NE
t->quadrants |= DWORD(HasElevationTile(qlvl + 4, qlat + 1, qlng + 0)) << 2; // SW
t->quadrants |= DWORD(HasElevationTile(qlvl + 4, qlat + 1, qlng + 1)) << 3; // SE
}
Does that seems correct to you ?
And if elev_mod data is found at a given level, should we try to find upper level data ?
I just tested your latest commitYes, of course, if the requested level is not the highest existing level then that would have caused the code to fail. How could I over-look something like that. Good catch.
I am little confused about (qlvl + 4) why the "+ 4" since, the initial for loop is " for (lvl = reqlvl; lvl >= 0; lvl--) "
Right now the elev mod requires a main level tile to work, without it, the data would need to be interpolated from a lower level main tile, which would require a lot of re-writing. There is also a problem that elevation in a planet scale is in "int16" format, might be better to use "float" to get a smoother slopes. Elevation files would remain in current formats. So, some planning would be required before starting to make changes.