Skip to content

V0.2.0

2024-08-04#

Well I guess I'm making captain's logs again. I restored the notes from last november thru this february. In the time between I've been working on adjacent projects in Godot and Bevy. Finally getting back in the groove and ready to try again here.

I've set up the devlogs (formerly captains_log) roughly organized by major milestones in the project, roughly aligned with git tags. Seems like a reasonable way to break it up to me.

I can't help it, I have to mess with the site theme too. 2 hours gone.

2024-08-05#

Starting from scratch. First question: 2D or 3D?

Honestly I'm not certain it matters. The physics engine, avian fully supports 2D and 3D as does the Bevy renderer. The renderer supports physically based rendering (PBR) for 2D and 3D too. As far as I can tell, though, radiance cascades are only doable in 2D.

In 2D physics-space, rendering-space, and screen-space are basically the same thing. We can hand-wave away translations therein and all the complexities of visualizing information about a 3D volume in 2D screen-space. Astrodynamics gets a little simpler in 2D but mainly for mission design rather than computations (where it basically doesn't matter much). It might be necessary to remove collisions between orbiting bodies in order to make things usable, though.

I'm going to go with 2D mainly because it makes it way simpler to visualize information like gravitational potential over large areas and it makes the use of compute shaders simpler as well. For example, offloading those gravity field calculations to the GPU with a shader and then recovering that information back on the CPU later.

Now I need to choose my first task. Let's start with a simple not-to-scale 2-body system.

  1. Spawn a central body and an orbiting body.
  2. Speed up or slow down the simulation clock.
  3. Add panning and zooming to the camera.
  4. Allow the camera to follow an entity, and to change which entity is followed.

Second question: which UI crate?

egui is naturally option here. Egui is fully featured, looks pretty good, and there are examples for basically every kind of UI element I could need. The downside is that Egui can't really be styled. This is probably the best option for now, accepting that I might re-do the UI later on with something more artsy.

Lunex is the UI crate that I've been most interested in using. It looks great, leans hard into ECS (which I want to get more experience with), and has diagetic UI at the forefront. I don't really need diagetic UI, but it would be cool to have interactive UI elements attached to entities instead of in a menu. The documentation for Lunex looks really great and the examples are stunning. I'd like to come back to this one later.

Other options are the default bevy_ui which is lacking some features and ergonomics, or sickle_ui, the prospective replacement for Bevy's native UI someday. Sickle and Bevy UI crates lean into "widgets" for UI elements. To be honest, this approach doesn't really "click" with me. I probably won't use it.

Verdict: egui now, lunex later.

Summary#

  • Decided to stick with 2D.
  • Decided to use bevy_egui for now, and come back to stylized UI later with bevy_lunex.
  • Added bevy_pancam, bevy-inspector-egui, bevy_prototype_lyon, and bevy_lit as dependencies.
  • Selected f64 features for avian2d, then went back to f32.
  • Made a basic UI with egui
  • Added basic entity spawner
  • Added todo.md

2024-08-06#

ChatGPT read https://arxiv.org/abs/2402.11150 and my time dilation notes and affirmed that I have a correct understanding and my math is mostly right. The suspicious deviation of my results from wikipedia's results is a units error. Wikipedia uses microseconds per day, but I show microseconds per second.

ChatGPT helped me make a stupid-simple demo to get started with time dilation.

2024-08-11#

I set up a simple resource that maps CoordinateTime to physics time, but it is represented as a hifitime::Epoch. Playing with time scales and durations. It was pretty easy to wire up time scale switching.

I found a date picker egui widget in the egui_extras crate but it only supports chrono-flavored time structs. I'll have to roll my own constructor that maps to/from hifitime-flavors. This probably deserves its own crate so I can later upstream it to hifitime.