LUMINSim Documentation

LUMINSim Documentation

This is an ongoing page as I (Andrew Mattson) document LUMINSim's current systems. This page is a major work in progress; feel free to add to it!

Going forward, I hope to add in-depth descriptions of the inner workings of each major system, including:

• Power
• Tools and tool swapping
• Terrain
• Multiplayer
• Each user-controlled scene (robots and astronaut)
• The UI (multiplayer menu, settings menu, keybind menu)
• Each (largely) independent scene and corresponding system(s) (brick maker, dirt spawner, tool spawner, etc.)

Getting Started

To learn how to get started with development yourself, visit the repository's README and follow the steps there to get the project set up.

Known Issues

The following are known issues that continuously plague the simulator.

Major Issues

Major issues are detrimental to fundamental functionalities of the simulator. Generally they have no known fix without major redesign of the system itself and adjacent systems.

• With no consistency or known cause, some BetterHingeJoint3D (see Classes) joints are floppy noodles. If you create a joint and it works at first, it will continue to work, but if it is a floppy noodle at first, it will always be a floppy noodle. Deleting and re-instantiating the joint scene does not seem to work.

Minor Issues

Minor issues are just annoying. Generally they have workarounds or can simply be ignored.

• The multiplayer synchronizers throw errors when connecting/disconnecting. No impact on multiplayer functionalities has been observed.

Repository Structure

• src/ – C++ GDExtension code for terrain and registration. Likely to be deprecated. See Terrain System (C++).
• demo/ – Godot project containing levels, assets, and GDScript systems.
  • export_presets.cfg – Information for Godot on how to export the project into platform-native forms. Created automatically by the Godot export menu.
  • game_manager.gd – Handles the majority of the multiplayer logic, especially the sending of data between the clients and the server. See Networking and Multiplayer.
  • project.godot – The main project file. Contains general project configurations and properties. This is the primary reference point for the Godot Engine when developing this project.
  • demo/astra – Files pertaining to the drivable Astra robot.
  • demo/astronaut – Files pertaining to the in-game, procedurally-animated astronaut character. See Astronaut Character.
  • demo/bin – Files pertaining to the compiled GDExtension binaries. Likely to be deprecated. See Terrain System (C++).
  • demo/components – Contains components or component-like scenes and related files. See Classes.
  • demo/environment – Files for the skybox (i.e., the stars in the sky).
  • demo/excahauler – Files pertaining to the drivable Excahauler robot.
  • demo/graphics – Contains many images for icons and textures, especially for the user interface. See User Interface.
  • demo/landers – Contains directories for different lunar landers. Landers are currently just static models.
  • demo/levels – Contains the main playable (i.e., non-UI) scenes and related files. See Levels.
  • demo/objects – Contains non-static (i.e., movable RigidBody3D) objects. See Objects.
  • demo/static_objects – Contains static (i.e., unmovable StaticBody3D) objects and their related code. See Static Objects.
  • demo/terrain – Scenes and files pertaining to the dynamic (i.e., mineable) terrain. See Terrain System (C++).
  • demo/terrain_fixed – Scenes and files pertaining to the static (i.e., unchanging) terrain. See Terrain System (C++).
  • demo/util – Scenes and files pertaining to UI as well as other useful scripts. See User Interface and Additional Utilities.

In-depth repository structure documentation (brief descriptions on a per-scene basis) may be created here by anyone.

Classes

The following scripts register custom nodes with the keyword class_name:

• ToolCouplerComponent.gd → ToolCoupler – manages attaching tools to a robot via physics joints.
• connector_component.gd → Connector – area detector used by tool couplers and charge stations.
• autonomy_component.gd → AutonomyComponent – simple navigation helper for NPC robots. See Autonomy System.
• charge_component.gd → ChargeComponent – tracks battery state and handles charging/discharging.
• better_hinge_joint_3d.gd → BetterHingeJoint3D – wrapper over Generic6DOFJoint3D for motorized joints.
• tool_attachment.gd → ToolAttachment – base class for all detachable tools.
• forks.gd → Forks – tool attachment for moving objects.
• bucket_attachment.gd → Bucket – digs into terrain to collect dirtballs.
• saw_blade_attachment.gd → SawBlade – spinning blade for cutting objects.
• dem_loader.gd → DemLoader – loads fixed DEM heightmaps and extends TerrainStatic256, which is declared via GDExtensions. See Terrain System (C++).

