[Scooby_Doo]

Is there any good time table (as in soon, very soon, maybe within your lifetime  ) for seperate cockpit models?  I'd like to know so I can decide to stop creating cockpits within my models (those that i'm still working on).

[taylor]

Probably within 6-8 months, that's the goal anyway.  Just depends on available time, whether anything more important comes up, etc.

[Nuke]

will it still be reverse comparable with the old way of using a submodel for the cockpit interior? i have several ships that use this method for cockpits (and rather successfully).

[Scooby_Doo]

I'm also wonder how we would handle including the new external cockpits with models that already have cockpits.  Probably have to rip out the original model cockpits.

[Einstine909]

I'm also wonder how we would handle including the new external cockpits with models that already have cockpits.  Probably have to rip out the original model cockpits.

nah, just take out the show ship flag

[Scooby_Doo]

But then you won't be able to see the ship outside the cockpit model.

[taylor]

The new method would simply use a separate POF for a cockpit model.  You would specify this with a tbl entry, and if you use "show ship" it will use this other POF rather than rendering the ship itself.

The current method of doing cockpits is just plain stupid.  You have to keep it hi-poly enough to work as a cockpit, and low-poly enough so that it doesn't kill frame rates for normal rendering.  And then you waste memory on higher quality cockpit textures too.  Having it as a separate POF is the only real way to do this right.

This way you don't have to compromise in the least: you get a nice low-poly cockpit for the ship model since you will never really look that close at it, and you get to use as much detail as you want for the "show ship" version.  You can also make better use of textures (glow/spec/normal) that would otherwise be a waste for a normal in-ship version.  And best of all you can get working cockpits on ships that you wouldn't normally want to model a typical in-ship cockpit for.  Plus, you can add a cockpit to a ship without ever even touching the ship POF itself.

[Scooby_Doo]

ummm taylor your preaching to the choir 

I have a feeling any ship with built in cockpit will need to get redone (delete the cockpit) if you want to use the newer method.  Otherwise you'll end up with a cockpit colliding/overlapping with another cockpit.  (the existing one and the new seperate pof one).  You can remove the show ship flag but then you wouldn't see the ship itself (such as wings...etc)

[taylor]

ummm taylor your preaching to the choir 

Yeah I know, but the new cockpit stuff is mostly only known in internal forums, so I just wanted to make sure that everyone else was aware of what the changes meant.

I have a feeling any ship with built in cockpit will need to get redone (delete the cockpit) if you want to use the newer method.  Otherwise you'll end up with a cockpit colliding/overlapping with another cockpit.  (the existing one and the new seperate pof one).  You can remove the show ship flag but then you wouldn't see the ship itself (such as wings...etc)

If you specify the cockpit POF then the old show ship method won't be used, so there won't be any conflict.  As far as wings and what not, you can include that just as easily in the cockpit POF too.  The cockpit POF can be anything of the ship that the pilot would view.  That way when we eventually get the code in to be able to look around freely in the cockpit, you'll always have something cool to see.


I know that I said this before in the internal, but for everyone else...  The main benefit is that the cockpit POF will ever be rendered only once per frame.  The in-ship cockpits on the other hand are rendered every time that LOD0 is shown on any instance of the that ship in a mission.  So the polys that you save from not doing decent in-ship cockpits will instantly translate to more polys that you can get away with on the separate cockpit model.  The cockpit model can also have a separate LOD setup so that detail settings can be used to give people to best choice of performance/quality.  You could make 2-3 versions of the cockpit model with different details and then the code can just use one of those based on the players detail settings.

The in-ship cockpit can only ever use LOD0, but because it is always rendered for any LOD0 instance of that ship in-mission, the modeler is forced to make sacrifices to keep the detail low enough, or be forced to sacrifice performance for the detail.  That can only ever be lose-lose, for everyone.

[Scooby_Doo]

What about using show ship along with the cockpit pof?  Assuming the ship doesn't have a cockpit of its own.  Also assuming the eye points of the cockpit and ship match up, you could do some small fudging so that it looks like the tub is actually inside the ship.  You'll probably want something like a "window frame" around it so you don't have to match up 100.00%

[taylor]

What about using show ship along with the cockpit pof?  Assuming the ship doesn't have a cockpit of its own.  Also assuming the eye points of the cockpit and ship match up, you could do some small fudging so that it looks like the tub is actually inside the ship.  You'll probably want something like a "window frame" around it so you don't have to match up 100.00%

That's a lot of assumptions though, and eventually something always goes wrong when you make them.

It also invalidates a lot of the benefit of the separate POF.  Using both will get you the good cockpit model to be sure, but it's also got the process the entire rest of the ship and that's going to slow the whole thing down.  You also have to now worry a lot more about z-fighting and render order as well.

You would be better off just taking your existing model, creating a really nice cockpit in it, cutting out all of the geometry that you can't see from the cockpit, and then using that as your cockpit POF.  You would still get all of the benefits of the old show ship method, but without all of the baggage that goes along with it.

[Nuke]

this is actually a pretty good idea as some of my cockpits are some 500-800 polies. no need rendering those on every ship. but ive been doing some experimental stuff with scripting that allows for some animated controls, such as yokes and joysticks and throttles in the cockpit. those worked well. and something i never really got it to work but wanted to do was some rtt on the panels as well. any chance some of theese ideas could become features?

[Kaine]

