Poor performance while flight planning for extended periods of time around bodies with many moons

[al2me6]

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.

[eggrobin]

(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.)

[eggrobin]

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.

Principia/ksp_plugin_adapter/ksp_plugin_adapter.cs

Lines 2246 to 2263 in 652152e

	var colour = celestial.orbitDriver?.Renderer?.orbitColor ??
	XKCDColors.SunshineYellow;
	if (colour.a != 1) {
	// When zoomed into a planetary system, the trajectory of the
	// planet is hidden in stock (because KSP then draws most things
	// in the reference frame centred on that planet).
	// Here we still want to display the trajectory of the primary,
	// e.g., if we are drawing the trajectories of the Jovian system
	// in the heliocentric frame.
	foreach (CelestialBody child in celestial.orbitingBodies) {
	colour.a = Math.Max(
	child.MapObject?.uiNode?.VisualIconData.color.a ?? 1,
	colour.a);
	}
	}
	if (colour.a == 0) {
	continue;
	}

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.

[eggrobin]

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).

[eggrobin]

Brought back to our attention by #4153.

We use two different angular resolutions in Principia:
To choose whether we plot a trajectory to start with, the resolution:

Principia/ksp_plugin_adapter/plotter.cs

Lines 158 to 161 in 68853a6

	// The angle subtended by the pixel closest to the centre of the viewport.
	double tan_angular_resolution = Math.Min(
	Math.Tan(vertical_fov * degree / 2) / (camera.pixelHeight / 2),
	Math.Tan(horizontal_fov * degree / 2) / (camera.pixelWidth / 2));

With a 60 degree FoV, that would be 1.3 arcmin on my laptop, 0.88 arcmin on childeric, 2 arcmin on belliniano (so the beefiest machine of the lot also gets the least work to do).

For plotting,

Principia/ksp_plugin/interface_planetarium.cpp

Line 93 in 68853a6

/*angular_resolution=*/0.4 * ArcMinute,

This is a slightly finer resolution than the diffraction limit. It notionally corresponds to 20/8 vision. It is also finer than any screen I have.

Even using the screen resolution as our angular resolution is probably overkill, but this is ridiculous and affects performance.