Backport of 3D Cockpit

[fluffyfreak]

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.

For example the wave.lua file becomes:

-- Copyright © 2008-2013 Pioneer Developers. See AUTHORS.txt for details
-- Licensed under the terms of CC-BY-SA 3.0. See licenses/CC-BY-SA-3.0.txt

define_ship {
name='Wave Heavy Hypersonic Fighter',
model='wave',
cockpit='cockpit',
forward_thrust = 88e5,
reverse_thrust = 29e5,
up_thrust = 15e5,
down_thrust = 15e5,
left_thrust = 15e5,
right_thrust = 15e5,
angular_thrust = 140e5,
camera_offset = v(0,.6,-13),
gun_mounts =
{
{ v(0,-0.5,-10.7), v(0,0,-1), 5, 'HORIZONTAL' },
{ v(0,-0.5,0), v(0,0,1), 5, 'HORIZONTAL' },
},
max_cargo = 30,
max_laser = 2,
max_missile = 4,
max_cargoscoop = 0,
max_fuelscoop = 0,
min_crew = 1,
max_crew = 1,
capacity = 30,
hull_mass = 13,
fuel_tank_mass = 22,
-- Exhaust velocity Vc [m/s] is equivalent of engine efficiency and depend on used technology. Higher Vc means lower fuel consumption.
-- Smaller ships built for speed often mount engines with higher Vc. Another way to make faster ship is to increase fuel_tank_mass.
effective_exhaust_velocity = 65000e3,
price = 93000,
hyperdrive_class = 2,
}

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 ;)

@Salwan I don't want to step on your toes with this stuff so if you're interested in discussing rendering instruments to textures then let me know and we'll discuss it on the forums.

Also this being a backport means that I didn't write the original so some of the decisions and code like the ShipCockpit.cpp/h files are almost as new to me as they are to anyone reviewing this PR.

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

[nozmajner]

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.

[Zireael07]

Wow, that's amazing!

[robn]

Building under Linux on robn/cockpit3d. Visuals look good. There's a few minor bits and pieces that need doing:

• Renaming variables and functions to conform to our coding standards
• Check saves do the right thing, and bump savefile version
• Get it running on the standard easing functions, or move these specialised ones there
• Move the interpolation functions from MathUtil to someone saner (probably a new Interp.h)

Functionally I'm planning one change - front view will always use the cockpit. I'll add a setting to allow it to be enabled and disabled. I think its better as a full preference rather than a thing that has to be cycled past. If the cockpit and the default cockpit are not available, then it'll just be the non-cockpit view as normal.

I'll start work on these tomorrow night - out of time today.

[robn]

Hmm, ShipCockpit inherits from ModelBody. I assume that's done to take advantage of the lighting functions in ModelBody, but its also kind of evil, as evidenced by the need to mess with the frame, which also causes a visible glitch in the cockpit render when the frame changes.

(ModelBody itself is pretty evil, and will go away someday).

Really the lighting code in ModelBody shouldn't even be there - it knows waaaay too much about the environment. It should probably be in its own class for anything that wants it. I'll do that.

[robn]

Man, we've strung ourselves up by the balls. The way that this lighting code binds cameras, bodies and space is nothing short of breathtaking.

This might take a while.

[robn]

Nah, its way too entangled right now. I'll work on the other stuff and get this merged, and then try to fix the light model afterwards. I don't really want to be a bottleneck here.

[robn]

Can someone explain to me why there are different easing functions implemented but not used? Does Paragon actually use them, or intend to?

[robn]

Almost there. Tomorrow I need to check saves, remove some casts, and maybe flatten all that easing junk. Then its one last check and merge.

[fluffyfreak]

They're just there because they were there when I pulled out across... much like the head/view movement stuff in ShipCockpit which I have mixed opinions on.
Sorry I haven't responded earlier, been a bit out of sorts.

[fluffyfreak]

If you wanted we could simplify ShipCockpit to remove all of the easing stuff and add our own later on. Then Paragon can do what they like with a clean base to build off and we can do what we like in response to @nozmajner desire for head-look and other things like camera shake on hits or something?

[fluffyfreak]

Also I merged your branch back into this PR.

[robn]

I've simplified and cleaned up the code as much as I can. I've left the movement in because it gives us something to experiment with and decide if we like it or not.

Still to do to make it "right" is the lighting and physics cleanup as mentioned above. I will be trying to deal with it in the next week or two.

[fluffyfreak]

Woohoo!

[Salwan]

Reason for implementing a new set of easing functions: I didn't notice the ones already there! I just wrote my own since they are small and simple to implement. There is no issue in using a different set of functions of course.

And the reason why we have the option to use different easing function types is for customization: changing the easing type will change how cockpit lagging feels.

[Salwan]

@fluffyfreak I gave dynamic cockpit features some thinking but nothing concrete yet. My ideas were a bit too ambitious. I thought about implementing cockpit components driven by LUA scripts so they become fully programmable and mod-able. A default set of components can be created but different types of ships can provide some custom components that not only differ in shape but in functionality too :-)

However I think the idea of rendering components to textures then using them in cockpits is a lot more feasible and can look very nice based on the cockpit screenshot by @nozmajner.