coilyco-gaming/galaxy-gen
Watch
2
0
Code Issues 7 Pull requests Projects Releases Packages 1 Wiki Activity Actions

Boundary ridge: gas confinement is load-bearing, and stars have their own edge #65

New issue
Open
opened 2026-08-07 06:35:52 +00:00 by coilyco-ops · 3 comments
coilyco-ops commented 2026-08-07 06:35:52 +00:00
Member
Copy link

Follow-up to the gas-fade work. The visible simulation boundary turned out to be two separate problems on the same radius. One is fixed, two are not.

Fixed

Gas is sprung inward past disk_r = size/2 - 1 (CONFINE_STIFFNESS), which makes that radius an equilibrium: every parcel drifting outward parks on it. The result is a genuine density ridge sitting exactly on the domain boundary, and the renderer was drawing it at 0.82 alpha while its fade spent its range on the near-empty sky outside. Gas now has its own fade completing at 0.94 * disk_r, inside the wall.

Verified by radial luminance profile at tick 0 (gas, effectively no stars), sampling 720 angles per ring:

f=0.600 lum=10.24   f=0.750 lum=9.37
f=0.650 lum=8.80    f=0.800 lum=9.85
f=0.700 lum=9.14    f=0.875 lum=10.55
f=0.725 lum=9.28    f=0.925 lum=10.62

disk_r maps to f=0.704. The profile is monotonic across it. No ridge.

Not fixed 1: the ridge still exists in the physics

Spreading the ridge itself, by ramping the confinement across a band inside disk_r the way stars got with HARD_CLIP_FACTOR, was implemented and reverted. At CONFINE_BAND_FRAC = 0.18 it perturbs the outer disk enough to break four Rust tests:

  • spiral coherence drops to 0.217
  • ring stops star-forming (the coherent ring window must remain actively star-forming)
  • elliptical relaxation fails its spheroid check
  • golden mass field per scenario changes

So the ridge is load-bearing for scenario dynamics, not incidental. Removing it means retuning the scenario force models with it gone, and regenerating the golden fields. That is a real piece of work, not a constant tweak. Not drawing it was the cheap fix; this is the honest one.

Not fixed 2: stars have their own edge, and it is sharper

The same radial profile at tick 900, once the stellar population is mature:

f=0.700 lum=11.12
f=0.725 lum=14.10
f=0.750 lum=19.76   <- peak, just outside disk_r
f=0.775 lum=9.73    <- sky floor
f=0.800 lum=9.85

A 2x bump peaking just outside disk_r, then a cliff straight to the sky floor at ~9.7. This is not gas (gas is zero out here by construction now) and it is not the vignette (that begins at f=1.04 at 1280x800). It is the stellar layer.

Likely cause: stars sit in the halo band between disk_r and 3 * disk_r with HALO_STIFFNESS pulling them back and STAR_HALO_DRAG bleeding their energy, so they pool just outside the disk rather than distributing across the band. The star fade runs to 1.32 * disk_r (f=0.929), so the cliff at f=0.775 is not the fade ending. Something else is cutting the stellar layer off there, and it should be found before tuning anything.

Probably related to the separate star-noise investigation (uniform mess by ~5k ticks): if stars are pooling in the halo band rather than holding disk structure, that is one mechanism for both symptoms.

Suggested order

  1. Diagnose the f=0.775 stellar cliff. It is a sharp feature, so it is likely a bound or a cull, not a gradient.
  2. Fold the halo-band distribution question into the star-noise sweep rather than doing it twice.
  3. Retune scenario forces without the confinement ridge, last and deliberately, with golden fields regenerated in the same commit.
