Talk:CompositeViewer support: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(→‎View Creation API: new section)
Line 34: Line 34:
It would however make sense to split up the implementation, i.e. so that the underlying compositor and the view can be created separately via two explicit fgcommands - there could still be a a higher-level fgcommand to call those two automatically, but otherwise it's probably easier to set up the whole thing in separate stages/steps, and also much cleaner code-wise.
It would however make sense to split up the implementation, i.e. so that the underlying compositor and the view can be created separately via two explicit fgcommands - there could still be a a higher-level fgcommand to call those two automatically, but otherwise it's probably easier to set up the whole thing in separate stages/steps, and also much cleaner code-wise.


If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST)
If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code (basically, indirect mode vs. immediate mode).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST)

Revision as of 11:37, 30 November 2020

Cgdae (talk) 12:23, 5 October 2020 (EDT) Apologies Hooray but i've removed the large note about OSG-3.6, as it was rather dominating the page and messing up the layout quite badly. I've put the information in amongst the other information about OSG.

View Creation API

Cquote1.png we could use XML or a property tree to represent all the properties of a new view - Nasal is perfectly capable of constructing either in response to a 'Create View' dialogue, and passing to SviewCreate() in the normal way.
— Julian Smith (2020-11-29 19:55:56). [Flightgear-devel] Sview?.
(powered by Instant-Cquotes)
Cquote2.png


Canvas based GUI dialog to create CompositeViewer views dynamically using a configurable Compositor pipeline.

Indeed, I think this is a very good point, and I believe it will present the least amount of work: As mentioned elsewhere, I have been toying with a simple Canvas based UI for the creation of views using the parameters that Fernando laid out at Canvas_View_Camera_Element#Create_a_Canvas_Element_subclass.

Note that this isn't intended to be a/the definite UI - but rather a simple way to set up views using a GUI, so that people (early-adopters) can more easily experiment with these features, and hopefully also help with wider testing and provide better bug reports along the way.

While it would obviously be possible to create a fancy Nasal (cppbind) or C++ specific API, I have come to the conclusion that it makes sense to go only through the fgcommand layer, passing a SGPropertyNode/props.Node structure with key/value pairs.

That way, we can trivially support PropertyList/XML files, but also views that are specified directly, as part of a sub-tree (e.g. for the CanvasView element).

Besides, this means that any UI/frontend can invoke the corresponding back-end code easily:


It would however make sense to split up the implementation, i.e. so that the underlying compositor and the view can be created separately via two explicit fgcommands - there could still be a a higher-level fgcommand to call those two automatically, but otherwise it's probably easier to set up the whole thing in separate stages/steps, and also much cleaner code-wise.

If the fgcommand/SGPropertyNode approach is used, we automatically end up with support for input files and dynamically-configured views using the same underlying code (basically, indirect mode vs. immediate mode).--Hooray (talk) 06:34, 30 November 2020 (EST)