Loading of Scenes, SceneElements and others

[Harald Scheirich]

There is currently a merge request under review that enables some additional functionalities for loading yaml (Runtime::addSceneElements and RunTime::duplicateSceneElemnts). It enables inclusion of other yaml files into a scene (semantically it acts as an #include, inside the scene file), but it also enables a duplication or cloning of one or more scene elements stored in a yaml file. These two work slightly different in the following manner 

addSceneElements

- adds loaded elements directly to the scene

- may refer to components that were already loaded

- may refer to components inside the file

- must not be executed more than once for the same file

duplicateSceneElements

- returns loaded elements

- must not refer to components that were already loaded

- may refer to components inside the file

- may be executed more than once for the same file

While this adds some needed functionality, the location of these function on Runtime was a much debated issue. This mail is to summarize some of the issues and to lay the groundwork for future improvements. The main reason to stick with the interface as was originally presented in the merge request is because of a few interdependencies that would have to be resolved before a cleaner version (as suggested by Paul Novotny) that is more conformant with prevalent style can be implemented. 

The current location of these functions is mainly driven by an current strict dependency between Framewrok::Scene and Framework::Runtime. There is a one to one relationship between the two of them. When SceneElements are added to the Scene, there is an assumption in the code (as signaled by the Scene constructor Scene(shared_ptr<Runtime>) that the runtime exists. The runtime currently when constructed creates a scene, and does not have a setter for the scene.

The suggested interface would have wanted a Scene::load(std::string) function, because of the assumptions that would have caused a scene to add its sceneelements to the runtime even when it was not the current scene.

An additional stumbling block is the use of the static registry inside yaml::convert for components, the addition of multiple loading functions required locking this structure, for an improvement of the interface we would like to move this registry into the scene in a way that localizes the registry to the scene therefore removing the need for the static structure. 

 

A third problem is how to deal with the duplication of scene elements for a consistent view it would be nice to enable the loading through a ->load() call on a structure, but the duplication supports multiple scene elements that are connected. 

Another question that came up is how to prevent small differences in the yaml file to confuse users in the system and how to keep the number of differnent "formats" down. This comes up when enabling the function SceneElement::load(). A single scene element in represented in YAML by a map

BasicSceneElement:

  Name: 

  ... 

A list of scene elements (in this case size 1) looks like this in YAML

- BasicSceneElement:

  Name

  ...

These are easily mistaken, and not compatible data types, the first is a map, the other a map inside a list, this would either require the user to make user they are calling the right load for the right file, or make us handle a larger number of cases to the loading of multiple scene elements is compatible with the loading of one scene element. 

As presumptive interface might look like this, this is pretty much the one from Paul's contribution here (https://www.assembla.com/code/OpenSurgSim/git/merge_requests/1489143?version=3#)

Scene:

load(std::string):

addSceneElement(std::shared_ptr<SceneElement>)

addSceneElements(std::vector)

addSceneElements(std::string)

addPrefab(Prefab)

SceneElement

load(std::string) // Flexibly deal with yaml '-' at the beginning, check against typename, or just serialize a scene element as a list of one

Prefab (Name TBD)

load(std::string) // Load a list o

Prefab* duplicate();

getSceneElement(std::string)

getSceneElements();

If I forgot something Paul, Ryan, Wesley or anybody please feel free to add

Harry

--

Harald Scheirich

Principal Software Engineer

Simquest Solutions Inc. 

hsche...@simquest.com