Follow-up to the gas-fade work. The visible simulation boundary turned out to be two separate problems on the same radius. One is fixed, two are not. ## Fixed Gas is sprung inward past `disk_r = size/2 - 1` (`CONFINE_STIFFNESS`), which makes that radius an equilibrium: every parcel drifting outward parks on it. The result is a genuine density ridge sitting exactly on the domain boundary, and the renderer was drawing it at **0.82 alpha** while its fade spent its range on the near-empty sky outside. Gas now has its own fade completing at `0.94 * disk_r`, inside the wall. Verified by radial luminance profile at tick 0 (gas, effectively no stars), sampling 720 angles per ring: ``` f=0.600 lum=10.24 f=0.750 lum=9.37 f=0.650 lum=8.80 f=0.800 lum=9.85 f=0.700 lum=9.14 f=0.875 lum=10.55 f=0.725 lum=9.28 f=0.925 lum=10.62 ``` `disk_r` maps to `f=0.704`. The profile is monotonic across it. No ridge. ## Not fixed 1: the ridge still exists in the physics Spreading the ridge itself, by ramping the confinement across a band inside `disk_r` the way stars got with `HARD_CLIP_FACTOR`, was implemented and reverted. At `CONFINE_BAND_FRAC = 0.18` it perturbs the outer disk enough to break four Rust tests: - spiral coherence drops to 0.217 - ring stops star-forming (`the coherent ring window must remain actively star-forming`) - elliptical relaxation fails its spheroid check - golden mass field per scenario changes So the ridge is load-bearing for scenario dynamics, not incidental. Removing it means retuning the scenario force models with it gone, and regenerating the golden fields. That is a real piece of work, not a constant tweak. Not drawing it was the cheap fix; this is the honest one. ## Not fixed 2: stars have their own edge, and it is sharper The same radial profile at tick 900, once the stellar population is mature: ``` f=0.700 lum=11.12 f=0.725 lum=14.10 f=0.750 lum=19.76 <- peak, just outside disk_r f=0.775 lum=9.73 <- sky floor f=0.800 lum=9.85 ``` A 2x bump peaking just outside `disk_r`, then a cliff straight to the sky floor at ~9.7. This is not gas (gas is zero out here by construction now) and it is not the vignette (that begins at `f=1.04` at 1280x800). It is the stellar layer. Likely cause: stars sit in the halo band between `disk_r` and `3 * disk_r` with `HALO_STIFFNESS` pulling them back and `STAR_HALO_DRAG` bleeding their energy, so they pool just outside the disk rather than distributing across the band. The star fade runs to `1.32 * disk_r` (`f=0.929`), so the cliff at `f=0.775` is not the fade ending. Something else is cutting the stellar layer off there, and it should be found before tuning anything. Probably related to the separate star-noise investigation (uniform mess by ~5k ticks): if stars are pooling in the halo band rather than holding disk structure, that is one mechanism for both symptoms. ## Suggested order 1. Diagnose the `f=0.775` stellar cliff. It is a sharp feature, so it is likely a bound or a cull, not a gradient. 2. Fold the halo-band distribution question into the star-noise sweep rather than doing it twice. 3. Retune scenario forces without the confinement ridge, last and deliberately, with golden fields regenerated in the same commit.
coilyco-ops commented 2026-08-07 15:04:22 +00:00
Author
Member
Copy link

The stellar cliff here is almost certainly the same bug as #66, not a rendering problem.

First, ruling out the renderer. The star fade culls at fade <= 0.02, which with FADE_START = 0.88 / FADE_END = 1.32 works out to about 1.276 disk_r, or f=0.898 in the profile coordinates used above. The measured cliff is between f=0.750 and f=0.775, i.e. 1.07-1.10 disk_r. So the cliff is not the fade ending, and it is not the vignette (f=1.04 at 1280x800). Nothing in the render path cuts there.

What does cut near there is a population boundary. process_stellar_halo retires any star sustained beyond STELLAR_HALO_MIX_RADIUS = 1.18 * disk_r for STELLAR_HALO_DWELL = 8 scans into the diffuse halo reservoir. Resolved stars draw as points; the reservoir draws as a smooth, much dimmer halo. So crossing that boundary is a discontinuous drop in surface brightness — exactly the shape measured, a bump then a cliff rather than a gradient. The steady-state edge sits somewhat inside 1.18 because a star has to persist out there to be retired.

That reframes the bump as an accumulation against a drain, which is where #66 comes in. Measured there: newborn stars are handed 2.0-3.2x the local circular speed (bcirc), well past the ~1.41x escape ratio. The disk has been launching most of the stars it forms. Those stars climb out, pile against the phase-mixing radius, and retire. The bump is the queue at the drain, and the growing mixed count through the run is the drain flowing.

So: one root cause, two symptoms. Stars born far too fast produce both the non-rotating disk in #66 and the halo pooling here. The BIRTH_ORBIT_RATIO_CAP fix in #66 should remove this bump without touching the renderer or the halo constants at all. Verifying now.

