Re: Shaders & Textures in Next

Thank you, Stuart!

I'll have a dig through that, convert a few aircraft over the next few
weeks and add anything I can find useful to the guide that might help
others.
All the best,
Alex

On Tue, 2 Jun 2026 at 15:55, Stuart Buchanan <[email protected]> wrote:

> 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
>

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