[WEB] KSP Transfer Illustrator

[theAstrogoth]

This project has been abandoned in lieu of a newer, much more usable implementation:

 

KSP Transfer Illustrator

 

Links

KSP Transfer Illustrator

KSP Trajectory Illustrator

Description

Inspired by existing mission planning tools (alexmoon's Launch Window Planner and Arrowstar's Trajectory Optimization Tool), I have made a couple of web apps to help visualize trajectories for mission planning. While the KSP Trajectory Optimization Tool is much more powerful and has many more features, the idea is that Transfer Illustrator can be used without downloading or installing any software and has an unintimidating user interface. I've also tried to make this app have some additional flexibility compared to the Launch Window Planner and to make it easier to interpret the information provided about orbit parameters and burn information.

KSP Transfer Illustrator:

• Generates Porkchop plots to visualize Δv costs for transfers across a range of departure and arrival times
• Computes transfers between spheres of influence (e.g. Kerbin to Duna) or within a sphere of influence (e.g. two distinct orbits around Kerbin)
• Determines optimal times and magnitudes of plane-change maneuvers during a transfer
• Determines ejection/insertion trajectories for transfers that involve exiting/entering a body's sphere of influence
• Displays interactive 3D plots of the calculated trajectories
• Creates downloadable HTML files with the interactive plots
• Loads orbit data from KSP savefiles

The KSP Trajectory Illustrator:

• Propagates trajectories across spheres of influence
• Computes orbit changes at (instantaneous) maneuver nodes
• Creates interactive 3D plots showing trajectories of multiple crafts/objects
• Reads flight data directly from savefiles

Plans for this project

While the apps are already in a usable state, there are several improvements I plan on making:

• Find a new way to deploy the app (the free version of Heroku I'm using has issues with worker timeouts during long computations) (Performance has improved to the point where this isn't a huge issue)
• Add UI elements to help copy and save orbit details
• Add more robust support for other solar systems (e.g. Kopernicus) 
• Find way to allow interactive plots to be embedded in forum posts (Not possible due to security concerns)
• Make the app a bit prettier
• More robust plane change maneuver options (90 degrees to intercept vs. AN vs. DN, inspired by this post)
• Gravity assist planning

This is my first project in Python and my first ever attempt at making a web app, so there's probably a lot that I can do to improve! Any suggestions or advice would be appreciated. Also, if you come across any bugs or incorrect results when using the app, I would appreciate feedback in this thread or on the project's GitHub repository.

 

Please share any requests for new features!

 

The KSP Transfer Illustrator is licensed under the MIT License.

Edited May 24, 2022 by theAstrogoth

[Arrowstar]

21 hours ago, theAstrogoth said:

While the KSP Trajectory Optimization Tool is much more powerful and has many more features, the idea is that Transfer Illustrator can be used without downloading or installing any software and has an unintimidating user interface.

Hey now.

Cool tool, though, it's gotta neat look to it.  You're on the right track with it.

[theAstrogoth]

On 7/7/2020 at 8:52 PM, Arrowstar said:

Hey now.

That probably came across a bit harsher than I intended! In a lot of ways, what I've made so far is my attempt at a copy of the TOT (without any of the mission or maneuver planning tools, of course).

 

