Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Topgun on November 03, 2007, 05:44:41 pm
-
I am looking for VA's NEW cockpit and can't find it. does anyone have a link?
-
If you mean this new internal one:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/InternalCockpit4.jpg)
Well it's basically on hold (in the feature requests wiki page) until either a coder finds the time & desire to implement the internal cockpit system in-game, or I learn to code and do it myself. ;)
(There's a list of what would need to be done here. (http://www.hard-light.net/forums/index.php/topic,48726.msg990018.html#msg990018))
However, I realise I forgot to release the optimised externally viewed cockpit model that I made to use in conjunction with that new internal one, so here's a package containing a .blend, .cob, .3ds and BMP and DDS versions of the texture.
http://www.freewebs.com/twisted-infinities-va/MiscStuff/Cockpit.zip
It doesn't include the internal one in the pic - if you want that it's in that post I linked to, but it does include all you'd need to put cockpits in your own ships, since the internal one is intended to become to be a separate pof that the ships tbl entry can link to. :)
-
thanks! just what I needed!
EDIT: the link does not work.
-
Ok, something about Freewebs has changed so that remote linking files like that does not work. That just pisses me off. :hopping:
You can rightclick->save as though still.
-
thanks.
-
:wtf:That seems like a lot of detail almost no-one will see.
-
Oh wow... looks like I need to do some cockpit redoing myself :eek:
-
:wtf:That seems like a lot of detail almost no-one will see.
I dunno about you, but I use the hat on my joystick all the time to look around. As such, I'd kinda expect to be able to see the cockpit around me if it's visible in front of me. That and if free-look ever comes about you'd be able to look around with the mouse while flying with the keyboard/joystick. ;)
And besides that you have renders and potentially new pilot video message thingies!
And also, I just can't ever seem to bring myself to do low detail stuff anymore. :(
-
About how many polys do you use for cockpits?
-
I used 1500 or so for that one - but most of it is used to bevel the edges of the consoles and stuff that's right in front of you. I don't know how well bump mapping would be able to address that kinda thing though, so polycount and texture resolution would probably depend on the cockpit design. I'd recommend you use as many as it takes to make your cockpit look as real as you can reasonably make it. :)
But remember two things:
1) The feature isn't actually there yet, so there's not much of a way to test anything. I suppose if we have enough cockpits floating around though some kind coder will finish it off. :D
2) You probably realise this already, but for those who use cockpits, the thing will be in front of their face the entire time they're in-mission, so they need to look as good as you can make them. Poor quality internal cockpit views will only ever prompt people to turn them off.
-
If we're talking about a seperate model cockpit, then we could probably go up even higher, as this is a seperate ship (sorta speak)
Also hi-res textures are a must.
-
Yeah they could definitely go higher - I built this one with the possibility in mind that it would have to be incorporated into each model, so I kept it lower than I would have liked (some parts are too square and stuff).
Incidentally, once I'm done with the Valkyrie I'll be finishing off Raa's HTL Horus model, and part of that will involve making a Vasudan cockpit. Combine that with any you make for your stuff, UT's Viper cockpit, Nukes plans (if he hasn't actually made it already) and I think Aldo already has a couple - well there will be quite a few all ready for the feature itself to arrive. ;)
Finally - if any mods want to use in-ship cockpits, can you add your mod name to the list of supporting mods in the Wiki's feature request page? (http://www.hard-light.net/wiki/index.php/Feature_Requests) Part of the reason for that page is so coders can keep track of the 'most wanted' features, and they're more likely to pick the ones that will make more people happy! :D
-
Question, would the original model be visible alongside the cockpit? I.E. would I have to also include parts of the ship mesh also with the cockpit?
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit1.jpg)
-
In my current thinking of the implementation, you would need a set of correctly shaped and named cockpit struts as subobjects of the cockpit model (we should soon be able to import subobjects into pofs using PCS2, making late additions not too troublesome since we can already move them around).
You'd do this for a few reasons:
1) They'd be better detailed than those on the actual ship pof
2) Much easier to position them nicely to obscure as little view as possible
3) Removes the big headache of figuring out how to position the internal cockpit pof inside the ship pof so that the struts are in the correct spot, but the standard externally viewed cockpit isn't all intersecting your internal pof.
4) Reusable cockpit struts - depending on the implementation, you might be able to specify which submodel of this internal cockpit would be used by individual ships
Your cockpit there looks good, but depending on how much you're willing to modify it, I'd recommend you try and add more screen-space through one of two ways:
1) Bigger console screens - my cockpit had pretty huge screen areas:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/InternalCockpit1.jpg)
...but still ended up really cramped for space:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/Template2_Brightened.jpg)
2) (Looks more likely in your case) Try and model in 'button functions'. As an example, the missile warning light wouldn't be on a console screen, but would be a separate button that lit up when needed.
Also, don't bother trying to make space for messages, the comm system directives or the escort list - they just take up way too much precious room. :(
-
How did you get the hud to look like that or just photoshopped for the moment?
My cockpit was more based on those way overly priced cockpit models found on turbosquid. more of a modern fighter style. Although I did use your back as inspiration. I'm grinding my teeth about the radar. You know what would really be nice, is like a Falcon 4 style hud, that you can switch modes
Also how about setting up two eye points. One of the ship and the other on the cockpit mesh. The game will link those two together, rendering the cockpit as the last object to be rendered.
-
It's just a ...err...paint-shop-pro-ed on I'm afraid. ;) (It is an in-game shot though - I put the cockpit as it's own pof with the show ship flag in the table. It looke quite nice with the lighting changing as you flew around)
Could you try fitting in a radar screen where the reddish bit between the two mainscreens is at the moment? Those screens would become kinda....not square anymore, but it really needs a radar, and it really should be in the middle for ease of use.
And yeah, being able to switch functions would be nice, but there's probably too much information that you might need at once for that to work well in a FS context.
-
beautiful....
-
Now all we need to find is a good 3d pilot.
-
heehee
-
How about using a Sim for a pilot? :D
Ok my attempts with skin and physique weren't that great and it definetley needs massive poly reduction and cleanup, especially around the crotch, but hey it's already uvmapped :)
Sim heads are on a different mesh (probably because they have special joints/vertices required for genetics)
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit2.jpg)
It's a lot cheaper than a $300 pilot mesh at turbosquish... :ick:
-
You know, if a cockpit is going to be implemented, it probably should be different for every fighter and bomber.
Speaking of, I want a look back feature. I want to see who's chasing me, a feature rather un-there in retail but one that is quite important for other dogfight sims or whatever.
-
3) Removes the big headache of figuring out how to position the internal cockpit pof inside the ship pof so that the struts are in the correct spot, but the standard externally viewed cockpit isn't all intersecting your internal pof.
Are you going to design the system so that the internal model will only show up if the ship is viewed in the cockpit, and the cockpit on the normal model will show outside? (Then it wouldn't slow down everytime you turned towards the ship with the complex cockpit.)
Also, don't bother trying to make space for messages, the comm system directives or the escort list - they just take up way too much precious room. :(
These can be left in their original positions.
I want a look back feature. I want to see who's chasing me, a feature rather un-there in retail but one that is quite important for other dogfight sims or whatever.
We already have one.
-
3) Removes the big headache of figuring out how to position the internal cockpit pof inside the ship pof so that the struts are in the correct spot, but the standard externally viewed cockpit isn't all intersecting your internal pof.
Are you going to design the system so that the internal model will only show up if the ship is viewed in the cockpit, and the cockpit on the normal model will show outside? (Then it wouldn't slow down everytime you turned towards the ship with the complex cockpit.)
..yeah that's what I said. ;)
The internal cockpit would be a separate pof used in place of the ship itself, while the external cockpit is done just as they are being done now.
You know, if a cockpit is going to be implemented, it probably should be different for every fighter and bomber.
Err, well unless you're volunteering to make like 25 separate cockpit models, I can tell you now that it's not gonna happen. ;) Not because FSO would be incapable of supporting it, but just this one cockpit took me a long time to texture - and even though I was probably going a bit overboard on the detail on it, it's not the sort of thing you can skimp on.
Scooby:
Problem with having a pilot is what happens when you look around in the cockpit - especially down, how do you handle the head? Do you have a pilot model without a head, put the camera in the head or just have no pilot? From past experience with the previous version of my cockpit (which had a pilot) actually having a pilot mesh gets really problematic with things like bits of the pilots head being visible from the cameras POV, so I gave him the boot for the new one and just followed HL2's example. :D
-
Hmm good point. Well when I exported the Sim mesh with Simpe, what you see was what was included in the base mesh, (body free... head extra :lol: )
And since no one can see into the cockpit, the head isn't really needed. That way you can see your legs, but not the inside of your head :)
Trying to clean up the mesh now, it comes in around 1500 polys.
-
You'd need some kind of rotation restraints in any potential free-look system though, or else you'd look down and see the stump of your own neck - which I think would be a bit disconcerting. ;)
-
Hahah ya
something like this
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit3.jpg)
-
That's cool and ....disturbing at the same time o_o
-
Sorta reminds me of that terrible dinosaur hunting game, except it's a guy this time and he's naked! :lol:
The camera's position isn't quite right.
Course this all means I'll have to go back and gut my existing models and remove their cockpits. But then I do have to go back and redo their normal maps once I get a new video card.
However if I figgle it just right, I don' t have to worry much about making it look connected with the main hull as I do now. Add what looks like a door frame panel around the edges.
-
Nono, you don't have to gut old models - the system this kind of cockpit is for would have each different cockpit as a separate pof. These would probably be attached to something like a hud config table or something that would specify the hud layout (or it would render the hud to the texture - whatever happens).
In the individual ships tables, you would have a line that specified the cockpit pof that particular ship uses, NO 'show ship' flag (as this would override the internal cockpit), and you would line the eyepoint up in the pof as normal. If the end user then turned cockpit view on, while in the inside view (ie, not chase view), the game would place the specified cockpit model so that it's eyepoint lined up with the eyepoint specified in the ship pof.
Then the components of the hud would be moved around to where they look like they're being displayed on the cockpit models console screens (or again it would render the hud to the texture - whatever happens).
-
ok................... :confused:
-
I love this idea, it's definitely something the SWC could use.
-
naked people? or just the improved cockpits in general...... wait; i already know the answer. still, that would be cool, being able to pan around the cockpit.... provided theres a button that returns you to perfect forward instantly...... cant tell you how many times i got screwed up in games like CFS3 cuz of that
-
Heh, I hate CFS3 for lack of that support too, I missed my CFS2 functionality. 'W' ftw.
-
You know, if a cockpit is going to be implemented, it probably should be different for every fighter and bomber.
Umm ya... I've got umm 36 fighters already done that would need cockpits...
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit4.jpg)
-
Oooh, I like the screens, buttons and switches on the front section there - nice. :) (Needs a darker floor though I think - it stands out too much there)
Also, that reminds me - since we don't yet know how they'll be implemented, it'd probably be a good idea to have a lot of texture space available to the console screens for now. It's still possible the HUD will end up being rendered to the texture itself, or to a separate overlay polygon or something, and if that's the case it'll need a lot of res in order to be able to read the text.
-
I would be guessing that each hud entry (radar, shields...etc) would have their own seperate textures, or a combined texture (either one is good) The cockpit resolution shouldn't matter as thats a seperate texture from the hud. In fact if we could just get the hud as it is right now into a texture, then we'll be good to go with placeable hud. Also that way any customized hud styles (b5/SW/WC...etc) will remain intact
i.e. game loads hud styles. game renders stats to the hud texture. the game then displays the hud texture to the appropriate areas (probably a special texture named "hud").
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit5.jpg)
-
lol, your pilots have leather seats!
Mine just slum it with the cheapest cloth on the market. ;)
Actually - here's the texture I used to make the seat if you want to try it out:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Textures/Cloth.jpg)
(just greyscale it and size it appropriately and I think it looks really good)
And it's looking nice. Leather seats aside it has that gritty-real feel I'm a big fan of in sci-fi stuff. :)
Can you show us a 1042 res pilots eye view?
-
I'm not sure what apeture to use on the camera... but
20mm
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit-20mm.jpg)
24mm
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit-24mm.jpg)
at 35mm the caution light is at the bottom and at 50 mm the instrutment panel is completely beneath you.
-
A good cockpit-view system needs both pan & zoom (fov) settings to be workable with real instuments.
Check out Lock On.
-
awesome pictures, but i dont understand a thing you're saying. still, it DOES look good.
-
What happens if you slant those flat, horizontal polys in front of the console screens down away from the viewpoint? They seem to be using up a reasonable amount of viewing area without doing anything, so it'd probably be best to shrink them a bit. (see piccy)
What you basically want to do is manipulate the thing so that the view neatly fits in all the console screens along the bottom - giving you a maximum view area of the consoles themselves and space in front of you. It's handy that you don't have a HUD panel with the reticle on it that needs to line up with the actual reticle in game. ;)
What I'm describing is basically something getting towards this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/SDCockpit.jpg)
I removed the flat and trimmed it to the right size in terms of fitting the consoles in, but I think chopping the flat polys off alltogether makes it look a bit too 2D. Maybe something in between?
-
Anyone know what field of view for freespace is in degrees? I know the default is .75, but .75 of what? Max's cameras use either millimeter lens or FOV degrees.
Ok let's see if my math is right..... the FOV for fs2 is in radians. .75 rad ~= 45degress. I setup a target spot light and a target camera at the exact same spots. Set the light to have a cone of 45deg. Now is that .75 diagnal, vertical or horiztonal? Because each one will cause the camera to have a different cone.
-
I don't intend to steal any thunder here, :nervous: but ive been working on this on and off for a while:
(http://i118.photobucket.com/albums/o93/Einstine909/Hardlight/Cockpit.jpg)
This is the actual cockpit from the Fs1 intro, i used those renders that are floating around here for reference.
I was wondering if this was anything to keep going on...
-
Ohhhh I like.....
/me goes off and steals some of Einstine ideas :lol:
LOL the / me command actually works here
BTW the hardest part besides coming up with the ideas is the cockpit displays. Since I have little real good artistic ability to create a texture from scratch I have to cut and paste from existing textures. Some of my panels ended up having to be redesigned to fit the actual texture.
-
/me thanks Scooby_Doo
so it does... Well they aren't my ideas, because im just remodeling them.
Im waiting for the Fs2 engine to be able to edit textures or play animations for this cockpit to work, so this could be a while... this was talked about in another thread, tho i cant remember what one...
-
I thought there might be more cockpits quietly in the works. :D
It looks very nice - great work. :)
Since I've already modeled and textured that exact cockpit though, how would you feel about maybe widening yours and making some other changes and we end up using yours as the 'standard' FS bomber cockpit? That way it'd have an overall shape consistancy with mine, but it would clearly be a different cockpit. The more cockpit variations we have, the better. :D
-
*snip*
First reaction:
HOLY $%#$, THAT'S DETAILED! :eek2:
Second reaction:
That looks like a very, very comfortable seat. :)
-
*snip*
First reaction:
HOLY $%#$, THAT'S DETAILED! :eek2:
Second reaction:
That looks like a very, very comfortable seat. :)
hehe.... that was from a bit ago, here is a new one:
(http://i118.photobucket.com/albums/o93/Einstine909/Hardlight/Cockpit2.jpg)
@VA: I agree with you, but i also want to finish this one up, so i will start the variants after this one, so that i have a base model to work of of.
-
Now I wish that we could allready use these with the full functionality and to give it the last bit of "realsim" make the pilot/cockpit move/shacke according to the way you are flighing...or even make it shacke hard as you when you are hit by a missile or shockwave.
-
whats with the ambient occ?
-
(http://i118.photobucket.com/albums/o93/Einstine909/Hardlight/Cockpit3.jpg)
Here is a better render with a joystick, need some advice on that throttle, I just cant get it to look good...
@Topgun: a). if you're wondering why I used ambient occlusion, it's easy, it looks good and simple to setup. b).if you're wondering why it looks so bad: its because I was too lazy to change the quality setting.
-
ambient occ? is that advanced light rendering in max?
-
Nah, im using blender, so... it could be :rolleyes: but i wouldn't know
-
I mean does it give you that shadow effect around corners?
-
Yes, it does. :nod: All without a single light :p
Now, should i model the entire cockpit or only the viewable parts (assuming you were the pilot)?
-
What I did was delete polys that no one would ever see, in game or rendered.
-
Model the whole thing, save it, then remove the obsolete polygons. Afterwards, release them both. :nod:
-
well, im taking a break from the modeling, but still pushing forward. The textured panel is the target info ( the bottom left stuff on the current hud ) the image is a 256 by 256, and can be bumped up if needed.
(http://i118.photobucket.com/albums/o93/Einstine909/Hardlight/Cockpit4.jpg)
Yes, back to crappy renders, i hate waiting :ick:
-
Hmm, it might be a better idea to get it in-game before going further, so you have an idea of how much viewing area you are dealing with since I don't think you'd be able to read any of that text in game. My version had pretty much the same screen area as yours does there, and I found it incredibly cramped once all the stuff had been put on it.
I posted this earlier, but it's even more applicable in this case:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/Template2_Brightened.jpg)
-
Good point,
I think i can get everything needed on to the center, center right, center left, and HUD screens, and make it readable. The camera would be closer to the HUD, and therefore make the cockpit take up less viewing space. But it is also based on preferences. I wouldn't mind having the cockpit take up all of the bottom half as long as it: a). gave enough information to be useful and b). was visually appealing and realistic. I am more of a fly-by-instruments kind of person, rather than a nose cam pilot. The cockpit puts you into the craft IMO, the more of it I see, the more I fell immersed in that ship. But anyway, I will do both, for popular demand :P
I'll have the rest of the essential screens done soonish, so a render of how I envision it to look will be up in a hour or so.
edit:
I'm thinking this:
(http://i118.photobucket.com/albums/o93/Einstine909/Hardlight/Cockpit5.jpg)
only the middle of the HUD will be the middle of the screen (monitor)
-
Finally found a somewhat usable body texture... it's Boba Fett from here: http://www.modthesims2.com/showthread.php?t=132559 (http://www.modthesims2.com/showthread.php?t=132559) I pulled the texture out of the package and luckily it worked directly onto the body mesh.
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit8.jpg)
-
Bring out your dead... bring out your dead..... :lol:
Took me a while to find this darn thread, it's over a year old... :eek2:
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit9.jpg)
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit10.jpg)
-
Headless
-
Well out of curiosity, what's the status on the cockpits? They looked pretty sweet
-
Why is the position of throttle and stick mirrored from normal layout?
Most people would likely prefer a layout where the stick is on right hand and throttle on left hand... I could understand that likely these components would be made interchangeable for leftie pilots, but I don't know if that should be reflected in the cockpit model detail... :p
-
*is left-handed* :nervous:
I don't think it really matters that much. Of course, if it could easily be mirrored to suit the majority's needs, then I suppose it should.
-
that looks sweet!
somebody should work on working instruments...this is essential for Diaspora and FotG!
Somebody start a X-Wing Cockpit :D
-
Wow, I just noticed this thread...
Why hasn't any of it been done yet? (I know Scooby has cockpits on his ships already)
-
*is left-handed* :nervous:
I don't think it really matters that much. Of course, if it could easily be mirrored to suit the majority's needs, then I suppose it should.
/me rasies left hand too :nervous: Although I'd probably fly it with my right hand.
Wow, I just noticed this thread...
Why hasn't any of it been done yet? (I know Scooby has cockpits on his ships already)
We're still waiting for cockpits to be finalized, currently no hud support is there (hud on display panels).
Also my cockpits on the existing ships are low-res and fugly compared to this.
The current model sit around 3,500 polys (over 1,000 for the pilot, without optimizations).
-
True, but they're there and don't need manual eyepoint editing.
-
/me rasies left hand too :nervous: Although I'd probably fly it with my right hand.
I used to use only my right hand for movement, until I started using the mouse for my right hand. I didn't want to sacrifice accuracy, but I also don't want to continuously roll my mouse back. So instead, I inverted the mouse buttons and moved it to the left side of my PC. From then on, I used my right hand to make wide movements while my left is used for making precise movements. I changed the layout so that managing everything became so much more convenient. It also made me realize that FreeSpace's default configuration is a bit inefficient when I can equalize shields, control speed, change primaries/secondaries, and launch countermeasures with just the keypad.
Quick Mock-up:
http://img23.imageshack.us/my.php?image=qwertyru7.png
-
Does anyone know how to flip a Max Biped around? I.e. have the left hand posed what the right hand is, and visa versa?
-
We're still waiting for cockpits to be finalized, currently no hud support is there (hud on display panels).
Also my cockpits on the existing ships are low-res and fugly compared to this.
The current model sit around 3,500 polys (over 1,000 for the pilot, without optimizations).
Your work on this issue is amazing scooby, - have you ever considered just realising the pit without HUD support? having the HUD float on top of a 3-D cockpit has never bothered me in Xwing Alliance...some of the XWAUP's new cockpits are incredibly imposing, and make the HUD very hard to read, but I love em just the same for the sense of scale and character they lend. I actually like having large portions of my view obscured, just feels 'right' and very cozy or something....
Just having a nicely detailed 3d structure in the game would look lovely with the smooth view slewing and padlocking in current builds. HUD support or no.
-
Actually what I would really like to see is have a helmet hud and a panel hud. Helmet hud would very similar to what is currently in use, but also have the ability to look down at the controls.
-
Looks neat. I wonder if you could use vertex shaders to make the arms move as he pushes on the joystick or whatnot ... wouldn't be quite right for other buttons tho.
-
Actually what I would really like to see is have a helmet hud and a panel hud. Helmet hud would very similar to what is currently in use, but also have the ability to look down at the controls.
I knoe that there will no doubt be helmet HUD tech in the next decade, but I've never seen any canon evidence of the GTVA using helmet mounted HUD displays, unless the visor that most pilots have up is a HUD display.
-
vertex shaders to make the arms move
ehhhhh.......
-
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit11.jpg)
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit12.jpg)
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit13.jpg)
(http://img.photobucket.com/albums/v356/Shodan_AI/cockpit14.jpg)
-
O
M
G!
ILY ILY ILY!
Please tell me that isn't photoshopped
-
Only thing pseudo-photoshopped is the hud displays, and even that is part of the rendering.
I'm trying to make several different canopy frame styles, so I can easily match it to whatever my current fighter I'm working on is. Just need to work on the backboard for those fighters with full 180 views.
-
Only thing pseudo-photoshopped is the hud displays, and even that is part of the rendering.
I'm trying to make several different canopy frame styles, so I can easily match it to whatever my current fighter I'm working on is. Just need to work on the backboard for those fighters with full 180 views.
I see, if I may say so, the second-to-last looks like a good one for the Valk. Second from the top would be a good one for the Herc.
-
I assume we're going to have the hud rendered to a texture correct? Could we set some specifics for what goes where on that texture?
I'm assuming we need a spot for:
- radar
- self-shield/hull
- target
- target shield/hull
- available and selected primaries
- ammo list for primaries (use "---" or infinite for non-balastic weapons)
- available and selected secondardies( with count and wait time)
- time and time compression
- targetting alert
- lock on alert
- eject alert
- Escort list (Probably not renderable in hud)
- Objectives(Probably not renderable in hud)
What else am I missing?
-
Rearm time?
-
That would be wait time.
Basically I would like to at least get started remodelling my stuff one last time.
-
That would be wait time.
Basically I would like to at least get started remodelling my stuff one last time.
Please do, a cockpit would be awesome. I only FRED though so I'm next to useless on this one.
-
it might be intresting to know that ive managed to get the nukemod cockpit demo to work on newer builds. im still getting some crashes and for some reason i cant render stuff like bitmaps to the textures (while camera views seem to be working fine). the radar works, but its not as pretty as it could be.
-
How does yours handle hud textures?
-
Perhaps a minor thing, but I'd switch the joystick and throttle (look at the F-16/F-22/F-35 cockpits) And make it fully digital with 3/4 large screens, and have the HUD a part of the helmet. Looks good so far! :yes:
-
How does yours handle hud textures?
right now, procedural generation. but thats kinda slow. all my atem[ts to render textures to the texture dont seem to work.
-
BTW how is the hud being rendered now?
-
either off all together or as it normally appears, nothing fancy like mapping target lead indicator and forward reticle onto an arbitrary polygon floating in space and having all indicators line up as they normally would. i would like to come up with some code for that. i have more than one project that would benefit from it. so i might do that.
also found a workaround for the bitmap issues, just create a polygon with the texture, give it a position and an orientation. it would suck, but it would work. i think i got my camera system working now. still need a way to pass any additional view commands to it (trackir / keyboard). turrets work but not well. they seem to get stuck (probibly used a < when i should have put a <=) sometimes. gun and camera work, suposidly but the orientation of the camera seems abit off.
probibly gonna do more radar modes, might work on a general info panel as well. see if i can get the basics like energy fuel, weapons, ets ect onto one screen. i find the optimal resolution to be 256 in hires mode and 128 in lowres. but i might just do everything at half that, then subdivide the geometry that panels is mapped to. the other idea was to create a single 512*256 map and writing out gauge functions that define procedural effects that take up a certain amount of texture space. for example my radar function defines a panel by (x1,y1,x2,y2...), the idea is the modder just specifies they type of radar and other parameters like range or field of view or scale, where its at on the main map. then you just map everything to one big texture then specify those parameters in a cfg file, the code then call s the appropriate functions.
this would require pre-rendering of the cameras to textures, and then just using drawPolygon to map it to the main texture. il have to see which way works faster. i might just update the camera textures on odd frames and redraw the panel texture on even frames, in a way only one rtt texture gets updated each frame, you can have multiple rtt textures, as the number increases the slower they refresh (because of the more time slices that are required). i might do something like update the main texture more frequently than other rtt operations. that way pure procedural operations can get faster updates. i think this will make it much more scalable.
-
probibly gonna do more radar modes, might work on a general info panel as well. see if i can get the basics like energy fuel, weapons, ets ect onto one screen. i find the optimal resolution to be 256 in hires mode and 128 in lowres. but i might just do everything at half that, then subdivide the geometry that panels is mapped to. the other idea was to create a single 512*256 map and writing out gauge functions that define procedural effects that take up a certain amount of texture space. for example my radar function defines a panel by (x1,y1,x2,y2...), the idea is the modder just specifies they type of radar and other parameters like range or field of view or scale, where its at on the main map. then you just map everything to one big texture then specify those parameters in a cfg file, the code then call s the appropriate functions.
This is kinda what I'm aiming at.
Ok given a 2048*2048 texture (or 1024*1024 or....) [remember in uv space pixel cords don't matter, percentages do] Approximately how much space should one reserve for the following?
- radar
- target
- self-shield/hull
- target shield/hull
- available and selected primaries including ammo count
- available and selected secondaries( with count and wait time)
- time and time compression
- eject
- autopilot
- targetting alert
- lock on alert
My guesses would be:
radar - 50x50%
target - 10%x10%
self shield - 10%x10%
target shield - 10%x10%
primaries - 5%x5%
secondaries - 5% x 5%
time - 5% x 5%
everything else - 2% x 2%
Mind you, not everything needs to be a perfect square, primaries, secondaries & time are usually words and can be more rectangular. Also it's sorta like putting together a puzzle, but you have no idea how to fit the pieces right without knowing the final size, and being unable to determine the final size until we know how to put the pieces together. :P
-
How about this?
(http://img.photobucket.com/albums/v356/Shodan_AI/HUDcopy.jpg)
edit: opps forgot about the forum's black background.
-
thats about the right amount of space.
im starting to think it might be better to do the rtt in engine. i know at least one coder wanted to do a system to optionally rtt gauges to specific named textures, which can then be mapped to various textures in the cockpit model. im not sure what the status is on that.
my lua based system seems to be slowing the game down a lot. im also doing a very simple radar, not the orb style radar which is probibly a lot more cpu intensive. of course radar is the worst case scenario. everything else is just something involving drawing text or bitmaps.
i had once attempted to draw 3d shield icons, but i could never seem to get the texture replacement to work correctly, and texture usage was a lot. it looks like some new texture replacement code got into scripting to make it possible. if not i could probibly just use bitmaps and overlay them over the model. there still seems to be a bug when calling some draw functions, resulting in nothing happpening when trying to draw to a texture.
its also becoming apparent that anyone using a cheap video chipset wont benifit from rtt, so int might be neccisary to create a placeholder system. probibly involving a 2d overlay of some sort. engine level support for that may need to be added. im not much too familiar with the hud table and what can be done with it. i might take a look and see what can be done right now. i may be able to code in some useful features.
-
I figure if an in-engine cockpit RTT system is going to come about, it'd be best to approach it as an entire system rather than in bits and pieces, like this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cockpit/CockpitMechanism.jpg)
Just a rough outline, but it would allow for a lot of modder flexability and ease of use, which would be crucial in getting people to go to the effort of using it.
-
What exactly is "RTT?" real time texturing?
Also if possible have it render allowable both to a texture and to the general hud. For example target stats. There would be a large panel version and a smaller on helmet version.
-
Render To Texture. Basically exactly the tech needed to render HUD stuff onto the mapping area image you posted before. ;)
And yeah, if the system I'm envisioning here were implemented you'd be able to do just that. In fact it would do just that by default, unless that 'No_Normal_Render' flag thingie were present.
-
i think a gauge should be able to set in any combination of rtt/overlay(see below) mode or hud mode. i can think of situations where id want to map a gauge to the panel but not the huds or vice versa. also some stuff i may want to render in both places.
think of overlay as being rendered to the hud but positioned and scaled automatically to a couple points in 3d space projected onto the screen (as you would by calling drawRectangle() in lua). sorta what would happen if you called getScreenCoords() in scripting. and then use the projected 2d coords as a place to draw the gauge between. by specifying 2 sets of 3d coords it should be possible to project it so that it lays approximately over the place on the panel where the gauge would be rendered to if rtt was possible, regaurgless of user view settings (trackir keyboard, ect). if both of the coords are not on screen the gauge is simply not rendered. aardwolf did something like it in lua for the fsrts.
i cant see animation replacment as working well. since only a handfull of gauges could be rendered correctly that way. the overlay meathod would work well because you really wouldnt have to do anything but recompute x1y1x2y2 each frame, and then render it to the hud as usual. this is sort of the way the reticle works when using head tracking.
-
I don't think you're quite interpreting the flowchart correctly. The system would allow any combination of HUD and/or model renderings of each guage.
TBH overlay sounds like it's just regular RTT, but with added bugs when things like camera shake and view rotations come into play (you'd need the 2d panel locations to basically exactly mimic the translations and rotations of the model), less efficient because you're basically recreating polys that are present in the cockpit model already but you're doing it on the fly and still basically using RTT anyway, and MUCH more tedious and confusing to set up for the modder in having to define all the points in space to create the planes. Maybe I'm interpreting that system incorrectly now, but it doesn't strike me as being a better solution to cockpits than RTTing straight onto a texture.
The animation replacement part of the system would work well because it's incredibly simple. The idea would be that it simply changes which ANI it's loading for that HUD guage.
Eg, say your cockpit model had a curve shape panel for the ETS that you simply couldn't nicely fit the standard square ETS guage into. With the animation replacement, you'd create your own curved ETS ANI that had the same functionality as the standard one (ie, same frames). However this curved guage would then ONLY fit the particular cockpit you'd created - you don't want it to just permanently override the square one for all cockpits. The animation replacement part of the system would substitute the guage ANI only for that particular cockpit.
So say the Star Wars mod had an Xwing cockpit model and a TIE cockpit model. For each ship you'd want to have very different styles of HUD guage to both fit with the theme of the rebellion or empire, as well as to fit on the actual screens you have on each of the cockpit models. For that you'd just have a set of rebel guages and a set of imperial guages that would be swapped in and out at will for whatever cockpit model you were dealing with.
In fact you could build an ugly cockpit for say a DIE wing ugly, with rebel style guages for the systems that would have come from a Y wing, and imperial style guages from the systems that would remain from the TIE. :)
-
well my overlay idea was for people whose chipsets do not have the capabilities for rtt. for the situation where you want to render a guage to a texture for use as part of your panel, but for some reason the system cant. for my computer your system works perfectly, but for somone with a crappy intel chipset, what do you do in place of the rtt?
the concept of overlay is that the gauge is rendered to the hud as if it were a normal gauge. however its xy coords can change depending on the view angle and position. take some vector in model space, subtract the camera vector (in model space), (un?)rotate it by the camera matrix, then project it to the screen. this gives you an xy location to place the gauge, which is used instead of the the values given in $<Gauge name>: x,y in the table.
-
Oh I see, but assuming people with such crappy chipsets incapable of RTT are in a shrinking minority - and of those only a fraction would actually use cockpits anyway, I'd suggest a check for whether that is the case or not, and if so just reverting to regular HUD drawing only.
TBH I think it would be sacrificing good modder usability (I know I would hate having to meddle with overlay 3d co-ords like that, and I doubt I'm alone there) so that a couple of people who really need to upgrade can have the option of using cockpits. ;)
-
BTW, neither of these implementations would have any effect on the modeler? The map would be same?
-
Option 1: Implement VA's idea and tell Nuke to either upgrade that stupid comp or shut up.
Option 2: Implement 2 simultaneous methods so that Nuke's poor theoretical computer can attempt and fail at rendering cockpits just to satisfy his inner geek and make it even less likely that this feature will get implemented in a timely manner.
-
BTW, neither of these implementations would have any effect on the modeler? The map would be same?
Neither method has any effect on the model, and the overlays method would not affect the texture either. As I understand it, the overlays system would work in much the same way as the RTT section of my system, but instead of rendering the guages onto a texture you'd render them onto a 3d polygon that you would have to define with vertex co-ords presumably in the cockpits table.
I think it would be a lot easier on the modders and the coder just to render the given guage at a specified location on a specified texture.
-
i also kind of question whether it would look good or not. things like camera roll would skew or distort the overlay in odd ways or in a manor which wouldnt line up properly. there is the modability, considering you have to define high and low res graphics, rtt and hud versions of each. in my opinion the hud_gauges table is one of the harder to understand tables. i could see it getting complex really fast.
what i was thinking was to have the vector optionally contain 2 or 3 components, if the parser sees 3 coords, then it knows its dealing with a point in model space and runs the transform math (which is probilby one line of code internally) each frame to determine where to put it, or if it sees 2 coords it knows its dealing with absolute screen position. not sure if the parser would like that, my assumption would be no, but it might be more versitile than i think it is. the feature would have other uses, such as if you want to use a different reticle configuration.
regaurdless of wherer that particular feature gets implemented. theres strill the matter of model integration. my demo used 3 panel textures to which gauges would be rendered. of course this gets tedis. the speed of rtt diminishes and texture usage increases as you add more textures. it might be better to define just one big texture for all guages that will be rendered to, and then the modder can either use uv mapping, coords, or a combination of both to line stuff up. anything rtted can get spewed out in the cache folder and moders can use that as a base template for uv mapping within their models.
my system also used a seprate set of geometry for panels which i had applied invisible to, they were raised a tiny amount above the normally textured panel. if you rendered a texture you could replace the invisible texture with the rtt texture. this allows you to use the cockpit model even if rtt didnt work, and you just see the fixed textures through the invisible polies (this is where overlay would be useful). then again you coulde have a static gauge map and replace that with the rtt image if it works.
none the less i look forward to any implementation of this system.
-
i may get a little off the actual thread's topic but , something could be improve with cockpit i think,
In race sim (rfactor, gtr gtl etc...) the cockpit view is really not static, i think that would give a bit more life to the cockpit view to have some light camera move/rotation when moving, like the head would do when you turn really strongly... also have a view shake when engaging afterburner would be damned cool.
have the view going a bit backward when accelerating and coming forward when slowing down
I don't know how hard it would be to implement that, but it'll give good feedback on the ship movement!
-
i may get a little off the actual thread's topic but , something could be improve with cockpit i think,
In race sim (rfactor, gtr gtl etc...) the cockpit view is really not static, i think that would give a bit more life to the cockpit view to have some light camera move/rotation when moving, like the head would do when you turn really strongly... also have a view shake when engaging afterburner would be damned cool.
have the view going a bit backward when accelerating and coming forward when slowing down
I don't know how hard it would be to implement that, but it'll give good feedback on the ship movement!
Yeah, just a bit of 'lag' between where the cockpit model goes and the centre of the view follows would add a lot of realism and make you feel like a human rather than a camera strapped into a fighter. :)
i also kind of question whether it would look good or not. things like camera roll would skew or distort the overlay in odd ways or in a manor which wouldnt line up properly. there is the modability, considering you have to define high and low res graphics, rtt and hud versions of each. in my opinion the hud_gauges table is one of the harder to understand tables. i could see it getting complex really fast.
Oh crap - I'd forgotten all about hud_gauges.tbl, and now that I look at it, it would be a bit tricky to implement cockpit model stuff around that (like, how would the ship specific gauge overides in hud_gauges.tbl work with ship specific cockpit models?)....and I'm not sure how much of it's actually working currently. AFAIK it was never finished. :\
regaurdless of wherer that particular feature gets implemented. theres strill the matter of model integration. my demo used 3 panel textures to which gauges would be rendered. of course this gets tedis. the speed of rtt diminishes and texture usage increases as you add more textures. it might be better to define just one big texture for all guages that will be rendered to, and then the modder can either use uv mapping, coords, or a combination of both to line stuff up. anything rtted can get spewed out in the cache folder and moders can use that as a base template for uv mapping within their models.
That's what me and Scooby have been talking about, so yeah I'd definitely agree that they *should* be done on one large UV map, but I'd prefer a system that didn't force that. :)
The workflow I was envisaging to mod this stuff would be to UV all the panels neatly onto a map, export a UV layout, and then use that to figure out where you want to put HUD gauges by pasting on actual size gauge templates and finding and recording the pixel co-ords of the top left corner of each gauge once you're happy with the overall layout. Plug those values into the RTT offset field (noted in the flowchart) and it will draw that HUD element onto the texture.
my system also used a seprate set of geometry for panels which i had applied invisible to, they were raised a tiny amount above the normally textured panel. if you rendered a texture you could replace the invisible texture with the rtt texture. this allows you to use the cockpit model even if rtt didnt work, and you just see the fixed textures through the invisible polies (this is where overlay would be useful). then again you coulde have a static gauge map and replace that with the rtt image if it works.
You can just draw new stuff over an existing texture in memory can't you? That's been my understanding of how it works anyway. If not then yeah a double layered thing would be the best way to go. :)
none the less i look forward to any implementation of this system.
As long as it's accessible and so actually gets used by the more casual modders, definitely. :D
-
Exactly what i thought! :yes:
About rendering hud , i think to help modders, a gui program with pre-filled field would be perfect! :yes:
Make me remember placing direcitonal thruster throught ship.tbl is quite a pain, beeing able to do it in pcs2 or another gui program that let place with gozmo those thrusters and copying coordinate to clipboard, paste it in the table would help to save time!
-
im gonna put up a newer version of my scripted system here in abit, it might help give you ideas. my current version is slow and buggy (and crashes due to mantis #0001899, so dont fire bank 3 gatlings). but its got some cool features like selectable camera screens and a working rtt radar (sorta).
anyway here it is
www.game-warden.com/nukemod-cos/downloads/cockpitdemo2.7z
runs on rc1 fine, just dont fire primary bank 3
and expect it to crash a lot
there are some features from my first cockpit demo that got disabled, like the drones. and some new features like selectable ship cameras. the radar works and to some degree the remote turrets (now includes a gatling turret version of the pf satyr). i wanted to do some ammo gauges but my current blood-alcohol levels would make that kinda difficult. il be falling off the internet at the end of the months and dont know how long i will be off line, so im putting this up now. hopefully it will be useful.
the cover my ass mission was a test of the feasability of flying a mission as a gunner, and probibly doesnt work because ive disabled the main view cameras (they jump around too much and mess stuff up, somone implement a feature to change between different eyepoints). the other test mission works fine. its freeded so that 1 and 2 keys change camera views. you can add stuff between the set target calls that will show up on the textures.
-
Exactly what i thought! :yes:
About rendering hud , i think to help modders, a gui program with pre-filled field would be perfect! :yes:
Make me remember placing direcitonal thruster throught ship.tbl is quite a pain, beeing able to do it in pcs2 or another gui program that let place with gozmo those thrusters and copying coordinate to clipboard, paste it in the table would help to save time!
That's what I'm trying to aim for. I don't really care how it's done, it's the final result is what I'm concerned with. And you don't really need a gui program, just the texture template itself.
-
my idea of how the process wil bee is as follows
create a table to define what gauges go where on the rtt texture.
dry run the game, have a launcher flag optionall;y spew out the texture the way that is done with cubemaps
use that texture when uv mapping the panels in your model, so you can see exactly where the gauges are going to end up.
create aplaceholkder texture for your gauges, should rtt not work, alternatively you can jsut use the map spewed out by the engine
convert your model as usual.
done
-
Couple things just dawned on me:
1.) Minor, if the pilot doesn't have a head, make sure the copilot does :lol:
2.) How are glowpoints and turrets handled? Since the model being displayed isn't the actual ship hull, rather the cockpit hull.
-
you know you could make the pilot/copilot head a sub model, and animate it to make it look at the target if its within his view. ive been messing around with the idea of multiple seat positions which the player can change around, so if you want to operate the turret you could let the ai fly the ship. youd just have to make sure that the other guys have a head.
as for weapon models ive demanded from the start that they absolutely must be visible from the cockpit. the coders said all such things were to be applied to the cockpit model, but ive not seen or tried it. watching gatling guns spin gives me a woody, also makes monitoring external weapons much easyer with your track ir. i also would want to make it possible to run animation scripts on objects in the cockpit, so i can have my working flight controls i have in my cockpit demo.
of course as i continue to learn the code structure of the fs engine, my ability to implement some of that myself is always increasing.
-
So basically you'd have a turret01, turret01-arm, turret01-destroyed attached to the main models detail0 and a turret01, ..... attached to the cockpit's mesh, in theory?
-
So basically you'd have a turret01, turret01-arm, turret01-destroyed attached to the main models detail0 and a turret01, ..... attached to the cockpit's mesh, in theory?
thats what i was told, i believe by taylor or goob or one of the main coders. however at the time i thouht i could do more using the old skool aproach using show ship, which became the cockpit demo. one of my long term projects is making freespace have the same kind of cockpit features youd find in your typical flight sim.
while most of the features ive used scripted submodel animation to create, like the controls in the cockpits and the manually operated turrets, i wonder if it might just be easyer to call one of the render model funcs and overlay them with the existing cockpit model system. still the weapon models dont seem to have and scripting interface at all.
weapon models is something i wanted to revisit anyway. was wondering if i could modify that system for use on turrets and gun points with custom normals or weapons with auto aim. ive had an idea for some time about a sidefire bomber much like the ac130 which would orbit a target and fire a barrage from an array of gimballed guns and bomb racks on the flank of a large freighter-sized gunship, aimed by fancy sight system involving an rtt panel with a mouse based aiming system. you would just click where you want the shots to go, this would define a point projected into 3d space where your weapons will converge. give you som level of fire control without completely distracting you from flying.
-
I'm a bit uncertain how this works - would making individual separate cockpit meshes mean you are essentially flying a cockpit, and can't see the ship model? Or would it mean the ship has a gaping hole where the cockpit would be, and it simply picks the right one and puts it in?
-
Essentially your flying the cockpit around (in first person view). The real model pof should be complete, a simple cockpit (if wanted or just black glass). A separate pof is your cockpit. I would place a copy of your ship around the cockpit mesh, then delete polys you can never see.
Something like this:
(http://img.photobucket.com/albums/v356/Shodan_AI/newdralkthi4.jpg)
-
Fair enough, that makes sense.
-
That's what i do actually (delete unseeable poly)
But doesn't the model have to be closed anyway?
I mean if you let some poly open in your model doesn't it make problem for the fs2 engine?
because i spared many hours to simplify/reclose models after deleting unnecessary polys.. and if it was not a necessary step... that would be pretty cool in fact :)
-
I've never had a problem with open meshes. :confused:
-
Yeah you can leave them open, they don't have to be airtight. Whatever cuts out the most polies or makes UV easier is probably preferred.
-
Might be a bit difficult to fly a ship that's not airtight. :P
-
meshes havent had to be solid for quite some time. and then it was mainly a requirement of the bsp compilers we had in the early days of modding. you can reduce a great deal of polies by leaving stuff open. the original fs models, all the turrets seemed to not have any underside polies. what i want to know is if anyone has attempted to copy an animation or weapon model from she ship that would work the same in the cockpit model.
-
OK, so after hanging out in #hard-light, I got back into the mood of finishing up the cockpit I was modeling. The problem I left off as was the balance of realism (cannon) and the visibility. If I go with the cockpit that the FS1 into vid shows, the view is very restricted to the top of the screen (1/3 left) this would make playing very difficult. So, what does HLP think of this? Cannon or visibility? It would also help to know what FS2's default FOV is... off to the wiki for that...
edit:
After some more chatting, we came to the conclusion that the "real" HUD was restrictive to where the camera was placed. By getting rid of that it made the visibility much better while still achieving the same effect.
(http://i118.photobucket.com/albums/o93/Einstine909/Hardlight/cockpit6.jpg)
Yay or nay?
-
That's a lot like VA's 14'th post on the first page, but with a lot less features.
-
Personally I would prefer something like VA's concept. Just a small heads up display with the aiming reticle at least, other than that, any cockpit is better than none :D But yeah, it looks good.
-
Looks pretty good. The default fov is .75 radians, which is already a bit high. Most people use a narrower fov to increase the sense of scale, although I use a higher fov in multi than in single player.
-
*snip*
Yay or nay?
If it ever comes to pass that cockpits are usable, that is pretty much exactly what i wanted, though a hud with the targeting reticule on it would be desirable, though just having it sit in the middle of the screen as normal would be fine. Either way, keep up the good work!
-
Well with moveable views...
(http://img.photobucket.com/albums/v356/Shodan_AI/NewDralth4.jpg)
(http://img.photobucket.com/albums/v356/Shodan_AI/NewDralthi3.jpg)
-
Dawwwwwwwg :D
-
Looks pretty good. The default fov is .75 radians, which is already a bit high. Most people use a narrower fov to increase the sense of scale, although I use a higher fov in multi than in single player.
Btw, would it be possible (from a coding point of view) to render the cockpit model with a fixed (hard-coded) fov ? Since a lot of people use custom fov settings, the final appearance of a cockpit model would vary quite a lot, possibly making it more obstrusive than originally intended or otherwise look weird.
Also, lining up a cockpit model with HUD gauges only makes sense, if the model looks exactly the same for all fov settings.
-
Btw, would it be possible (from a coding point of view) to render the cockpit model with a fixed (hard-coded) fov ? Since a lot of people use custom fov settings, the final appearance of a cockpit model would vary quite a lot, possibly making it more obstrusive than originally intended or otherwise look weird.
Also, lining up a cockpit model with HUD gauges only makes sense, if the model looks exactly the same for all fov settings.
Why don't you just make it a 2D cockpit then? I'm sure you could do something similar to MSFS panels or X-Wing cockpits quite easily. :nervous:
It wouldn't work well for 3D cockpit. Especially if you pivot the view around the cockpit; it would look supremely weird if the cockpit and the background were rendered in different field of view.
I'm going to just repeat my suggestion and opinion that cockpits will only be truly usable when FS2_Open gets in-game adjustable field of view commands similar to IL-2 Sturmovik series of games.
-
I don't see why it couldn't already be an extension of the TrackIR stuff. We can already pan around, and we know we can set the FOV so it seems like all the pieces are there.
-
Btw, would it be possible (from a coding point of view) to render the cockpit model with a fixed (hard-coded) fov ? Since a lot of people use custom fov settings, the final appearance of a cockpit model would vary quite a lot, possibly making it more obstrusive than originally intended or otherwise look weird.
Also, lining up a cockpit model with HUD gauges only makes sense, if the model looks exactly the same for all fov settings.
Why don't you just make it a 2D cockpit then? I'm sure you could do something similar to MSFS panels or X-Wing cockpits quite easily. :nervous:
It wouldn't work well for 3D cockpit. Especially if you pivot the view around the cockpit; it would look supremely weird if the cockpit and the background were rendered in different field of view.
I'm going to just repeat my suggestion and opinion that cockpits will only be truly usable when FS2_Open gets in-game adjustable field of view commands similar to IL-2 Sturmovik series of games.
Because I want the lighting effects and cockpit movement when turning (à la Starlancer), and for that you need a 3d cockpit. I'm not sure if you would notice if the cockpit geometry had a different fov than the rest... since it is much closer to the eye point than the rest. (actually, that's a really interesting question)
I'm just thinking from a modelers point of view... if I go through the trouble to set up cockpit geometry so it lines up with the HUD nicely... and then notice that it looks crap with different fov settings, it sortof is a buzzkill.
-
Personally, I tend to think that fitting the HUD to the cockpit avionics to achieve a "gauged cockpit" look is somewhat hackish anyway. No offense, but HUD is not supposed to be like that. Also, it will fail hard as soon as one turns their head in the cockpit just as much as it will with different field of view settings.
I would rather just have the cockpit have good-looking static or slightly animated panels, with an option of putting in render-to-texture gauges/displays when that particular feature gets put into the engine, and leave the HUD what it most likely is; a helmet-mounted head-up display.
Also, yes you would notice the difference between fields of view. Particularly when you turn your head. There would be a difference in angular velocity of outside and inside rendering when the point of view is in turning motion. This would especially affect anyone willing to use TrackIR, but would also likely be noticeable with how the left/right/up/rear views work at the moment.
chief1983: That sounds interesting and promising...
-
I think that the HUD from the game is just a regular, fixed position HUD, as at the time the game was made, helmet mounted ones were a more of a WIP than anything outright usable if I'm not mistaken.
-
Well, the HUD is visible in the Apollo in the FS1 intro, and it's just like a current jet fighter fixed HUD.
But Herr Doktor raises some good points about what happens when you turn your head, so locking the fov for the cockpit doesn't make much sense.
-
freespace lacks alot of features that modern fighters have had for years. such as te ability to lock a missile onto every target in range and launch simultaneously, or look and lock capabilities. or visibility enhancements (such as filling in blind spots with video from cameras all over the aircraft) in fact freespace missile tech seems to predate the nam era in terms of effectiveness. i tink they were kinda going for a ww2 feel. as cool as a helmet mounted display would be, it would feel out of place in freespace without a bunch of other features.
i kinda like the way the hud works in trackir mode. ive written scripts before to do things like aim turrets, select targets, and lock missiles just by looking at it. i like the concept helmet mounted display, but it kinda goes against the ww2 style of the game. id rather have the hud rtted and mapped to some polies (or rendered to the hud to overlay over some fixed points in 3d space), for cannon ships. that doesnt mean the idea of an hmd should be abandoned, since it coud be an awesome feature for certain ships.
-
Long time since last post.... Anything happening on this front?
-
I'm building external cockpit in my fighter models, but I do know if they've fixed the Z-rendering issue.
-
Seen movies on YouTube featuring a simple 3d-cockpit and I don't care if it's perfect or not - I want to try it out.
The reason why I "revived" this thread ;7
-
Seen movies on YouTube featuring a simple 3d-cockpit and I don't care if it's perfect or not - I want to try it out.
The reason why I "revived" this thread ;7
well the cockpit demo is on svn for testing
http://www.hard-light.net/forums/index.php?topic=69358.msg1369566#msg1369566
of course you need an svn client (tortoise works). should be able to create a folder in your fsroot called cockpitdemo, and checkout the cockpit demo there.
-
I know next to nothing about coding and stuff - What is svn?
I followed your link and when I try to get the "stand-alone" cockpit-thingy I only get to a directory-structure (running Mozilla on Win7).
This might be real n00bish for you since you're probably used to the way it works but I'm definately not used to it.
All help is welcome.
-
Get TortoiseSVN (http://tortoisesvn.tigris.org/) and install it (32bit unless you know you have 64bit Win7). Create a new folder in your freespace directory, called 'cockpitdemo'. Right click on it, and you should have some new options from Tortoise. One should be 'Checkout' or something like that. A dialog will come up, and basically you want to check out the HEAD or latest revision, from http://nukedspace.fsmods.net/svn/trunk/cockpitdemo/
Then just select the cockpitdemo mod in the FSO launcher.
Very similar steps for getting the FSO source (http://www.hard-light.net/forums/index.php?topic=52845.0) can be adapted to this situation, so use those pics as a sort of reference.
-
Alright - Thanks for the answer.
Got that Tortoise Software and managed to download the mod.
I do get errors though - I downloaded 3.6.12 rc2 and tried to use that one with the new TrackIR.dll and the listed PostProc/Shaders stuff.
Still get a crash - I get through the main meny and the briefing - When I finally are about to get into space I get a black screen of death and need to ctrl+alt+del and start the task manager (ctrl+shift+esc doesn't work) to see an "Error!" window come up.
This is the contents of that window:
LUA ERROR: [string "onframe.lua"]:79: attempt to index field '?' (a nil value)
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0
Source: (null)
Short source:
Current line: 0
- Function line: 0
------------------------------------------------------------------
------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------
------------------------------------------------------------------
I get 3 choices here: Yes, No and Abort.
Hitting anything but Abort makes me get into a "loop" where I get the same error again. When I hit Abort I get what I believe is the same error again:
LUA ERROR: [string "onframe.lua"]:79: attempt to index field '?' (a nil value)
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0
Source: (null)
Short source:
Current line: 0
- Function line: 0
------------------------------------------------------------------
------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------
------------------------------------------------------------------
....
... hitting Abort a second time closes the "Error!" window and I'm returned to the Launcher (using the lates launcher as well 5.5e).
Looking at other threads I see more detailed error-reports - How do I provide/generate those so I can give you guys more information?
Thanks for the support guys - Hopefully we can iron these errors out.
BTW...
I didn't use any other mod afaik since I chose the Cockpitdemo mod as the "Primary" mod.
-
be sure youre using 3.6.12 rc2, and do not what so ever run it with any other mods (that includes mediavps!). also (this is very important) the mod directory name needs to be "cockpitdemo".
if it still is not working run a debug build and post your fs2_open.log.
-
How are you doing your cockpits nuke? Via external pof?
-
actually im using the old skool meathod of using the "show ship" flag. i dont think theres any way to animate submodels in the cockpit pof (though i may just be able to use gr.drawModel() to create animated interior elements), or change its textures. i want to use the newer system so that i can have interior glass, add detail, and maybe speed up rendering (less detailed external view cockpit), but i dont think its fully possible to implement all the demo's features into an external cockpit model at this time.