Orbiter 2024 Launch readiness

[jarmonik]

Also, could we simply copy "tileedit" binary from Orbiter 2016 and add it to the repository, no need to include Qt ?

 

[n72.75]

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 ?

I think there should be be away to build them.
we can either create VS projects that get copied in, or cmake files that users generate them.

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.

 

[jarmonik]

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.

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.

Debug Libs are now include in the "SDK" PR.

 

[GLS]

Another "small" item to work is the "2016 Edition" scenario folder... maybe that should be renamed "Features", or the scenarios could be moved to other folders and new scenarios added showcasing the new 2024 features (the docking is one such feature).

 

[GLS]

Debug Libs are now include in the "SDK" PR.

So we now have binaries in git???

 

[jarmonik]

So we now have binaries in git???

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.

 

[GLS]

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.

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.

With that system, one day somebody will forget something, and the package will have debug and release libs of different versions. Yeah, its not the end of the world, but it would almost be better to just forget the github automatic builds and make packages completely manually.
Does this solution work? https://www.orbiter-forum.com/threa...of-debug-and-release-builds.41532/post-615576

As for time, the documentation alone will take at least another 2-3 weeks, so there should be time to try a few things.

 

[patio]

Hello

FYI @jarmonik

I think the latest commit broke the custom camera rendering (I use Generic Camera MFD)

the planet rendering is blurry (as if tiles are not loaded for Custom Camera Rendering)

 

[johnnymanly]

The camera distance resets when you switch between external/internal views.
I this expected behavior? this is in pr #446 and #448.

 

[patio]

Hello

FYI @jarmonik

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

 

[jarmonik]

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

Ok, 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.

 

[patio]

Ok, 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 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 ?

 

[GLS]

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.

Something like this:

...
|
+ 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
|
...

This would probably make the elev_mod data irrelevant, as with this system an addon could override the elev (and other tiles).
We then have the Antelope Valley data, which we probably want to load always.... could/should more than 1 modification tree be loaded?
Something to think about, in its own thread, away from this release.

 

[jarmonik]

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

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.

 

[jarmonik]

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 ?

Can't you just flatten the main elevation under the launchpad ? (in the furute)

1. We have Elev.tree
2. which is overridden by /Elev/ files (*.elv)
3. which are overridden by Elev_mod.tree
4. which is overridden by /Elev_mod/ files (*.elv)

For the tile textures we only have Surf.tree which is overridden by /Surf/ files (*.dds) so, the steps 3. & 4. feel a bit unnecessary and messy.

Might be more practical to have something like NASSP_Elev.tree (defined in a scenario) which would override the main tree downwards from a specific node.

 

[patio]

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 ?

 

[jarmonik]

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 ?

Yes, 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.

 

[patio]

Yes, 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.

I just tested your latest commit

It works

thanks

 

[patio]

hello @jarmonik

I still see a display bug similar to the flicker bug you fixed some time ago

I use D3d9 client

happens only with vessel markers enabled

see attached screenshots

 

[jarmonik]

So far. I haven't been able to reproduce the problem with stock vessels.