I was going to PM you a few questions about how you calculate transfer and ejection orbits, but I don't think I can yet as a new member of the forum with <5 posts, so I'll ask here instead. I noticed some small differences in the details for a transfer obtained from my tool (which tends to more closely match results from alexmoon's) and your TOT (the first figure). I also saw that your departure burns have a radial component. I think that differences in our results might come from two simplifying assumptions I am making when I calculate ejection trajectories:

1. that the periapsis of the departure trajectory is at the location of the burn, and
2. that the the position of the craft when it leaves the starting body's SOI can be ignored, since I solve Lambert's problem beforehand using the positions of the planets rather than the position of the craft after ejection and at encounter.

Can you share how you have done your calculations without the need for these assumptions if that's the case, or point me toward any relevant resources or parts of your code? Sorry if this is a vague/unclear request, I can try to clarify if what I'm asking doesn't make any sense.

Also, thanks for taking a look at the app and for the encouragement!

[Arrowstar]

3 hours ago, theAstrogoth said:

That probably came across a bit harsher than I intended! In a lot of ways, what I've made so far is my attempt at a copy of the TOT (without any of the mission or maneuver planning tools, of course).

No worries, I'm just giving you a hard time. You aren't the first person to say KSPTOT is a bit intimidating and you won't be the last.

Quote

I was going to PM you a few questions about how you calculate transfer and ejection orbits, but I don't think I can yet as a new member of the forum with <5 posts, so I'll ask here instead. I noticed some small differences in the details for a transfer obtained from my tool (which tends to more closely match results from alexmoon's) and your TOT (the first figure). I also saw that your departure burns have a radial component. I think that differences in our results might come from two simplifying assumptions I am making when I calculate ejection trajectories:

1. that the periapsis of the departure trajectory is at the location of the burn, and
2. that the the position of the craft when it leaves the starting body's SOI can be ignored, since I solve Lambert's problem beforehand using the positions of the planets rather than the position of the craft after ejection and at encounter.

Can you share how you have done your calculations without the need for these assumptions if that's the case, or point me toward any relevant resources or parts of your code? Sorry if this is a vague/unclear request, I can try to clarify if what I'm asking doesn't make any sense.

1. I don't require the burn location to be at the periapsis of the outbound orbit, no.  What I do is optimize the burn location (the true anomaly) in the elliptical orbit and compute the delta-v required to achieve the required outbound hyperbolic excess velocity vector from that point.  I then minimize that delta-v using an optimizer.  The code in the file computeDepartArriveDVFromEllipticTarget should give you a rough idea of what's going on. Also look at computeHypOrbitFromEllipticTarget as well.  Sorry for the lack of comments anywhere, I'm pretty terrible at doing that. And you're right, occasionally this does result in small radial components to the burn.
2. You're correct here, at least for the porkchop plot and Compute Departure code.  I make the same assumption.

Feel free to ask any other questions and go through the KSPTOT code base for ideas: https://github.com/Arrowstar/ksptot/

[theAstrogoth]

On 7/9/2020 at 2:16 PM, Arrowstar said:

1. I don't require the burn location to be at the periapsis of the outbound orbit, no.  What I do is optimize the burn location (the true anomaly) in the elliptical orbit and compute the delta-v required to achieve the required outbound hyperbolic excess velocity vector from that point.  I then minimize that delta-v using an optimizer.  The code in the file computeDepartArriveDVFromEllipticTarget should give you a rough idea of what's going on. Also look at computeHypOrbitFromEllipticTarget as well.  Sorry for the lack of comments anywhere, I'm pretty terrible at doing that. And you're right, occasionally this does result in small radial components to the burn.

Thanks for your explanation! I think I understand what your code does in general, and I can see how this lets you deal with non-circular starting orbits, even if I'm unfamiliar with how the MATLAB optimizers and constraints work exactly. I really appreciate the help!

Side Note: I noticed that another reason I might be getting different results because of the way I'm calculating the semi-major axis of departure orbits. I don't treat the excess velocity the way it's typically defined (at r=Infinity) but instead account for the starting body's SOI, since we're using patched conics and there is some gravitational potential energy that just disappears at the SOI change. So instead of:

hEng = norm(hVInf)^2/2;
hSMA = -gmu/(2*hEng);

I use something like:

hSMA = 1/(2/soi - norm(hVInf)^2/gmu)

For a vInf of 900m/s from Kerbin (for a trip to Duna), this is a ~10% difference in SMA, but the difference will be smaller for more expensive trips.

Quote

2. You're correct here, at least for the porkchop plot and Compute Departure code.  I make the same assumption.

When is it important to not make this assumption? Maybe for flybys? It also seems like it might be a bad assumption when the SMA is not much greater than the SOI, like with the Mun (SOI/SMA is ~20%). And what do you do for those situations? My first guess would be to do something like:

1. Solve Lambert's problem with the planet's positions
2. Get the ejection trajectory from the starting body
3. Get the state vector at departure from starting planet's SOI
4. Re-solve the Lambert problem with the new starting position
5. Repeat from step 2 until convergence of start positions
6. Get the state vector at encounter with the target planet's SOI, and use it to calculate the arrival trajectory

I haven't tried this yet, so I'm not sure how quickly it converges (if at all), or if it even really makes sense to do in the first place. It seems like doing this would be much more computationally expensive.

[Arrowstar]

5 hours ago, theAstrogoth said:

When is it important to not make this assumption? Maybe for flybys? It also seems like it might be a bad assumption when the SMA is not much greater than the SOI, like with the Mun (SOI/SMA is ~20%). And what do you do for those situations? My first guess would be to do something like:

1. Solve Lambert's problem with the planet's positions
2. Get the ejection trajectory from the starting body
3. Get the state vector at departure from starting planet's SOI
4. Re-solve the Lambert problem with the new starting position
5. Repeat from step 2 until convergence of start positions
6. Get the state vector at encounter with the target planet's SOI, and use it to calculate the arrival trajectory

I haven't tried this yet, so I'm not sure how quickly it converges (if at all), or if it even really makes sense to do in the first place. It seems like doing this would be much more computationally expensive.

Honestly at this point, you're not going to be able to use Lambert solvers with any sort of real accuracy I think.  You can try your method though, and if you do, please report back the results to share, as I'm interested in seeing how well it does work.  I suspect the reality of the situation, though, is that you would have to eliminate the zero-radius SoI assumption and propagate the orbits through the patched conics directly, which is what the high fidelity tools in KSPTOT do.  This is not an easy task.

Also note that I don't think there's an in-between: you either always make that assumption or you always don't.  I can't see how you'd get around it any other way.  Using a Lambert solver inherently involves the zero-radius SoI assumption, so if you use it, you're already locked in to the downsides of that approach as far as I can tell.  Or so I think.  Feel free to prove me wrong.

[theAstrogoth]

On 7/28/2020 at 6:18 PM, Arrowstar said:

You can try your method though, and if you do, please report back the results to share, as I'm interested in seeing how well it does work.

I think it looks (somewhat) promising. My test cases so far have been starting from circular, equatorial orbits with altitudes of 100km and traveling to a parking orbit of 100km for 1) Kerbin to Duna and 2) the Mun to Minmus. For iterating for the starting position, I arbitrarily capped it at 10 iterations and chose a tolerance of 1km. I generated Porkchop plots (with 101 start times x101 flight times) for these transfers and marked points where the starting position failed to converge.

