{"id":834,"date":"2026-10-12T04:55:08","date_gmt":"2026-10-12T04:55:08","guid":{"rendered":"https:\/\/openvsp.org\/blogs\/?p=834"},"modified":"2026-10-12T04:55:08","modified_gmt":"2026-10-12T04:55:08","slug":"openvsp-3-55-0-released","status":"publish","type":"post","link":"https:\/\/openvsp.org\/blogs\/announcements\/2026\/10\/12\/openvsp-3-55-0-released","title":{"rendered":"OpenVSP 3.55.0 Released"},"content":{"rendered":"<p>This was going to be a .1 fix release, but along the way it gained a bunch of API extensions that I think warrant a .0 release.  After that, it grew.  And grew.  And wouldn&#8217;t stop growing.  No shiny features here, it is pretty much fixes across the board.  However, it is a ton of stuff.<\/p>\n<p>Typically OpenVSP work is driven by features identified by my sponsors.  This works out pretty well for everyone.  However, every once in a while, I like to take a chunk of time and hit issues identified by community users.  This release is the result of one of those sprints.<\/p>\n<p>The inspiration for this sprint was the Parasite Drag tool.  As I experiment using AI to help with my side projects and more recently OpenVSP, I am always worried about introducing AI Slop.  The truth is, Human Slop is also a thing.  The Parasite Drag tool is one such example.  It was developed many years ago by someone without a ton of experience.  I clearly should have done a lot more code review of it (and ended up rewriting a lot of it), but I didn&#8217;t.  I&#8217;m sure bitrot has made the situation worse, but there were a lot of problems that have clearly been there from the start.<\/p>\n<p>Recently, a friend was trying to use it and was hitting many frustrating obstacles.  The tool was unusable.<\/p>\n<p>I don&#8217;t have time to go down this particular rabbit hole, so I threw AI at it.  I didn&#8217;t quite say &#8220;Claude, here is a dumpster fire, fix it&#8221;, but it was pretty close to that.  I gave some guidance along the way.  I reviewed all the changes (but without reviewing the original or resulting code overall).  So, here is the result.  I&#8217;m optimistic, but not naive.  I&#8217;m sure it isn&#8217;t perfect, but I&#8217;m also counting on the fact that it can&#8217;t possibly be worse than what it was.  Hopefully it is now in a good enough place that people can use it, make bug reports, and we can converge to something of the standard that we expect.<\/p>\n<p>The API changes that drove the .0 release were driven by the observation that there were many methods that accessed other entities by index (position in an array) when they could instead access them by ID.  For example, setting the material properties for a part in a structure.<\/p>\n<p>So, we did a big audit to search out anything in the API that accessed things by index and added new ID based versions alongside.  No existing calls were changed or removed, but there are a bunch new API calls alongside your old favorites.<\/p>\n<p>While we were there, we made another pass at API consistency, this time in the name of error messages.  Now the error numbers returned should match the failure and the messages should all match the offending API function.<\/p>\n<p>A certain pathological case for surface-surface intersection was incredibly slow.  One example file went from 13.5 minutes to 40 seconds.  Most models aren&#8217;t pathologically bad, but still benefit nicely from the fix.<\/p>\n<p>While we were there, we noticed that memory usage was surprisingly high.  Changing two std::deque to std::vector in one place (none of the deque capabilities were being used) took peak memory usage from 52GB to 10GB.  A bunch more work reduced it to 6GB (and it got faster too).<\/p>\n<p>The back calculation of a simple retraction mechanism for a stowed gear was broken, it should be fixed and improved.<\/p>\n<p>That led to some esoteric trigonometry floating point accuracy fixes that nobody will ever notice or need, but they&#8217;re there now.<\/p>\n<p>Some Geometry Analysis GUI features were not behaving consistently.  Options that should be deactivated were active (but of course didn&#8217;t work).  Things should be consistent now.<\/p>\n<p>A problem with geom placement driven by RoutingGeom messing with the update path has been fixed.<\/p>\n<p>Some problems with Projected Area not accepting projection direction in the expected way have been resolved.<\/p>\n<p>POGS gcomp files now replace spaces in component names with underscores.<\/p>\n<p>A seam in the mesh when splitting and joining tip caps was being dropped.  Now it isn&#8217;t.<\/p>\n<p>The CompGeom wetted volume calculation would sometimes fail to allocate all the volume.  A new algorithm is faster and more accurate.<\/p>\n<p>CompGeom also now does a better job classifying inside\/outside for coincident tris.<\/p>\n<p>There were a lot of other fixes in there, but this seems like enough.<\/p>\n<p>Features:<\/p>\n<ul>\n<li>API: everything reachable by ID; consistent error reporting<\/li>\n<\/ul>\n<p>Build System:<\/p>\n<ul>\n<li> Intel Mac VSPAERO no longer needs libomp installed<\/li>\n<li> libIGES updated<\/li>\n<\/ul>\n<p>Bug Fixes:<\/p>\n<ul>\n<li> Parasite Drag overhaul<\/li>\n<li> Large memory reduction in CFDMesh, FEAMesh and trimmed CAD export<\/li>\n<li> Much faster surface intersection on thin, tilted surfaces<\/li>\n<li> Landing gear stowed position converts to an equivalent mechanism<\/li>\n<li> More accurate angle and transformation calculations throughout<\/li>\n<li> Geometry Analysis: API and GUI apply the same settings; up to 200 slices<\/li>\n<li> Mode, set and Projection choices kept in the file and across screens<\/li>\n<li> A Routing Geom could move the Geoms its points sit on<\/li>\n<li> Projected Area direction from a Geom was stale or applied before the Mode<\/li>\n<li> From Point Visibility crashed with a point secondary<\/li>\n<li> A Geom can no longer be made a child of something that depends on it<\/li>\n<li> CompGeom: no garbage volumes from propeller disks and ground planes<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>This was going to be a .1 fix release, but along the way it gained a bunch of API extensions that I think warrant a .0 release. After that, it grew. And grew. And wouldn&#8217;t stop growing. No shiny features &hellip; <a href=\"https:\/\/openvsp.org\/blogs\/announcements\/2026\/10\/12\/openvsp-3-55-0-released\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":16,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-834","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/posts\/834","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/comments?post=834"}],"version-history":[{"count":1,"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/posts\/834\/revisions"}],"predecessor-version":[{"id":835,"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/posts\/834\/revisions\/835"}],"wp:attachment":[{"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/media?parent=834"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/categories?post=834"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/openvsp.org\/blogs\/wp-json\/wp\/v2\/tags?post=834"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}