Umbra - Making the Dip Actually Mean Something

• Kepler solved the “where the heck is the planet” issue, but I still had a “how much light does it actually block” issue, and the answer wasn’t as simple as I first thought
• My first instinct was just measuring the distance between planet and star centres and eyeballing a dim amount from that, which is wrong the second the planet is anything other than fully in or fully out
• What you actually need is the overlap area between two circles, so I built circleOverlapArea() using the proper lens equation, it takes the centre distance plus both radii and works out the exact overlapping region
• This is what gives you the sloped ingress and egress on the light curve instead of a dip that just snaps to a flat bottom, which is a lot closer to what a real transit looks like
• Also added depth ordering off the back of this, since I needed to know when the planet’s on the near side of the orbit vs the far side so it draws in front of or behind the star correctly (sin of the eccentric anomaly tells you which side you’re on, handy)
• Once the flux number was actually trustworthy, I edited the instrumentation to go with it:
  • fixed the stats panel (radius ratio, current flux, transit depth, max depth, eccentricity, transit count, measured period)
  • rising-edge detection so it counts transits and times the period itself, rather than me just reading it off the speed slider
  • fixed the light curve graph itself, plotting flux over time with gridlines so you can actually see the dip shape as it happens

Genuinely didn’t expect the geometry bit to be the harder half of this session, Kepler felt like the scary one going in but the overlap maths turned out to be the fiddlier of the two!

I also distributed all my code into separate files as for some reason I put it all inline in one html file and I got some reviews about file structure on my other projects, so didn’t want to repeat that lol