For the Kerbin to Duna trip, the starting position failed to converge for 2.5% of the transfers. For the Mun to Minmus, the failure rate was much higher at about 20%. Plots below, with failures to converge marked with black dots. There is also the plot for Mun-Minmus without iteration for reference.

Kerbin to Duna

Mun to Minmus

With iteration:

Without iteration:

 

So it looks like this fails with transfer orbits that have high inclinations. It could be that small changes in start position cause drastic changes in the transfer orbit at these start/flight times.  I'll have to look more closely at what exactly is happening when this fails, and can share if I notice anything interesting.

I haven't yet touched anything about the target position of the Lambert problem, and I expect this will become a bit harder when we need to have convergence for both the start and end positions.

On 7/28/2020 at 6:18 PM, Arrowstar said:

I suspect the reality of the situation, though, is that you would have to eliminate the zero-radius SoI assumption and propagate the orbits through the patched conics directly, which is what the high fidelity tools in KSPTOT do.  This is not an easy task.

I'm curious about this. Do you have any papers/other resources that I could look at that give an introduction?

 

 

 

EDIT: I repeated the above tests for transfers with a mid-course plane change maneuver, and there were far fewer failures (0% and 1.3% respectively). So maybe high inclination is related to the problem, but not entirely to blame. Also, I expect failure would become a bigger problem again when getting rid of the zero-radius SOI assumption at the target.

Kerbin to Duna (plane change)

Mun to Minmus (plane change)

 

Sorry for all the huge plots.

Edited August 1, 2020 by theAstrogoth
typo

[Arrowstar]

3 hours ago, theAstrogoth said:

I'm curious about this. Do you have any papers/other resources that I could look at that give an introduction?

I'm afraid not.  I had to work out all of the SoI transfer logic myself because in general, commercial software does not work like KSP does.  It's not that hard in principle though: when you get to an SoI edge, you transform your position and velocity to be relative to the new SoI you're moving into, and then you propagate with the new gravity source.

[theAstrogoth]

I've updated the app with some major improvements:

• added insertion trajectory plots
• replaced 2D markers with 3D spheres to represent celestial bodies in plots
• added toggles for "cheap" start and end parking orbits, which match the inclination of the departure/arrival trajectories
• added functionality to manual selection of starting and ending orbital elements
• implemented "patching" across SOIs in attempt to give accurate predictions for arrival trajectories
• fixed bug in determining reference directions for certain orbits

