OpenRocket Export to OBJ Issues

[boatgeek]

I'm working on my first OR-to-3D print design, and I'm running into an interesting issue. I would like to cap the ends of my nose cone and transition for a couple of reasons, but when I cap the ends in OR, the entire transition and/or the entire nose cone gets filled in. The OR file and and STL file of all of the .OBJ objects are attached.

In the image below, you can see the uncapped (and unfilled) cone and transition on the left, and the filled on the right. The transition just has the aft end capped--if I cap the forward end, the entire thing becomes a solid like the nose cone.



In other info, OR's mass calculations appear to reflect just a cap on the end, not the entire filled volume. Can you tell if this is a setting issue vs. a bug in the software?

Thanks!

 

[neil_w]

Could be a bug. Paging @SiboVG.

In the meantime could you work around it by leaving it uncapped, then putting a bulkhead where the cap would be?

 

[boatgeek]

Could be a bug. Paging @SiboVG.

In the meantime could you work around it by leaving it uncapped, then putting a bulkhead where the cap would be?

I definitely can, and that might be the best solution. The next issue is that I'd really like to have three holes in the "centering ring" cap. I'm making it as if it were a cluster centering ring, but OR isn't cutting the outer holes for some reason. They show on the template, but not in the .OBJ output. That's still relatively easy to fix with a drill press though.

 

[neil_w]

It would not be surprising if there are various little edge cases like this that aren't quite right yet... keep reporting what you find, we'll get it all cleaned up eventually.

(Filing directly on Github would be especially helpful, if you're able).

 

[SiboVG]

I think I coded this on purpose. If you have a fully capped geometry and would include an inner mesh, some slicers can act up because your geometry is not manifold anymore (you have a floating mesh inside your outer mesh). I guess at one point we'll have to introduce an extra setting to pick between manifold geometry and "true" geometry.

 

[jhill9693]

Yeah, I don't think this is a bug. How would your printer print the top cap without some sort of internal support? Print as a solid object with low infill, such as 20% or maybe even less.

 

[boatgeek]

I think I coded this on purpose. If you have a fully capped geometry and would include an inner mesh, some slicers can act up because your geometry is not manifold anymore (you have a floating mesh inside your outer mesh). I guess at one point we'll have to introduce an extra setting to pick between manifold geometry and "true" geometry.

[sorry for the late reply--I lost notifications on this thread]

I see here you're going with that for transitions, particularly where both ends are capped. Where one end is capped, I don't see the value of filling up the shoulder--that doesn't seem to be any different for the printer than just an end cap. If just the top were capped, the part would have to be rotated in the printer to print upside down.

For the nose cones, I don't think that the printer would have any more issues with the geometry than they would for a hollow nose cone with no end cap. I see where you're coming from on slicers, though. I don't have enough experience to know their quirks.

For both nose cones and transition pieces, the part as modeled in the .OBJ is almost certainly heavier than the OpenRocket model. From my limited testing, the OR model correctly added the weight of the thickness of an end cap, but did not add the weight of the fully-filled in shoulder. I know the shoulder would normally have some small percentage infill, so the finished part wouldn't likely be as overweight as a model with full density in the whole shoulder. That's an area that I don't really know how to navigate, but might be good to tell the user about.

 

[thzero]

Yeah, I don't think this is a bug. How would your printer print the top cap without some sort of internal support? Print as a solid object with low infill, such as 20% or maybe even less.

Add supports in the slicer

 

[RocketTree]

I didn't want to start a new thread for this, so hope you don't mind if I add to this one...

When I export an OBJ file for a part in OpenRocket, I could always open it with Creality Slicer and start printing. No problem, until yesterday. Now I get the error in Slicer "Failed to load. File may be corrupt or inaccessible". It still opens nose cones, but will not open centering rings, tubes, or other parts in Slicer. It does open centering rings and parts that I previously exported from OR in the past, with no problem. I have tried making a dozen different files, rings, parts, etc and get the same result.

I have the latest OR version and haven't changed anything.

Any ideas?

 

[SiboVG]

I didn't want to start a new thread for this, so hope you don't mind if I add to this one...

When I export an OBJ file for a part in OpenRocket, I could always open it with Creality Slicer and start printing. No problem, until yesterday. Now I get the error in Slicer "Failed to load. File may be corrupt or inaccessible". It still opens nose cones, but will not open centering rings, tubes, or other parts in Slicer. It does open centering rings and parts that I previously exported from OR in the past, with no problem. I have tried making a dozen different files, rings, parts, etc and get the same result.

I have the latest OR version and haven't changed anything.

Any ideas?

Could you also share one of the .obj files that triggers the error please?

 

[RocketTree]

Could you also share one of the .obj files that triggers the error please?

For sure, here are some examples. I had to change the filename to .TXT from .OBJ so it would attach to my post. Thanks!

 

[thzero]

For sure, here are some examples. I had to change the filename to .TXT from .OBJ so it would attach to my post. Thanks!

The ork file might be useful too..