Re: HDR / PBR / compositor info

--===============2564480241022648495==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_DS7PR07MB7734CC06579144B41C4A3162CCFA2DS7PR07MB7734namp_"

--_000_DS7PR07MB7734CC06579144B41C4A3162CCFA2DS7PR07MB7734namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,
About emission, I understand however since AC3D is still supported I would =
like to be able to make that work still, and I rely on that for indicator l=
amp and panel integral backlighting in a lot of aircraft.

I don't really understand then so what would replace emission for something=
 like a lamp where when the lamp is on I want to add emission to it and not=
 with the PBR world?

I understand what you're saying however when I'm saying is that if the flig=
ht model and everything are still using the Z up direction then I really th=
ink we need to keep the models with the Z up as well. Things get really con=
fusing really fast if I have to start juggling coordinate transforms.

So even though technically the standard is different, the application in fl=
ightgear is that Z is the up direction and personally I think that we shoul=
d keep things uniform.

Not doing that makes things quite complicated from an aircraft point of vie=
w and means converting a model from AC to glTF requires manual rework at le=
ast unless some script is available and in my experience that can sometimes=
 be troublesome depending on exactly what is used. Perhaps a good script ca=
n be developed but still it seems like an unnecessary burden.

Plus adding the annoyance of having different coordinate systems in the sam=
e program.

Kind Regards,

--
Josh Davidson
________________________________
From: James Turner <[email protected]>
Sent: Monday, 13 July 2026 08:08:29
To: FlightGear developers discussions <[email protected]=
et>
Subject: Re: [Flightgear-devel] HDR / PBR / compositor info



On 10 Jul 2026, at 07:32, Josh Davidson <[email protected]> wrot=
e:


Basically, it would be so cool if we could reduce the amount of "unnecessar=
y breaking" occurring in the glTF migration.

There=92s two aspects to this:

- we want to move as close to standard glTF as possible, in many areas: coo=
rdinates, handling of nested files, animations, PBR materials, transparency=
, etc. AC3D was always a quirky format choice, glTF is the defacto modern s=
tandard in this space. Being as closely aligned as we can, makes it much ea=
sier to use existing glTF assets directly in FlightGear with, ideally, zero=
 changes.

In the long term, this would mean encoding all our custom animations as glT=
F extensions, so we can ditch the wrapper XML as well, but probably that=92=
s an incremental journey, where we support more and more things either insi=
de the glTF file (where eg, Blender can see it), or outside.

Next week I=92m actually joining a Khronos / SIGGRAPH session (remotely) on=
 future glTF enhancements, and eg the recent major version added support fo=
r =92sub models=92 which of course we need. I=92m going to be looking out f=
or what else is missing to make our XML format redundant, if we possibly ca=
n. But it=92s going to be a journey for sure.

BUT, the second thing:

- most of the changes should be handled by tooling, not manually performed.=
 I.e we need to start creating some scripts (likely in Blender again, since=
 it has a Python APi and all the building blocks) to read an ACD3 + XMl, an=
d produce an updated glTF with correct coordinates and such. This won=92t b=
e able to automatically fix up some aspects (see below), especially, the me=
tal/roughness/albedo textures, but most other things should be automatic. L=
ikely we end up with some scripts that require some user guidance, but it s=
hould be a one-time operation.

(I=92m also wondering if we can use an image-aware LLM to do the texture co=
nversion, since my impression is this the most time-consuming manual step :=
 i.e classify areas of existing diffuse/specular textures into =91probably =
painted aluminium=92 or =91vinyl=92, and then derive corresponding metallic=
/roughness/albedo data=85 if anyone wants to play with that, would be welco=
me)


I would also like to ask why the emission animation was removed? What about=
 existing AC3D models? What if I need to make something light up conditiona=
lly? What do I do then?

Straight emission doesn=92t make sense in the PBR world, as I understand it=
. The standard PBR solution would be image-based-lighting, i.e you create e=
ssentially an emission map, but I don=92t know if the current PBR code actu=
ally supports IBL yet.

