Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Scooby_Doo on November 19, 2007, 04:39:47 am
-
Is there any good time table (as in soon, very soon, maybe within your lifetime :drevil:) 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).
-
Probably within 6-8 months, that's the goal anyway. Just depends on available time, whether anything more important comes up, etc.
-
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).
-
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.
-
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
-
But then you won't be able to see the ship outside the cockpit model.
-
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.
-
ummm taylor your preaching to the choir :D
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)
-
ummm taylor your preaching to the choir :D
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. :D
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.
-
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%
-
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.
-
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?
-
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!
-
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.).
-
sweetness
*giggles with anticipation*
-
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).
-
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?
-
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.
-
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.
-
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. :p :D
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.
-
Sounds great.
So you need a list of possible additions to the HUD, eh?
-
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.
-
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 :)
-
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.
(http://img.photobucket.com/albums/v356/Shodan_AI/Extras/hudcopy.jpg)
-
:nervous: :nervous:
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. :no:
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?
-
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.
-
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. :p The planned system looks almost identical though - the only real difference is how to how to handle different cockpit struts.
-
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?
-
Well using that sample I posted above...
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit7.jpg)
although there are problems with uvmapping and distortion
I added three extra planes to the cockpit panel. Applied that texture, and uv mapped it.
-
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.
-
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! :p
-
Whats RTT?
Also you should be able to create huds and use right off the bat without scripting it.
-
RTT => Render-to-texture.
#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.
-
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.
-
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.
-
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. :p :D
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 (http://www.youtube.com/watch?v=WKdg-Uk9K9k) im cool with it. :D
if not i stand to loose alot 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. alot 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.
-
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.
-
RTT => Render-to-texture.
#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 :P
-
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! :p
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.
-
:nervous: :nervous:
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. :no:
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" ??
-
its messy but its working now
http://www.youtube.com/watch?v=-PM69ICOhsE
-
very cool! ;)
And we could put any gauge onto the cockpit model? Or disable gauges we do not want/need?
-
Very Sweet!!
btw were you moving the cockpit or was it from natural head bob inertial?
-
the guages in the demo were static, however the yoke and throttle work(you cant see it though because of clipping issues). im still not sure how gauges are gonna work. once rtt gets fixed its not to hard to render any scripted gauge to a texture and use that for your panels. hopefully non scripters will be able to use the hud_table to do the same thing.
i was using my trackir to move the view in the cockpit through mouse emulation. i essentially used the same function that i used in my mouse script to provide the rotational data. i built a rotation matrix from the euler angles and multiplied the ships's orientation by that matrix (or was it the other way around, i dont remember), and set that matrix to a camera. i could have just used the mouse (handles just like an fps but you cant do a 360), the thumbstick on my throttle, or the track ir mouse emulation. so i chose the latter works quite well.
a big problem was aiming, as you can see my reticle was useless. i tried using my leading reticle, but i couldnt get it to draw on the cameras hud. it works but not with the camera code.
the only real means of any input for scripting is the mouse. its probibly possible to hijack control from Physics.ForwardThrust or Physics.RotationalVelocityDesired to get the actual joystick positions, but this doesnt let you have any more than 4 axes, and they double up for flight control. i can imagine anyone making land vehicles, mechs, ect would use that meathod. with further adjustments elsewhere control a turret with the joystick.
-
:yes: You da man!
-
Trying to remember how it was done in Falcon 4, when your in target eye lock mode. I think the recticle was fixed in the correct position, and when you couldn't see the recticle, a little arrow pointed to where it was located.
-
my reticle doesnt care what your view angle is, my problem was that i couldnt get it to draw.
-
:nervous: :nervous:
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. :no:
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?
I never would have hoped for the SCP team to turn its eyes towards virtual cockpits, since it seems the majority of the space-sim community shares your opinion ARSPR. FS2 is so good that I ALMOST forgave it for not having cockpits when i played the retail release. And when i finished, I still thought that the only thing that could've made it a better game, would've been 3d-cockpits. For me, a cockpit not only pushes the impression of sitting in a fighter, it adds both scale and depth to what is otherwise a flat plane rushing face-forward through space. As an avid flight-simmer, I just get rankled by space-sims that think they can get away with ditching the cockpits, just cause Freespace and Wing Commander 4 did it. Flight sims and racing sims usually feature functional cockpits since the game designers actually have a real-world analogue to *simulate* unlike space-sim developers, but even non-functional cockpits ground the sim experience in the familiar reality of sitting inside a vehicle.
Many cockpit trashers argue that a space vehicle wouldn't have an exposed aircraft-style cockpit, and would rather embed the pilot deep within the ship and surround him with a seamless projection of surrounding space. (This doesn't change the fact that almost all space-sims, FS2 included, clearly feature aircraft-style cockpits on their ship models) Rational or no, this bubble idea is just too abstract for my tastes, as are cockpitless vehicle sims of any breed.
Ah sorry to clutter this technical topic, since the issue being discussed is not 'should cockpits be made' but i had to.
Anyway, to the artists and coders here at hard-light, I now shake your hands and say you're a big part of the reason PC gaming is great. Thanks to all.
-
One thing i really, really dislike in true virtual cockpits is the instrument panel. If taken an example from for example IL-2 (or modern fighter jet sims)... When i played it in 1024 x 768 reso i have absolutely no way of reading the gauges as they got far too blurred. Those were readable only while zooming which isn't exactly practical while dogfighting... Of course in single player mode i could always pause the game while checking the instruments but that just kinda proves my point.
That is virtual cockpit frame would be great sorta like in I-W2 or in that Nuke's example clip.
Virtual instrument panels not so much (mainly because they are mostly unreadable). If some one claims to be able to make instrument panels, that do not totally clutter the main view and, that are readable from (preferably from 640 x 480) 1024 x 768 upwards then.. cool. But as so far i haven't seen any in fighter sims.
-
One thing i really, really dislike in true virtual cockpits is the instrument panel. If taken an example from for example IL-2 (or modern fighter jet sims)... When i played it in 1024 x 768 reso i have absolutely no way of reading the gauges as they got far too blurred. Those were readable only while zooming which isn't exactly practical while dogfighting... Of course in single player mode i could always pause the game while checking the instruments but that just kinda proves my point.
That is virtual cockpit frame would be great sorta like in I-W2 or in that Nuke's example clip.
Virtual instrument panels not so much (mainly because they are mostly unreadable). If some one claims to be able to make instrument panels, that do not totally clutter the main view and, that are readable from (preferably from 640 x 480) 1024 x 768 upwards then.. cool. But as so far i haven't seen any in fighter sims.
with a track ir or other proper view controls, its actually possible to lean forward and get a closeup glance of the panel without a whole lot of thought. even in the middle of a dogfight. as far as modern combat goes, the cockpits are way to complex to display on small, (relatively) low res screens. its better in ww2 sims, and would probably be even easier in freespace because of the relative incomplexity of the hud.
keyword is situational awareness. the virtual cockpit is really only a part of that. in a fully immersive system of cockpit and view controls, the role of the cockpit is more to provide a frame of reference for your view controls, and secondly to provide gauge information. first rule of air combat is keep youre head on a swivel. view controls through a track ir or other system (freetrack, extra joystick axes, mouse, ect). even then you may get lost as to what direction youre facing. a good cockpit is important here to give you clues as to which way youre looking. you see part of a wing or a reflection in the glass and you know exactly where youre looking.
panel gauges are an extra. i found the track ir useful even in mw2. where the cockpit models are flat shaded, are very simple, and have no gauges. the very simple flat shaded cockpit models did lend themselves very well to view orientation. and the ability to look around improved my combat performance. my plan for panels in nukemod was to provide more technical information that the average freespacer would probibly never be concerned with, rather than just copying gauges off the hud. this also tends to be more realistic, in that the hud is just a simplified version of any other gauges which may be on the panel.
-
I never would have hoped for the SCP team to turn its eyes towards virtual cockpits, since it seems the majority of the space-sim community shares your opinion ARSPR. FS2 is so good that I ALMOST forgave it for not having cockpits when i played the retail release. And when i finished, I still thought that the only thing that could've made it a better game, would've been 3d-cockpits. For me, a cockpit not only pushes the impression of sitting in a fighter, it adds both scale and depth to what is otherwise a flat plane rushing face-forward through space. As an avid flight-simmer, I just get rankled by space-sims that think they can get away with ditching the cockpits, just cause Freespace and Wing Commander 4 did it. Flight sims and racing sims usually feature functional cockpits since the game designers actually have a real-world analogue to *simulate* unlike space-sim developers, but even non-functional cockpits ground the sim experience in the familiar reality of sitting inside a vehicle.
Many cockpit trashers argue that a space vehicle wouldn't have an exposed aircraft-style cockpit, and would rather embed the pilot deep within the ship and surround him with a seamless projection of surrounding space. (This doesn't change the fact that almost all space-sims, FS2 included, clearly feature aircraft-style cockpits on their ship models) Rational or no, this bubble idea is just too abstract for my tastes, as are cockpitless vehicle sims of any breed.
Ah sorry to clutter this technical topic, since the issue being discussed is not 'should cockpits be made' but i had to.
Anyway, to the artists and coders here at hard-light, I now shake your hands and say you're a big part of the reason PC gaming is great. Thanks to all.
:welcomesilver:
I somewhat share your opinion. I personally think that cockpits aren't cool in PC games while I love cockpits of games like Ace Combat. Look elsewhere when you're pointing to a certain location is a feature of consolle games I love. Cockpits aren't intended as "something that makes the HUD look more realistic", they influence the game experience.
-
fs scp is great the way it is.
but i would also like to see cockpits! it completely changes the experience, like nuke stated before. it gives you a much more "realistic" impression of the game. for example, i play colin mc rae dirt only in the cockpitview. of course, maybe i would drive better in the chase or bumper view, but i like the feeling. and i'm still not a too bad colin mc rae driver.
what i want to say: cockpits are very important for a realistic experience, like it should be in a sim. and freespace is a great sim.
PS: sorry for OT
-
Is there any good time table (as in soon, very soon, maybe within your lifetime :drevil:) 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).
Wonder no more (http://www.hard-light.net/forums/index.php/topic,51203.0.html)
-
How are Rendered cockpits going to deal well with the issue of 16x9 vs 4x3 aspect ratio's and the resolutions distoring because the hud and background are 2D expecting to be 4x3 interfacing improperly with a hardware 3D running true?
Can HUD and Background be rendered seperately? Because if so, would this work:
Game (3D) resolution is 1600x900. (16x9)
Draw Background (not as scaled to fit) at 1600x1200 (4x3).
Draw/Overlay HUD as 900x675 (4x3).
Would this resolve targeting box wobbly issues as well as background "moonwalk" issues?
Or create entirely different issues?