[TrashMan]

Sounds great.

So you need a list of possible additions to the HUD, eh?

[taylor]

So you need a list of possible additions to the HUD, eh?

For hud_gauges.tbl updates, yeah.  That will likely be a reference for what needs to be possible on a 3D cockpit too, so the more complete that 2D code is the easier it will be to do the 3D stuff later on.

[Tolwyn]

well, hud_gauges allows to move certain elements, but not all at the moment. I am not sure if it offers an  ability to disable certain hud gauges.

At any rate, it would be cool to be able to move: energy distribution, comm window, weapon selection, radar and so on

[Scooby_Doo]

Ugh... catching up...

How about render, while running, the hud to a dynamic texture with a fancy name like "HUD", with a transparent background.  Have each hud control in a specific area.  The modeler would then use a template of the texture "HUD", also the template would be named "HUD" and would UVmap the polygons to the correct hud area.  Then the game would use the dynamically built hud texture where-ever it sees a mesh in need of texture called "HUD" For example shield, have a square polygon apply the "HUD" texture name to it and uvmap it so that it maps just the shield status.  Course you would need a second squarish polygon behind it, but give it whatever texture you want, something like dirty glass.

[ARSPR]

 
Sorry if this post hurts somebody but this is just my opinion. Please take it only like that, an additional opinion.

Cockpit are beautiful, wonderful, pretty and ultra shiny. But they are fully useless.

When I'm dogfighting a Shivan horde I want to see everything, (and even more), and if I have a cockpit in the middle, it just blocks some of my view area.

I'm pretty sure that 95% of the gamers are going to turn them off after the initial "how-wonderful-my-Herc-controls-are" runs. At least this happened to me with X-Wing series. And when I firstly ran retail FS I remember wondering "Hey, these guys have been smart enough to forget about stupid block-my-view cockpits". A fully transparent HUD is just great.

I don't know how much effort all the cockpit coding will take, but I feel it is mainly a waste of time and resources, (and SCP coder community is short of them both). Please spend it in other areas  .

I feel cockpit improvement is just like if someone told about codding a fully 3D mainhall. Of course it's an addition, but a worthy one?

[Tolwyn]

It is a matter of oppinion. Do you turn off cockpit in a racing game? I do not play NfS anymore, because they removed cockpits! In Wing Commander 3 I always played with cockpits turned on (even if I could turn them off), because they improve the overall "I am sitting in a star fighter" feeling.

[Vasudan Admiral]

I used to be of the same opinion ARSPR - I'd always turn cockpits off in any game. However, having worked on the FS one recently, I think I've changed my mind there. As Tolwyn says, it really ramps up the 'in-a-starfighter' feeling, which truth be told I didn't even realise it was lacking before.

So yeah - it's basically just a personal preference thing.

Anyway - I'm glad to hear cockpits are on the todo list, although it would have been even nicer if anyone could have mentioned it to me in that whole 'cockpit model feedback thread' thing. The planned system looks almost identical though - the only real difference is how to how to handle different cockpit struts.

[Flaser]

Ugh... catching up...

How about render, while running, the hud to a dynamic texture with a fancy name like "HUD", with a transparent background.  Have each hud control in a specific area.  The modeler would then use a template of the texture "HUD", also the template would be named "HUD" and would UVmap the polygons to the correct hud area.  Then the game would use the dynamically built hud texture where-ever it sees a mesh in need of texture called "HUD" For example shield, have a square polygon apply the "HUD" texture name to it and uvmap it so that it maps just the shield status.  Course you would need a second squarish polygon behind it, but give it whatever texture you want, something like dirty glass.

Hmm...I had a wild idea: how about going with an "all modeled" HUD?
So instead a re-rendered texture at each frame you'd have a bunch of flat/simple polygons in the appropriate position relative from either the cockpit model, a submodel of the cockpit model, or tied to the view point if it's a visor element.

You could map current HUD functions to those polies by scripting their position, movement etc. to the data that currently handles the HUD right now.

So you'd have a set of trigger stats that currently drive the HUD and translating that to some kind of display device would be up to you. It could be a hell of a lot of work to make a HUD but with a number of templates it could be really powerful and absolutely modable.

Now even without in depth knowledge of the code, I know some problems are sure to crop up:
-Sticking these "display/HUD" polygons to the cockpit: how are they generated, are they modeled as part of the model or are they separate objects?
-If separate objects how is render order resolved?
-If they are subobjects how are they highlighted that they should be treated differently?
-In both cases can the animation code handle re-creating useful (readable, visible) devices?
-For changing items, that show labels, texts, or any data that should be something readable - ergo requiring a string input - how does this system handle these items. Are these objects generated/swapped on the fly? Or is it a place where render to texture is the most sane thing to do?

