<TEXTURE> element issue

[Marcin]

Hi.

I migrated my CustomDraw elements to TEXTURE element using the rendering plugin. As this is background element I use TEXTURES_BELOW_PANEL = 1 in the panel.cfg

As you can see it renders quite well and very fast:



however I have 2 problems that only appears on the VC. On 2D panel ALL IS GOOD and it is the same XML gauge.

1) The first issue is the black rectangle. I experimented a little bit and it is not related to the XML code as when I removed all elements and kept only TEXTURE element the black top left rectangle was still there. I believe it is something related with the model. As I am not 3d modeller could you give me a hint what could be wrong in that model definition ?

2) The second issue is the use of RECTANGLE element with Transparency attribute. It is used for dimming/shadowing some of the elements of PFD symbology. In 2D compass rose and altitude indicator are shadowed however in 3D VC view they are not. Can you tell me what is wrong ? Something in the model. The following code is used for the shadow:

<Element id="Shadow">
<FloatPosition>219.000,232.000</FloatPosition>
<Image id="pfd_360_rose_shadow.bmp" Alpha="true" Name="pfd_360_rose_shadow.bmp">
<Transparent>true</Transparent>
<Axis>144.000,144.000</Axis>
<Bright>true</Bright>
</Image>
<Rectangle id="Shadow">
<Bright>true</Bright>
<Width>300</Width>
<Height>300</Height>
<FillColor>black</FillColor>
<Transparency>0.800</Transparency>
</Rectangle>
</Element>

and it looks <Transparency>0.800</Transparency> has no effect on that rectangle element.

BTW, one thing I also noticed. When background_color in panel.cfg IS NOT 0,0,0 then the texture element is NOT visible on 2D panel. When I move the gauge I can see it is rendered as it blinks for a second then it is covered by the background. I am not sure this is expected behavior.

[Marcin]

This issue is also reproducible on V3 and V4 of P3D. Can anyone from LM help me ?

The most critical for me is point 2) with Rectangle object.

[Beau Hollis]

The reason for the textures above/below option and the requirement of a 000 background in the below case is that the XML gages draw using GDI to a texture in system memory. Texture elements reside in GPU memory. We composite the panel image and any texture elements into a render target during the final GPU render. In the case of a 2d panel, that target is the swap chain back-buffer. In the case of a VC texture, it is an off-screen render target that references a texture mapped by name in our texture map.

I would expect a non-zero background color to cause the texture elements not to show in the VC variant as well. Is this not the case?

One of the main differences in two window types is how alpha is handled during the composition. While rendering a VC texture, we write the alpha into the output RT. This is required for things like HUDs to work because the VC texture don't have an existing scene to blend with. This can be an issue if you 3d model uses the texture via a material with alpha blending. The xml based image writes its alpha which causes the texture element to blend out. You can either update the model in that case, or turn off the alpha write mask via the panel.cfg.

Note also that while texture elements can be controlled within a gauge, they are applied per-panel. Something like that black box could occur if there were another gauge on the panel that was drawing a black box.

Undocked panel windows don't alpha blend the panel image render since there isn't a scene behind.

All that said, I'm still not sure why those transparent boxes work in one and not the other. You can get the $ texture by name from your plugin. If you needed to do some complex level of composition the engine doesn't support, you could pull the vc texture and generate the final texture in your plugin, provided you don't need to catch clicks on it.

Another thing worth noting is that the way we pass textures into Scaleform allows for true element layering. Because scaleform renders all elements on the GPU, there isn't a need for the above/below and blend modifiers.

[Marcin]

Many thanks Beau for the response.
1) 000 background understood. It would be nice to have in the documentation in the section describing TEXTURES_BELOW_PANEL panel attribute.

2) You were right about the black box. It was another gauge in the same VC section that was causing it. I focused on the XML gauge forgetting I need to look at the whole panel. Thanks for that.

3) Unfortunately I cannot resolve the problem with shadow. In fact it is issue with <TRANSPARENCY> attribute. To disconnect from my code I have created simple XML gauge and used your DX11 sample (yellow cross on blue background). Now the results are in the screenshots below. When the transparency value is >= 0.5 the element becomes full transparent and when it is below (0.4 in the example) it becomes full opaque.

You can look at it as it seem P3D issue. Anyway the only option I have is to build that shading into the texture unless you find a solution that can be done without touching your code.

XML code:

<?xml version="1.0" encoding="windows-1250"?>
<SimBase.Document Type="AceXML" version="1,0" id="G1000 PFD">
<Descr>AceXML Document</Descr>
<SimGauge.Gauge id="ShadowTest" ArtDirectory=".">
<FloatPosition>0.000,0.000</FloatPosition>
<Size>1400,915</Size>
<Element id="Bezel">
<FloatPosition>0.000,0.000</FloatPosition>
<Image id="G1000_BackgroundMFD.bmp" Name="G1000_BackgroundMFDINOP.bmp">
<Transparent>true</Transparent>
<Bright>true</Bright>
</Image>
</Element>


