Re: Shaders & Textures in Next

Hi Folks,

Collating responses:

On Tue, Jun 2, 2026 at 3:03 PM Patrick Callahan <[email protected]>
wrote:

> Is anyone considering working on developing migration documentation in the
> near future?
>

> Who are the likely players?
>

I'm not an aircraft developer, but I wrote a very quick guide here for what
is required:  https://wiki.flightgear.org/Howto:Convert_from_AC3D_to_glTF

I expect there is more to do, particularly for more complex aircraft.  One
key difference is that we want to avoid having aircraft-specific Effects.
So if there's an effect that folks want for an aircraft we really want to
built it into the fgdata HDR effects.

On Tue, Jun 2, 2026 at 3:24 PM Alex Barrett <[email protected]>
wrote:

> I gave that a go and the good news is I was able to restore textures!
>
> The issue seems to be that the gltf format requires different
> positioning/animation, or maybe just passed in a different format and I
> can't find any information about how that might be? An example of an
> aircraft that, in .ac format, works fine apart from the textures, once
> exported to gltf with PBR compatible textures ends up looking like it's
> just come out of a blender (which it did...but not that one)
>

Tl;DR - you need to do a transformation on the animations in gltf as the
axes are different.  See document referenced above.

Are we going to need to look at redoing all the aircraft we maintain
> entirely in terms of models and animations?
>

If you want them to work properly in PBR/HDR the textures are going to need
to be re-done, shaders updated, and animations adjusted.

Updating aircraft to use gltf is going to be a bit of work.  However, one
of the advantages of gltf is that rendering in Blender should match
rendering in FlightGear.  So aircraft developers should be able to do a lot
more developement in Blender directly.  Longer term, we will hopefully
extend this to include animations.

Also if we're using models in gltf format does that mean we won't be able
> to fly with those running older versions of FG via multiplayer as
> presumably they won't be able to see the models.
>
We'll have to produce packages with aircraft still in .ac format for the
> multiplayer model if we're going to maintain backwards compatibility with
> other versions online? That feels like quite a lot of work for many
> developers that we could probably do with putting rather a lot of effort
> into making sure people are aware and able to have time to discover the
> necessary work required.
>


The aircraft identifier sent over MP is the .xml aircraft model file.  So
provided that filename stays the same (and we will probably use different
branches of fgaddon or aircraft repos for this), then each client will
render their own version of the aircraft locally.

On Tue, Jun 2, 2026 at 3:32 PM Alan Teeder wrote:

> Assuming this is the Bell  UH1 from FGaddon I did a quick test with next.
> The aircraft, including panels looks OK. This error message is repeated
> continuously :-
>
> [sentry] ERROR LOG: Nasal runtime error: nil used in numeric context
>   244.40 [ALRT]:nasal        at
> C:/fg/fgaddon/Aircraft/UH-1/Nasal/rotorwash.nas, line 34
> [sentry] ERROR LOG:   at C:/fg/fgaddon/Aircraft/UH-1/Nasal/rotorwash.nas,
> line 34
>
I suspect that may be something to do with Effects that no-longer exist on
'next'.

-Stuart

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