Feature wishlist

The feature wishlist details some desired features for OpenRocket, concentrating on ones that can reasonably well be implemented without deep knowledge of the OpenRocket internals. If you find something you'd like to contribute (or make something up yourself), please inform us about that on the OpenRocket-devel mailing list and we can help you get started.

This page complements the distribution TODO file, which contains more ideas in a shorter form. Please feel free to comment on the issues.

UI improvements

There are various places in need of attention in the UI. The UI code is also in some places a bit messy, and should be cleaned up.

• Intuitive zooming of the plots
  • normal magnifying glass buttons for zoom in/out
  • currently click-drag towards the lower-right zooms in, towards the upper-left resets the zoom to original - very unintuitive (JFreeChar default)
  • should be implemented as a generic component that could be used in various places
• Ctrl+scroll wheel should zoom in/out the rocket design (and maybe also plots)
• Component databases
• Rework base frame to have better use of realestate. Replace the component selection box with something smaller and reuse that space for editing components. Perhaps use a library like InfoNode Docking Windows

3D view of the rocket

A 3D view of the rocket is greatly desired, but I have no experience in 3D programming. Below are a few ideas or a "wish list" (not all need to be implemented!)

• 3D view as an alternative to the side and back rocket view
  • rotation using the mouse drag-and-drop
  • either "normal" view or a translucent view, where the opacity of each component is something like 0.3-0.5
  • decals - allow a user to define 1-n images that are positioned at some point of the rocket body or fins
  • allow configuring a spiral wound for body tubes
  • selecting components by clicking on them (like you can in the 2D view). Not sure whether it's a good idea to show the selected component in any special way though.
  • allow defining "shininess" of the component (there's really something like 3 parameters controlling this, but for UX I think we should try to make a single parameter which works reasonably for all)

• An animation of a simulated flight
  • general overview of flight (with possibility to magnify the rocket)?
  • different camera angles to choose from, some ideas:
    • launcher view
    • profile view
    • a camera attached to the rocket pointing to the side / tail
    • a camera moving along with the rocket either from the top or side
  • selectable launch scenery
  • allow selecting whether xyz-axis are displayed on the rocket during flight
    • provides a visualization of what the rocket is doing during the flight
    • rocket movement often very hard to visualize looking at just graphs
    • may require additional flight parameters to be stored during simulation

Printing support

Printing is one of the most asked-for features for OpenRocket. At the same time it would be natural to allow exporting the same as PNG, SVG or PDF.

Support can be implemented in various levels. At least the following are candidates for places where print/export may be desireable:

• fin templates, conical transition/nose cone templates, nose cone profiles
• the rocket design view
• the simulation plots (JFreeChart has some support built-in)
• printing a design report (see below)

Creating/printing a rocket design report

The ability to create a report containing the most important design information to present to a RSO at a launch event. The structure of the report could be something like the following:

• Title
• Section describing the rocket in general without motors
  • design name
  • empty mass & CG
  • CP position
  • CP position at 5 degree AOA (or similar)
  • number of stages
  • parachute/streamer sizes
  • max. diameter (caliber)
• Section for each motor configuration
  • a summary of the motors, e.g. 3xC6-0; B4-6
  • a list of the motors including the manufacturer, designation (maybe also info like burn time, grams of propellant, total impulse)
  • total grams of propellant
  • total impulse
  • takeoff weight
  • CG and CP position, stability margin
  • predicted flight altitude, max. velocity and max. acceleration
  • predicted velocity at chute deployment
  • predicted descent rate
• Diagram of the rocket (positioned vertically on the right side of the first page)
  • CP position
  • CG position without motors and in each configuration (the labels should alternate on right and left sides to avoid being on top of each other)

The user flow could be something like the following:

• Select from menu Rocket -> Design report
• A dialog opens to ask which motor configurations to include in the report
  • maybe ask paper size as well
• Simulations are run for each to get most up-to-date info
• Report is shown to user, allowing them to save or print it

Technical considerations:

• Predicted data readily available from OR (ask for details)
• The rocket plot can and should use the same rendering as the design window
• How to define launch conditions? Should the user select simulations to include in the report instead of motor configurations?

One issue is also in what format and how to create the report. Below are a few alternatives that have been considered, others are possible as well.

• Generate the report in HTML
  • Pros:
    • easy to generate
    • can be displayed using a JTextPane
    • allows saving as HTML
    • easy to print from Java using JTextComponent.print()
  • Cons:
    • including the plot might be problematic and requires a separate file when saving
    • rocket diagram needs to be in raster format
    • no support for smart pagination
• Use iText or some other PDF generator
  • Pros:
    • exported directly as PDF, only one file in output
    • more control, can produce more professional-looking output
    • rocket diagram can be in vector format
    • can be better paginated
  • Cons:
    • may be more difficult to generate(?)
    • smart pagination may be challenging / require additional work
    • displaying and printing the report may need separate support (maybe using PDFBox?)
• Generate LaTeX document and figures for later compilation
  • Pros:
    • Extremely high quality output
    • Equations, pagination, sections, hyperlinks and anything else you could want
    • Fully vectorised graphics
    • User can easily manually customise output file
    • Easy to program on the Java side as just generating plain text
  • Cons:
    • Requires an external LaTeX distribution
    • Not everyone knows LaTeX.

Rocket Model and Simulation enhancements

• Add deployment events, ignition events, and other rocket components to be modified per configuration. Examples of configurable properties:
  • mass objects to support models with changable nose weight or different electronic configurations
  • different recovery devices used for different motor selection
  • use different deployment events (different altitude settings for example) with different motors
  • better model high power staging and air-starts
• Support fins on transitions

Memory profiling

OpenRocket seems to consume quite a lot of memory, and likely has numerous memory leaks. (During initial development the effort was on getting it to work, not managing memory.) Below are a few suggestions what could be done to improve the memory handling.

• Profile OpenRocket's memory usage to find potential leaks
• Implement a scheduled task that checks the memory usage every ten seconds or so
  • Warn the user if 90% of available memory has been used
  • Offer to send memory profiling data automatically to developers (?)

Aerodynamic computation enhancements

While OpenRocket produces reasonably accurate results for typical model rockets, there are many cases which are in need of expert attention.

In most cases the implementation can be done by the core developers if only clear methods are available!

• Drag and CG estimation at higher supersonic speeds (>1.5M) are currently poor

• Support for additional components, such as external pods and tube fins
  • Estimation of CG, CNa and drag coefficient are required

• Roll rate estimation is off by about a factor of two for unknown reasons (see sections 3.3 and 6.3 of the technical documentation)

• Aerodynamic force computation using CFD (computational fluid dynamics)
  • Should preferably use some standard package such as Elmer or OpenFOAM
  • Communication either using JNI or stdin/stdout to a standalone executable
  • Implementation requires at least:
    • creation of the simulation mesh
    • calling the computational method
    • deducing the forces and moments (preferably being able to separate the contribution of different components)
    • cacheing and interpolating data for efficient simulation
  • Visualization would be a great plus!
• Should implement warning when the descent velocity is too high
• Support parachutes with holes, x-form parachutes
• Custom shaped nose cones - perhaps the aerodynamics could be estimated by approximating the shape with a series of transitions.