Consider enabling antialiasing

[andreasfranke1]

Describe what is missing or deficient and why it should be included or improved.

See this comparison for MSAA 8x enabled:

The thing about disabled antialiasing is that the orbit lines tend to flicker a lot when the camera is not locked relative to the orbit. An option in the settings to enable antialiasing (you can set antialiasing during the game run: https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-property-msaa-3d, more info on antialiasing here).

If this is a simulation or planetarium "content" proposal, describe how the content should appear and how users should interact with it.

No response

If this is a "code" or "development platform" proposal, describe how developers will use the new system. Provide detailed API if possible.

No response

If applicable, provide implementation code, pseudo-code, mock-ups, diagrams, or orbital maths. Do you have any helpful tips or gotchas to watch out for?

No response

Which of the following describes your feature? (1) A feature or content improvement for our Planetarium. (2) An improvement for game/app developers that should be in our core repositories. (3) An improvement for game/app developers that should be an optional addon.

This could either be only for the planetarium or in the core repos already. I can imagine many devs wanting this since it makes things look smoother a bit.

[charliewhitfield]

These are now in-app runtime options in the Options popup. See commit.

Note: I experienced a crash while using 4x MSAA and directional shadow size 16384 (now also an options setting) and moving about Saturn with its heavy shadow detail. The shadow detail might be the heavier load here, with the combo too much. (My AMD driver is also 1.5 years without update.) Keep us posted on any crashes you experience.

[andreasfranke1]

I will, thanks!

[charliewhitfield]

Reopening in case anyone notices that AA options don't fully fix orbit lines.

The AA settings might help with noted flicker, but they can't really fix alias effect for an opaque line. The lines are required to be opaque (unshaded) now for the mouse-over fragment id system to work. This will change in the future when Godot's Compositor is fully implemented. When that's done we'll have CUSTOM0, CUSTOM1, etc., channels that we can write to from id shaders instead of ALBEDO. Then we can have non-opaque lines with an AA line shader.

[charliewhitfield]

There really is no way to AA a line drawn using Mesh.PRIMITIVE_LINE_STRIP. You're stuck with 1 pixel width; line_width settings aren't exposed by Godot because they are totally unreliable across renderers and GPUs. Bottom line I think is that the line primitive is only barely supported at all. It's a holdover from early video game line graphics. The modern approach is to double pixel count and render a ribbon. I hesitate to do that for our 70000 asteroids. But that gets you control of width, so edges can then be alpha softened with an AA shader.

[charliewhitfield]

Note new Godot feature coming in 4.8. It's not directly on topic here, but I think the new feature will allow easy implementation of an orbit "trailing" effect. I'll probably revisit orbit lines when this is in release stage. I think what we can do is implement IVPathVisual using a mesh ribbon rather than PRIMITIVE_LINE_STRIP to solve aliasing for these lines. That's reasonable for 100s of IVBody instances.

IVSBGOrbitsVisual draws the 10000s or 100000s of asteroid orbits and should remain as PRIMITIVE_LINE_STRIP, so probably can never be improved for aliasing.