I have made an attempt at using a genetic algorithm to getting near-continuous positions across SOI edges, but I still haven't figured out an easy way to get the solutions to converge for the high inclination interplanetary transfers. Since these tend to be transfers that are less desirable due to high Δv cost, I've just added a warning message for when the algorithm fails to converge, and then display trajectories calculated with the zero radius SOI assumption. All in all, I'm happy with this for now, especially since it works within the 30 second cap on computation time in free Heroku.

Here's an example of the level of accuracy I got for a trip from the Mun to Minmus. I used the Transfer Illustrator app to get the ejection trajectory parameters, and then I copy/pasted them onto a craft in HyperEdit in-game and let it coast until it got to Minmus. Comparison of actual and prediced orbital elements below:

It hit the target trajectory pretty well! It had similar success on a test trip from Kerbin to Jool, also. 

 

Next up is setting up some kind of config files/reader method to allow loading of different solar systems (e.g. RSS).

[theAstrogoth]

I've made few more helpful improvements:

• substantially reduced computation time (~1/3)
• added support for non-circular parking orbits
• added Sol system using orbital elements from the RSS mod
• added orbital elements to hovertext in 3D plots
• improved Instructions tab
• added UI element for choosing number of points sampled in the Porkchop plot
• fixed app behavior with blank/invalid inputs

Planned features:

• clipboard copy/paste of orbit parameters
• option to select transfers that match your start parking orbit's mean anomaly

 

I think I'm pretty close to having the kind of functionality I set out to provide with this app. The biggest problem I still need to solve is the limit on computation time for web servers in AWS or Heroku. Alternatively, I can try to package it as a downloadable program, but then you might as well just use the Trajectory Optimization Tool.

Otherwise, I'm considering reading up on using genetic algorithms for planning multi-gravitational-assist missions, but I think that sounds like a tall order for a small web app. The other thing would be calculating "finite"/low-impulse burn trajectories, but that probably requires some integration and optimization knowledge that I don't have yet.

Edited August 21, 2020 by theAstrogoth

[theAstrogoth]

A few more things for anyone following along:

• added option to match mean anomaly and epoch for a starting parking orbit
• added arrows showing burn directions and locations, with hovertext detailing prograde, normal, and radial components
• fixed bug in calculation of a transfer with a plane change maneuver
• improved display by hiding blank plots (e.g. if the transfer has no insertion trajectory)

I wanted to post a few screenshots showcasing the different kinds of things the app can do. So far, it can...

...show the ejection burn for your transfer. This one is from a trip from Kerbin to Moho. Hovering over any of the orbits or burn arrow would show the Keplerian elements or burn components, respectively.

...display the transfer trajectory. This one is a trip from Moho to Kerbin with a mid-course plane change maneuver.

...display the insertion burn. For this one, I set a custom, non-equatorial parking orbit around Jool.

...calculate transfers within a single sphere of influence. Here is a transfer from Minmus to a parking orbit around Kerbin. Also shown is a two-burn orbit change around Kerbin.

 

 

Let me know if there is anything in particular I should try to implement next!

[AbhChallenger]

I messed around with the app. However, unless I have messed up the settings. I can't get it to actually target the LAN of the arrival orbit. This is important for say resupplying a lunar station or proceeding to landing soon after orbital insertion. As correcting LAN is very costly in propellant.

Any possibility of implementing that?

[theAstrogoth]

58 minutes ago, AbhChallenger said:

I messed around with the app. However, unless I have messed up the settings. I can't get it to actually target the LAN of the arrival orbit. This is important for say resupplying a lunar station or proceeding to landing soon after orbital insertion. As correcting LAN is very costly in propellant.

Any possibility of implementing that?

If I understand correctly, you want to have a specific LAN/inclination on the insertion hyperbolic orbit. You're right that the app doesn't (yet) do what you're looking for; it uses the capture burn to match the orbital elements you supply for the ending orbit, and depending on the transfer, this could be expensive. When searching for a low delta-v orbit, the app should already prefer ones that don't require costly corrections. However, for transfers involving the Mun/Moon, the app may not return the "best" transfer right away, because of the relative size of the Mun's SOI compared to the transfer orbit, the initial estimate for delta-v shown in the porkchop plot tends to have a lot of error. Clicking around a bit in the plot, or adjusting the ranges on the departure and flight times, might help you find a lower-cost transfer.