Very glad to hear this change is going to happen. I always thought the current cockpit method was just silly, both for the reasons Taylor has outlined and for practical game-world reasons. IMO they'd probably use materials for the cockpit viewing area that you couldn't see through from the outside anyway. Just make all cockpit glass reflective and save the polys for the rest of the ship!

[taylor]

and something i never really got it to work but wanted to do was some rtt on the panels as well. any chance some of theese ideas could become features?

That's something else that a dedicated POF could give us, though perhaps not at first.  The long-term goal that I see is that you could define subsystems in the cockpit that basically translate to gauges which we would then use rtt to texture with HUD info.  That could also give us other cool effects too, like gauges being blown out, or special effects for disrupted radar, and things like that.  We could even add support for a virtual/projected HUD: gauges that are always "floating" in front of you regardless of where you look (for 360 degree viewing; think F-35 HMDS).  The possibilities will certainly not be endless, but this could give modders a LOT to play with.

Initially it's just going to be a basic cockpit POF though.  The other stuff we should be able to phase in over time, as we redo and build up the basic render infrastructure (improved rendering performance and reduce memory usage, more efficient collision detection handling, better shader effect support, material system, etc.).

[TrashMan]

sweetness

*giggles with anticipation*

[Tolwyn]

the thing is, to implement realistic looking cockpits it should be possible to move hud elements around (or disable them completely, depending on the cockpit model).

[Flaser]

Two questions:

• What about seeing damage to your own ship from the cockpit? How will the new method handle that?
• I assume the new system will allow one to look around the cockpit, and use a padlock view. What the status on that?

[Nuke]

it would probibly be a good idea to not render the lowres cockpit model (any submodel named cockpit_interior) of a player ship if it has an external high detail cockpit model and the view is internal. id still like show ship to be valid though. cause sometimes theres external geometry and weapon models of your ship you would like to show.

the thing is, to implement realistic looking cockpits it should be possible to move hud elements around (or disable them completely, depending on the cockpit model).

if the hud is rendered onto polygons in 3d on a virtual lcd in the cockpit, it should look like the hud as defined by the game or as modified through scripting/or hud_gauges.tbl. in the event of rtt gauges, the positions of each would could easily be defined by uv data in the model. just map the panel uv coords to a place where the particular gauge would be rendered into the rtt panel map.

[Tolwyn]

if the hud is rendered onto polygons in 3d on a virtual lcd in the cockpit, it should look like the hud as defined by the game or as modified through scripting/or hud_gauges.tbl. in the event of rtt gauges, the positions of each would could easily be defined by uv data in the model. just map the panel uv coords to a place where the particular gauge would be rendered into the rtt panel map.

scripting is out of the question because it is not in the stable branch and hud_gauges.tbl does not support all HUD elements.

[taylor]

the thing is, to implement realistic looking cockpits it should be possible to move hud elements around (or disable them completely, depending on the cockpit model).

That's the ultimate goal obviously, to allow the creation of both realistic flight-sim style cockpits, as well as more arcade-style cockpits.

In the meantime though, hud_gauges.tbl could be expanded to allow for profiles that would allow different ships to have different HUD setups.  And adding more gauges is just something that is (or should be) on the todo list.  I'd add them myself, but I honestly don't know what's missing, so a list of what doesn't work would be a help.

Plus I think that Backslash was/is working on hud_gauages.tbl stuff, so maybe he has already gotten some of this worked out.

Two questions:

• What about seeing damage to your own ship from the cockpit? How will the new method handle that?
• I assume the new system will allow one to look around the cockpit, and use a padlock view. What the status on that?

a) Damage can/will be mirrored on the cockpit model based on what the player ship has.  This is sort of a given in order for it to work and be believable.  You actually have far less ability in this respect with the current way that show-ship works.

b) The new cockpit setup won't actually allow you to do that, it will just make adding such code finally worth it.

it would probibly be a good idea to not render the lowres cockpit model (any submodel named cockpit_interior) of a player ship if it has an external high detail cockpit model and the view is internal. id still like show ship to be valid though. cause sometimes theres external geometry and weapon models of your ship you would like to show.

The old show-ship method will be dead, and you aren't going to lose anything, so get over it already.   

The cockpit pof can have anything that you want on it.  The code will simply mirror as much as possible about the state of the player ship on that model, whether it's damage, submodel animations, external weapons, whatever.  The only difference is that with the cockpit pof you won't have to pull any punches with regards to detail.  Add your polys and make it look as good as you want.  It's only ever going to be rendered once per frame, so you simply don't have to deal with all of the crap that you have to go through to make a regular ship model work well.

Plus, having the cockpit as a submodel in a ship incurs a performance penalty (just as any submodel does), so making as much of a ships cockpit part of the main hull as possible will make a ship render faster/more efficiently.  Simply having the cockpit as a submodel hurts far worse than any potential waste of polys.

If you use "show ship" and have the cockpit pof entry specified, then it will only ever use the cockpit pof, period.  We aren't going to hybrid anything, because as I said earlier, the current method is simply stupid.  There isn't necessarily a reason to remove support for it, but I'm most certainly not going to maintain support for it working together with the new features that are coming in the future.

And the reason that "show ship" would still be required (in case someone askes) even when a cockpit pof is specified, it's because that way we can have support for a species default cockpit too, but still allow individual ships to make use of regular hud_gauages.tbl rather than a 3D model.