Orbiter 2024 Launch readiness

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
Also, could we simply copy "tileedit" binary from Orbiter 2016 and add it to the repository, no need to include Qt ?
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,694
Reaction score
1,352
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,914
Reaction score
2,908
Points
188
Website
github.com
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).
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,914
Reaction score
2,908
Points
188
Website
github.com
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

Member
Joined
Sep 13, 2011
Messages
41
Reaction score
14
Points
23
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)
 
Last edited:

johnnymanly

Donator
Donator
Joined
Mar 17, 2008
Messages
55
Reaction score
23
Points
8
Location
Southwest Pennsylginia
The camera distance resets when you switch between external/internal views.
I this expected behavior? this is in pr #446 and #448.
 
Last edited:

patio

Member
Joined
Sep 13, 2011
Messages
41
Reaction score
14
Points
23
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Member
Joined
Sep 13, 2011
Messages
41
Reaction score
14
Points
23
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,914
Reaction score
2,908
Points
188
Website
github.com
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:
Code:
...
|
+ 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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Member
Joined
Sep 13, 2011
Messages
41
Reaction score
14
Points
23
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
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

Member
Joined
Sep 13, 2011
Messages
41
Reaction score
14
Points
23
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

Member
Joined
Sep 13, 2011
Messages
41
Reaction score
14
Points
23
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
 

Attachments

  • Capture d'écran 2024-03-26 123538.png
    Capture d'écran 2024-03-26 123538.png
    806.8 KB · Views: 15
  • Capture d'écran 2024-03-26 123610.png
    Capture d'écran 2024-03-26 123610.png
    909 KB · Views: 15

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,666
Reaction score
795
Points
128
So far. I haven't been able to reproduce the problem with stock vessels.
 
Top