Devlog 5: Kerbal Gravity Program (KGRP)

KGRP is a mission planning tool I’m building for KSP players and actual aerospace engineers to map out complex trajectories. It’s loosely based on libraries like Skyfield, Poliastro, and Trajectorize. The ultimate goal is to make it easy to plot out massive interplanetary trips, whether you’re trying to reach Jool and Sarnus (with the Outer Planets Mod) or calculating a real-world journey out to Neptune.

---

What happened today

Today was a very, very buggy day. I had to tackle the core rendering systems, but I ended up running a grueling gauntlet through almost every Python graphics library out there—Panda3D, Ursina, ModernGL, VPython, and more.

Every single one of them introduced some kind of blocking issue:

• Windows that were supposed to pop up via Tkinter or Pygame-CE started doing random things like teleporting wildly across my screen or rendering with completely broken layout dimensions.
• Even when a window finally initialized and stayed stable, it would just mock me with a dead black screen entirely missing our blobs of color (the actual planets and calculated orbit lines).

This black-screen loop is exactly what hit me when I switched over to PyVista.

Why the Viewport went Black

Staring into a blank 3D canvas is a rite of passage when writing an engine from scratch. After tracking down the pipeline bugs, the black screen in PyVista boiled down to three classic astrodynamics simulation mistakes:

1. The Compound Drift Bug (mesh.translate)
   Using mesh.translate(inplace=True) directly mutates the underlying vertex memory of the sphere meshes. Because my physics engine loop advances frames based on absolute coordinates (get_absolute_pos_at_ut), relative delta transforms compounded exponentially. Within frame one, the planets physically flew millions of kilometers away from the camera.
2. The Camera Initialization Trap
   Setting camera_position = 'iso' while the newly instantiated planet objects were still sitting uninitialized at (0, 0, 0) forced the viewport to lock its focus onto a microscopic bounding box. The moment the first timer tick updated positions, everything teleported way past the active field of view.
3. Scaling
   Using a singular scale factor for both orbit diameters and planetary dimensions created a massive rendering mismatch. A planet with a 6,000 km radius shrinks down to a fraction of a single pixel when drawn on a canvas scaled to capture massive astronomical unit (AU) trajectories, rendering it invisible.

Next Flight Steps for Devlog 6

With a stable graphics viewport finally up and running, the graphics engine foundation is secure. The next challenge is implementing the actual trajectory planning functionality. My primary focus items for the next devlog will be:

• The Trajectory Tracer: Working out how to render a dynamic, rolling polyline tail behind a Spacecraft body as it traces arcs across different coordinates.
• Camera Tracking Hooks: Hooking into interactor mouse clicks so that double-clicking a planet or vessel pins the camera target matrix to that object, keeping it centered even at high time warp rates.
• Optimizing Kepler Solvers: Ensuring the underlying analytical Newton-Raphson solvers can handle high eccentricities without dragging down frame rates.