I'll have to do some thinking to see if I can add matching for the insertion hyperbola itself, but calculating a transfer to match a target parking orbit is already sort of tricky (see some of the earlier posts in this thread).

I set up an arbitrary orbit around the Mun to hit from Kerbin. At first, the app gave an insertion burn that had a pretty big normal component, but it wasn't too hard to find another transfer that had a smaller one.

 

Would you mind sharing the details for your starting and ending orbits? Thanks for giving the app a try!

 

EDIT: I realized you might have left the "cheapest ending orbit" box checked, as it is by default. This makes the app ignore all the orbital elements you input other than SMA, and is intended for if someone doesn't have a specific target orbit in mind.

Edited August 25, 2020 by theAstrogoth

[AbhChallenger]

I don't have any exact orbits in mind. Just situations that have messed up my attempts to do different types of missions in the past.

 

For instance. I wanted to place a dedicated lander that can be refueled into lunar orbit first then transfer a crew to it for landing. What I quickly found was unless I was lucky. I almost never arrived in a similar LAN to the lander from Kerbin. So I ended up having to use large amount of propellant to correct the plane. So I tried to use your app to target just the LAN and even with those options off. The ending orbit is still a completely different LAN than I need.

I know you compute time is limited. So in my case. I just need the ability to match the plane. Or even just the LAN. I don't care if the ending orbit impacts the moon or barely scrapes the SOI. I can fix the orbit the moment I enter SOI. But LAN has to be changed at the node.

[theAstrogoth]

2 minutes ago, AbhChallenger said:

For instance. I wanted to place a dedicated lander that can be refueled into lunar orbit first then transfer a crew to it for landing. What I quickly found was unless I was lucky. I almost never arrived in a similar LAN to the lander from Kerbin. So I ended up having to use large amount of propellant to correct the plane. So I tried to use your app to target just the LAN and even with those options off. The ending orbit is still a completely different LAN than I need.

This is something that should be working already. Did you enter an LAN and inclination for the target orbit under the advanced settings tab? If so, your the orbit will match the plane you've specified. If not, you'll get an equatorial orbit by default.

[AbhChallenger]

It must have been because I did not set an inclination. As I was focused on LAN. That indeed seemed to have fixed it! Thanks!

[AbhChallenger]

1 hour ago, theAstrogoth said:

If I understand correctly, you want to have a specific LAN/inclination on the insertion hyperbolic orbit. You're right that the app doesn't (yet) do what you're looking for; it uses the capture burn to match the orbital elements you supply for the ending orbit, and depending on the transfer, this could be expensive. When searching for a low delta-v orbit, the app should already prefer ones that don't require costly corrections. However, for transfers involving the Mun/Moon, the app may not return the "best" transfer right away, because of the relative size of the Mun's SOI compared to the transfer orbit, the initial estimate for delta-v shown in the porkchop plot tends to have a lot of error. Clicking around a bit in the plot, or adjusting the ranges on the departure and flight times, might help you find a lower-cost transfer.

I'll have to do some thinking to see if I can add matching for the insertion hyperbola itself, but calculating a transfer to match a target parking orbit is already sort of tricky (see some of the earlier posts in this thread).

I set up an arbitrary orbit around the Mun to hit from Kerbin. At first, the app gave an insertion burn that had a pretty big normal component, but it wasn't too hard to find another transfer that had a smaller one. ..........

I actually want to request this if possible. You are right that it is not too difficult to find a smaller insertion burn. But for near polar orbits it is a bit more difficult to find a good one. Heavy fuel tankers really eat their propellant reserves with every meter per second they have to spend.

 

Edit: For instance playing with a random orbit I am able to get that normal burn down to 78.41 m/s

That is already far far better than what I was able to do before. Yet if I could just get that number down even further. I could save propellant for the lander.

Edited August 25, 2020 by AbhChallenger

[theAstrogoth]

16 minutes ago, AbhChallenger said:

Heavy fuel tankers really eat their propellant reserves with every meter per second they have to spend.

If you're only concerned about minimizing delta-v, then I think that the app might already be as helpful as possible, since it tries to minimize total delta-v for the transfer. Matching the insertion hyperbola would not necessarily help, since it might make your ejection burn more expensive. The only way you'd get any guaranteed benefit is if your burn at Earth/Kerbin parking orbit was somehow free.

