Question regarding AR Rocket Builder & Space Flight Sandbox Project

[Piyush Singh]

Hi Team,

I am really interested in the AR Rocket Builder and Space Flight Sandbox project for GSoC 2026.

I wanted to ask if it is possible for two individuals to work on this project by dividing the tasks into two logical modules. A friend and I have worked together on many AR projects in Unity before, and we believe splitting this into two focus areas would allow for a much more detailed implementation.

Here is how we are planning to divide the work:

• My Focus (AR Rocket Builder): I will handle the AR interaction layer. This includes the ARCore integration, the UI for selecting parts, the snap-to-fit logic for assembly, and the 3D model management for the modular rocket pieces.

• My Friend's Focus (Space Flight Sandbox): They will handle the simulation and physics layer. This includes the flight dynamics (thrust-to-weight ratios, drag, gravity), the particle systems for launch effects, and the logic for the transition from the assembly stage to the flight sandbox.

We plan to submit separate proposals, but we will mention how our APIs and modules will interface with each other. If we apply this way, how should we frame our proposals so the mentors aren't confused and can see the combined vision?

We would also like to share our past joint projects to show our experience with AR and Unity. Please let us know if this modular approach fits the organization’s requirements.

[Himanshu Vishwas]

Hi there,

Thanks for showing your interest in the project. I liked your moduler approach, but if gsoc will allow two participants in one project then only we can be able to proceed. Right? 

As of now we have thought of one contributor, also we marked this project as large sized project. 

I would like to know more about your approach both two contributor and single contributor in more detail.

Thanks and regards,

Himanshu

--
You received this message because you are subscribed to the Google Groups "catrobat" group.
To unsubscribe from this group and stop receiving emails from it, send an email to catrobat+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/catrobat/6265d96a-0a10-4b3d-b1ee-bd4c835d4d12n%40googlegroups.com.

[Sankalp Pathak]

Hi Himanshu,
Thanks for the positive feedback on our project approach , really appreciate it!

We've thought through how to divide the work cleanly between us, so here's a breakdown of who's handling what.

Module A: AR Interaction & Rocket Assembly (Piyush Singh)
Piyush is owning everything the user touches before hitting "Launch".
This includes setting up AR surface detection and anchoring using AR Foundation (ARCore/ARKit) so the rocket workspace sits stably on real-world surfaces even as the user moves around. He's building the modular rocket part catalog (nose cones, body tubes, fins, engines, fuel tanks, decouplers) where each part is defined as a ScriptableObject carrying properties like mass, drag coefficient, thrust rating, and fuel capacity.
On top of that, he's implementing a snap-to-fit assembly system with node-based attachment logic. When you drag a part near a compatible connection point, it snaps in with visual feedback (green for valid, red for invalid), and certain rules prevent nonsensical placements like attaching an engine at the top. While you build, the system continuously shows real-time structural data like Center of Mass, Center of Thrust, Thrust-to-Weight Ratio, and symmetry checks, all rendered as AR overlays.
The UI side covers a parts selection panel, gesture controls (tap, drag, rotate, pinch-to-scale), undo/redo, and a pre-launch checklist. He's also integrating Firebase so users can save, load, and share their rocket designs.

Module B: Physics Simulation & Space Flight Engine (Sankalp Pathak)
I'm taking over everything that happens once the rocket leaves the ground.
The core is a flight dynamics engine that simulates thrust, gravity, aerodynamic drag, and torque in real time, with planet-configurable gravity. For numerical stability, I'm using RK4 (Runge-Kutta 4th order) integration at a fixed 60Hz timestep, with rocket mass decreasing as fuel burns.
Failure modes are fully simulated. The rocket will behave realistically if TWR drops below 1, structural stress exceeds limits, misalignment causes tumbling, fuel runs out mid-flight, or it simply hits the ground. Each failure has a corresponding visual effect.
Multi-stage support includes decoupler firing, clean stage detachment as a separate physics object, and upper stage ignition with recalculated mass. For visuals, I'm using GPU-instanced particle systems for engine exhaust, smoke trails, explosions, stage separation bursts, and atmospheric heating, optimized to run smoothly on mobile.
I'm also building trajectory visualization with motion trails, force arrows, velocity/altitude HUD, and orbit prediction for high-altitude flights. Gravity presets will cover Earth (9.81 m/s²), Moon (1.62 m/s²), Mars (3.72 m/s²), and a custom sandbox mode. Finally, a replay and telemetry system will let users play back their flights, view altitude/velocity/fuel graphs, and compare multiple flight runs.

How the two modules connect
The handoff between our two modules happens through a single RocketConfiguration object, a serializable data structure that holds part types, positions, masses, thrust values, fuel capacities, stage definitions, and computed values like total mass, CoM, CoT, and TWR.
When the user presses Launch, Piyush's module generates this object. My module picks it up and runs the simulation from there. This keeps our code largely independent, lets us test and demo our parts separately, and makes integration straightforward.

We've planned two integration checkpoints, one mid-project and one near the end, to make sure the build to launch to simulation flow works end to end.
We're also working on the entry task and will have our demos ready to share soon. Let us know if anything in the architecture needs a rethink or if you'd like more detail on any part.

Thanks,
Sankalp Pathak & Piyush Singh

[Piyush Singh]

Hello Himanshu,

We understand that you’re currently busy mentoring for GSoC, so please feel free to take your time. However, we would really appreciate your input on this when you get a chance, as it will help us start working on the proposal and prototype.

We also hope that the idea we’ve proposed aligns with GSoC guidelines.

Looking forward to your valuable feedback.
Thank you.