Render HUD to Texture: Render to texture is currently a feature that's available using the scripting system. You can easily render pretty much anything to cockpit models and ship models using the Lua subsystem. However, a common request despite the availability of script-based render to texture is the capability to render-to-texture existing HUD gauges that have already been built into the code.
The HUD code has been rewritten to be flexible enough to feature this capability. And as a result, Diaspora is currently testing this feature using the DRADIS radar as shown in various video previews. The plan is to open this feature up to all HUD gauges and not just the DRADIS radar once it's definitively stable and ready.
script level rtt is buggy as hell right now. granted it was pretty rock solid in 3.6.12, it had its quirks but for the most part it worked well. i managed to do several from-scratch hud and panel elements, entirely in scripting, and managed to apply them to ship geometry (old-skool cockpit submodel using show ship flag, as scripting access to cockpit modes was non-existant at the time). it worked well, had working radars and whatnot, and a system for animating subobjects within the cockpit model and elsewhere so you could have animated cockput controls and potentially others, such as control surfaces. i also had intended to make its features modder friendly so they could edit familiar tables to configure the script for their mod. of course at some point the rtt features of script just did not work with 3.6.13.
right now i think ive identified 2 distinct problems. one i believe is a geometry issue in my testbed models. when i converted models for use in my rtt heavy cockpit script, i didnt make models from scratch, i just used some of the cockpits already found in various nukemod ships. i essentially used pcs2 to insert a few polygons which were textured for the mfd panels i was using at the time. the mfd textures would be replaced with textures generated by the script. now this worked before 'go faster' builds came along and after that i had a whole bunch of issues with uv space banding. i found out that this had nothing to do with render to texture calls and 2d stuff worked fine. i think the problem had something to do with ibos (the effect is similar to the uv space corruption that happened recently in the nightly builds). to fix this id just have to work on the models abit more.
the second issue is probibly not relevant to to your hud system, but getting the renderFrame() call to work with a render target is really hard to make work. it kinda works right now, sometimes, but at what appears to be 1/4 the resolution (it kinda renders to the bottom left corner of the texture). some times it renders to the screen in an odd way, instead of into a texture. this is only useful if you want things in your cockpit like a simulated monitors, mirrors, etc.
i just want to bring this up, kind of a heads up on whats going on with the scripting side.
hey swifty a question:
The new HUD will allow us to animate it?
i was thinkin at this :
as you know the pitch ladder moves...it should be a good improvement
scripting. learn it, know it, love it, and then use it for evil.
it does however bring up a good point. id like to some how make it so scripting and the hud system have some degree of interaction. i want to use scripting to create gauges. scripting gives you drawing primitives, capacity for bitmap rendering, some 3d rendering features, in addition to maths and access to game data. everything you need to come up with gauges just like the one in the picture there. problem with these scripted gauges, is that you pretty much treat it as a function to be called on the draw hud hook. it just draws on top of whatever was on the hud without regard to its layout. you could give the scripting access to some information about the hud layout, but it still requires scripting talent to get it to work with your mod.
instead what if i define the gauge with scripting, and place it with the hud layout system. so when it comes time to render that gauge, it runs a hook ($on hud gauge render: name of gauge). and when it does the script is passed layout data such as: resolution, size, color, Slew, etc. as an example, some time ago a modder wanted to use my attitude gauge from my atmospheric flight script
. it shoulda been easy to hand it over, a table and some graphics. but i had to do a lot of cut and paste to make it standalone and then had to tweak it to look right on their hud at different resolutions. it would be nice if i can just say, "stick this in your mod folder and configure it in hud-gauges.tbl". would also make it much much easier to render custom gauges to texture without having to have the script manage the render targets and texture replacement.