Planetfall 2.0 (apparently)

[hiran]

Could we simply play an animated gif? Or mp4? Could we render the player's ship on top of the video?

Short answers: No, no, and no.

I can display a series of pre-rendered images, saved as png files. That’s all I can do. If you can get the animation split into individual images, then I suppose, yes, I can display them. That would be, assuming let’s say 15 frames per second, around 75 images.

For a single landing sequence.

If you want to vary that sequence in some way, say, change the sky colours. That’s another 75 images.

Any time you want to tweak what you see, that’s more pre-rendered images to create.

My point here isn’t to tear down the suggestion, but to focus on my limitations. I can’t do that. I want to create something that feels satisfying, but operating within my graphical abilities. Clouds I can do. A little bit of zoom, some cycling “docking” markers I can do. Beyond that, it will need someone else to add some input. And the goal here is to make something that can be varied based on the planet/moon parameters: sky colour, cloud cover, day/night, etc. so landing feels different at different planets.

Ok, I'll take these 75 images. Which means it is low quality (only 15 fps) but it could be an animation.
Next I'll think of the content we want to render.

And you are right - it would differ depending on the planet and the ship. But I'll ignore that for now.

[cbr]

I’ve been thinking about how to make visuals work. The video where I approach at a shallower angle, the transition to the clouds image actually felt fairly natural, I think because the change in sky colour was also visible as you descend closer towards the ground.

Does it have to be the case that the landing sequence begins at a certain altitude?

While it makes sense that the flasher be at extreme low altitude (else the player could potentially fly under it), could not the player be docked there from a greater distance?

I appreciate that this is kind of what happens anyway but suppose that the last part of the approach was simulated by the cloud sequence etc.

Not only would the cloud placement seem more logical (even though we don't see any over the planet) but the absence of any visible landing site need not be so obvious.

What I'm imagining therefore would be markedly different to docking at a station in one respect.

Imagine the Aegis equates to the planetary vicinity (altitude begins to drop) and that the station equates to the surface (0 altitude). The old version of planet fall had you dock at the 'station' but why not dock instead at the buoy?

This 'buoy' would need be bouy-like in distance from the station only, it could otherwise be more like a shrunken Aegis i.e. a distance, not an entity.

On the spectrum version of elite they couldn't/didn't do ai Docking, so instead, the player activating the Docking Computers within the Aegis immediately say the Docking tunnel effect.

Currently, we're struggling to simulate a satisfactory landing approach, so why not have it take place (the Docking effect) from just a little further away and help hide the fact that oolite planets are too small to make it look reasonable?

I really liked the angled aproach.

So what your looking for is nice way to go from reaching the approach point and entering the (land)station

Some thing with circles could work...

[hiran]

I really liked the angled aproach.

So what your looking for is nice way to go from reaching the approach point and entering the (land)station

Some thing with circles could work...

Something like this is what I had in mind.

[Redspear]

So what your looking for is nice way to go from reaching the approach point and entering the (land)station

I think so yes. So landing/docking sequence begins at say 1km rather than at 1m.

[phkb]

Continuing with the cloud theme for the moment: YouTube - PlanetFall2 latest landing animation
Here I've matched up a red-hued version of the cloud image to the planet's air color.

[Redspear]

Here I've matched up a red-hued version of the cloud image to the planet's air color.

It does look better when they match.

By 1:30 in the video, there's a strong sense that the player is no longer in space I think:

• approx 30 seconds in - apparent darkening of some areas of the texture
• approx 50 seconds in - stars fading
• approx 1 minute in - stars virtually gone
• approx 1 min 30 sec in - sky significantly lighter

I think once you reach that stage the only logical reason to continue is for visible 'touch down' on the surface but that doesn't suit any of the cloud based landing sequence (which I like by the way).

So if 'docking' began at 1:30 instead of approx 2:05 then there's a sense that the site is still some way away and the final approach has been 'cut-scened'. Not as fun as a visible docking structure but then we don't have one of those. Even if we did then it only highlights the fact that the rest of the highly populated planet is completely bare.

The angled approach could work in your favour here.
Without rescaling, even the biggest planets won't come close to flattening out at 0 altitude. I've long imagined a sort of no fly zone below a certain altitude and the ship's altimeter reflecting that. So 0m isnt the distance from the surface, it's the distance from the no-fly zone. Unless you adopt an external view then it kind of works...

So, in short: planetary landing is conceptually cool but getting close to the planet texture isn't cool, regardless of the resolution. Thus my suggestion of docking from further away and at higher altitude.

[hiran]

Continuing with the cloud theme for the moment: YouTube - PlanetFall2 latest landing animation
Here I've matched up a red-hued version of the cloud image to the planet's air color.

This approach is a really nice play with planet ground vs atmosphere. It convinces me.

Once the beacon is reached it looks awful. The rectangles do not match at all, and all of a sudden just a blue earth sky... This one needs further improvements.

Thinking loudly...
Is it possible to create one outside screenshot of the ship and render that on top of the 75 frames? And definitely remove the rectangles?

[cbr]

When the beacon is reached, close the shutters...

[Redspear]

When the beacon is reached, close the shutters...

...But not over the HUD. Looks like the pilot's helmet has shutters

[phkb]

Is it possible to create one outside screenshot of the ship and render that on top of the 75 frames? And definitely remove the rectangles?

Well, it's *possible*. But the rendering has to be done beforehand. I can't render it during play. So, unless we just assume everyone is flying a stock Cobra Mark III, rendering everyone's ship (and possible paint job) might end up being slightly more work that what I had in mind!

[hiran]

Is it possible to create one outside screenshot of the ship and render that on top of the 75 frames? And definitely remove the rectangles?

Well, it's *possible*. But the rendering has to be done beforehand. I can't render it during play. So, unless we just assume everyone is flying a stock Cobra Mark III, rendering everyone's ship (and possible paint job) might end up being slightly more work that what I had in mind!

So the question would be whether an OXP can generate a screenshot at all. If yes, we could separate the problem:
- take a screenshot
- make use of it

If you focus on the second, for now just assume everyone is flying a stock Cobra Mark III.

[hiran]

When the beacon is reached, close the shutters...

...But not over the HUD. Looks like the pilot's helmet has shutters

that's my first thought as well. Shutters between the pilot and the controls takes a lot of immersion away.

But what if the graphics to be shown is not a metal door but actually the spaceport? Then it would be experienced like a strange cut between scenes in a movie.

[phkb]

So the question would be whether an OXP can generate a screenshot at all. If yes, we could separate the problem:

All the signs are pointing to "Nope" on that one as well. We can programmatically take a screenshot (and even this is not available in a normal Oolite installation - you need the debug release), but we can't do anything with said screenshot afterwards. The only resources we can use are ones that are in the "Images" or "Textures" folder of an OXP before you start the game.

[hiran]

So the question would be whether an OXP can generate a screenshot at all. If yes, we could separate the problem:

All the signs are pointing to "Nope" on that one as well. We can programmatically take a screenshot (and even this is not available in a normal Oolite installation - you need the debug release), but we can't do anything with said screenshot afterwards. The only resources we can use are ones that are in the "Images" or "Textures" folder of an OXP before you start the game.

Rats. That means we'd have to add functions to the core.

[phkb]

Something like this, then? YouTube PlanetFall2 new landing animation

Oh, and if someone wants to send me a better door design, please feel free. The only caveat is that the doors need to be square or rectangular (not with cool, funky, overlapping bits, like in cbr's example). That's the shape of the model I'm using.