These classes are referenced throughout the systems described below.

Autonomy System

The current autonomous driving logic is implemented by the AutonomyComponent script. Every robot scene instantiates this node under its root VehicleBody3D.

Currently, this is how it works:

• A child NavigationAgent3D computes a path when pathfind_to(target_pos) is called.

• During _physics_process() the component steers the robot toward the next path point using the get_drive() and get_steer() helpers.

• The helpers are polled by astra_3d.gd so the component effectively overrides manual controls when active.

• If progress stalls the script nudges the body upward and forward to get free. Once the destination is reached the have_arrived flag is set.

Proposed External API

To enable players to program autonomy from outside the engine, a new AutonomyServer node could expose a local API via WebSocket, HTTP, or MQTT. The simulator would send each robot's state to this server, including data like true position, velocity, tool data, and battery level data, and eventually realistic simulated sensor data. An external script could connect to the API and issue commands such as drive, steer, actuate arm, and so on.

This approach decouples vehicle logic from the engine so users can iterate on autonomy in any language without recompiling the project. The AutonomyServer would relay commands to the relevant nodes (mirroring the current get_drive() and get_steer() methods) while still supporting multiplayer authority checks via GameManager.

Terrain System (C++)

C++ based GDExtensions currently provide the terrain implementation and may be replaced in the future with a more developer-friendly system.

Static Terrain

TerrainStatic256 loads heightmaps and generates render and collision meshes.

Dynamic Terrain

TerrainSim extends TerrainStatic256 to simulate excavation, landslides, and merging dirtballs back into the heightmap.

Terrain Tools

Scripts such as dirt_spawner.gd and dirtball.gd spawn and merge mobile particles with the dynamic terrain.

Power System

Movable vehicles include a ChargeComponent that stores amp-hours and battery percentage. Robots consume charge while driving or actuating, and static objects like charge stations or solar panels provide power when connected.

Tools and Attachments

All interchangeable implements derive from ToolAttachment. Robot arms have ToolCoupler nodes that detect nearby Connector areas and create physics joints to attach or detach tools. Available tools include the Bucket, Forks, and SawBlade. tool_spawner.gd respawns tools removed from its bays.

Robot Systems

Astra Robot

The main scene is astra_3d.tscn. astra_3d.gd handles driving, energy usage, and tool attachment. It works with astra_arm_3d.gd and astra_hopper_3d.gd and their associated .tscn files for the robot's arm and hopper.

Astronaut Character

astronaut_character_3d.gd provides walking and camera control for a procedurally animated astronaut.

Excavation Tools

Attachments such as the bucket, forks, and saw blade extend ToolAttachment for various tasks.

Excahauler Robot

The main scene is excahauler_3d.tscn. Unlike Astra's implementation, all functionalities are within that .tscn file and the associated .gd file. Currently, only Excahauler's main arm (boom, stick, and tilt) is implemented, as trying to set up the scoop (fork and dump) joints in an identical way results in uncontrollable, noodle-like joints.

Objects

WIP.

Static Objects

Charge stations, solar panels, tool spawners, and other environment pieces provide energy or spawn tools.

Networking and Multiplayer

game_manager.gd manages synchronized player/object data and signals for network updates. multiplayer_menu.gd lets players host or join games, start sessions, and handle disconnects.

User Interface

The ui.gd, joystick.gd, and keybinds_menu.gd scripts provide HUD elements, customizable input bindings, and optional on-screen controls for mobile users.

Cameras and Controls

movable_camera_3d.gd and freecam.gd implement user-controlled cameras, both first- and third-person.

Levels

Scenes in demo/levels/ (e.g., main3D.tscn with script main3D.gd) instantiate players, objects, and the terrain simulator, driving the overall game loop.

Independent Scenes

Several standalone scenes provide gameplay utilities:

• brick_maker.gd – creates bricks when filled with loose dirt.
• tool_spawner.gd – keeps bays stocked by respawning attachments.
• dirt_spawner.gd – continuously emits dirtballs for terrain testing.

Additional Utilities

Miscellaneous helpers include fps_counter.gd for performance output and freecam.tscn which can be spawned via the command console for debugging or spectator play.

Future Work

The repository is under active development. Planned areas of documentation include deeper explanations of the power system, tool workflow, and multiplayer networking. Contributions are welcome.