90
edits
Changes
Jump to navigation
Jump to search
Line 46:
Line 46: + + + + + + + + + + + + + + + +
Talk:CompositeViewer Support (view source)
Revision as of 00:18, 5 December 2020
, 00:18, 5 December 2020Question about union trees
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)
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)
<hr>
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.
--[[User:Cgdae|Cgdae]] ([[User talk:Cgdae|talk]]) 19:17, 4 December 2020 (EST)
<hr>