OpenRocket... A few items for my wish list.

shop deals on amazon
the model rocket show
Shop deals on ebay
SilicdyneTRF
The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
OK, I successfully got the unstable version running from inside Eclipse (where the 3D views will work, although the bug on the Mac when exiting 3D finished view is still there :(). My assessment of the pods implementation in its current state is "better than nothing, but not great". At the moment at least, pods are associated with the sustainer, and so if you want to have pods connected to the ends of fins you have to calculate exactly where that will be, and then configure the pods accordingly. That means a lot of calculation whenever you set it up initially, and then a lot of recalculation any time you want to make adjustments to the design.

Because fins can still only be attached to body tubes, fins attached to fins require pods and then 0-diameter body tubes (yay, more phantom BTs) to attach them to. Ring tails are still not implemented.

Certainly, the new capability will make it *possible* to do a lot of new stuff with designs, but unless some significant improvements are made, it's not going to be fun.
 
K'Tesh said:
You can see more about it in my tutorial thread:

https://www.rocketryforum.com/showt...-s-OpenRocket-Tutorials&p=1595653#post1595653

https://www.rocketryforum.com/showt...-s-OpenRocket-Tutorials&p=1595899#post1595899
Click to expand...

OK, I think I followed your procedure correctly (took me awhile to figure out I had to type in the -x values, I couldn't drag the points beyond zero until I entered a couple negative values).

Here is my result...looks like the technique makes pretty pictures, but not accurate for stability calcs for V2 rockets...please OR developers, give us fins on transitions!!!

V2_BT101_OR.jpg

View attachment V2_BT101.ork
 
Last edited:
I decided to give the OR-Unstable file a try but got Java error 13. Any thoughts or am I just getting in over my head?
 
Screaminhelo said:
I decided to give the OR-Unstable file a try but got Java error 13. Any thoughts or am I just getting in over my head?
Click to expand...

I believe it may be due to a difference between Eclipse and the JRE that you have installed, perhaps one is 32-bit and the other is 64-bit?
 
That was exactly the problem. I downloaded 64 bit because that is what I used to have. The 32 bit version opened up just fine. Thanks for the reply
 
Now that was kind of fun! 5 motor cluster with a central D12, 4 A10T's in boosters and 4 more A10T's in pods!

It looks like the developers are working on the list of wants (pods, boosters and fractional inches are what I have noticed so far). It's not RocSim, yet, but you can't beat the price!
 
I've been using it to fiddle with some new designs. Great for someone like me who needs to visualize something to get a feel for it. One thing I have noticed in this version is that it seems to currently sim only one of the motors in multiple side boosters. I was getting half the expected altitude in OR versus the same design in RockSim as a test. Simulation accuracy for the new stuff is just not there yet.

The take-away though, for me, so far of all this messing with the unstable branch is the assurance that they are in fact working on adding some cool stuff.

Fun for tinkering with different designs that aren't possible with the release version however, sooner or later these new features will have to sim accurately. I think that is the real focus at the moment. The #1 purpose of OpenRocket is simulation. New stuff has to sim properly before it's released. That takes time. After digging thoroughly into the code, I can appreciate that this is a really hefty project that people are building with their free time.

There's a lot I like about RockSim. Only thing is that it's closed source and isn't free. Worth it? Perhaps. Depends on what you need. OpenRocket isn't far behind though and I like where they're going with it.
 
After seeing someone on FB gluing on fins in the "Pop Fin" orientation, I'd love to see OR include grain direction markers for fin templates (could help the noobs).
 
I'd love to see an "Inner transition" so I could sim parts with a conic section (such as Estes PNC-50Y (blow molded) nosecones).
 
Who was it that was asking for simulation results to be able to be copied to a spreadsheet? I've wanted that too. I just checked the current build and it's been added today! Very cool. Just select the lines, right click, copy, then in Excel, paste. BOOM!
CaptureX.PNG

Also exporting freeform fin coords to CSV is in as well.

Thanks to "dkingsley" on GitHub for these :clap:
 
Cabernut said:
Who was it that was asking for simulation results to be able to be copied to a spreadsheet? I've wanted that too. I just checked the current build and it's been added today! Very cool. Just select the lines, right click, copy, then in Excel, paste. BOOM!
View attachment 310839

Also exporting freeform fin coords to CSV is in as well.

Thanks to "dkingsley" on GitHub for these :clap:
Click to expand...

Wow, that was me! I will have to make sure I have the latest version...thanks for the update!
 
I have been putting off deep diving into Java for years, I knew enough Java to be able to follow code but I mainly work in C#, C++, and C. I used the copy-to-clipboard and export free form fin to Csv files to somewhat stretch my capabilities. I did this while iterating on my L3 documentation, and I am glad other people find it useful.

I have a couple more little helper items for OpenRocket that I hope to clean up in the next week. Also, today I pushed the initial Rhino plugin code to gitHub that will read an OpenRocket file and create a 3D solid model. The code does not support all features of OR yet, but for a single stage rocket is should be pretty good.

OpenRocketSample.png

RhinoSample.png

RhinoSampleBodyTubesTransparent.png
 
Not sure if I have posted this feature request but here goes... the ability to print ogive transitions just like nosecones (I use the nose cone print to create patterns for turning my own nose cones, or add the ability to add tailcones either conical or ogive and have them print the same way nose cones do.
 
A FB post got me thinking... Payloadbay.com's Fin Guide Tool (which has us enter our BT diameter, # of fins, fin thickness, and fin span) is a very powerful tool. I absolutely LOVE it... However, I am always in a little fear that the site will someday disappear. Also, it doesn't have a way of handling fins that are not perpendicular to the surface of the body tube.

Would OR be able to create a similar tool that could be printed from a rocket's file that would overcome that issue? I could imagine it automatically adjusting when a rocket is upscaled/downscaled (provided that the fin thickness is updated to be accurate should it not be a perfect upscale/downscale).
 
A hopefully "easy" feature to add if its not in there already:

I'd like the default configuration name to include the case, such as [{motors} {case}] so I don't have to do this manually for each configuration:

1682474520898.png

I find this helpful on the simulations page so I can quickly see what size motor hardware is used for each row.

1682475009917.png

Digging through the source code, it looks like {manufacturers} should work here too, but it didn't for me. Are there other fields available?

Thanks for all the work the team has put into OpenRocket.
 
CoAz2k said:
A hopefully "easy" feature to add if its not in there already:

I'd like the default configuration name to include the case, such as [{motors} {case}] so I don't have to do this manually for each configuration:

View attachment 577267

I find this helpful on the simulations page so I can quickly see what size motor hardware is used for each row.

View attachment 577268

Digging through the source code, it looks like {manufacturers} should work here too, but it didn't for me. Are there other fields available?

Thanks for all the work the team has put into OpenRocket.
Click to expand...
I second that feature request since I also add the case size manually.
 
CoAz2k said:
A hopefully "easy" feature to add if its not in there already:

I'd like the default configuration name to include the case, such as [{motors} {case}] so I don't have to do this manually for each configuration:

View attachment 577267

I find this helpful on the simulations page so I can quickly see what size motor hardware is used for each row.

View attachment 577268

Digging through the source code, it looks like {manufacturers} should work here too, but it didn't for me. Are there other fields available?

Thanks for all the work the team has put into OpenRocket.
Click to expand...
Filed as issue #2204: https://github.com/openrocket/openrocket/issues/2204
 
CoAz2k said:
Digging through the source code, it looks like {manufacturers} should work here too, but it didn't for me. Are there other fields available?
Click to expand...
It was added after the 22.02 release, so it will only work in the next OR release.

Luckily for you, I did do some extensive rewriting of the flight config naming code, so shouldn't be too difficult to implement :).
 
That will be awesome. I know my hardware well enough to not need the manufacturer included, but sometimes I get my similar average impulse motors from different manufacturers mixed up. Lots of H123, H125, H128, etc. out there. The difference in case designations would tell me instantly whether that one was CTI or AT.
 
Request:-
Ability to export a csv file of the profile between 2 nominated points at a nominated interval (1mm or 0.5mm for detail, but able to choose your own spacing). This would allow you to generate a nosecone or transition for 3D printing easily with a bit of simple data manipulation.
 
RocketScientistAustralia said:
Request:-
Ability to export a csv file of the profile between 2 nominated points at a nominated interval (1mm or 0.5mm for detail, but able to choose your own spacing). This would allow you to generate a nosecone or transition for 3D printing easily with a bit of simple data manipulation.
Click to expand...
Wouldn't it be easier to just have us support 3D export of each rocket part? (I am working on this, but at a slow side-project pace)
 
SiboVG said:
Wouldn't it be easier to just have us support 3D export of each rocket part? (I am working on this, but at a slow side-project pace)
Click to expand...
No.
With the coordinates between 2 points, which you should be able to get as you have the profile drawn, you can then import them into any cad program and produce a nosecone or whatever. Sometimes to produce a nosecone, it's more than a single nosecone profile. A nosecone could be a round nose followed by a transition followed by another transition. An example would be the Der Red Max nosecone, but there are many others. A simple export of the points between 2 points gives all of those components that form an actual nosecone in one go. For a Thunderbird 1 nosecone, I think there were 8 transitions to get the shape.
With each component exported as an STL, you'd need to stack them and join them.
I've got a nosecone design program for SCAD as does Bill Kalsow. They do all the secondary stuff required to make a nosecone already, like wall thickness, shoulder support for printing without having a full support all the way to the bed and a few other things for printing in the real world. It would be easy to integrate the points method and then export an STL after.
Most nosecones printed are not just a skin with infill these days.
The points export gives a simple solution with data that's easy to manipulate.
What do you think? Which is easier?
 
Last edited:
RocketScientistAustralia said:
No.
With the coordinates between 2 points, which you should be able to get as you have the profile drawn, you can then import them into any cad program and produce a nosecone or whatever. Sometimes to produce a nosecone, it's more than a single nosecone profile. A nosecone could be a round nose followed by a transition followed by another transition. An example would be the Der Red Max nosecone, but there are many others. A simple export of the points between 2 points gives all of those components that form an actual nosecone in one go. For a Thunderbird 1 nosecone, I think there were 8 transitions to get the shape.
With each component exported as an STL, you'd need to stack them and join them.
I've got a nosecone design program for SCAD as does Bill Kalsow. They do all the secondary stuff required to make a nosecone already, like wall thickness, shoulder support for printing without having a full support all the way to the bed and a few other things for printing in the real world. It would be easy to integrate the points method and then export an STL after.
Most nosecones printed are not just a skin with infill these days.
The points export gives a simple solution with data that's easy to manipulate.
What do you think? Which is easier?
Click to expand...
The 3D export would not be in STL, but in OBJ, as this makes the model editable (editing STL files is a nightmare). You can then still easily edit the OBJ (e.g. wall thickness) in CAD software, and then export that to STL.

IMO your request is a bit niche, so OBJ exporting will probably be implemented before this.
 
SiboVG said:
The 3D export would not be in STL, but in OBJ, as this makes the model editable (editing STL files is a nightmare). You can then still easily edit the OBJ (e.g. wall thickness) in CAD software, and then export that to STL.

IMO your request is a bit niche, so OBJ exporting will probably be implemented before this.
Click to expand...
Hi Sibo,
There are obviously many ways to do something. I think you'll find that while nosecones are produced by programs like Fusion that use obj files, Programs like scad can produce parametric nosecones and fin cans that are easier in general for users to produce and print. Not everyone is an expert in Fusion and it's not a simple program to be expert in.
I recognise that I'm not the one that's going to have to do the work to produce a points export from OR. But again am requesting it as a resource to all.
Happy for you to PM me to see if there's a way through this that will work.

Appreciate all the development team's efforts.
 
Having had a chance to think further, an OBJ export would work for me. It would be really useful if multiple pieces could be exported as a single OBJ file. :)
Like all of the Der Red Max nosecone, not just the tip...
Cura can import them, I can stack if required and then export back to SCAD
:)
Would this be in the next release? Happy to beta test it.
 
Last edited:

Similar threads

Anonymous
Optimizing Fin Shapes in Rocksim
2
Replies
31
Views
1K
Brandon.L
Brandon.L
SolarYellow
Bertha/Ranger/etc. & commercial "elliptical" nose cones
Replies
4
Views
352
SolarYellow
SolarYellow
Back_at_it
Estes Impulse down scale. Calling this one "Half Impulse"
Replies
12
Views
999
Back_at_it
Back_at_it
billmi
The obligatory introduction
Replies
8
Views
608
billmi
billmi
mago0
5.5 Goblin build for my L1
2
Replies
32
Views
2K
mago0
mago0

Latest posts

Back
Top