(Hopefully James or Stuart know better)

Kind regards,
James


--_000_DS7PR07MB7734CC06579144B41C4A3162CCFA2DS7PR07MB7734namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
Hi,</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
About emission, I understand however since AC3D is still supported I would =
like to be able to make that work still, and I rely on that for indicator l=
amp and panel integral backlighting in a lot of aircraft.</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
<br>
</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
I don't really understand then so what would replace emission for something=
 like a lamp where when the lamp is on I want to add emission to it and not=
 with the PBR world?&nbsp;</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
<br>
</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
I understand what you're saying however when I'm saying is that if the flig=
ht model and everything are still using the Z up direction then I really th=
ink we need to keep the models with the Z up as well. Things get really con=
fusing really fast if I have to
 start juggling coordinate transforms.</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
<br>
</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
So even though technically the standard is different, the application in fl=
ightgear is that Z is the up direction and personally I think that we shoul=
d keep things uniform.</div>
<div id=3D"ms-outlook-mobile-body-separator-line" data-applydefaultfontstyl=
es=3D"true" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-system=
, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;" dir=3D"auto">
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt;">
<br>
</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
Not doing that makes things quite complicated from an aircraft point of vie=
w and means converting a model from AC to glTF requires manual rework at le=
ast unless some script is available and in my experience that can sometimes=
 be troublesome depending on exactly
 what is used. Perhaps a good script can be developed but still it seems li=
ke an unnecessary burden.&nbsp;</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
<br>
</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
Plus adding the annoyance of having different coordinate systems in the sam=
e program.</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
<br>
</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
Kind Regards,</div>
<div style=3D"font-family: Aptos, Aptos_MSFontService, -apple-system, Robot=
o, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" =
dir=3D"auto">
<br>
</div>
</div>
<div style=3D"font-family: Aptos, Aptos_MSFontService, -apple-system, Robot=
o, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(33, 33, 33);" =
id=3D"ms-outlook-mobile-signature" dir=3D"auto">
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
--</div>
<div dir=3D"auto" style=3D"font-family: Aptos, Aptos_MSFontService, -apple-=
system, Roboto, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(3=
3, 33, 33);">
Josh Davidson</div>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> James Turner &lt;jame=
[email protected]&gt;<br>
<b>Sent:</b> Monday, 13 July 2026 08:08:29<br>
<b>To:</b> FlightGear developers discussions &lt;[email protected]=
rceforge.net&gt;<br>
<b>Subject:</b> Re: [Flightgear-devel] HDR / PBR / compositor info</font>
<div>&nbsp;</div>
</div>
<div style=3D"line-break:after-white-space"><br id=3D"x_lineBreakAtBeginnin=
gOfMessage">
<div><br>
<blockquote type=3D"cite">
<div>On 10 Jul 2026, at 07:32, Josh Davidson &lt;[email protected]=
om&gt; wrote:</div>
<br class=3D"x_Apple-interchange-newline">
<div>
<div class=3D"x_elementToProof" style=3D"font-style:normal; font-variant-ca=
ps:normal; font-weight:400; letter-spacing:normal; orphans:2; text-align:st=
art; text-indent:0px; text-transform:none; white-space:normal; widows:2; wo=
rd-spacing:0px; text-decoration-line:none; text-decoration-style:solid; fon=
t-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,san=
s-serif; font-size:12pt">
<br>
</div>
<div class=3D"x_elementToProof" style=3D"font-style:normal; font-variant-ca=
ps:normal; font-weight:400; letter-spacing:normal; orphans:2; text-align:st=
art; text-indent:0px; text-transform:none; white-space:normal; widows:2; wo=
rd-spacing:0px; text-decoration-line:none; text-decoration-style:solid; fon=
t-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,san=
s-serif; font-size:12pt">
Basically, it would be so cool if we could reduce the amount of &quot;unnec=
essary breaking&quot; occurring in the glTF migration.</div>
</div>
</blockquote>
<div><br>
</div>
<div>There=92s two aspects to this:</div>
<div><br>
</div>
<div>- we want to move as close to standard glTF as possible, in many areas=
: coordinates, handling of nested files, animations, PBR materials, transpa=
rency, etc. AC3D was always a quirky format choice, glTF is the defacto mod=
ern standard in this space. Being
 as closely aligned as we can, makes it much easier to use existing glTF as=
