20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
→Implementation
m (→Implementation) |
|||
| Line 134: | Line 134: | ||
== Implementation == | == Implementation == | ||
{{See also|Canvas View Camera Element}} | |||
Most of the required [[PagedLOD]] work (involving the tile manager in SimGear) has been recently completed - so there isn't too much missing in terms of refactoring on the SG side - primarily, you'll want to look at the "view manager" in $FG_SRC/Viewer and identify "singleton" use-cases there. | Most of the required [[PagedLOD]] work (involving the tile manager in SimGear) has been recently completed - so there isn't too much missing in terms of refactoring on the SG side - primarily, you'll want to look at the "view manager" in $FG_SRC/Viewer and identify "singleton" use-cases there. | ||
{{PatchAvailable|url=https://forum.flightgear.org/viewtopic.php?f=71&t=23929#p317448}} | |||
* First of all, you'll have to replace the existing viewer with a single CompositeViewer - FlightGear's view manager is property-controlled, and there's currently the hard-coded assumption that there's only ever a single active MAIN view (other supported views are SLAVE views, i.e. slaved to the main view). | |||
* You'll find dozens of references to something like '''globals->get_view_mgr()''' in quite a few places demonstrating the underlying assumption. | |||
* So just change the function's signature and add an optional index, defaulting it to '''0''' - that way, you won't have to touch all the places wanting to have the single main view. | |||
{{Note|For starters, it would also make sense to disable the splash screen, multi-threading, and scenery/terrain loading entirely, just to have something really basic working and then take it from there (i.e. use --disable-scenery, or refer to the [[Minimal Startup Profile]]).}} | |||
Once that is working, it comes down to trial & error, i.e. testing multiple independent viewers, each having their own instance/access to the tile manager - the work itself is well understood and pretty straightforward, and pretty much all core developers agree that this is a worthwhile thing to aim for - it's just not currently being prioritized or being worked on by anybody else as far as I am aware. | |||
If you're interested in seriously pursuing this, you'll want to look at the CompositeViewer example in the OSG source tree, and read up on discussions about CompositeViewer coding on the OSG list. | |||
For the SG/FG side of things, the aforementioned wiki articles should be pretty comprehensive already - and then you'll probably want to get in touch with fellow FG developers using the FG developers mailing list. | For the SG/FG side of things, the aforementioned wiki articles should be pretty comprehensive already - and then you'll probably want to get in touch with fellow FG developers using the FG developers mailing list. | ||
Depending on your degree of familiarity with OpenGL/OSG coding, you could have a basic version of this running within 3-4 weekends - but I guess it might take at least another 4-6 weeks of spare time coding to actually tease out all the hard-coded assumptions about having a single main view only. | Depending on your degree of familiarity with OpenGL/OSG coding, you could have a basic version of this running within 3-4 weekends - but I guess it might take at least another 4-6 weeks of spare time coding to actually tease out all the hard-coded assumptions about having a single main view only. | ||
The other issue is getting your work reviewed, i.e. committed upstream, which is known to be a particularly long, tedious and painful process - especially for anything non-trivial that may possibly break critical parts of the simulator - which is why it's a good idea to start networking early on, i.e. by discussing this work way ahead of time and getting people involved to provide feedback - which may involve working through a gitorious topic branch. | The other issue is getting your work reviewed, i.e. committed upstream, which is known to be a particularly long, tedious and painful process - especially for anything non-trivial that may possibly break critical parts of the simulator - which is why it's a good idea to start networking early on, i.e. by discussing this work way ahead of time and getting people involved to provide feedback - which may involve working through a gitorious topic branch. | ||
The underlying PagedLOD work in SimGear work is generally understood to be vital for other parts of the simulator, so anything related to this should also be appreciated. | The underlying PagedLOD work in SimGear work is generally understood to be vital for other parts of the simulator (especially better multi-threading and LOD support), so anything related to this should also be appreciated. | ||
== Related == | == Related == | ||