# Surface BaseApollo Landing Site Sceneries for Orbiter 2016

#### ggalfi

##### Active member
Hi all,

I've begun a project to create sceneries for the Apollo landing sites (only HD texture and elevation maps) and theirs few kilometers of neighborhood. You may find the downloadables and other infos on this page:
Currently Apollo 11-16 are ready (both 13 and 14 aimed for the Cone Crater in Fra Mauro formation, so they share the same scenery files).

Please read carefully on the site or in the readme files how to properly set up the Visual effects menu and Moon.cfg files to get the higher LOD elevation tiles to be properly displayed.

Originally this thread was running under the name "Apollo 11 Tranquility Base Scenery ", but as I was able to overcome (or at least circumvent) some issues caused by bumpier terrains, I plan to do the same procedure for the sites for other lunar landing missions, so it seem to me reasonable to put all these stuff under the same topic. Any comments, testing results, screenshots on this sceneries are welcome.

Happy landings, try not to dig out any new impact craters with the LM!

Last edited:

Thank you!

#### Interceptor

##### Well-known member
Very nice,thank you.

#### n72.75

Tutorial Publisher
Donator
Cool! Was looking forward to this.

Alright, first person to land *in* the Little West Crater.

#### kuddel

##### Donator
Donator
Hey ggalfi,

I've taken a look at your patch and it looks reasonable.:thumbup:

But I have one question:

Why do you divide the parent elevation points by tgtres (mgr->ElevRes()) here, when converting them from float to INT16:
PHP:
// -----------------------------------------------------------------------

{
//...
if (elev_file) {
//...
}
else if (lvl > 0) {
//...
if (elev_mode == 0) {
//...
for (int i = 0; i < ndat; i++) pelev_temp[i] = (INT16)(pelev_file[i] / tgtres); // why ????
//...
}
}
}

Shouldn't it just be:
PHP:
			for (int i = 0; i < ndat; i++) pelev_temp[i] = INT16(pelev_file[i]);

as it was in the original (where no conversion was necessary)?

#### ggalfi

##### Active member
Hey ggalfi,

I've taken a look at your patch and it looks reasonable.:thumbup:

But I have one question:

Why do you divide the parent elevation points by tgtres (mgr->ElevRes()) here, when converting them from float to INT16:
PHP:
// -----------------------------------------------------------------------

{
//...
if (elev_file) {
//...
}
else if (lvl > 0) {
//...
if (elev_mode == 0) {
//...
for (int i = 0; i < ndat; i++) pelev_temp[i] = (INT16)(pelev_file[i] / tgtres); // why ????
//...
}
}
}

Shouldn't it just be:
PHP:
			for (int i = 0; i < ndat; i++) pelev_temp[i] = INT16(pelev_file[i]);

as it was in the original (where no conversion was necessary)?
Hi Kuddel,

first of all, I am more than happy if you find my hack useful, however there are two issues you should know about:
1. It causes some black tiles in KSC scenery. The occurence of these tiles is a bit odd, because not the closest ones are they, but they appear when the POV is very close to the surface (Alt<1km). I haven't put yet any effort to investigate of the problem, but I still believe that it could be resolved easily.
2. That is the difficult one, because it is related to Orbitersim's physical engine: even if D3D9Client displays a high LOD elevation, Orbitersim calculates with a lower LOD elevation and the altitude difference could be up to a few meters. That means practically that e.g. in the case of Apollo 12, when the LM landed on the edge of a 200m crater, you will see in Orbitersim that the LM sinks in the lunar dust up to it's ascent stage. Pretty disappointing view. The only solution here seem to me to bargain with dr. Schweiger to allow higher resolution elevation maps in the physical calculations.

in the trunk version pelev_file is an array of integer and the unit for that is tgtres. In my hacked version it is an array of floats and unit is one meter. And when it is passed to some (at least for me) arcane part of Orbitersdk by that "mgr->GetClient()->ElevationGrid(...)" call, I didn't want to happen that with improper scaling, that's why I divided by tgtres (unit is 1m -> unit is tgtres). So I practically recreated the old pelev_file through that pelev_temp.

---------- Post added at 11:45 PM ---------- Previous post was at 11:24 PM ----------

Cool! Was looking forward to this.

Alright, first person to land *in* the Little West Crater.
That's one small prank for an armchair astronaut but one giant no-no for a real one

#### kuddel

##### Donator
Donator
Thanks ggalfi for the information!

I will try to look deeper into this, but first let's start with one piece at a time

1. It causes some black tiles in KSC scenery. The occurence of these tiles is a bit odd, because not the closest ones are they, but they appear when the POV is very close to the surface (Alt<1km). I haven't put yet any effort to investigate of the problem, but I still believe that it could be resolved easily.
I have applied a (slightly modified) version of your patch to the current trunk (HEAD version) of D3D9Client and I can not see that issue.
Maybe I accidentally fixed that problem