sets directly in FlightGear with, ideally, zero changes.</div>
<div><br>
</div>
<div>In the long term, this would mean encoding all our custom animations a=
s glTF extensions, so we can ditch the wrapper XML as well, but probably th=
at=92s an incremental journey, where we support more and more things either=
 inside the glTF file (where eg, Blender
 can see it), or outside.</div>
<div><br>
</div>
<div>Next week I=92m actually joining a Khronos / SIGGRAPH session (remotel=
y) on future glTF enhancements, and eg the recent major version added suppo=
rt for =92sub models=92 which of course we need. I=92m going to be looking =
out for what else is missing to make our
 XML format redundant, if we possibly can. But it=92s going to be a journey=
 for sure.</div>
<div><br>
</div>
<div>BUT, the second thing:</div>
<div><br>
</div>
<div>- most of the changes should be handled by tooling, not manually perfo=
rmed. I.e we need to start creating some scripts (likely in Blender again, =
since it has a Python APi and all the building blocks) to read an ACD3 + XM=
l, and produce an updated glTF with
 correct coordinates and such. This won=92t be able to automatically fix up=
 some aspects (see below), especially, the metal/roughness/albedo textures,=
 but most other things should be automatic. Likely we end up with some scri=
pts that require some user guidance,
 but it should be a one-time operation.</div>
<div><br>
</div>
<div>(I=92m also wondering if we can use an image-aware LLM to do the textu=
re conversion, since my impression is this the most time-consuming manual s=
tep : i.e classify areas of existing diffuse/specular textures into =91prob=
ably painted aluminium=92 or =91vinyl=92,
 and then derive corresponding metallic/roughness/albedo data=85 if anyone =
wants to play with that, would be welcome)</div>
<br>
<blockquote type=3D"cite">
<div>
<div class=3D"x_elementToProof" style=3D"font-style:normal; font-variant-ca=
ps:normal; font-weight:400; letter-spacing:normal; orphans:2; text-align:st=
art; text-indent:0px; text-transform:none; white-space:normal; widows:2; wo=
rd-spacing:0px; text-decoration-line:none; text-decoration-style:solid; fon=
t-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,san=
s-serif; font-size:12pt">
<br>
</div>
<div class=3D"x_elementToProof" style=3D"font-style:normal; font-variant-ca=
ps:normal; font-weight:400; letter-spacing:normal; orphans:2; text-align:st=
art; text-indent:0px; text-transform:none; white-space:normal; widows:2; wo=
rd-spacing:0px; text-decoration-line:none; text-decoration-style:solid; fon=
t-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,san=
s-serif; font-size:12pt">
I would also like to ask why the emission animation was removed? What about=
 existing AC3D models? What if I need to make something light up conditiona=
lly? What do I do then?</div>
</div>
</blockquote>
<div><br>
</div>
<div>Straight emission doesn=92t make sense in the PBR world, as I understa=
nd it. The standard PBR solution would be image-based-lighting, i.e you cre=
ate essentially an emission map, but I don=92t know if the current PBR code=
 actually supports IBL yet.</div>
<div><br>
</div>
<div>(Hopefully James or Stuart know better)</div>
<br>
</div>
<div>Kind regards,</div>
<div>James</div>
<br>
</div>
</body>
</html>

--_000_DS7PR07MB7734CC06579144B41C4A3162CCFA2DS7PR07MB7734namp_--


--===============2564480241022648495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2564480241022648495==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--===============2564480241022648495==--