Talk:CompositeViewer support: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Created page with "~~~~ 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 am...")
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[User:Cgdae|Cgdae]] ([[User talk: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.
[[User:Cgdae|Cgdae]] ([[User talk: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.
I've put the information in amongst the other information about OSG.
== View Creation API ==
{{FGCquote
  |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.|{{cite web |url=https://sourceforge.net/p/flightgear/mailman/message/37164487/
    |title=<nowiki>[Flightgear-devel] Sview?</nowiki>
    |author=<nowiki>Julian Smith</nowiki>
    |date=<nowiki>2020-11-29 19:55:56</nowiki>
  }}
}}
[[File:CompositeViewer-prototype-UI.png|thumb|[[Canvas]] based GUI dialog to create [[CompositeViewer Support|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 <code>fgcommand</code> layer, passing a SGPropertyNode/props.Node structure with key/value pairs:
<syntaxhighlight lang="javascript">
fgcommand("composite-viewer-create", props.Node.new({
}));
</syntaxhighlight>
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), as long as those are using the same format internally (which makes sense).
The low-level implementation would expect a corresponding SGPropertyNode structure, a higher level fgcommand could then provide an "option" or a "mode" to either specify an XML file on disk, or a property tree branch that already contains the required nodes. That way, the back-end would look the same, and we would only need to call readProperties() first whenever people want to use a file-based view declaration.
For the CanvasView scenario, that would mean that the CanvasView element would merely replicate/alias properties used by the CompositeViewer/Compositor systems, so that each element would get a property-based handle to the relevant modules.
Besides, this means that '''any''' UI/frontend can invoke the corresponding back-end code easily:
* [[QtQuick use in FlightGear|Qt5]]
* [[PUI]]
* [[Phi]]
* [[Canvas]]
* [[Nasal]]
* [[Telnet usage]]
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).--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 06:34, 30 November 2020 (EST)

Revision as of 14:19, 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:

fgcommand("composite-viewer-create", props.Node.new({

}));

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), as long as those are using the same format internally (which makes sense).

The low-level implementation would expect a corresponding SGPropertyNode structure, a higher level fgcommand could then provide an "option" or a "mode" to either specify an XML file on disk, or a property tree branch that already contains the required nodes. That way, the back-end would look the same, and we would only need to call readProperties() first whenever people want to use a file-based view declaration.

For the CanvasView scenario, that would mean that the CanvasView element would merely replicate/alias properties used by the CompositeViewer/Compositor systems, so that each element would get a property-based handle to the relevant modules.

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)