adrian wrote in Wed Mar 26, 2014 5:53 am:They do better in the visual department (we would too if we had a team of dedicated people to optimize Fred's Rembrandt), but they're not so far ahead in core features. I think we have a couple very unique stuff. And we could have even more, if the powers that be didn't put a very high barrier for entry.
Actually, a couple of weeks ago we started "reverse-engineering" Rembrandt to better understand what's having such a massive impact on performance there , because its internals are not very well documented unfortunately. And "barrier to entry" is two-folded obviously - because some "obscure" features are inevitably also pretty complex to come up with in the first place.
Rembrandt itself is already much better documented than most existing FG features, FredB did a great job there - it stalling is certainly because of the lack of "internals" knowledge, i.e. the camera/renderer/rendering stages side of things.
The original "Understanding Rembrandt" effort got kinda stalled in the meantime admittedly. But based on working through the commits, as well as Fred's and Mathias' comments on the devel list, I do believe that Zan's "newcameras" work could (and probably) should be revived and generalized for this - that would expose all building blocks required for "deferred rendering", which would mean that those would not just be available to Rembrandt itself, but also to other effects/shaders, such as Thorsten's work (ALS et al).
But to be honest, I think if Thorsten were to decide that he wanted to take some time off from FG, we would also be facing a similar "technology lock-in", because most of his work also isn't really understood/maintained by others. So what we're dealing with here is not so much a "barrier to entry" per se, but instead the
bus factor.
We've seen some extremeley skilled contributors making sizable contributions without them ever documenting the internals, so that getting up to scratch with things later on may be next to impossible without spending a huge amount of time, that could be equally spent on re-designing certain features/systems.
This is something that we have actively worked to address in the context of Nasal/Canvas and efforts like the ND/MapStructure frameworks, i.e. those are now extensively documented, not just including "roadmaps" and "milestones", but also internal design stuff, including even step-by-step tutorials and coding examples - admittedly, this has taken up quite a bit of spare time, that could have just as well been spent "coding" - but given the wiki stats, we seem to be on the right track here, i.e. most of these articles have seen between 2k-8k views within just ~10-12 weeks, which is kinda impressive (some of our most popular articles "only" have seen 40k views in years!), but this also ensures at the same time that even if some of us were to disappear for a few months, people would still be able to pick up where we (TheTom, Philosopher, Gijs, me) left off, no matter if this means "maintaining" our existing code - or modernizing/replacing it completely.
In professional software development circles, writing documentation is a necessary evil, as is writing unit tests - in FlightGear, people prefer to spend their time doing "fun" stuff instead for understandable reasons. Then again, some of the main building blocks and key technologies in FlightGear were developed by people who obviously understood that having sufficient docs is at least as important for a feature to survive than the actual code, just look at architectural pillars contributed by people like David Megginson or Andy Ross - those are typically the same guys who were responsible for much of the original documentation targeted at core developers, no matter if it's through extensive use of doxygen comments or through dedicated design articles.
So the issue really is twofold, assuming that we are talking here about novel features like the radio propagation code, I fully agree that this would be great to have in FG as an option - but at the same time, I am wondering how much of its design is actually documented for fellow/future developers ?
Seriously, documenting and mentoring seems to scale particularly well around here, just look at the plethora of features conceived/implemented within the last 18-24 months, and all the stuff that people are currently working on, or look at the number of views that the TerraGear/WorldScenery 3.0 article has seen in just a few weeks (~250).
Some of our most active contributors spent little to no time ensuring that future developers will be able to continue their work - and that's a problem that will only really become obvious once someone is too busy with other aspects of their life to contribute (or even just back to answer questions).
Now, regarding Rembrandt in particular, we are only missing 2-3 Canvas enhancements to allow effects/shader guys to pick up where FredB left off - which are primarily, 1) camera support, 2) effects/shader support, and people have this working in various stages already, sometimes unrelated to Canvas (Zan's newcameras branch), and sometimes not yet fully integrated (e.g. the shader stuff). But generally it is foreseeable that additional rendering schemes (deferred rendering) could then be implemented by people without having to touch any C++ code.