I will create a new branch for this in the next few days, so we can all look at the same code-base. Be patient, I might not have time for it ASAP

2. That is the difficult one, because it is related to Orbitersim's physical engine: even if D3D9Client displays a high LOD elevation, Orbitersim calculates with a lower LOD elevation and the altitude difference could be up to a few meters. That means practically that e.g. in the case of Apollo 12, when the LM landed on the edge of a 200m crater, you will see in Orbitersim that the LM sinks in the lunar dust up to it's ascent stage. Pretty disappointing view. The only solution here seem to me to bargain with dr. Schweiger to allow higher resolution elevation maps in the physical calculations.
Not much we can do about this, I think. But hey, Orbiter BETA is still a BETA, right? So there's hope

in the trunk version pelev_file is an array of integer and the unit for that is tgtres. In my hacked version it is an array of floats and unit is one meter. And when it is passed to some (at least for me) arcane part of Orbitersdk by that "mgr->GetClient()->ElevationGrid(...)" call, I didn't want to happen that with improper scaling, that's why I divided by tgtres (unit is 1m -> unit is tgtres). So I practically recreated the old pelev_file through that pelev_temp.

Thanks for the clarification. But I can't seen any difference whether I apply the division or not (visually that is).
So I think ElevationGrid(...) just works "dimension less"...

We can hopefully evaluate this more precise once I've setup that feature-branch...

Stay tuned and keep up the good work!

#### kuddel

##### Donator
Donator
Finally I found some time.
You can find my current "work in progress" in this feature branch: svn://mirror.orbiter-radio.co.uk/D3D9client/branches/floatElevTest

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
That means practically that e.g. in the case of Apollo 12, when the LM landed on the edge of a 200m crater, you will see in Orbitersim that the LM sinks in the lunar dust up to it's ascent stage. Pretty disappointing view.

That issue should be already fixed. But the fix only works with "linear interpolation" not with the "cubic" at a moment.

I did sent PM to Martin to ask if he has ideas/preferences on how to fix the issue but I didn't receive an answer.

The main problem appears to be that Orbiter's physics uses a floating point interpolation of elevation data but the interpolated results are handed over to the D3D9Client in INT16 format for rendering. We have our own code for bi-linear interpolation in float basis but we are still lacking the cubic one.

---------- Post added at 09:55 ---------- Previous post was at 09:22 ----------

If I recall correctly in Orbiter 2016 resolution for Lunar elevation is 1 meter per bit and in Orbiter Beta it is 0.5 meters per bit. So, I wonder is this "tgtres" due to mixing 2016 and Beta elevations ?

Last edited:

#### ggalfi

##### Active member
Finally I found some time.
You can find my current "work in progress" in this feature branch: svn://mirror.orbiter-radio.co.uk/D3D9client/branches/floatElevTest
Hi Kuddel,

thanks for taking care of this. Generally it looks good (it is built and runs without any problem). However with Tranquility Base scenery it provides only a minor improvement compared to the main branch D3D9Client, so it practically looks same as the second set of screenshots on my scenery's page.

But if I "unscale" the elevation load algorithm, it provides the best LOD as I could achieve. So my two changes were
• In SurfTile::ReadElevationFile I've changed this
PHP:
if (e) {
if (scale != tgt_res) { // rescale the data
double rescale = scale / tgt_res;
for (i = 0; i < ndat; i++)
e[i] = float(e[i] * rescale);
}
if (offset) {
float sofs = float(offset / tgt_res);
for (i = 0; i < ndat; i++)
e[i] += sofs;
}
}
to this:
PHP:
if (e) {
for (i = 0; i < ndat; i++)
e[i] = (float)(offset + e[i] * scale);
}
• In float SurfTile::Load this
PHP:
mesh = CreateMesh_quadpatch (res, res, elev, mgr->ElevRes(), 0.0, &texrange, shift_origin, &vtxshift, mgr->GetPlanet()->prm.tilebb_excess);
to this
PHP:
mesh = CreateMesh_quadpatch (res, res, elev, 1.0, 0.0, &texrange, shift_origin, &vtxshift, mgr->GetPlanet()->prm.tilebb_excess);
and it works nicely.
Maybe there is a more elegant way, probably in the tile LOD selection algorithm, but honestly I was too lazy to understand it to the level I'd be able to modify it.

#### ggalfi

##### Active member
That issue should be already fixed. But the fix only works with "linear interpolation" not with the "cubic" at a moment.

I did sent PM to Martin to ask if he has ideas/preferences on how to fix the issue but I didn't receive an answer.

The main problem appears to be that Orbiter's physics uses a floating point interpolation of elevation data but the interpolated results are handed over to the D3D9Client in INT16 format for rendering. We have our own code for bi-linear interpolation in float basis but we are still lacking the cubic one.

---------- Post added at 09:55 ---------- Previous post was at 09:22 ----------

