uni-bremen-agst / see Goto Github PK

Can be reproduced by the graphs generated by Bauhaus.

Unity's serialization has difficulties with serializing cyclic data structures. All graph data structures
are highly cycle (GraphElements are contained in Graph but also have a graph attribute; Node has a parent Node and Children nodes as well as incoming and outgoing edges; and Edge has a source and target Node). Unity's serialization will stop serializing after a certain depth and, hence, information
will be lost. The problem also causes very long start up times when we start the game from within the
editor.

A candidate for solving this issue my be the Odin serializer.

The inner circle can be become quite large and wastes space. We need to seek better layouts.

We want to add other metrics to the nodes (and possibly edges) by reading them from CSV
files, where one column represents the linkname and all other columns additional metrics.

We want the user to add new edges during the game. They must have a visual analogous to automatically created edges and must be added to the underlying graph, too. For the latter, they must have an edge type.

Evolution animation is currently not working anymore.

The cubes for the nodes currently have only a wall texture. Instead, we may want to decorate them by other things such as windows (for the number of public entities) and the like. They may also glow as a sign of recent changes.

Currently, each spline has a fixed buckle factor of 0.5f: https://github.com/uni-bremen-agst/SEE/blob/master/Assets/SEECity/Layout/BSplineFactory.cs#L131. It should be a configurable option. Also, I suggest to use 0.85f as default.

Existing graph edges drawn by Line Renderers should be animated similar to dynamic calls in Torben's code (he uses spheres along the line; but other option may be considered, too).

When a GXL file is loaded, the node types contained therein are listed in the inspector. They can then by selected by the user. Only those nodes having one of the selected node types are actually drawn. This works for single graphs, but not for the animation of a graph series (evolution).

We want to give the user the chance to select the node types retrieved from the very first graph in the series. Those node types selected by the user will then define the set of node types to be visualized for the whole graph series.

Hint: The EvolutionScene has already the necessary settings for rendering an evolution. Use that instead of the MainScene.
The button "Load First Graph" in the Inspector let's a user load the first graph in the graph series. Its node types are then listed. They can be checked on or off, but that decision is currently ignored. The code run by "Load First Graph" is the starting point for implemented the requested feature.

Note: The assumption here is that no new node types are later added in the history.

Each building is placed in a garden. By design, the garden is separated into four different sections. These sections could be colored along the lines of Donut charts to present additional information on the building.

The inner circle of a subsystem is currently unused but may be a place to show additional aggregated data on the subsystem as a heat map, e.g., degree of erosion indicators.

We need a few improvements to the evolution animation relating to the code structure and
the animation. Regarding the code structure, we want the code to be better integrated in
the existing SEE code. Regarding the animation, we want more visible clues that something
has changed. Currently, changes in game objects far from the camera are hardly visible
or even not visible at all in case of occlusion.

The visual must disappear and the deleted node/edge must be removed from the graph.

Note: While selecting a node is already possible, selecting an edge is not yet implemented.

To study how users traveled in a city, we need a visualization of their paths gathered at runtime.

We want the user to add and scale new nodes. We need to name them afterwards. They must have a visual and must be added to the underlying graph, too. For the latter, they must have a node type. The shape of the visual must be determined by the user.

We want to support multiple hardware (head-mounted displays with controllers, keyboard,
mouse, touchscreen, etc). Currently, interaction is handled at various places in the code.
We need one central component that receives the inputs and distributes it to all other
components handling the input. For this reason, we need a unifying framework of
all kinds of user interactions via different types of hardware.

Unity offers different kinds of input systems we could base our application-specific framework on:

• classic UnityEngine.Input
• com.unity.inputsystem: it is a new alternative to the classic UnityEngine.Input and claimed to be more extensible and customizable; here is an introduction
• XR Interaction Toolkit; it is intended for virtual and augmented reality interactions; the Valve Index, however, is not yet supported.

We want the user to be able to move a node from one place to another.

If a node is moved within its city, we need to move its incoming and outgoing edges along with it.

TinySpline 0.3.0 is about to be released. Features relevant for SEE:

• Spline evaluation now has logarithmic time complexity. This may improve the build time of cities.
• A memory leak in the C#-Binding was fixed.

Large graphs may be loaded but they cannot be visualized anymore. We need a way to reduce
such very large graphs.

We could add a function that allows one to cut all descendants of nodes of a given node type
from the graph. Metrics for the nodes at which descandants are cut could be added that count
the number of descendants that were cut.

We currently have only a flat rectangle packer. As an alternative to TreeMaps (which have a fixed size that must be specified upfront), we would like to extend the rectangle packing to whole node hierarchies. This new layout would yield the original CodeCities by Richard Wettel and Michele Lanza.

Decorate the game objects with the software-erosion indicator icons.

Method Node.getChildren() should return the children in alphabetic order based on their Source.Name. This gives us a deterministic presentation and allows one to compare similar subsystems more easily.

We want to make the reflexion analysis available at run-time during the game. The user needs to model the architecture and map the implementation components onto the architecture components. The incremental reflexion analysis already implemented in #410 needs to provide immediate feedback.