<Element id="Screen">
<FloatPosition>184.000,37.000</FloatPosition>

<Element id="Texture">
<FloatPosition>0.000,57.000</FloatPosition>
<Texture id="CursorTexture">
<Name>CursorTexture</Name>
<Width>1024</Width>
<Height>682</Height>
</Texture>
</Element>

<Element id="360">
<FloatPosition>240.000,355.000</FloatPosition>
<Visibility>(L:G1000_HSIFormat, enum) 0 == </Visibility>
<Element id="Shadow">
<FloatPosition>219.000,232.000</FloatPosition>
<!--Image id="pfd_360_rose_shadow.bmp" Alpha="true" Name="pfd_360_rose_shadow.bmp">
<Transparent>true</Transparent>
<Axis>144.000,144.000</Axis>
<Bright>true</Bright>
</Image-->

<Rectangle id="Rectangle">
<Axis>144.000,144.000</Axis>
<Bright>true</Bright>
<Width>300</Width>
<Height>300</Height>
<FillColor>red</FillColor>
<Transparency>0.500</Transparency>
</Rectangle>

</Element>

</Element>

</Element>
</SimGauge.Gauge>
</SimBase.Document>

Transparency 0.5



Transparency 0.4



panel.cfg

[Vcockpit01]

size_mm=512,512
visible=0
pixel_size=1024,1024
texture=$Panel_1

gauge05=C172SP_G1000SVS!ShadowTest, 0,0,384, 251



Background_color=0,0,0
TEXTURES_BELOW_PANEL=1
disable_alpha_write=1
;TEXTURES_USE_ADDITIVE_BLEND=1
;TEXTURES_USE_ADDITITVE_BLEND=1

Best regards

Marcin

[Beau Hollis]

Thanks for the example. I will make a ticket to look into it. Does this still happen without the image tag? I believe this might have to do with underlying image format. The system supports a 5551 binary alpha format and an RGBA 8888 format. It tries to pick which is needed based element settings. Perhaps the format of the background image is being forced on the elements that are layered on top. I didn't see anything specifically when looking at the code, but its possible the full alpha format is forced for on screen windows because they don't know what will be behind them. You might try using 8888 bitmaps and setting Transparent and Alpha in the xml settings so see if that helps.

[Marcin]

Yes, this happens even if there is no image tag at all. For example with such XML gauge:

<?xml version="1.0" encoding="windows-1250"?>
<SimBase.Document Type="AceXML" version="1,0" id="G1000 PFD">
<Descr>AceXML Document</Descr>
<SimGauge.Gauge id="ShadowTest" ArtDirectory=".">
<FloatPosition>0.000,0.000</FloatPosition>
<Size>1400,915</Size>

<Element id="Screen">
<FloatPosition>184.000,37.000</FloatPosition>

<Element id="Texture">
<FloatPosition>0.000,57.000</FloatPosition>
<Texture id="CursorTexture">
<Name>CursorTexture</Name>
<Width>1024</Width>
<Height>682</Height>
</Texture>
</Element>

<Element id="360">
<FloatPosition>240.000,355.000</FloatPosition>
<Visibility>(L:G1000_HSIFormat, enum) 0 == </Visibility>
<Element id="Shadow">
<FloatPosition>219.000,232.000</FloatPosition>

<Rectangle id="Rectangle">
<Axis>144.000,144.000</Axis>
<Bright>true</Bright>
<Width>300</Width>
<Height>300</Height>
<FillColor>red</FillColor>
<Transparency>0.500</Transparency>
</Rectangle>

</Element>

</Element>

</Element>
</SimGauge.Gauge>
</SimBase.Document>

[Beau Hollis]

We dug into this a bit and were able to reproduce the alpha clamping in your simple red/blue sample. In our tests, this alpha clamping affected both the vcockpit texture use case and the 2d window. We're unable to get transparency values (other than 0 and 1) to blend with window underneath or with texture elements drawn below the panel. This was true even if we removed the texture element. Can you reproduce the working case in a 2d window using your simplified sample?

This was actually not surprising. While gauge elements use different image color formats for drawing their content based on the alpha setting, the panel texture itself is a 5551 texture with a binary alpha. That's why elements within the texture can blend with each other, but the final alpha value is clamped to 0 or 1. Scaleform supports full RGBA alpha output and allows texture elements to be mapped to movie clips and composited in any order. That may be your best bet for achieving this sort of effect.

Thanks