Finally when one looks at all the myriad problems, I'm not sure that the all-modeled approach is a good immediate goal.
Why bring it up then?
Because in the end some of those features could be very handy, and thinking about them ahead of time could ease laying the groundwork for the later development.

What both a modeled and a rendered to texture approach share to is how to handle on-the-fly generated content. The current method is through hard coded procedures that create the HUD elements from a discreet set of graphic elements and functions.

The new system will need a base set of those, but if modability is desired, some sort of scripting and/or rendering interface will have to be implemented to generate those elements from the trigger data in a dynamic manner.

Beside the "mere rendering" (Mere? Ha! That is already a complex problem of its own!) handling of the new cockpit what are the plans for this new "HUD" / "rendering" interface?

[Scooby_Doo]

Well using that sample I posted above...

although there are problems with uvmapping and distortion
I added three extra planes to the cockpit panel.  Applied that texture, and uv mapped it.

[WMCoolmon]

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.

I agree that you could implement separate cockpit models without much problem. In fact, you could probably do it in less time that people have collectively spent talking about it in this thread. And you'd gain a lot of advantages too.

But just because you come up with a better method doesn't mean that the old one is "stupid", worthless, and is going to require incredible amounts of support to keep going. All the flag does is keep the player ship from being skipped when all of the ships are being rendered. If you were to put the player in control of a large capital ship, or a ship with substantial structural elements in front of the player viewpoint (the Cylon raider comes to mind) it would make sense to use the show ship flag. It wouldn't require modelers to remodel that portion of the ship in the cockpit model, adjust it to look right given the player perspective, re-UV that, update it if there were ever changes...etc, etc. And what happens if you find that you need to move the eyepoint due to balance issues? Do you re-model the cockpit to adjust the external ship elements with relation to the cockpit? Or do you just leave those out and compromise the realism that was the point of having cockpits in the first place?

Removing "show ship" would also break backwards compatibility with the cockpit released so far.

Because the standard ship_render function is used instead of a special model_render call, damage on the ship is shown. So if one of the prongs on the Cylon Raider were chipped off, you would see that with the "show ship" flag. And additionally, damage decals would show up (if they are ever fixed) as well as damage spew.

I'd guess that the "show ship" flag, as it is, takes up maybe 50 lines of code, possibly half that.

So my opinion: Leave the "show ship" feature as it is, and implement a separate "$Cockpit POF:" that's drawn after all of the 3D elements in a mission but before the HUD.

EDIT: I should add that, just based on a mental guess at what would be required to do what you're saying, it would take more code to turn the "show ship" function on and off based on the addition of a "$Cockpit POF" than to just keep them separate and leave it up to the modder. You'd certainly have to change the former much more than the latter.

[WMCoolmon]

Per the discussion on 3D HUDs, I've thought of it this way:

1. UVWrap a separate texture with real-looking displays on your ship
That way if somebody's computer doesn't support RTT (doubtful) or someone looks at the ship in the tech screen, they see the fake HUD screen.

2. Using RTT, render the HUD onto a dynamic texture

3. Using texture replacement, replace the original texture from #1 on the ship with the texture from #2.

4. Enjoy

Now with separate cockpit models, I don't think it'd be a whole lot different. You'd have to add support for texture replacement on the separate model, and the model rendering function already supports texture replacement as long as you set up an int[] array properly when you render the model. So all you'd have to do would be to change #3.

Obviously there are some small things you'd have to deal with - for instance, how do you access the current cockpit model from scripting? But I feel like it's kind of silly to spend all the time on a system for creating 3D HUD gauges that, in the end, will only be slightly less complex than scripting it, and will be limited to what's been hardcoded.

It also feels kind of silly to me to go to all that trouble, just so you can use the same hud gauges - which are over a decade old, and notorious for being impossible to mod much - and turn them ever so slightly to look 3D. Be bold!

[Scooby_Doo]

Whats RTT?

 Also you should be able to create huds and use right off the bat without scripting it.

[WMCoolmon]

RTT => Render-to-texture.

Code: [Select]

#Conditional Hooks
$State: GS_STATE_GAME_PLAY
$On Frame: [
if not tex then
   tex = gr.createTexture(512, 512, TEXTURE_DYNAMIC)

   if tex:isValid()
      Player.Textures['HUD'] = tex
   end
end

if tex:isValid() then
   gr.setTarget(tex)
   gr.setColor(255, 255, 255)
   gr.drawString("Hello there", 0, 0)

   --Draw other HUD gauges here

   gr.setTarget()
end
]

