Surface Base Apollo Landing Site Sceneries for Orbiter 2016

ggalfi

Well-known member
Joined
May 31, 2020
Messages
74
Reaction score
131
Points
48
Location
Budapest
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:
All flown Apollo landing missions (11-17) are ready. Apollo 13 and 14 both 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:

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,672
Reaction score
1,329
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Cool! Was looking forward to this.

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

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,063
Reaction score
507
Points
113
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:
// -----------------------------------------------------------------------

bool SurfTile::LoadElevationData ()
{
	//...
	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

Well-known member
Joined
May 31, 2020
Messages
74
Reaction score
131
Points
48
Location
Budapest
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:
// -----------------------------------------------------------------------

bool SurfTile::LoadElevationData ()
{
	//...
	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.

So to answer your question:
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
Joined
Apr 1, 2008
Messages
2,063
Reaction score
507
Points
113
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 ;)

So to answer your question:
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
Joined
Apr 1, 2008
Messages
2,063
Reaction score
507
Points
113
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,632
Reaction score
764
Points
128
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

Well-known member
Joined
May 31, 2020
Messages
74
Reaction score
131
Points
48
Location
Budapest
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

Well-known member
Joined
May 31, 2020
Messages
74
Reaction score
131
Points
48
Location
Budapest
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
    apollo12_ls_screen1.jpg
    162.9 KB · Views: 163
  • apollo12_ls_screen2.jpg
    apollo12_ls_screen2.jpg
    72.1 KB · Views: 152
Last edited:

jarmonik

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

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,672
Reaction score
1,329
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Just wanted to say that I'm super excited for your Apollo 12 scenery.
 

ggalfi

Well-known member
Joined
May 31, 2020
Messages
74
Reaction score
131
Points
48
Location
Budapest
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
Addon Developer
Donator
Joined
Oct 16, 2007
Messages
1,035
Reaction score
93
Points
63
Location
UT_SLC
Website
sites.google.com
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

Well-known member
Joined
May 31, 2020
Messages
74
Reaction score
131
Points
48
Location
Budapest
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
Addon Developer
Donator
Joined
Oct 16, 2007
Messages
1,035
Reaction score
93
Points
63
Location
UT_SLC
Website
sites.google.com
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 !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
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
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,632
Reaction score
764
Points
128
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 ?
 
Top