[Mav]

that still hasnt been set in stone. right now i have a bunch of invisible textures in my model, floating over the textured screens in my ship. if rtt doesnt fail then those invisible textures are replaced with rtted textures. of course this is temporary. also it tends to cripple framerates right now and theres some z sorting issues when dealing with the rtt cameras. i also at some point want to add working hud screens and i have an idea how to make it work, but im lazy. modability isnt hard though, my script parses a custom table file for most of the ship settings, contains info about player controllable turrets, camera positions, scripted animations and such.

Well, all I want is a way to assign hud anis to as texture of a polygon with "show ship" activated, just like the thruster ani which is also controlled by ingame variables (speed, afterburner) is assigned by placing a thruster01.pcx there... Is something like that already doable or at lest in the works?

id like to get all this stuff working with the new cockpit model feature, but i have no scripting access to those that i know about. so this only works with show ship cockpits.

What exactly is this "new cockpit model feature" ?

meaning that if you make the cockpit model to high res youl slow down the game because they get rendered for every ship in the mission. you could probibly get around this with per subobject detail distances (if they ever get implemented) or maybe detail boxes. performance is the main issue with the script at this point.

The approach I detailed above would easily take care of this via LODs - or at least I think it should... shouldn't it??


Admittedly, I haven't yet gotten into Lua scripting... so I'm pretty lost on the things you talk about it...  (What, for example, does "rtt" reference to?? )

[The E]

"rtt" stands for "render to texture". It's a technology where you can paste the view from a camera placed somewhere in your 3d space, and use the output as a texture on some model that the player actually gets to see. Examples for this would be the big screens Dr Breen is appearing on in HL2s opening. An obvious application for this in FS2 would be HUD elements projected onto 3d cockpit models.

[Nuke]

render to texture simply makes it possible to render to a texture instead of just the frame buffer. this texture then may be used in game. you can simulate mirrors and cameras and the like. you can also output 2d graphics to texture to make gauges. it works much better than just using an ani. there might be some degree of script control over animation playback, which works fine for any 1 dimensional gauge like a throttle indicator.

[Mav]

Hmm... kk, thanks for explaining.

So, as I understood it, this "rtt" is still being WIP then... hm.
Me hopes it'll make it into 3.6.11 , then .

[The E]

You could do it right now, but it has serious performance penalties. Needs an engine rewrite, most likely.

[Nuke]

it can be made to work but its nearly cutting the framerate in half in all my tests.

[Mav]

Can't it be kept from being drawn for all fighters by LODing ??

[Aardwolf]

"rtt" stands for "render to texture". It's a technology where you can paste the view from a camera placed somewhere in your 3d space, and use the output as a texture on some model that the player actually gets to see. Examples for this would be the big screens Dr Breen is appearing on in HL2s opening. An obvious application for this in FS2 would be HUD elements projected onto 3d cockpit models.

Except it can also mean "real time tactics", which led to some confusion when Nuke was talking about it, leading me to think he was already working on something like the FS2 RTS Mod. Then I was like "well, there should be an RTS Mod!" so we made one. And it was good.

[The E]

Can't it be kept from being drawn for all fighters by LODing ??

You don't understand. It is horribly inefficient, even if it is only drawn for the player.
And as it is drawn via scripting, it's relatively easy to not do it for every ship in the mission; that is not the point.

[Nuke]

my system only creates textures for the player. however there is a lot of inefficiency because of the number of render targets im using. all the 2d effects need to be drawn to one texture, cameras need to be rendered to their own textures then drawn as a 2d image to the main texture, since theres no way to mirror the scene properly. now you should be able to mirror the camera matrix to flip the scene the right way, but freespace seems to be built around 3x3 matrices which really gets annoying for this kinda thing. final version i might just go to using a single video screen only, and all the cockpit done with one texture, then i can alternate the render targets every frame so only one texture gets updated. still its so slow that its gonna need to be an optional feature for people with high end system.

[Col. Fishguts]

Did you ever post a example of your RTT script?

I would be happy with something simple as rendering the target computer view onto a texture, which would then be mapped into a cockpit POF.

[Aardwolf]

Hey, "Drones..."-related question: is it possible to have weapons with hitpoints that are not targetable (or which are not targetable with B, i.e. you would have to use the reticle targeting control) ?

[Nuke]

i kinda have that already, i have a multi-target type weapon that works with a tight beam radar. right now the radar range is adjustable so you can cover a narrow beam at long range or a wide beam at close range, however with some tweaks i can make the beam tighter so you would have to keep the target sighted to hit it.