From: James T. <ja...@fl...> - 2020-04-07 19:28:52
|
> On 7 Apr 2020, at 18:37, Fernando García Liñán <fer...@gm...> wrote: > > Sounds great. Just a few comments related to the compositor: > > On Tue, Apr 7, 2020 at 1:46 PM James Turner <ja...@fl...> wrote: >> And we can consider making tooling (scripts, etc) to help with updating aircraft to work on ’next’, eg if there’s changes in Effects needed to work with the compositor. > > Currently only aircraft that have custom shaders require the most work > to port, but to my knowledge those are the best developed and under > active development, so I can individually help aircraft devs and even > study if any of the features for which they decided to create a custom > shader can be made default. > > I can also provide a script to port Rembrandt lights to the "standard" > SGLight syntax, but I recommend manual tweaking as they don't work > exactly the same, so a 1:1 conversion won't look as good. > > There are other things like optimizing for shadow mapping, but then > again only the most complex aircraft will need to take care of > optimization so I can help with that, one by one. Still, the > Compositor wiki article provides some pointers. Great, ti sounds like we already have more tooling, and fewer things to change, than I realised, so that is excellent news. > > Another issue is the model-combined situation. Currently the normal > map is optional so people need to paste the <generate> block and the > shader attributes to every effect that inherits from model-combined. > This is not forwards compatible as future rendering pipelines won't be > able to use normal mapping (there are only three techniques currently > being pasted, see > http://wiki.flightgear.org/Howto:Add_effects_to_an_aircraft#Using_model-combined-deferred). > Right now I've chosen to be backwards compatible so I haven't made any > changes to model-combined, i.e. we still use techniques 4 and 7. If we > decide to be forwards compatible we will need to make every model that > doesn't use normal mapping use something else other than > model-combined, consequently breaking backwards compatibility. This > change can be made trivially with a script, but I guess this can only > be done on fgdata and fgaddon. Any comments on this backward vs. > forward compatibility are appreciated. > I would definitely says that after 2020.2 is the right time to choose forwards compatibility over backwards compatibility. Especially if we can script it. Essentially I’m assuming there will be enough divergence across the 2020 and following releases, that we’re better to take the hit and fix any structural issues we can, within reason. Ideally we will also end up with a ‘migrate_aircraft.py’ which can be trivially run on FGAddon to convert un-maintained / un-developed aircraft from 2020 to whatever changes are needed. But I think we’ll review that as the post-2020 features develop, and we see what things actually break, what can be kept working without compromising forwards compatibility, and so on. Maybe it ends up being quite minimal changes for many straightforward aircraft, which obviously would be ideal. Kind regards, James |