mockingbirdnest
Poor performance while flight planning for extended periods of time around bodies with many moons
For example, severe performance degradation is experienced while fine-tuning Jupiter encounters due to the amount of moon trajectories visible on-screen.
A potential solution, as first mentioned by N9Gaming on Discord, is to make trajectories hideable: https://discord.com/channels/319857228905447436/480397772248580098/837123055880503307.
(Note: this is a tracking bug opened at my request so that we don’t forget about this performance issue; it is unlikely that we will do something about this in the near term. As an example of a concrete effect, Reach’s save for the « all planets flyby » video only has a manœuvres up to July 1977, i.e., for the inner solar system trajectory—whereas there are TCMs into the early 80s—; I suspect it was impractical to plan the outer solar system TCMs within the same flight plan.)
First thing I am noticing when investigating this: the following logic, which tries to piggyback on stock to draw only a subset of the celestial trajectories, is broken. We now try to plot the trajectory of every body, spending a while considering, e.g., the trajectory of Io while zoomed on Neptune.
I suspect the change to the value of colour in #3135 is the culprit, since this used to work.
https://github.com/mockingbirdnest/Principia/blob/652152ea70325d4f53fa39ff1b23e36138637861/ksp_plugin_adapter/ksp_plugin_adapter.cs#L2246-L2263
This is obviously disastrous in terms of performance.
The stock logic was never really appropriate, and as we have just seen, relying on stock is a bit brittle; we should try to come up with our own criterion for ignoring celestials.
PlotRP2Lines (the C# function that takes the already projected points and calls UnityEngine.GL.Vertex3 on them) seems to take 30 ms for 10000 points on childeric (scaling linearly with the number of points).