Surface Base Apollo Landing Site Sceneries for Orbiter 2016

[ggalfi]

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 ?

I've written him today. Hope he'll be able to help us, as it affects most of the landing site (e.g. Apollo 16 landed just a few meters off to a pretty deep crater).

 

[ggalfi]

Orbiter 2036? Did you time travel to late '30s and came back?

You've never tried to fly a vessel faster than speed of light, haven't you?

 

[NukeET]

Orbiter 2036? Did you time travel to late '30s and came back?

What a rude person. Couldn't you have had the decency of sending a private msg so I could correct it? Were you born that way, or are you just working hard at it?

 

[Sbb1413]

Deleted my post. ?

 

[1987VCRProductions]

I'm getting this weird elevation issue from the Apollo 11 site. I'm using the main release of Orbiter 2016 with the D3D9 client.

 

[barrygolden]

This seemed to have knocked out my d3d9 version

 

[gattispilot]

How do you install it?

So you install in the Orbiter root directory. Read the doc

 

[ggalfi]

View attachment 22847

I'm getting this weird elevation issue from the Apollo 11 site. I'm using the main release of Orbiter 2016 with the D3D9 client.

Hi,

seem to me the elevation is magnified for somewhat reason. It once happened to me also, when I began to experiment with these elevation maps and used a scale factor lower than 1m (it is now 0.1 meter in the current release of A11 LS). But it was with an older version of D3D9Client, which handled incorrectly elevation maps with scale != 1.0 . Please make sure that you are using an up-to-date version of it, with Orbiter beta (and not the 2016 version). If you still have issues within that setup, I'll put more effort to investigate the issue. I haven't planned to release a version with scale==1, as I see Orbiter 2016 a legacy stuff and the Beta with D3D9 as the future. However if a few people say that I should do that then I'll give in.

 

[ggalfi]

