Re: HDR / PBR / compositor info
James Turner <[email protected]> Mon, 13 Jul 2026 14:08:29 +0100
| Newsgroups | gmane.games.flightgear.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============4311129615250407766== Content-Type: multipart/alternative; boundary="Apple-Mail=_284935BB-A6A8-4960-A269-471779DF428E" --Apple-Mail=_284935BB-A6A8-4960-A269-471779DF428E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Jul 2026, at 07:32, Josh Davidson <[email protected]> = wrote: >=20 >=20 > Basically, it would be so cool if we could reduce the amount of = "unnecessary breaking" occurring in the glTF migration. There=E2=80=99s two aspects to this: - we want to move as close to standard glTF as possible, in many areas: = coordinates, handling of nested files, animations, PBR materials, = transparency, etc. AC3D was always a quirky format choice, glTF is the = defacto modern standard in this space. Being as closely aligned as we = can, makes it much easier 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 = glTF extensions, so we can ditch the wrapper XML as well, but probably = that=E2=80=99s an incremental journey, where we support more and more = things either inside the glTF file (where eg, Blender can see it), or = outside. Next week I=E2=80=99m actually joining a Khronos / SIGGRAPH session = (remotely) on future glTF enhancements, and eg the recent major version = added support for =E2=80=99sub models=E2=80=99 which of course we need. = I=E2=80=99m going to be looking out for what else is missing to make our = XML format redundant, if we possibly can. But it=E2=80=99s 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, and produce an updated glTF with correct coordinates and = such. This won=E2=80=99t 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 scripts = that require some user guidance, but it should be a one-time operation. (I=E2=80=99m also wondering if we can use an image-aware LLM to do the = texture conversion, since my impression is this the most time-consuming = manual step : i.e classify areas of existing diffuse/specular textures = into =E2=80=98probably painted aluminium=E2=80=99 or =E2=80=98vinyl=E2=80=99= , and then derive corresponding metallic/roughness/albedo data=E2=80=A6 = if anyone wants to play with that, would be welcome) >=20 > 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 = conditionally? What do I do then? Straight emission doesn=E2=80=99t make sense in the PBR world, as I = understand it. The standard PBR solution would be image-based-lighting, = i.e you create essentially an emission map, but I don=E2=80=99t know if = the current PBR code actually supports IBL yet. (Hopefully James or Stuart know better) Kind regards, James --Apple-Mail=_284935BB-A6A8-4960-A269-471779DF428E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On 10 Jul 2026, at 07:32, Josh Davidson = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div class=3D"elementToProof" = style=3D"font-style: normal; font-variant-caps: normal; font-weight: = 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = 0px; -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid; = font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, = Helvetica, sans-serif; font-size: 12pt;"><br></div><div = class=3D"elementToProof" style=3D"font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: 2; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration-line: none; text-decoration-thickness: auto; = text-decoration-style: solid; font-family: Aptos, Aptos_EmbeddedFont, = Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: = 12pt;">Basically, it would be so cool if we could reduce the amount of = "unnecessary breaking" occurring in the glTF = migration.</div></div></blockquote><div><br></div><div>There=E2=80=99s = 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, transparency, etc. AC3D was = always a quirky format choice, glTF is the defacto modern standard in = this space. Being as closely aligned as we can, makes it much easier to = use existing glTF assets directly in FlightGear with, ideally, zero = changes.</div><div><br></div><div>In the long term, this would mean = encoding all our custom animations as glTF extensions, so we can ditch = the wrapper XML as well, but probably that=E2=80=99s 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=E2=80=99m actually joining = a Khronos / SIGGRAPH session (remotely) on future glTF enhancements, and = eg the recent major version added support for =E2=80=99sub models=E2=80=99= which of course we need. I=E2=80=99m going to be looking out for what = else is missing to make our XML format redundant, if we possibly can. = But it=E2=80=99s 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 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, and produce an updated glTF with = correct coordinates and such. This won=E2=80=99t 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 scripts that require some user = guidance, but it should be a one-time = operation.</div><div><br></div><div>(I=E2=80=99m also wondering if we = can use an image-aware LLM to do the texture conversion, since my = impression is this the most time-consuming manual step : i.e classify = areas of existing diffuse/specular textures into =E2=80=98probably = painted aluminium=E2=80=99 or =E2=80=98vinyl=E2=80=99, and then derive = corresponding metallic/roughness/albedo data=E2=80=A6 if anyone wants to = play with that, would be welcome)</div><br><blockquote = type=3D"cite"><div><div class=3D"elementToProof" style=3D"font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid; = font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, = Helvetica, sans-serif; font-size: 12pt;"><br></div><div = class=3D"elementToProof" style=3D"font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: 2; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration-line: none; text-decoration-thickness: auto; = text-decoration-style: solid; font-family: Aptos, Aptos_EmbeddedFont, = Aptos_MSFontService, Calibri, Helvetica, sans-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 = conditionally? What do I do = then?</div></div></blockquote><div><br></div><div>Straight emission = doesn=E2=80=99t make sense in the PBR world, as I understand it. The = standard PBR solution would be image-based-lighting, i.e you create = essentially an emission map, but I don=E2=80=99t 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></body></html>= --Apple-Mail=_284935BB-A6A8-4960-A269-471779DF428E-- --===============4311129615250407766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4311129615250407766== 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 --===============4311129615250407766==--