Talk:CompositeViewer Support

From FlightGear wiki
Revision as of 00:18, 5 December 2020 by Cgdae (talk | contribs) (Question about union trees)
Jump to navigation Jump to search

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)

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), 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)

SviewCreate() already understands much of conventional <view> specifications so that it can clone the current view. At some point we might want to introduce a new way of specifying views that can better make use of Sview's flexibilities compared to conventional views, e.g. with an alternative <sview> tag or similar.

But we might want to specify extra things such as customised heading/pitch/roll/zoom values etc. If we required the caller to add these extra things to the <view> specification, then the caller would have to either pollute the global /sim/view[]/ tree or copy it into a temporary tree and add in the required custom values.

So i wonder whether, rather than taking a single SGPropertyNode*, SviewCreate() should instead take a std::vector of SGPropertyNode*'s which it treats as a kind of union of trees. When the sview code looks for a particular tag such as z-offset-m, it would look in each SGPropertyNode* in turn until it finds a match. Thus the caller can override aspects of the default view by specifying an extra tree at the start of the list.

However if we think it's ok to require the caller (e.g. Nasal code) to modify a copy of a global /sim/view[]/ tree, then tree unions are not necessary. This would probably be conceptually simpler too.

Either way, i'll can try to implement something in next this weekend so that people can try things out soon.

--Cgdae (talk) 19:17, 4 December 2020 (EST)