Questions about HUD and textures.

[Krzysztof z Bagien]

I'm working on cockpit and HUD mod (well, it's actually more like a way for me to learn Blender, but maybe I can make something that looks good enough to share), and I'd like to know:
1. Is there a way to apply animated textures to, for example, cockpit or ship meshes? I guess not, since whole cockpit uses single texture file, but maybe...?
2. Can I change blast panels default texture?
3. Can I change blast panels opening animation (eg. make it slide back for civ ships; or make separate parts move in different directions)? Can some parts of glass remain not covered with blast panels at all?
4. I want some HUD elements to look like they are cockpit buttons or displays (like 3 lower displays). After engaging a jump drive, cockpit mesh moves back a little (to show that ship is moving really fast) and lower display panels move with it, but upper (compass, thruster/control indicators etc.) do not. Is there a way to make them move in that situation?
Trade, Navigation etc. buttons are static, so I can work around it and simply make actual 3D objects which, with right placement, from pilot's perspective will be seen where HUD buttons are; but compass and thruster/control indicators can't be done that way since they are dynamic.

[Vice]

1. Is there a way to apply animated textures to, for example, cockpit or ship meshes? I guess not, since whole cockpit uses single texture file, but maybe...?

No, they are indeed fixed. Certain HUD elements can be animated with certain image filename sequences outlined in the customizing kit.

2. Can I change blast panels default texture?

Yes, although an unlabeled/untested option. You can use the filename ccpitshield.dds in the \hud folder to try and replace it.

3. Can I change blast panels opening animation (eg. make it slide back for civ ships; or make separate parts move in different directions)? Can some parts of glass remain not covered with blast panels at all?

No, the movement pattern and coverage pattern is/are fixed (coverage shares the same mesh structure as the glass mesh).

4. I want some HUD elements to look like they are cockpit buttons or displays (like 3 lower displays). After engaging a jump drive, cockpit mesh moves back a little (to show that ship is moving really fast) and lower display panels move with it, but upper (compass, thruster/control indicators etc.) do not. Is there a way to make them move in that situation?

No, those elements are attached to the pilot's helmet, so they move and rotate with the pilot's view rather than the ship they are sitting in.

Trade, Navigation etc. buttons are static, so I can work around it and simply make actual 3D objects which, with right placement, from pilot's perspective will be seen where HUD buttons are; but compass and thruster/control indicators can't be done that way since they are dynamic.

Correct, although you can move them out of view if you want to try your approach with cockpit bound button options rather than helmet bound.

[Krzysztof z Bagien]

OK, another set of questions :]

You say that compass etc. are helmet bound and they move with pilot's view - but they don't. They are always in the same position in 3D space, if they were actually bound to pilot's view - shouldn't they always be in the same position on screen ?

Can objects other than cockpit use textures, normal, specular and emissive maps in any other format, or is only .dds supported?

