20,741
edits
Understanding Rembrandt: Difference between revisions
Jump to navigation
Jump to search
m
→Internals
mNo edit summary |
m (→Internals) |
||
| Line 193: | Line 193: | ||
<li>in its current form, the setup/init logic isn't designed to be dynamically adjusted, i.e. many attributes are not yet exposed to properties/listeners, or only read during startup</li> | <li>in its current form, the setup/init logic isn't designed to be dynamically adjusted, i.e. many attributes are not yet exposed to properties/listeners, or only read during startup</li> | ||
<li>this is a common trait of C++ code that didn't quite progress beyond "prototyping" - it took Zakalawe almost 2 years to implement reset/re-init support in its current form </li> | <li>this is a common trait of C++ code that didn't quite progress beyond "prototyping" - it took Zakalawe almost 2 years to implement reset/re-init support in its current form </li> | ||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221229#p221229 | |||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Sun Oct 19</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|Both, Fred and Mathias, seemed pretty eager to adopt Zan's work back then:<br/> | |||
[https://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg36481.html https://www.mail-archive.com/flightgear ... 36481.html]<br/> | |||
[https://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg36486.html https://www.mail-archive.com/flightgear ... 36486.html]<br/> | |||
<br/> | |||
Meanwhile, we ended up with Canvas as an abstraction mechanism for FBO management via properties - so integrating Canvas would indeed be a logical choice, unrelated to any particular manifestation like ALS or Rembrandt - integrating these technologies would primarily mean that new features could be prototyped without necessarily having to customize the hard-coded renderer logic - including things like our hard-coded skydome for example, which could be implemented in fgdata space then - which would not just be relevant for efforts like Earthview (orbital flight), but also make other things possible that would currently require a fair amount of tinkering with the C++ code. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221229#p221229 | |||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |||
|author=<nowiki>Hooray</nowiki> | |||
|date=<nowiki>Sun Oct 19</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|I am not talking about Rembrandt and/or ALS in particular here - I am just seeing the main challenge being the lack of accessibility when it comes to required structural changes to the C++ code - regardless of the concrete renderer - the lack of Rembrandt maintenance, and the slow response whenever ALS requires C++ level changes, is primarily because the corresponding renderer code is not being maintained actively - moving this into fgdata space via effects and shaders is a logical thing to do, and will allow people like Thorsten (or yourself) to make corresponding modifications without facing a core development bottleneck when it comes to Rembrandt/FGRenderer or any other $FG_SRC/Viewer modifications.<br/> | |||
<br/> | |||
The CameraGroup.cxx file is basically begging to be refactored sooner or later. None of this needs to involve Canvas, it would just be a straightforward and generic approach to do so, but certainly not mandatory - Zan's original work was implemented using directly XML and the property tree - however, Canvas contains a few helpers to make this increasingly straightforward, requiring very little in terms of code (e.g. PropertyBasedElement as a container for subsystems implemented on top of the property tree). | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221229#p221229 | |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221229#p221229 | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||