As we are only hours from the 51st anniversary of Apollo 12 lunar landing, I finalized the scenery file for that mission. As there was no way to make Orbitersim physical engine use these HD elevation maps during calculating the physics, I circumvent the sinking-into-lunar-dust problem by suitably adjusting the overall height of my elevation maps. So if you land right on the money (and Apollo 12 mission was planned as pinpoint landing, wasn't it? ), the LM will stand normally on the surface. If you land somewhere else, you may expect some floating and sinking vessels.
You may download the necessary files from here: http://absimp.org/orbitersim/apollolandingsites.html
No screenshots at the moment, because I wanted to share this before the "deadline".
So gear up your Intrepid and try to find Snowman in the Ocean of Storms!

 

[ggalfi]

Fra Mauro is rolled out! You may get history straighten out - at least virtually - and on the 51th anniversary of Apollo 13 you may try to land Aquarius near to Cone Crater. Just don't fiddle too much with O2 fan switches...
Seriously: I investigated carefully the issues with the non-matching physical and visual elevations and come to the conclusion that it was partially my fault as I have only changed the ElevationResolution in Config/Moon.cfg - but I tested it with AMSO and NASSP - both are using their own Moon.cfg. So setting these cfg files properly solved most of my previous problem, the only remaining issue is the quantization artifacts due to the 0.5 meter elev resolution. I think even with this little glitches, these high LOD tiles in the most recent Orbiter Beta - D3D9Clients combination are working beautifully so no more need for my hack for the latter. A few screenshots from Fra Mauro:

This screenshot was taken with the astronauts standing circa at station "C", facing to the rim of Cone Crater which is about 20 meters from there. Shepard and Mitchell weren't able to look into the crater as it was practically invisible for them even at this very close location.


On this bird's eye view it is pretty obvious how close the astronauts were to the rim of the crater.


The Triplet.


The Fra Mauro Landing site - Cone Crater is on the right, the Triplet with the landed LM is in the center.

 

[jalexb88]

Fra Mauro is rolled out! You may get history straighten out - at least virtually - and on the 51th anniversary of Apollo 13 you may try to land Aquarius near to Cone Crater.

This definitely makes the landings much more immersive, thanks for the great work!

One issue I have is that sometimes the LM seems to "land" about ~10 feet above the ground and remains there until it transitions to the landed state and then in snaps down to the correct height, very strange.

This screenshot shows this: (It looks like its still hovering, but it is in fact landed but not yet in the "landed" state, i.e.. that period when you see the FDAI still jiggling for a few seconds after engine stop ) and the absence of the probes shows that it is not still in the hovering phase.

And after a few seconds the LM settles into the "landed" state and it pops down to the correct height:

And afterwards if I fire an RCS thruster which puts it into the not landed state and will pop back up to the position in the 1st screenshot for a few seconds until it settles into the landed state and then pops back down

I thought this could be because of the elevation not matching the visuals issues you mentioned about before, but since you did say it should at least be ok at the actual landing coordinates (as I did in my test) then it shouldn't be an issue I think. Any ideas?

Just to add, I have MaxPatchResolution = 18 and ElevationResolution = 0.5 D3D9Client Beta R30.1 (Sep 7 2020)

EDIT: What is weird is that it only happens on some scenarios. It only seems to occur when you fly the landing from a scenario starting anytime before pitch-over. If I save and reload in the moments before landing (during P66) then the issue will not occur on the reload. ? So it seems the only way for me to not have the issue is to save/reload just before the landing. If I land with the issue present, the save/reloading after the landing also seems to solve it.

 

[4throck]

Just to comment that the surface textures can be used with the standard (not beta) Orbiter 2016.
No problems, they are quite nice and detailed.

How about releasing terrain for the standard version ? I understand that resolution would be lower, but still an improvement over the default elevation tiles...

 

[barrygolden]

It would cool to see the Littrow wrinkle ridges plan for Apollo 14 to land at or Alphonsus crater near the ranger crash site.

 

[ggalfi]

This definitely makes the landings much more immersive, thanks for the great work!

One issue I have is that sometimes the LM seems to "land" about ~10 feet above the ground and remains there until it transitions to the landed state and then in snaps down to the correct height, very strange.

This screenshot shows this: (It looks like its still hovering, but it is in fact landed but not yet in the "landed" state, i.e.. that period when you see the FDAI still jiggling for a few seconds after engine stop ) and the absence of the probes shows that it is not still in the hovering phase.

And after a few seconds the LM settles into the "landed" state and it pops down to the correct height:

And afterwards if I fire an RCS thruster which puts it into the not landed state and will pop back up to the position in the 1st screenshot for a few seconds until it settles into the landed state and then pops back down

I thought this could be because of the elevation not matching the visuals issues you mentioned about before, but since you did say it should at least be ok at the actual landing coordinates (as I did in my test) then it shouldn't be an issue I think. Any ideas?

Just to add, I have MaxPatchResolution = 18 and ElevationResolution = 0.5 D3D9Client Beta R30.1 (Sep 7 2020)

EDIT: What is weird is that it only happens on some scenarios. It only seems to occur when you fly the landing from a scenario starting anytime before pitch-over. If I save and reload in the moments before landing (during P66) then the issue will not occur on the reload. ? So it seems the only way for me to not have the issue is to save/reload just before the landing. If I land with the issue present, the save/reloading after the landing also seems to solve it.

Yeah, I've experienced this as well. When I land (intentionally ) within a crater like one of the Triplet's, it first stops at the mean elevation then after a few seconds it jumps to the bottom of the crater. I can only guess what is happening here: maybe the physical engine - similarly to the graphics engine - loads the higher resolution tiles after a while, and in a non-landed state for a few seconds it is uncertain what is actual surface elevation. What I want to investigate is that there are emin, emax (elevation min-max) values in each .elv file, these could be used as a hint for Orbiter whether is it worth to go any deeper LOD for more accurate elevation. In the elevation files what I have generated I take care of these, but the original, LOD<=12 tiles and their emin-emax values are not necessary consistent with the finer (and maybe a little bit biased) elevation tiles. But again, it is just guessing, I don't have any information on what is happening behind the scenes.

 

[ggalfi]

Just to comment that the surface textures can be used with the standard (not beta) Orbiter 2016.
No problems, they are quite nice and detailed.

How about releasing terrain for the standard version ? I understand that resolution would be lower, but still an improvement over the default elevation tiles...

Yes, I also discovered that with setting the appropriate Moon.cfg the non-beta Orbiter shows the high-LOD elevations. Just the quantization artifacts are more pronounced for some reason (maybe the lack of smoothing), and the surface textures are not displayed with as high LOD. I still have to refresh the description on my site to reflect this new improvement.

I don't think I want to release any non-beta terrain, as the resolution is controlled by Moon.cfg which is common for both std and beta, and as you have observed it works well with both of them. Just ignore my former degrading comments on standard O2016 and simply use these elevation files

 

[ggalfi]

It would cool to see the Littrow wrinkle ridges plan for Apollo 14 to land at or Alphonsus crater near the ranger crash site.

The roadmap for me is first finish the landing sites for the remaining Apollo missions (15,16,17). Then I will move on to some other sites which has their own Digital Terrain Model (DTM). There are only few other than the Apollo site, you may look up your favourites on LROC Quickmap whether they have one. But building a DTM from scratch - it is a more complex story. When I was working on this Fra Mauro package I played a bit with Ames Stereo Pipeline, and I was able create a few kilometer neighbourhood of Cone crater from an NAC image pair but the quality was far from the "factory-made" DTM's. So only the latter was used int this scenery.

 

[jalexb88]

Yeah, I've experienced this as well. When I land (intentionally ) within a crater like one of the Triplet's, it first stops at the mean elevation then after a few seconds it jumps to the bottom of the crater. I can only guess what is happening here: maybe the physical engine - similarly to the graphics engine - loads the higher resolution tiles after a while, and in a non-landed state for a few seconds it is uncertain what is actual surface elevation. What I want to investigate is that there are emin, emax (elevation min-max) values in each .elv file, these could be used as a hint for Orbiter whether is it worth to go any deeper LOD for more accurate elevation. In the elevation files what I have generated I take care of these, but the original, LOD<=12 tiles and their emin-emax values are not necessary consistent with the finer (and maybe a little bit biased) elevation tiles. But again, it is just guessing, I don't have any information on what is happening behind the scenes.

Ah makes sense. But just by curiosity, did you observe that odd behavior at the actual landing coordinates too? I would of thought to expect some odd behavior if you land away from the actual landing location (in a crater), but in my landing though, the weird behavior happens at the correct (actual) landing spot as the screenshot above shows me right over the picture of the real Antares in the surface texture.

 

[4throck]

I don't think I want to release any non-beta terrain, as the resolution is controlled by Moon.cfg which is common for both std and beta, and as you have observed it works well with both of them. Just ignore my former degrading comments on standard O2016 and simply use these elevation files

I tried and I get blocks of lower terrain around the LM.
It seems like lower level elevation tiles need to be updated to reflect the new data. Perhaps levels lower than 13 ?

 

[ThatRedMelon]

Is the download site down? The landing sites look awesome but I am unable to download this.

 

[ggalfi]

Is the download site down? The landing sites look awesome but I am unable to download this.

I wasn't aware that the VPS I'm using for the landing sites was restarted a week ago. I was notified in email on the restart, however I skipped it - shame on me. It is up and running now. Thanks for letting me know this issue!