Re: [Flightgear-devel] Integration of the new subsystem design and the OSG scene graph management.

[James T. <zak...@ma...>]

> On 28 Apr 2016, at 11:14, Edward d'Auvergne <tru...@gm...> wrote:
> 
> = Possible solution =
> 
> I've been thinking about this since the tagging of 2016.1.1, and the
> belated report that precipitation was also broken.  I now have an idea
> for a design that might solve this problem.  This is however rather
> invasive, so there might be a better way.
> 
> Firstly I would like to make FGScenery the sole manager of OSG branch
> creation and destruction.  I.e. all scene_graph->addChild() calls are
> brought into the scenery manager.  I think this would simplify the FG
> OSG implementation by centralising and standardising branch
> management.

That’s 100% a good idea, except that maybe we shoudl then rename FGScenery to SceneGraphManager or similar, since it will own many non ‘scenery’ pieces such as AI models, weather and so on.

Another option is to make FGRenderer the optional piece - I started doing some work this direction in December last year. I.e without FGRenderer there is no rendering at all, and hence no scene-graph.

> Secondly, each of the subsystems that manage a branch via their
> update(dt) method would be modified to run happily both in the
> presence and absence of the scene graph branch.  This may require more
> work, for example testing the state of the branch and running
> initialisation code, e.g. the remnants of init(), if an uninitialised
> branch is encountered.  This may introduce latency, but this should
> only be encountered on start up or reset.
> 
> Importantly, this design would enable subsystems to run in full
> isolation, in a stand alone mode.

I think that’s okay but I would prefer that scene-graph updating was a new, separate method distinct from update().

Eg:

	virtual void SGSubsystem::updateDisplay() { }

(Or ‘updateVisuals’ as preferred)

Actually, we should really do with with subclassing, making an SGDisplaySubsystem with:

	virtual void initVisuals();
	virtual void updateVisuals();
	virtual void shutdownVisuals();

With the expectation that the manager layer (FGScenery or FGRenderer) calls initVisuals / updateVisuals / shutdownVisuals if it exists.

This also forces the implementation of each subsystem to distinguish simulation pieces (modifies properties) from display pieces (reads but hopefully does not modify properties, modifies OSG state)

How does this sound?

Kind regards,
James