3D Cockpits

[FluffyFreak]

Paragon recently gained 3D Cockpits which I have backported
https://github.com/pioneerspacesim/pioneer/pull/2603

I wrote more about it in the PR:

Description:
3D cockpits, we've long discussed them and there's mixed responses from the Pioneer team but code talks and here is Paragons working 3D cockpit code.

This is yet-another-backport from Paragon by @Salwan, the guy is churning out some great stuff!

How it works:
You define a separate model for the cockpit (I've been working with @nozmajner on getting a single cockpit model ready that can be used in Pioneer) then you add a reference too it in the ships Lua definition file.

That's it, it appears as the 4th option when pressing the F1 key.

You can re-use the same cockpit for multiple ships, so all of the fighters from a certain manufacturer might use a common cockpit module. That means we don't need to create special cockpit models for each and every ship. Also the ships work fine without ANY cockpit model being defined.
In that instance the F1 key will skip right over the cockpit mode and cycle back around to the default internal view.

Testing it:
@nozmajner has provided me with a work-in-progress cockpit that you can download for testing.
Just put that in the mod folder and then add the line cockpit='cockpit', to whichever ships Lua definition file that you want to test the cockpit with.

Issues and Future work:
No known Issues as such but it's quite obvious that we're going to have to continue to use the 2D control panel for the time being because there's no support for rendering controls to a texture and displaying them inside the 3D HUD yet.

There's some future work right there of course and it's something that I've already started to look into but I'm backlogged so it's going to take me a few days / weeks. Eventually I'll just render things like the scanner and other instruments / information to texture which will be used by the model. It's conceptually trivial except where it meet the Pioneer codebase ;)

Reason for putting it forward now:
It's important to get this first block into Pioneer to minimise code-drift and rot between Paragon<->Pioneer as I want the future work to flow both ways more easily.

Also to stop it becoming a single huge EPIC commit that takes 6 months to do and another 3 to review.

People can try it out without affecting Pioneer itself by using the cockpits and ships as mods which will give our modelers time to create assets, we can also gather feedback about who likes what and any potential issues.

FluffyFreak

[bszlrd]

I'll copy my comment from git:

My mod above uses the 'default_cockpit' name if you want to try that out instead of the one that comes with Paragon.
It's meant to be a fully enclosed generic (maybe gimballed) cockpit with monitors for view-port (needs some visual cue for that), so it can be used in any of the ships as a placeholder.
It has some baked-in self-illumination right now, imitating glow from the monitors, but it also get's illuminated by the external lights, like if the monitor shines quite a lot more on bright areas.

And it could be fit into the wave already :).

I think this is a great addition, even if it means more work for modelers too, in the end. :) It adds to the feel of mass, and can help differentiate the ships even more, and could help to define their character more.




I took this one as an opportunity to do some groundwork, to see, if a prefab approach would work (both for texture and model side). I think it will. It needs some experimentation though, to make it as simple as possible.
Those handrails and AC nozzles could be used right away for example, and that hose could be laid out with a single curve, including it's connector on the end.

I've also started to put one in the Amphiesma earlier to see how easy it is to put one into the geometry of the ship. Since if there's a good prefab library, then that will be the most of the work, to model and texture the interior, walls, and stuff.
It has quite limited view for sure, but I think it's not a real problem, since we have camera views already, which could be considered as VR control or a huge monitor in my opinion.
And that's what I was meant about character. You opted for that cheap OPLI ship, so now you have to put up with it's sub-par view, but only if you saved up a bit more, then you would have the Pumpkinseed's or Mola's large windshield cockpit. :)


One issue that comes to my mind right away is that there should be some kind of limited mouse look or something, so the modeler doesn't need to put all of the instruments to be visible on the fixed forward POV.
And another thing that comes to my mind is maybe it would be more ergonomic to have a separate key to switch from internal/cockpit view. Like numpad5 could go to cockpit if there's one for the ship, and the other numpads would stay as they work right now, so you could access each of them instantly.

[Zordey]

I am not a huge fan of full cockpits (in any game really) but I do like the look of the first 2 shots there. Unfortunately I think most ships cockpits will be rather more like the bottom screenshot which is totally useless for flying (and therefor wont be used beyond initial amusement)

But I suppose it is all about giving choice, and once you are in space, there isnt much to see anyway...

Nozmajner, where can I grab a copy of your cockpits to have a look how they are put together?

[bszlrd]

I think the main point of cockpits is immersion, at least for me, and I liked working on it :). And if the instruments are working, then flight should be possible despite poor views. But I agree, there should be choice.

Here are the sources for it, with packed textures.

[robn]

I've been happy to avoid the topic for the last couple of years because we haven't had any code to support it. But now there's code on the table, so I've been forced to spend a good chunk of my day thinking about it and how I want to approach it. So here we go.

When talking about 3D cockpits I see two aspects: the cockpit imagery itself (mostly the window or lack of window) and the working instrumentation. The split does not seem unreasonable. Even PR#2603 says that it is a precursor to the instrumentation.

