[Vasudan Admiral]

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.

[Scooby_Doo]

BTW, neither of these implementations would have any effect on the modeler?  The map would be same?

[blackhole]

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.

[Vasudan Admiral]

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.

[Nuke]

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.

[Reprobator]

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!

[Vasudan Admiral]

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.

[Reprobator]

Exactly what i thought! 


About rendering hud , i think to help modders, a gui program with pre-filled field would be perfect! 
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!

[Nuke]

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.

[Scooby_Doo]

Exactly what i thought! 


About rendering hud , i think to help modders, a gui program with pre-filled field would be perfect! 
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.

[Nuke]

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

[Scooby_Doo]

Couple things just dawned on me:

1.) Minor, if the pilot doesn't have a head, make sure the copilot does 

2.) How are glowpoints and turrets handled?  Since the model being displayed isn't the actual ship hull, rather the cockpit hull.

[Nuke]

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.

[Scooby_Doo]

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?

[Nuke]

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.

[voidSkipper]

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?

[Scooby_Doo]

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:

[voidSkipper]

Fair enough, that makes sense.

[Reprobator]

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

[Scooby_Doo]

I've never had a problem with open meshes.