If the bump survives the fix, then STELLAR_HALO_MIX_RADIUS and the resolved-to-diffuse brightness step are worth revisiting on their own — the transition should probably cross-fade rather than switch. But that is a second-order polish item, not the cause, and it should not be tuned until the population dynamics are right.

Note the remaining item on this issue is unchanged and independent: the gas confinement ridge is still load-bearing for scenario dynamics, and removing it still needs the scenario force models retuned with golden fields regenerated.

The stellar cliff here is almost certainly the same bug as #66, not a rendering problem. First, ruling out the renderer. The star fade culls at `fade <= 0.02`, which with `FADE_START = 0.88` / `FADE_END = 1.32` works out to about 1.276 `disk_r`, or **f=0.898** in the profile coordinates used above. The measured cliff is between f=0.750 and f=0.775, i.e. **1.07-1.10 `disk_r`**. So the cliff is not the fade ending, and it is not the vignette (f=1.04 at 1280x800). Nothing in the render path cuts there. What does cut near there is a **population** boundary. `process_stellar_halo` retires any star sustained beyond `STELLAR_HALO_MIX_RADIUS = 1.18 * disk_r` for `STELLAR_HALO_DWELL = 8` scans into the diffuse halo reservoir. Resolved stars draw as points; the reservoir draws as a smooth, much dimmer halo. So crossing that boundary is a discontinuous drop in surface brightness — exactly the shape measured, a bump then a cliff rather than a gradient. The steady-state edge sits somewhat inside 1.18 because a star has to persist out there to be retired. That reframes the bump as an accumulation against a drain, which is where #66 comes in. Measured there: newborn stars are handed **2.0-3.2x the local circular speed** (`bcirc`), well past the ~1.41x escape ratio. The disk has been launching most of the stars it forms. Those stars climb out, pile against the phase-mixing radius, and retire. The bump is the queue at the drain, and the growing `mixed` count through the run is the drain flowing. So: one root cause, two symptoms. Stars born far too fast produce both the non-rotating disk in #66 and the halo pooling here. The `BIRTH_ORBIT_RATIO_CAP` fix in #66 should remove this bump without touching the renderer or the halo constants at all. Verifying now. If the bump survives the fix, then `STELLAR_HALO_MIX_RADIUS` and the resolved-to-diffuse brightness step are worth revisiting on their own — the transition should probably cross-fade rather than switch. But that is a second-order polish item, not the cause, and it should not be tuned until the population dynamics are right. Note the remaining item on this issue is unchanged and independent: the gas confinement ridge is still load-bearing for scenario dynamics, and removing it still needs the scenario force models retuned with golden fields regenerated.
coilyco-ops commented 2026-08-09 03:36:36 +00:00
Author
Member
Copy link

The stellar edge here is now measured rather than inferred, and the previous comment's prediction holds. Confirming it, and correcting one detail in it.

"Not fixed 2" is confirmed, and the mechanism is the drain

