Show/hide inner edges on hover and improve spline performance

This release incorporates the changes by @falko17 from pull request #622.
Builds for Windows and Linux are available below.

Details

This implements a new edge layout option for code cities that, when activated, also fades in edges connected to inner nodes of the hovered node.

While this closes #531, it should be noted that showing/hiding a lot of edges at once causes a big performance hit, regardless of whether Buildup or Fading is used as animation kind. The best example for testing this is hovering over the root node, as this causes all nodes to be shown. This has yet to be investigated before merging.

Performance Improvements

Performance has been improved (while constructing/destructing edges) by about 130%.
Framerates were previously at ~5 FPS while animating edges, and are now at ~13 FPS for Buildup animations and ~40 FPS for Fading animations.

The following was implemented to improve performance when meshes are updated or created (SEESpline:CreateOrUpdateMesh):

• When the color of the edge needs to be changed, only UpdateMaterial() is invoked, as it is unnecessary to rebuild the entire mesh in that case.
• The lists' capacity has been specified, so that it doesn't have to be resized when new items are added.
• The lists have been changed to arrays, as they are converted to arrays in the end anyway and are of fixed size.
• The three separate for-loops over tubularSegments have been combined into a single loop.
• All loop-independent calculations (including partial calculations) have been moved outside the inner loop. This had the biggest impact, as the inner loop body is executed very often.
• Sine and cosine values per inner iteration j are now pre-calculated instead of executed as part of the inner loop.

Open Problems

The following has also been commented in SEESpline:404. (See 4b8c3a0.)

We should strive for at least 30 FPS rather than 13. Looking at the profiler, I see at least two possible avenues
for further optimization:

1. The biggest performance hit comes from the fact that we have to interop with the native C code, specifically that we have to convert a lot of objects back-and-forth between C# and C data structures, and that we have to do so within the unoptimized interop code.

   • One solution may be to move this part into C code, as it uses no Unity-specific code. We would thus avoid those interop performance problems.

2. The other big performance hit comes from the many vector operations we have to do, such as the normalization in the innermost loop. While this is unavoidable, note that the loop is heavily parallelizable – the only dependency between iterations is the index variable, which can be easily computed in each iteration.

   • One solution may be to parallelize this loop. We could either use Unity's "Parallel jobs" system (https://docs.unity3d.com/Manual/JobSystemParallelForJobs.html) or if we want to get especially fancy, we could use the GPU to do the calculations, using Unity's "Compute Shaders" (https://docs.unity3d.com/Manual/class-ComputeShader.html). While the latter is most likely much more efficient, it is also likely more complicated. Another open question is whether we want to parallelize not only across spline segments, i.e., the mentioned loop, but also across splines themselves (since quite often, multiple spline operations are carried out at the same time).

Results

Together with @msteinbeck, I have implemented option 1 in TinySpline. While the code itself and tests are done, we weren't able to test the implementation in SEE yet, as generating bindings to C# proves to be a bit troublesome. This is also the reason why the change has not yet been merged into TinySpline.

Additionally, I have (tried to) implement option 2, using Unity's Job system to parallelize the job per spline. However, I did not notice any increase in FPS, either because the job system overhead is too big (one job is created per spline—the job system may not be designed to handle such a large number of jobs) or because I did not implement the multithreading correctly, which is also a real possibility. However, multithreading will probably not solve all of our problems anyway, as Unity does not (seemingly) support multiprocessing, that is, distributing the threads over multiple CPU cores. Instead, we will probably have more luck with approaches like LOD, or not rendering all edges when too many are on screen (as users would be unable to discern them anyway).

In any case, performance improvements like that are outside the scope of this PR. For this specific feature (animating inner edges), I would simply advise using the "fading" animation kind, which does not decrease FPS at all. With this in mind, we could merge this PR (as it originally only pertained to #531) and include the TinySpline changes in a later PR, once they are merged into TinySpline's master branch.

---

See original pull request for details.

Update OpenAI package

This release incorporates the changes by @falko17 from pull request #621.
Builds for Windows and Linux are available below.

Details

• The new OpenAI package 5.0 is used. This necessitated referencing a new assembly in SEE.asmdef. Additionally, the prompt has been slightly edited to use cheaper tokens, as the model behind gpt-3.5-turbo has also been updated by OpenAI to be more responsive to prompts.
• Update to the new Unity version 2022.3.3f1.
• Test coverage reports will be uploaded when a PR is merged into master.

---

See original pull request for details.

Introduce one single parameter for all animation durations

This release incorporates the changes by @falko17 from pull request #620.
Builds for Windows and Linux are available below.

Details

This changes all operator calls to take factor instead of duration as a way of controlling the animation speed.
This has the advantage of letting the user decide a common base animation duration (via the SEE City configuration in the editor) that is then multiplied with a given factor for each animation.
Setting the duration to 0 disables animations completely.

This closes #569.

---

See original pull request for details.

CI Hotfix: Working build releases

This release incorporates the changes by @falko17 from pull request #618.
Builds for Windows and Linux are available below.

Details

This fixes the following problems:

• Builds were unnecessarily compressed even if they were not going to be uploaded.
• Builds were cleaned before the release steps, leading to missing ZIP files.
• Write permissions for the release step were missing.
• A setup dependency for the release step was missing.

After this is merged, any merged PR should result in a new release being created afterward, re-using the PR title and description, along with a built version of SEE for Windows and Linux.

---

See original pull request for details.