If I recall correctly in Orbiter 2016 resolution for Lunar elevation is 1 meter per bit and in Orbiter Beta it is 0.5 meters per bit. So, I wonder is this "tgtres" due to mixing 2016 and Beta elevations ?
Hi Jarmonik,

I guess, the problem is not with the vertical resolution rather the horizontal one. Seem to me that orbitersim does not goes up to LOD18, only 14. D3D9Client uses 4 notches finer LOD in linear interpolation mode, that's why it is possible to display the finest elevation map. However the physical calculations are still using LOD14. In case of the (yet unpublished) Apollo 12 scenery you see the landed and sinked LM-6 on the edge of the Surveyor crater on the attached images. Also the floating rocks of AMSO are not made of unobtanium rather they are flying because their position is based on the physical elevation, and not the rendered one.

#### Attachments

• apollo12_ls_screen1.jpg
162.9 KB · Views: 144
• apollo12_ls_screen2.jpg
72.1 KB · Views: 134
Last edited:

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
Hi Kuddel,
In SurfTile::ReadElevationFile I've changed this

• PHP:
if (e) {    if (scale != tgt_res) { // rescale the data        double rescale = scale / tgt_res;        for (i = 0; i < ndat; i++)            e[i] = float(e[i] * rescale);    }    if (offset) {        float sofs = float(offset / tgt_res);        for (i = 0; i < ndat; i++)            e[i] += sofs;    }}
You might be on to something, I'll have to investigate that more closely. Mean while, If the physics is limited to level 14 then could you try to increase "MaxPatchResolution = 16" from Moon.cfg. If I recall correctly the elevation grid is two levels lower than that.

Last edited:

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
I have looked into this and there is a new version of client uploaded to SVN (Trunk). I came to the same conclusion as you did, it looks like the physics doesn't go beyond level 14 and there's not much I can do about it.

So far I get the best results by disabling level 17,16,15 elevation (by renaming the folders) and adding the following line in AMSO/Moon.cfg "ElevationResolution = 0.25". That enables the physics to work in 0.25 meter increments in elevation instead of 1 meter. Going below 0.25 might cause other issues.

#### n72.75

Tutorial Publisher
Donator
Just wanted to say that I'm super excited for your Apollo 12 scenery.

#### ggalfi

##### Active member
Just wanted to say that I'm super excited for your Apollo 12 scenery.

I'm aware of the attempt of subconscious influencing The reason why I haven't published it yet is that I am very unsatisfied with the "sinking LM" phenomenon. However I have an idea how to cure it: I think if I adjust (or "fake" if you will) the lower LOD elevation maps to reflect the altitude at the exact landing spot of LM-6, then - provided you execute a precise touchdown - the physical and displayed elevation will fit well. Just please give me some time to crawl through the problem.

#### NukeET

##### Gen 1:1
Donator
I'm aware of the attempt of subconscious influencing The reason why I haven't published it yet is that I am very unsatisfied with the "sinking LM" phenomenon. However I have an idea how to cure it: I think if I adjust (or "fake" if you will) the lower LOD elevation maps to reflect the altitude at the exact landing spot of LM-6, then - provided you execute a precise touchdown - the physical and displayed elevation will fit well. Just please give me some time to crawl through the problem.
What is the source of your data for the location of A12 landing site?

#### ggalfi

##### Active member
What is the source of your data for the location of A12 landing site?
I've used LRO NAC imagery (to be specific: M1119029214L and R) for the textures and on them the descent stage of LM-6 is clearly visible. You can use it as a landing cue (e.g. in AMSO you point the LPD into it, or in NASSP you may rely on your piloting skills). It is similar to what you can do with the Apollo 11 scenery.

#### NukeET

##### Gen 1:1
Donator
I've used LRO NAC imagery (to be specific: M1119029214L and R) for the textures and on them the descent stage of LM-6 is clearly visible. You can use it as a landing cue (e.g. in AMSO you point the LPD into it, or in NASSP you may rely on your piloting skills). It is similar to what you can do with the Apollo 11 scenery.

Ok. When AMSO for Orbiter 2016 was released, I tried all landings, and noticed that the original numbers used in the scenario for A12 was a bit off for both Intrepid and Surveyor 3. I used LRO data to fix it.

Last edited:

#### 4throck

##### Enthusiast !
Haven't checked the current AMSO landing site coordinates, but these should be quite accurate:

They are derived from LROC imagery, so should match any LROC derived surface textures.
Still uncertainty for Apollo 12 LM is 2.2 meters

#### jarmonik

##### Well-known member
Orbiter Contributor
Beta Tester
The reason why I haven't published it yet is that I am very unsatisfied with the "sinking LM" phenomenon.

Since you have invested a lot of efforts to create a nice environment for Apollo 11 and 12 landing sites, Have you tried to contact Martin via PM and talk about the issue ?

Replies
4
Views
877
Replies
16
Views
820
Replies
0
Views
482
Replies
5
Views
918