#End
That is the complete set of scripting (sans the rest of the HUD) you would need to (1) create a texture, (2) assign it to the space mapped to texture 'HUD' on the player ship, (3) draw "Hello there" in the upper-left hand corner.

Example assumes the unstable branch, and that RTT and texture replacement are working.

[Scooby_Doo]

Does this assume the rendered texture has specific areas like in my first pic?  Because you'll need a sample so that we can uvmap the polygons correctly.

[WMCoolmon]

Your image looks like what the texture would look like while being rendered to. You'd then UV wrap portions of that texture to different places on the model.

If you ran out of space on the first texture, you could make a separate texture. You'd be specifying which textures to use in scripting itself, so the names could be whatever you liked, and you could have as many as you liked (but as few maps, and always smaller than 2048x2048, would be best).

You wouldn't be able to use existing gauges; you'd have to remake those in scripting. If you were using straight retail gauges, it'd only have to be done once. Once one person remade the retail FS2 HUD in Lua, everyone else could either use that or improve on that.

You aren't going to be able to instantly use scripting and get all the features talked about in this thread; it still needs more updates to display everything the HUD shows right now, although you can access things that the HUD doesn't show right now, too. I just see it as being a more valuable investment of time because once it's completed, you can take the original retail gauges and expand on them without additional hardcoding; with a hardcoded system, you're left running back to the code every time you come up with a new type of gauge, even if it only relies on basic graphics functions.