The comment above read the bump as an accumulation against the STELLAR_HALO_MIX_RADIUS drain, and predicted the birth-velocity fix would remove it. It could not be tested, because that fix was reverted. Testing it directly through the new ablation harness (#66), stars drained into the diffuse reservoir by t=2500, irregular=>spiral, size 500, seeds 12345 / 12346:

configuration 12345 12346
baseline 3200 9009
birth ratio cap 1.06 114 149
axisymmetric field 144 242
both together 110 175

The drain falls 30-80x. So the bump really is a queue at a drain, and the queue is fed by stars on orbits their potential cannot hold. Two independent causes for that, per #66: over-fast births, and scattering off the clumpy coarse field. Either one alone shuts the drain nearly all the way, which is why this symptom is easier to fix than the rotation collapse next door - that one needs both.

The correction

The comment attributes the bump to the birth velocity, singular, and expected BIRTH_ORBIT_RATIO_CAP to remove it "without touching the renderer or the halo constants at all." Measured, the axisymmetric-field ablation removes the drain just as well with birth velocities completely untouched. So the birth velocity is a sufficient cause, not the cause. That does not change what to do here - both live in #66 and both shut the drain - but the causal claim was narrower than the evidence supports.

Item 1 of the suggested order is closed

The f=0.775 cliff is a population boundary, not a bound or a cull in the render path, and not the fade ending. The previous comment's arithmetic ruling out the renderer stands and the drain numbers above corroborate it. Nothing further to diagnose.

What I did not do, and why

The resolved-to-diffuse cross-fade. Currently a star is deleted from the resolved population at 1.18 disk_r while radialFade still draws it at about 0.24 alpha, and at the measured steady-state population edge near 1.10 disk_r it draws at about 0.5. That step is the cliff, and the structural fix is to let the resolved layer end where the physics stops resolving stars - FADE_END tied to STELLAR_HALO_MIX_RADIUS rather than sitting beyond it, with the diffuse gradient taking over. It already peaks around 1.03 disk_r, so the handoff radius is well placed.

Not landing it now for the reason this issue already gave: it should not be tuned until the population dynamics are right, and they are not. The current edge radius is a steady-state artifact of the drain, so a fade tuned to today's population edge encodes today's bug. It is also the one piece here I cannot measure reproducibly - the radial luminance profiles on this issue were taken ad hoc and there is no committed tool that reproduces them. Worth building that tool alongside the change rather than tuning blind.

Item 3, retuning the scenario force models without the confinement ridge. Untouched and still the honest fix. This issue correctly sequences it last, and #66 has just changed what the stellar layer will look like when the retune happens, so doing it first would mean doing it twice. It also needs golden fields regenerated in the same commit and a push to main rolls the public site, which makes it a deliberate call rather than an incidental one.

Status

  • Item 1, diagnose the stellar cliff: closed, it is the drain.
  • Item 2, fold the halo-band question into the star-noise sweep: done, numbers above.
  • Item 3, retune without the confinement ridge: open, unchanged, still gated on #66.
  • New, small: the resolved-to-diffuse cross-fade, ready to do once #66 settles the population edge, and wanting a committed radial-profile tool with it.

No physics or renderer change landed against this issue. The harness that produced these numbers is on main and inert by default - see docs/ablation.md.

The stellar edge here is now measured rather than inferred, and the previous comment's prediction holds. Confirming it, and correcting one detail in it. ## "Not fixed 2" is confirmed, and the mechanism is the drain The comment above read the bump as an accumulation against the `STELLAR_HALO_MIX_RADIUS` drain, and predicted the birth-velocity fix would remove it. It could not be tested, because that fix was reverted. Testing it directly through the new ablation harness (#66), stars drained into the diffuse reservoir by t=2500, irregular=>spiral, size 500, seeds 12345 / 12346: | configuration | 12345 | 12346 | |---|---|---| | baseline | 3200 | 9009 | | birth ratio cap 1.06 | 114 | 149 | | axisymmetric field | 144 | 242 | | both together | 110 | 175 | **The drain falls 30-80x.** So the bump really is a queue at a drain, and the queue is fed by stars on orbits their potential cannot hold. Two independent causes for that, per #66: over-fast births, and scattering off the clumpy coarse field. Either one alone shuts the drain nearly all the way, which is why this symptom is easier to fix than the rotation collapse next door - that one needs both. ## The correction The comment attributes the bump to the birth velocity, singular, and expected `BIRTH_ORBIT_RATIO_CAP` to remove it "without touching the renderer or the halo constants at all." Measured, the axisymmetric-field ablation removes the drain just as well with birth velocities completely untouched. So the birth velocity is *a* sufficient cause, not *the* cause. That does not change what to do here - both live in #66 and both shut the drain - but the causal claim was narrower than the evidence supports. ## Item 1 of the suggested order is closed The `f=0.775` cliff is a population boundary, not a bound or a cull in the render path, and not the fade ending. The previous comment's arithmetic ruling out the renderer stands and the drain numbers above corroborate it. Nothing further to diagnose. ## What I did not do, and why **The resolved-to-diffuse cross-fade.** Currently a star is deleted from the resolved population at `1.18 disk_r` while `radialFade` still draws it at about 0.24 alpha, and at the measured steady-state population edge near `1.10 disk_r` it draws at about 0.5. That step is the cliff, and the structural fix is to let the resolved layer end where the physics stops resolving stars - `FADE_END` tied to `STELLAR_HALO_MIX_RADIUS` rather than sitting beyond it, with the diffuse gradient taking over. It already peaks around `1.03 disk_r`, so the handoff radius is well placed. Not landing it now for the reason this issue already gave: it should not be tuned until the population dynamics are right, and they are not. The current edge radius is a steady-state artifact of the drain, so a fade tuned to today's population edge encodes today's bug. It is also the one piece here I cannot measure reproducibly - the radial luminance profiles on this issue were taken ad hoc and there is no committed tool that reproduces them. Worth building that tool alongside the change rather than tuning blind. **Item 3, retuning the scenario force models without the confinement ridge.** Untouched and still the honest fix. This issue correctly sequences it last, and #66 has just changed what the stellar layer will look like when the retune happens, so doing it first would mean doing it twice. It also needs golden fields regenerated in the same commit and a push to `main` rolls the public site, which makes it a deliberate call rather than an incidental one. ## Status - Item 1, diagnose the stellar cliff: closed, it is the drain. - Item 2, fold the halo-band question into the star-noise sweep: done, numbers above. - Item 3, retune without the confinement ridge: open, unchanged, still gated on #66. - New, small: the resolved-to-diffuse cross-fade, ready to do once #66 settles the population edge, and wanting a committed radial-profile tool with it. No physics or renderer change landed against this issue. The harness that produced these numbers is on `main` and inert by default - see [docs/ablation.md](../src/branch/main/docs/ablation.md).
coilyco-ops commented 2026-08-09 03:51:12 +00:00
Author
Member
Copy link

The stellar half of this issue is compiled into #70, along with #66.

The halo bump here and the rotation collapse there share one root cause, and the drain numbers above are what tied them together. #70 owns that fix.

Two things stay on this issue, because they are genuinely separate:

  • The gas confinement ridge retune ("Not fixed 1"). This is about gas and CONFINE_STIFFNESS, and has nothing to do with stellar orbits. Still the honest fix, still needs the four scenario force models retuned with golden fields regenerated.
  • The resolved-to-diffuse cross-fade. A small renderer change, and it should wait until #70 settles where the stellar population actually ends - otherwise it encodes today's drain-driven edge radius. Worth building a committed radial-luminance-profile tool alongside it, since the profiles on this thread were taken ad hoc and nothing reproduces them.
The stellar half of this issue is compiled into **#70**, along with #66. The halo bump here and the rotation collapse there share one root cause, and the drain numbers above are what tied them together. #70 owns that fix. **Two things stay on this issue**, because they are genuinely separate: - **The gas confinement ridge retune** ("Not fixed 1"). This is about gas and `CONFINE_STIFFNESS`, and has nothing to do with stellar orbits. Still the honest fix, still needs the four scenario force models retuned with golden fields regenerated. - **The resolved-to-diffuse cross-fade.** A small renderer change, and it should wait until #70 settles where the stellar population actually ends - otherwise it encodes today's drain-driven edge radius. Worth building a committed radial-luminance-profile tool alongside it, since the profiles on this thread were taken ad hoc and nothing reproduces them.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
aos/claude/mg96-fm
aos/claude/mg96
gg/claude/74-ci-in-dev-base
No results found.
Labels
Clear labels   
burndown-2026-06
Backlog burndown June 2026

  
autonomy
async-consult
 A human needs to consult on the issue to upgrade it to headless

  
autonomy
epic
 This issue has many units of sub work - its size makes it meaningfully exclusive with other autonomy types

  
autonomy
headless
 The agent can perform the work on its own

  
autonomy
live-collab
 The agent and the human need to work together in realtime

  
c#
Requires C# work, flagged b/c it requires a Eco server restart

  
priority
P0
 priority tier

  
priority
P1
 priority tier

  
priority
P2
 priority tier

  
priority
P3
 priority tier

  
priority
P4
 priority tier

  
role/ai
requires work from the AI Engineer role

  
role/creator
requires work from Content Creator role

  
role/design
requires work from the design role

  
role/director
requires work from the director role

  
role/engineer
requires work from the engineer role

  
role/exec
requires work from the exec role

  
role/human
requires a person, and specifically not an agent seat

  
role/ops
requires work from the ops role

  
role/qa
requires work from the QA role

No labels
burndown-2026-06
autonomy
async-consult
autonomy
epic
autonomy
headless
autonomy
live-collab
c#
priority
P0
priority
P1
priority
P2
priority
P3
priority
P4
role/ai
role/creator
role/design
role/director
role/engineer
role/exec
role/human
role/ops
role/qa
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/galaxy-gen#65
No description provided.