Stellar Evolution Studio

The System Builder’s Phenomena palette lets you place large-scale astrophysical structures directly into a designed system: Nebula, Planetary Nebula, Supernova Remnant, and Dust Cloud. Each type is not a visual overlay — it triggers physics-appropriate state enforcement across the system.

Selecting Planetary Nebula or Supernova Remnant initiates a conversion flow: the system inspects what exists in the star catalog and presents options specific to the hosting star’s mass and spectral class. Dust Cloud and Nebula placements affect local extinction values and provide a physically grounded medium for embedded stellar populations.

Every phenomenon type reflects a real astrophysical state — planetary nebulae are the ionized shells of post-asymptotic giant branch stars, and supernova remnants are the expanding ejecta shells left by core-collapse or thermonuclear events. Placing them in a designed system means committing to the physical consequences those states imply.

When a Planetary Nebula is added to a system, the builder offers to convert the hosting star to a White Dwarf. For each planet in the system, the designer then chooses one of three outcomes: remove the planet entirely, contribute its mass to the white dwarf debris disk, or leave it in its current orbit.

The debris disk outcome is physically motivated by the WD pollution scenario — rocky bodies tidally disrupted inside the Roche limit of a cooling white dwarf produce a detectable circumstellar disk, observed around a significant fraction of white dwarfs in the solar neighbourhood. Assigning a planet to the debris disk models the fate of its material in this context.

Adding a Supernova Remnant opens conversion to Neutron Star or Black Hole, with the same per-planet fate decisions expanded to reflect the energy scales involved: vaporize (within the blast radius), eject (orbital disruption from mass loss), or keep (surviving beyond the disruption zone). Ejection is grounded in orbital stability analysis — when a star loses mass suddenly, the binding energy of each planetary orbit is recalculated, and only orbits that remain bound survive.

Every designed system runs in one of two integration modes. Keplerian mode computes clean elliptical orbits from classical orbital elements — semi-major axis, eccentricity, inclination, and the remaining Keplerian parameters — and is the default for authored systems. Orbits are displayed as precise ellipses and update instantly when any parameter changes.

N-body mode replaces computed orbits with full gravitational integration. Each body carries a state vector — position (x, y, z) and velocity (vx, vy, vz) in the system’s reference frame — which the integrator advances at each step using contributions from every other massive body. Initial state vectors can be assigned directly in the builder, giving precise control over the starting configuration before integration begins.

Once N-body is running, the system monitors for orbital stability. When the configuration has relaxed to a stable state — semi-major axes and eccentricities no longer drifting — the Lock Orbits control becomes available. Selecting it reads the current N-body state, derives best-fit Keplerian orbital elements for each body, and writes those back as the system’s Keplerian parameters. Switching to Keplerian mode then shows the new, physically derived orbit lines in place of the pre-relaxation values. The process mirrors the N-body relaxation pass used during large-scale generation.

The same N-body relaxation available in the Design Studio is the mechanism used by the generation pipeline when N-body mode is enabled during galaxy generation. Designed and generated systems share a common physical foundation — not a simplified approximation for the interactive case.

At generation scale, N-body relaxation is applied across stellar populations in a distributed Spark job. Multi-body gravitational interactions are computed using a Barnes-Hut tree that scales as O(N log N), making relaxation tractable even for systems with large numbers of bodies. The relaxed state vectors produced by the pipeline are the same format as those authored directly in the builder.

This means a system designed and relaxed in the Studio — with planet fates decided, orbits locked to the post-relaxation Keplerian parameters — can be exported with state vectors that are directly comparable to pipeline-generated systems. The distinction between “designed” and “generated” is one of authorship, not physics.