Note that this serves as a meta-issue, keeping track of the general progress of the Reflexion Analysis as well as several sub-issues.

Progress

This section tracks the current progress and planning on implementing Reflexion Analysis in gameplay. Entries written in italics have low priority and may be moved to follow-up issues.

• Color nodes according to which reflexion subgraph they belong to (implementation vs architecture).
• Upon dragging an implementation node on an architecture node:
  • Run the incremental analysis step, which adds a MapsTo edge.
  • Move the impl. node to the arch. node and size it down...
    • ...moving its child nodes along with it.
    • ...moving its edges along with it.
      • Edges should also be animated while they're moved along.
      • Colors should similarly be animated when changing edge states.
      • As should node placements.
  • #448
  • #449
  • #450
    • #451
• #440
• #442
• Handle all events sent out by the incremental reflexion analysis in SEEReflexionCity, modifying the graph and displaying results in a suitable manner (see below).
  • Keep a mapping of propagated edges to the edges they were originally propagated from so that the original edges can be visibly modified.
• Display absences, convergences and divergences...
  • ...by modifying the color in the LineRenderer for the SEESplines.
  • ...by modifying the color in the MeshRenderer for the SEESplines.
    • Test this change in the meshes—at the moment, meshes seem only to be used in the evolution.
  • #507
  • #443
  • #444
• We need to make sure we don't break any integration with the action history or network synchronization:
  • #445
  • #446
  • #447

Kevin and David are to implement architecture modeling and mapping. Given that we want
to be able to check the architecture against the implementation using the reflexion analysis.

Bauhaus uses GVL to load and store layout information. It would be nice to import layout
data from Bauhaus (for instance, for architecture descriptions). We also want to load and save
layouts, so why should we invent yet another different format. We may be able to reuse GVL.
The only problem I see is that GVL is inherently 2D while we need 3D layout information. Moreover,
edge layout is likely neither captured in GVL.

As an alternative, we could store the layout in the GXL. Then the layout should be stored and read and respected by GraphRenderer.

We need to be able to create a Graph both within the Editor as well as during the game (the latter for the reflexion analysis, for instance). We need to serialize the whole graph in its entirety.

Currently, Nodes will be serialized only through the NodeRefs attached to the game objects
using Odin's serialization mechanism, but their edges will not be serialized.

A new Unity version 2019.4.4f1 LTE is out. This may be a major step that is why we use a separate branch for this upgrade.

To better support the animated evolution of a city, we need to refactor the layout algorithms
(anything deriving from ILayout) as follows:

• replace long parameter list of layouts by single configuration parameter of type GraphSettings

• layout algorithms receive the game objects as input and yield their positions and scalings; they
  do no longer actually add the game objects to the scene

• layouting of nodes and edges should be separated from each other

• in the near future, it should be possible to implement incremental layouts where new inner and
  leaf nodes can be added, deleted or scaled differently

We want to view our city in VR using HTC Vive and Leap Motion.

We want a minimap that gives an overview of the scene as a bird's eye view.

Multiple players should be able to use the application online, together. Players should be able to see each other, manipulate the world and see manipulations of the world, that other players did. Voice chat should potentially be supported.

The city should be scalable by the user. Additionally, the table should act similar to a window, such that parts of the city, that do not fit onto the table are be hidden. The user should be able to move the city around smoothly.

Aufgetreten mit dem EdgeLayout Spline und der minimal_clones.gxl

IndexOutOfRangeException: Index was outside the bounds of the array.
SEE.GO.EdgeFactory.DrawEdges (System.Collections.Generic.ICollection1[T] layoutNodes) (at Assets/SEECity/GameObjects/EdgeFactory.cs:99) SEE.Game.GraphRenderer.EdgeLayout (SEE.DataModel.Graph graph, System.Collections.Generic.ICollection1[T] layoutNodes) (at Assets/SEECity/Game/GraphRenderer.cs:176)
SEE.Game.GraphRenderer.DrawCity (SEE.DataModel.Graph graph, UnityEngine.GameObject parent) (at Assets/SEECity/Game/GraphRenderer.cs:256)
SEE.Game.GraphRenderer.Draw (SEE.DataModel.Graph graph, UnityEngine.GameObject parent) (at Assets/SEECity/Game/GraphRenderer.cs:103)
SEE.Game.SEECity.DrawGraph () (at Assets/SEECity/Game/SEECity.cs:234)
SEE.Game.SEECity.LoadAndDrawGraph () (at Assets/SEECity/Game/SEECity.cs:197)
SEEEditor.SEECityEditor.SetUp (SEE.Game.SEECity city) (at Assets/Editor/SEECityEditor.cs:59)
SEEEditor.SEECityEditor.Buttons () (at Assets/Editor/SEECityEditor.cs:31)
SEEEditor.SEECityEditor.OnInspectorGUI () (at Assets/Editor/SEECityEditor.cs:19)
UnityEditor.UIElements.InspectorElement+<>c__DisplayClass55_0.b__0 () (at <455e94fe44aa49359a209950d8d8b123>:0)
UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)