I might consider adding the insertion-hyperbola-matching anyways, in case you wanted to match a particular flyby trajectory without any course corrections.

The big problem for your situation is that the estimated delta-v in the porkchop plot is much less accurate with transfers involving moons than it is for ones between planets. I'm stuck with this estimated value for selecting the "best" transfer because  it takes too long to calculate accurate delta-v for each possible transfer. If I eventually figure out how to get around this limit on computation time, it will be possible to make the app return the actual lowest delta-v transfer. But for now, you're stuck with clicking around a bit and modifying the search window.

[AbhChallenger]

Actually I would not mind having a more expensive ejection burn. If for instance. If I needed to spend 150 extra m/s on the ejection stage to save the tanker 78 m/s later that is fine because I normally have a dedicated ejection stage. Could there be perhaps a way to add weights or optimize for the insertion burn?

Regardless as it is now I should be able to do the missions I want once I return to playing KSP again. Thanks!

Edited August 25, 2020 by AbhChallenger

[theAstrogoth]

10 hours ago, AbhChallenger said:

Actually I would not mind having a more expensive ejection burn. If for instance. If I needed to spend 150 extra m/s on the ejection stage to save the tanker 78 m/s later that is fine because I normally have a dedicated ejection stage. Could there be perhaps a way to add weights or optimize for the insertion burn?

I've added a couple of alternate display options for the porkchop plot, so you can visualize the departure and arrival Δv separately. This might help if you're trying to minimize one or the other, as you described. Since the estimated Δv in the porkchop plot tends to not closely match the actual Δv once the trajectory has been patched across SoI changes (esp. for transfers involving moons), it might only be marginally helpful.

Sidenote: I played around with a few random transfers, and it seems that minimum total Δv and minimum arrival Δv transfers seem to mostly overlap, as you might expect.

[AbhChallenger]

I just did a quick test and found that at 89 deg inc. Total dv favored saving fuel on the departure stage. However I did find that for a small increase in cost for departure. The theoretical tanker would slowly drift into a great LAN at SOI change. Your display options helped me to find that balance so thank you!

When I send the crew. I would spend the extra propellant to arrive at a normal time.

[theAstrogoth]

5 hours ago, AbhChallenger said:

I just did a quick test and found that at 89 deg inc. Total dv favored saving fuel on the departure stage. However I did find that for a small increase in cost for departure. The theoretical tanker would slowly drift into a great LAN at SOI change. Your display options helped me to find that balance so thank you!

When I send the crew. I would spend the extra propellant to arrive at a normal time.

I'm glad the change was helpful! When you try this out in-game, let me know if you're successful.

I haven't been doing much in-game testing, but I realized today that I might be setting moon positions incorrectly. Things will always work for transfers between two different moons or between two different planets, but I suspect that for a transfer from Kerbin to the Mun, for example, the app will have everything shifted by some angle. Need to look into how the game sets reference directions for moons.

[theAstrogoth]

I was inspired by the 3D KSP Solar System Model and the really cool KSA Operations Tracker to add a few things to the 3D orbit plots:

• Sliders that change the positions of all moons/planets and the vessel's position in the transfer trajectory by adjusting the time
• SoI spheres around celestial bodies
• 2D Markers in addition to the 3D spheres for celestial bodies, so they stay visible when you zoom out

I might eventually add more elements (apoapsis, periapsis, asc/descending nodes) and make things toggleable.

Here's how the transfer plot looks for a trip from the Moon to Minmus. I thought that seeing the SoIs at departure and arrival was pretty cool.

 

 

[theAstrogoth]

False alarm about moon positions. Positions in the app match those in the 3D KSP Solar System Model.

I followed through with adding some additional display elements, mostly copying the toggles from the KSA operations tracker (shoutout to @Drew Kerman !) I've also made it so that the orbits of all bodies show a full period. Here's a screenshot of the Joolian system with some of the new additions:

 

[HebaruSan]

On 8/24/2020 at 9:46 PM, theAstrogoth said:

Let me know if there is anything in particular I should try to implement next!

I realize this is probably a big ask, but it would be amazing if those images you're sharing were interactive (drag to rotate the view) on the forum as they are on the real app, similar to how tweets can be embedded. Presumably that would require creating a plugin for the forum and getting the moderators/admins to enable it, so I won't hold my breath, but maybe they'd be up for it if they saw the potential.