Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Droz on February 23, 2005, 10:33:42 pm
-
1st and foremost 1st person cockpits with WORKING Guages. That would be AWESOME.
2nd, TrackIR Support with 6DOF Vector Support. I ask you to take a look at //www.naturalpoint.com and look through it to understand what it is if you don't know. The Naturalpoint Devs will actually HELP you implement it into the game. With this we obviously need some form of Freelook in the game so that comes hand in hand.
All I have right now, it's a short list, I know.
I have no intention of saying any of this in an insulting way, just so you guys know. I ask for these things cause I know NOTHING of coding. I'm a hardware guy, I only build em and break em :).
I love what's going on here, and this has literally reignited my interest in this game, as well as the squad I fly with in other games (IL2, LOMAC, etc.)
Keep it up fellas :)
-
FYI, if TrackIR support is added, the guys at naturalpoint will put free advertising for the project on the site :).
-
It really shouldn't be too hard to add TrackIR support, however, none of the devs have it so that could make testing it difficult.
I'd be interested in adding it if you or someone else with the device can test builds.
On the 1st point, there are a few ways I can see doing that (I've done some thinking).
1-Generate textures of the default HUD font at startup. These could then be mapped on individually using the texture replacement SEXPs. This could cause massive slowdowns and would be limited by the texture limits for ships, not to mention the extra coding work to designate textures to be replaced and actually do the replacing
2-Wait until a render-to-texture function is implemented. For D3D, that would mean upgrading to DX9. I'm not sure about OpenGL
3-Modify the existing 3D functions so that the gauges are drawn in 3D space. Right now, the text and images are mapped onto polygons and then rendered. It wouldn't be texture mapping, it wouldn't be as difficult to implement as #1, but it would still be very difficult for modellers and coders. Modellers would have to define points on the model with pretty high accuracy (hundredth of a unit), probably via a TBL file. Coders would have to update the code to read/parse that data, and then have the HUD automatically switch to using 3D functions if points are defined for a given gauge. A new text-display function would have to be written for both D3D and OGL modes for 3D text display.
Edit:
4-(Which I basically couldn't do with my current 3D knowledge) Have a separate texture for a cockpit model. This would contain color-coded sections, much like the interface click maps. When the model is loaded, the texture would also be loaded, mapped, and the points for the sections loaded into memory. At this point the same thing would be done as in #3, the gauges would be projected in 3D space. I've no idea if this method would actually even be possible though.
-
Think I get you reguarding the number one options.
As for the TrackIR support, I would be happy to help out. I have both the TrackIR and the Vector expansion so I can test all of it.
I know adding in TrackIR support is usually rather simply, not sure about 6DOF though, you'd have to talk to the naturalpoint devs on that one. But I'd be more than happy to help with that :).
-
6DOF would be more difficult to add, yeah, but I think most of that would be extracting the necessary code from the normal keyboard/joystick controls section and making it work with the SDK. It depends on how they've implemented things; hopefully, it's similar enough that the keyboard input functions (or the joystick input functions, but I'm less familiar with those) could be used.
2DOF seems like it'd be pretty immersive though, and there's only one or two sections of the code that deal with view-setting that'd have to be changed. Obviously you'd need initialization/destruction functions too, but that shouldn't be too bad.
-
in order to make the cockpit rendering, we might have to make the cockpit render totaly seperate from the actual ship model. Actually viewing the cockpit from inside the model seems like a round about hackish way of doing things.
-
well, I'm the man to test it for ya if ya want. I have all of it :)
-
Originally posted by Drew
in order to make the cockpit rendering, we might have to make the cockpit render totaly seperate from the actual ship model. Actually viewing the cockpit from inside the model seems like a round about hackish way of doing things.
Not necessarily, no. You should still be able to look around inside the cockpit, the only problem would be the placement of the pilot model inside the cockpit. Although, actually, by setting the clipping plane just right and limiting the FOV you could probably fix that problem for the most part, if the eyepoint for every model was in the center of the head.
Rendering the ship model was the simplest way to do it, but really isn't all that hackish. There's no problem with discrepancies between the cockpit model and the ship model, parts of the ship aren't missing, etc. The biggest problem I can come up with is that it limits polys and textures in the cockpit - and it can be more difficult to add the cockpit to a model (Although then you have a model with a cockpit).
-
The way I'd like to see it done would require a new version of the POF format, and if we are going to go that route then we should just upgrade the model format altogether. It could be a new chunk in the existing format, but if we go that route the format has to be upgraded anyway and there are a number of pressing limitations to the POF format as it stands.
Anyway, the way I think it should be done is to build a seperate cockpit model that is very high definition, but have it only render for the player in place of his ship. It'd be ignored on every other ship, and thus not tie rediculous texture sizes and polycounts to a very small space. If part of your fighter is supposed to be visible from the cockpit, model that in too, but only the faces that you can see; anything outside of the cockpit glass FOV would never be seen so thus would need no model data.
EDIT: this does raise concerns with discrepencies between model and cockpit, but that should be avoided easily-enough if the ship creator knows what he's doing.
-
If Bobboau or whoever upgrades the POF format can manage that, sure, but if I were to do any sort of seaparate cockpit thing, I'd have to make it a separate POF.
-
That actually has it's positives too, since you'd only be loading one of the things at any given time. Either-or. I just think the limitations of rendering out the actual ship are pretty substantial and shouldn't be ignored.
-
100% with stratcom, less rendered is more frames.
Coolman, you let me know when you want it tested and I'll be happy to do so.
-
I SO want to upgrade the pof specification.
-
People! Test bob's stuff!
-
Bobb's superdetail boxes somewhat make the whole to model in or not issue moot.
They are a perfect solution perfomance vice to have über detail.
-
word on the TrackIR accessability?
-
It's...there. I just recently got e-mail back in an easily accessible state, and have been learning OGL for Ferrium, so it's been pushed back on The List.
-
that's cool :)