[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 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.

so long as i can still have this im cool with it.
if not i stand to loose of work, as many ships need to be re-re-re-re-modeled. inducing a condition of the modders equivalent of re-inventing the wheel.

we still want out outside view cockpits though. of media vp ships have them. and the orthodox means of putting them in requires glass in another texture (ive done it by putting glass into the main texture on some ships) and putting the cockpit geometry into a submodel. i say leave that part in and leave it up to the modder to optimize. just use a much lower poly cockpit on those. submodels can be detail boxed or loded to further improve their rendering performance.

better sorting code can further improve performance. for example make it so that if a ship and all its subobjects only use a single texture, then render the submodels and ship as one object rather than doing submodels seprately. so that ship, cockpit sub model, and glass, which share the same texture, could all be rendered in one pass.

my idea was merely to exclude that submodel, render the external ship, then the cockpit model over it. so people could keep their existing cockpits, benefit from the new cockpit feature, and still see the external structures of the ship.

Well using that sample I posted above...
*piccy*
although there are problems with uvmapping and distortion
I added three extra planes to the cockpit panel.  Applied that texture, and uv mapped it.

this is exactly how i would implement an rtt hud. but i would use the future materials system to blend the basic rtted panel texture with other pre-drawn maps. for example you can make a glass diffuse map with shine and env maps and use the hud texture as a glow map. or you might want to blend it into a transparent glass texture for use in a 3d hud screen. you can also match the appearance of the screens to fit particular cockpits, like vasudans might use different display technology.

then again it would be much simpler to draw the glass on the panel as if the screens were off or blacked out. then to put planner overlays just over the surface to which the rtt texture need be applied. either way you use the uv space to tell the game what gauge to put where.

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.

I agree that you could implement separate cockpit models without much problem. In fact, you could probably do it in less time that people have collectively spent talking about it in this thread. And you'd gain a lot of advantages too.

But just because you come up with a better method doesn't mean that the old one is "stupid", worthless, and is going to require incredible amounts of support to keep going. All the flag does is keep the player ship from being skipped when all of the ships are being rendered. If you were to put the player in control of a large capital ship, or a ship with substantial structural elements in front of the player viewpoint (the Cylon raider comes to mind) it would make sense to use the show ship flag. It wouldn't require modelers to remodel that portion of the ship in the cockpit model, adjust it to look right given the player perspective, re-UV that, update it if there were ever changes...etc, etc. And what happens if you find that you need to move the eyepoint due to balance issues? Do you re-model the cockpit to adjust the external ship elements with relation to the cockpit? Or do you just leave those out and compromise the realism that was the point of having cockpits in the first place?

Removing "show ship" would also break backwards compatibility with the cockpit released so far.

Because the standard ship_render function is used instead of a special model_render call, damage on the ship is shown. So if one of the prongs on the Cylon Raider were chipped off, you would see that with the "show ship" flag. And additionally, damage decals would show up (if they are ever fixed) as well as damage spew.

I'd guess that the "show ship" flag, as it is, takes up maybe 50 lines of code, possibly half that.

So my opinion: Leave the "show ship" feature as it is, and implement a separate "$Cockpit POF:" that's drawn after all of the 3D elements in a mission but before the HUD.

EDIT: I should add that, just based on a mental guess at what would be required to do what you're saying, it would take more code to turn the "show ship" function on and off based on the addition of a "$Cockpit POF" than to just keep them separate and leave it up to the modder. You'd certainly have to change the former much more than the latter.

i think that explains it better. i think the solution is rather than replace the old system entirely with a new strict system. rather add features to complement existing features in a manner that sets up a more flexible system of features. essentially give the modders the tools and leave it up to their ingenuity to create a working cockpit. there are a million and one ways to improve the performance of a model. if we dont like the way our model performs we can always fix it. thing is most of the features needed to create a realistic virtual cockpit are already in game or at least the head branch. many of them just need to be refined to a point where brought into the stable branch.

[Scooby_Doo]

Basically the background texture of the RTT is 100% transparent.  And since I'm using a rect polygon in front of another, any transparency from the hud texture will show the back texture.  Could be a blank glass screen.. or if you have heads up hud, nothing behind the hud textured poly so you see the game.

[Nuke]

RTT => Render-to-texture.

Code: [Select]

#Conditional Hooks
$State: GS_STATE_GAME_PLAY
$On Frame: [
if not tex then
   tex = gr.createTexture(512, 512, TEXTURE_DYNAMIC)

   if tex:isValid()
      Player.Textures['HUD'] = tex
   end
end

if tex:isValid() then
   gr.setTarget(tex)
   gr.setColor(255, 255, 255)
   gr.drawString("Hello there", 0, 0)

   --Draw other HUD gauges here

   gr.setTarget()
end
]

#End
That is the complete set of scripting (sans the rest of the HUD) you would need to (1) create a texture, (2) assign it to the space mapped to texture 'HUD' on the player ship, (3) draw "Hello there" in the upper-left hand corner.

Example assumes the unstable branch, and that RTT and texture replacement are working.

texture replacement apears to work, RTT does not.
and you forgot a then 

[TrashMan]

Per the discussion on 3D HUDs, I've thought of it this way:

1. UVWrap a separate texture with real-looking displays on your ship
That way if somebody's computer doesn't support RTT (doubtful) or someone looks at the ship in the tech screen, they see the fake HUD screen.

2. Using RTT, render the HUD onto a dynamic texture

3. Using texture replacement, replace the original texture from #1 on the ship with the texture from #2.

4. Enjoy

Now with separate cockpit models, I don't think it'd be a whole lot different. You'd have to add support for texture replacement on the separate model, and the model rendering function already supports texture replacement as long as you set up an int[] array properly when you render the model. So all you'd have to do would be to change #3.

Obviously there are some small things you'd have to deal with - for instance, how do you access the current cockpit model from scripting? But I feel like it's kind of silly to spend all the time on a system for creating 3D HUD gauges that, in the end, will only be slightly less complex than scripting it, and will be limited to what's been hardcoded.

It also feels kind of silly to me to go to all that trouble, just so you can use the same hud gauges - which are over a decade old, and notorious for being impossible to mod much - and turn them ever so slightly to look 3D. Be bold!

If you could get it to work that way it would be awesome! It sounds simple enough and intuitive enough, without requiring too much work from anyone! Brilliant.

[Reprobator]

Sorry if this post hurts somebody but this is just my opinion. Please take it only like that, an additional opinion.

Cockpit are beautiful, wonderful, pretty and ultra shiny. But they are fully useless.

When I'm dogfighting a Shivan horde I want to see everything, (and even more), and if I have a cockpit in the middle, it just blocks some of my view area.

I'm pretty sure that 95% of the gamers are going to turn them off after the initial "how-wonderful-my-Herc-controls-are" runs. At least this happened to me with X-Wing series. And when I firstly ran retail FS I remember wondering "Hey, these guys have been smart enough to forget about stupid block-my-view cockpits". A fully transparent HUD is just great.

I don't know how much effort all the cockpit coding will take, but I feel it is mainly a waste of time and resources, (and SCP coder community is short of them both). Please spend it in other areas  .

I feel cockpit improvement is just like if someone told about codding a fully 3D mainhall. Of course it's an addition, but a worthy one?

Have you ever eared about : "immersion" ??