Can blast panels and cockpit glasss also use normal, specular and emissive maps? (I don't think that would be really usefull, but is it possible at all?)
And how about joystick and throttle - can they use custom texture, normal map etc.?

[Vice]

You say that compass etc. are helmet bound and they move with pilot's view - but they don't. They are always in the same position in 3D space, if they were actually bound to pilot's view - shouldn't they always be in the same position on screen ?

They are always in the same position in 3D space relative to the pilot's head as it moves around... which is positional, hence moving with the pilot's view. They are projected to a particular point in 3D space and are bound to the central position of the pilot's head. But they do also (counter-)rotate with the pilot's head rotation to stay 'virtually' centered to the forward view. This is particularly important and true for the gunsight, which remains projected to forward center to remain aligned with the nose of the ship and where weapons will be aiming.

So those elements move with the pilot's head position as center and (counter-)rotate to remain centered to forward as the pilot rotates their head to retain directional alignment. You'll find this is true of -all- helmet bound display elements, including the target direction indicator, object/non-target direction indicators, nav marker, waypoint marker, quest marker, MDTS auto-aiming arrow, and ILS/landing tunnel indicator.

So if you move the pilot's head -position- with TrackIR or VR, the compass, top menu options, control/thruster indicators, and gunsight will remain locked to the pilot's viewpoint as center, but those elements also rotate to remain aligned to the forward direction when the pilot's head rotates (or any direction to align with a point in space they need to indicate). If you accelerate or decelerate, you'll see the gunsight and compass tape remain in their consistent positional locations while the cockpit of the ship moves around. So one set of display elements remain properly locked to the helmet's position while others (cockpit displays), which are bound to cockpit point elements, are unbound and move around.

Some modern jet fighters and helicopters use similar 'HMD' systems to project indicators that continually point to fixed positions in space regardless of how the pilot rotates their head. The systems in the game simply apply the concept to a limited realm of selectable menu options, gunsight, and target indicator data.

Can objects other than cockpit use textures, normal, specular and emissive maps in any other format, or is only .dds supported?

Some yes, some no. The customizing kit should indicate where 'PNG' options may be available. Normal maps will almost always use PNG only since DDS artifacts can negatively impact how they work.

Can blast panels and cockpit glasss also use normal, specular and emissive maps? (I don't think that would be really usefull, but is it possible at all?)

No, those are limited to diffuse maps only (although they do also employ a shadow map index internally for that effect).

And how about joystick and throttle - can they use custom texture, normal map etc.?

Yes, they share the same base image/texture indexes as the primary cockpit structure/mesh. So you can fit in any additional custom textures detail you may want into the image area of those texture indexes, then UV map them from those indexes as desired.

[Krzysztof z Bagien]

I'm just nitpicking here and it's not really a major concern, but my point is that while it's true that some indicators should always "point forward" (and they do in modern HMDs), some can be shown enywhere in 3D space (like target indicators, it's logical they are overlaid on an actual target), there are also some things that are always displayed in front of pilot's eyes (eg. airspeed or altitude, weapon status etc.); and we have only the first two - if I look to the right I won't be able to see my velocity for example, and it would seem useful fully utilise that HMD if I have one.
Slightly OT, but I just watched some videos of F-35 HMD and man! It can display picture-in-picture video from external cameras; with that thing pilot can actually see THROUGH his plane!

Edit: and sorry for dumb question, but where exactly I can check whether something can use .png instead of .dds? There is no such information in custom kit documentation.
Or does it mean that, for example, heatflare should always be .png, but asteroid texture can only be .dds?

[Vice]

Slightly OT, but I just watched some videos of F-35 HMD and man! It can display picture-in-picture video from external cameras; with that thing pilot can actually see THROUGH his plane!

Yes, exactly. And in the game, you can turn off the 3D cockpit and have the full view effect as well.

and sorry for dumb question, but where exactly I can check whether something can use .png instead of .dds? There is no such information in custom kit documentation.
Or does it mean that, for example, heatflare should always be .png, but asteroid texture can only be .dds?

For one example:

starsX-0.dds or starsX-0.png = background forward direction
starsX-1.dds or starsX-1.png = background right direction
starsX-2.dds or starsX-2.png = background rear direction
starsX-3.dds or starsX-3.png = background left direction
starsX-4.dds or starsX-4.png = background down direction
starsX-5.dds or starsX-5.png = background up direction

When the filename listing(s) show either a 'PNG' option on its own or in addition to a 'DDS' option, then it's available. For most/all of the larger texture options though, I would strongly recommend using texture compression via DDS to minimize the chance players with minimum/low-spec systems will crash from the game when their system runs out of memory.

[Marvin]

I haven't used .dds textures for this game but I have used them elsewhere. And, IIRC, there are a number of possible options associated with .dds ... also, IIRC, you (Vice) mentioned elsewhere which option works best. Sooooo ... could you please remind me (and, this time, I'll make note of it ... maybe even nudge Dave to include it in his masterpiece Guide).

[Vice]

DDS is best used with larger textures, for example, ship's diffuse (base), emissive (labelled 'lights' in filename), and specular (labelled 'shader' in filename) textures. PNG is used for normal maps. A good tool for generating DDS textures from original PNG media is The Compressonator: http://developer.amd.com/tools-and-sdks ... essonator/ DXT5 is the compression format I would recommend.

[Marvin]

DXT5 is the compression format I would recommend.

Thanks, Vice. That's the part I was looking for.


P.S. Btw, I just now checked the Customizing Kit and, to quote from the Kit:

You can optionally apply different resolution levels for each image set, if desired. Using the DDS image format will allow you to use texture compression (ie DXT5) for larger images with less memory overhead.