Currently, the name of the subsystem is shown when in sight. It pops up all of a sudden. We might want to add a smooth animation so that is gets larger until it reaches its full extension.

The user wants to see the source code for a selected block (or edge).

In order to allow the player to select whose code window should be displayed, the following steps will be followed for now:

1. Refactor ShowCodeAction to work with multiple code windows.
   • Specifically, the active player should be saved in a field, and there should be a dictionary which associates each player (for now, a string suffices) to a list of CodeWindowSpaces.
     • Perhaps they should be in a serialized form, so they can be more easily sent over the network.
2. ShowCodeAction should then (for now) associate all open code windows with the local player in the dictionary.
3. Next, the CodeWindowSelectionMenu has to be implemented, which can be opened using TAB. This will extend SelectionMenu, and have two entries:
   - One called "None". This will do nothing as its entryAction.
   - One for the local player. This will cause the code windows saved in the dictionary for the local player to be loaded.
   - Both of these will have an exitAction which hides all of their code windows when it's called.
4. Now, another indicator for the bottom left corner can be implemented. For this, the existing ActionStateIndicator should be refactored. This will display:
   • The word "local" if the own code window is open,
   • The IP address of the player whose code window is open,
5. Once this works, the local code windows should be synchronized (sent to the server) whenever:
   • The active line number is changed
   • The active tab is changed. This also covers:
     • A new window (tab) is created
     • An existing window (tab) is closed
   • The last tab (or the panel itself) is closed.
   • Note that these events should only be sent to the server if the active code window belongs to the local player (i.e. the local player should not be able to remotely control other people's windows.) Local control is still possible, but won't be synchronized.
   • Concerning how the code windows are sent (serialized), the following is sent over the network:
     • Filename
     • Title
     • Active line number
     • Active tab
6. The other direction should be implemented: The events sent out by the server need to be handled by ShowCodeAction.
7. Finally, the other players need to be listed in the code window selection menu.
8. CodeWindowSpace should be called CodeSpace.
9. HasStarted should be used instead of manual null checks against objects which get initialized on Start.
10. GameObject name may be different across the network, so they should be attached to a fixed GameObject.

The user wants to onfigure a city at run-time, i.e., during the game.

The Knuckles Controller Input by Valve Index should be integrated uniformly to HTC Vive's controllers.

Co-ordinate system in layouting should be adjusted (Unreal vs. Unity).

EvoStreets should work with buildings, too.

EvoStreets should be combined with RectanglePacking.

Currently the layouts have direct access to the game objects they are to lay out. It would be
better to separate the creation of game objects from layouting. This way the layout algorithms
could be used in other contexts. It would also simplify the animation and the new hierarchical
layouting currently under way.

all
selected
unselected
incoming/outgoing/all of selected building
transitive closure (backward/forward/all)

This is a duplicate to issue #153 and will be removed.

The player should be able to add an annotation to an object. Additionally the player should be able to remove and edit existing annotations.

If a game object representing a graph node is hovered overed, its source name should appear above its roof. The user can specify the distance between the roof and the label in the inspector of the Unity editor.

We should be able to zoom in and out of inner nodes of underlying graph, in terms of the code city, of city districts. A partial implementation is already available. We need to complete it with the necessary interactions for all supported environments (VR, desktop, gamepad).

There are different alternatives to iTween, which is currently used, such as

• DoTween
• HOTween
• LeanTween
• GoKit

There may be others.

We need to evaluate those do decide on a suitable tween library for the long run. After deciding which one to use, we need to replace the current iTween calls by the newer library (if we decide to replace iTween at all).

Each GXL file containing the graph data and some metrics may have an extra CSV file that contains additional metrics for the nodes. In the animation of the evolution of graphs, these files are currently ignored.

Whenever a GXL file is read in, the associated CSV should be read in and its content applied to the node visualization (if the metrics in the CSV file are chosen to determine any of the lenghts or the color of a visualized node.

Note: These CSV files are optional. If a CSV file does not exist, the animation of the evolution should simply continue.

Note: The SEECityEvolutionEditor allows a user to specify the directory where the GXL files are located. All files in that directory are loaded in the alphabetic order. The CSV filename of a GXL file X.gxl must be X.csv so that we can relate the two.

The source-code location where to trigger the loading of the CSV is method SEECityEvolution.LoadData().

To experiment with different kinds of graphs, it would be useful to have a random generator
for graphs. The input parameters should be at least: number of nodes and edges and maximal depth of the node hierarchy. We also need settings for node and edge metrics. It may also be useful to have
control on the number of edges for inner nodes and leave nodes.

Currently, only a single type of edge can be treated as a hierarchical edge (Enclosing). We want multiple types (e.g., Part_Of, Defined_In, Belongs_To).

All layouts but BundledEdges alllow a user to draw the edges below the ground.
BundledEdges should allow that, too.

Allow a user to observe the execution of a software at the level of single source code lines. This work will extends Torben's visualization of dynamic call graphs. In addition to the calls, a user wants to see the executed source lines. For this, we need a visualization of source code including syntax highlighting.