I don't really have a problem with cockpits themselves, provided they don't look crap. I'm of the opinion its mostly an artistic or stylistic concern. I don't personally appreciate how obscuring the screen improves immersion, but I know that lots of people like it and I don't feel strongly about it either way.

Working instrumentation is a totally different story.

One of the most important goals I have for Pioneer is for it to have a consistent and usable UI. The current flight UI is terrible. It uses a great deal of space but shows very little useful information and has very poor affordance. I've been trying to improve this in various ways since I joined the project three years ago and we're only now getting to the point where we stand a chance, and there's still a long way to go. Its really important that we get this right.

I don't see how we can build a high quality flight UI when we can't control position and layout of important elements. And that seems to be what we're talking about here, since we can expect arbitrary cockpit models to place UI elements at odd positions, angles or perhaps not at all. So suddenly we can't guarantee that necessary information is presented to the player.

I also doubt its going to be feasible to interact with most of these elements sanely (press buttons etc). I don't expect there would be room to show all necessary information either, which still necessitates a HUD of some kind. And there's been other discussions in the past about your actions affecting the HUD (eg damage knocking out the HUD entirely), which would be problematic.

I much prefer an idea that has been discussed previously. The HUD is an image projected in some way (onto the eyeballs or some holographic thing). Its mostly flat, though perhaps slightly curved, because of whatever fiction we invent for it. But its very much not a physical, tangible thing. That doesn't preclude having an actual window to look out of, but does mean we don't have to try to shoehorn a UI up against some 3D model.

I'm not saying that it has to be done that way, but you'll have to change my mind about cockpit instrumentation of the kind shows in the mockups above. I don't see how it can work by itself, and I don't see how it can be a optional without a lot of additional code complexity and conflicting design. Unless you convince me then its not going to happen.

[FluffyFreak]

I don't get the "when we can't control position and layout of important elements", currently you'd have to edit Lua files or control flow and layout using the GUI. Basically a coders job, going back and forth scripting layout and widths manually.

If it's embedded in panels textured into a 3D model then it's simple for an artist to move it around instead, arguably quicker and easier without going through the coder bottleneck.
So it's just one person doing it instead of another and the elements rendered to a panel would still be GUI based so the lists of contacts would be a GUI layout controlled system.

The arguments against don't make much sense to me either: interacting is just ray projection if we want to do that, we have as much room as for 2D GUI - the full screen - it also doesn't preclude us using a 2D GUI still or from moving elements onto right/left views, also we still control the layout of the model and elements used for Pioneer and included in the download (if someone wants to do a mod with a truly awful UI then they're as free to do so with a 2D GUI as a 3D one), damage is easy since we'll be rendering the GUI in engine - so we control that just like we would a 2D GUI, in fact it *is* still a 2D gui just rendered onto a 3D model.

Also if you want the HUD projected then how about we render it to a texture and project it onto the canopy? Since that's almost exactly what we're talking about anyway.

[FluffyFreak]

Also, it is optional. It's like when you're playing a racing game and the camera can switch between the bumper (HUD only, aka Internal), in-car (cockpit) and 2 distances of following (like our external and sidereal).

It's not being forced on anyone it's an option for people who want to use it, and you know that the forums have always been split on that as much as they are on everything.

[robn]

I think I probably haven't explained my position very well. I'm not talking about technology at all - I know how 3D instrumentation is implemented. I know how the projected HUD would be implemented too. I'm talking about whether or not we can achieve a consistent user experience if we do this.

Maybe if we look at it from another angle. We're basically talking about including multiple UI layouts, one for each ship. Each of those needs to provide the full set of functions to the player in an internally-consistent and usable way.

Given how hard it is to design a usable UI, my thought has always been that we'd be best to focus our efforts on getting it right once. I don't see how that's possible if every ship is bringing its own layout.

[bszlrd]

And if we reuse what will already be on the HUD, putting it on screens? And while you guys are working on the HUD, I have plenty of time to cook up some nice cockpits and prefab kits for them, so when the UI part is ready, We just have to place them and they are ready to go.
I'm still thinking that it's a worthy addition and good for immersion, but I understand that it's not everybody's cup of tea. And it could add quite much to the character of a ship.

[robn]

Look at the mockups. Can every element on there be placed sanely in every cockpit? And if they can't, where do they go?

If they go on a 2D overlay, where do they go? They need to not obscure the cockpit controls and we need to be able to guarantee that for every cockpit that comes along.

If we do have a 2D overlay as well the cockpit controls, why do we even have cockpit controls?

What about new elements we might like to make? Do we need to update every cockpit to use them? Similarly if we remove one.

Do the elements have roughly similar positioning between cockpits and the 2D HUD? Are they guaranteed to be clearly visible on all screen sizes and orientations?

If the elements are intended to be interactive, can we guarantee large enough hit targets so that its not possible to accidentally hit the wrong element?

All of these questions are important. Consistent layout is crucial for a good user experience. This is in no way as simple as just rendering UI elements to textures and displaying them on a model.