[Dilmah G]

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.

[Scooby_Doo]

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?

[Dilmah G]

Rearm time?

[Scooby_Doo]

That would be wait time.

Basically I would like to at least get started remodelling my stuff one last time.

[Dilmah G]

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.

[Nuke]

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.

[Scooby_Doo]

How does yours handle hud textures?

[SPECTRE87]

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!  

[Nuke]

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.

[Scooby_Doo]

BTW how is the hud being rendered now?

[Nuke]

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.

[Scooby_Doo]

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. 

[Scooby_Doo]

How about this?


edit: opps forgot about the forum's black background.

[Nuke]

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.

[Vasudan Admiral]

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:



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.

[Scooby_Doo]

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. 

[Vasudan Admiral]

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.

[Nuke]

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.

[Vasudan Admiral]

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.

[Nuke]

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.