This version is dedicated to the X-57 Maxwell.

I remember the joy and excitement the team had as they watched
Administrator Bolden announce the program and the first piloted
NASA X-plane designation in more than a decade.  I was in the
audience at Aviation 2016 poised to upload the model to the Hangar
as soon as the announcement was made.

OpenVSP played at least a small part in the early stages of the
program.  Fit Model was used to build the fuselage model for the
Tecnam.  Nick used OpenVSP for the configuration studies.  Jeff used
it for the wing design.  Brandon designed the signature folding props
and nacelles.  He went on to maintain the definitive geometry that
would be the basis for all the CFD studies you've seen.  There are
other uses and users that I am regrettably leaving out.  It was an
honor to support their work and to have OpenVSP make a contribution.

This week, I'll join those friends and many others at the X-57
Closeout to glean what I can from the vast learnings of this team.
I know this didn't turn out the way you'd all hoped.  I also know
that you've made a big contribution to aeronautics.  You've changed
the design space.  You've moved the needle forward.  Congratulations
on your collective success.  Thank you for all your work.


Once again, this release has been a long time in the making.  There are
only a handful of main themes here -- and while you might not think they
apply to you, I strongly encourage everyone to upgrade.  In addition
to some really cool advances (that you might not need), there are a ton
of smaller improvements and fixes that will benefit everyone.

So go ahead and start your download before you finish reading this
message.  I'll wait here until you come back.

Thomas Nascenzi & the team at M4 Engineering and I teamed up on an SBIR
for the Navy starting a bit over two years ago.  While lots of smaller
features from this effort have already been released, this release
marks a milestone in this project -- the general release of what was
originally the 'big ask'.  Don't worry, there will be a lot more
progress from this project to share in the future, but this is an
exciting development for everyone involved.

The Navy uses a couple conceptual design tools (ADAPT and AIDEN)
that can use OpenVSP as a geometry engine.  They talk to OpenVSP
through the Python API.  These tools have a GUI front-end that the user
spends most of their time with.  The Navy wanted to be able to have
the OpenVSP GUI open and interactive at the same time as their other
aircraft design tool's GUI was open and actively manipulating the OpenVSP
model.  Change something in ADAPT, see the change in OpenVSP and
vice versa.

This may seem straightforward, but there is a lot of magic that has to
happen for this to work.  Making it work took a lot of Python magic as
well as a lot of C++.  Thomas and I worked together on this -- with
Thomas handling all the Python (and the good ideas) and me supporting
with whatever was needed on the C++ side.

So, you can now have an OpenVSP GUI open and interactive while your
custom Python application pounds away.  At a minimum, you'll be able
to visualize and interact with a 3D model of your concept as your
optimization study progresses.  I have no doubt that users will come
up with many more applications for this capability.

Of course, having a fully-featured OpenVSP GUI open while another
program is manipulating the model may seem like running with flaming
scissors.  It might be.  To address this, we've added some
'parental control' API routines.  These calls allow you to disable
certain features and capabilities in the OpenVSP GUI.  For example,
you can Nerf the OpenVSP GUI to a view-only interface for a
model.  We'll see how this works out in practice and if more is needed.

We've moved the API documentation from being specified where things
are registered in AngelScript to their native C++ home.  This also
allows us to generate a parallel set of Python documentation for
the API.  Going forward, the OpenVSP website will host both Python
and C++ / AngelScript documentation for the API.  The Python docs
are also now included in the openvsp package and should be available
in your IDE when you're using OpenVSP.

Among all of this work, there are some small changes to the Python
API.  It should be pretty harmless and generally more Pythonic, but it
might cause API users a few headaches.

One of the C++ changes to support using the GUI from Python affects
how 3D objects are updated to the graphics card.  We now attempt to
update these objects less frequently.  This should also provide a nice
performance boost, but at the risk of losing things once in a while.
If you find that something vanishes where it was previously visible,
mention it on the Google Group.



Next, some bad news.  In addition to lots of good stuff, 3.33.0 also
included some lousy regressions.  These regressions made FEAMesh and
CFDMesh both slow and crashy.

If you aren't into sausage making, skip a few paragraphs...

   The performance regression was super subtle.  The regression was
   actually over in Code-Eli (50487cc2bbfe).  Notice how I nonchalantly
   say "This does mean that a copy of the surfaces must be made because
   they are no longer const.".  Yep, that was it right there.  I even
   knew I was doing it at the time.

   Something I did to improve the accuracy and reliability of a
   surface-surface intersection algorithm inadvertently caused us
   to copy and destroy a giant complex data structure a bazillion times.
   All the time was spent allocating and releasing memory.

   The fix (c53f910aa2e4) was to allow a shift to be incorporated into
   the surface evaluation on-the-fly and switching back to a const
   reference.


   The crash-causing regression was something else entirely.  When
   our mesher (CFD or FEA) generates an initial mesh (InitMesh), it
   transforms every surface patch into flat 2D space and generates
   the initial mesh there.

   You might be wondering why you can't just use the surface's U,V
   parametric coordinates for generating the initial mesh.
   Unfortunately, a square in U,V is not guaranteed to look anything
   like a square on the surface.  The closer we can get to flattening
   the surface without distortion, the better.

   For years, we've used an algorithm based on Mysticism and Voodoo
   to map surfaces from U,V to 2D space.  It generally worked, but it
   was a dark place that will make you see things that aren't there.

   In our next regression (47e5744550eb), I tried to replace the
   old approach with something I thought would be an improvement.
   Spoiler alert, it broke things.  In particular, it would distort
   surfaces near degeneracies in a way that fine meshes would turn
   out hosed.

   As it turns out, this flattening problem is something that computer
   graphics researchers have been working on for years, so it made
   sense to drop the custom code and use an off-the-shelf solution
   instead (OpenABF).  It does a great job and should provide all
   the benefits I was hoping to achieve when I 'upgraded' the
   algorithm earlier.


The good news is, not only are these regressions fixed in this version,
I spent a bunch of time profiling FEAMesh under some extreme use
cases (thanks James Joseph) which revealed some unexpected slowdowns.
I was able to re-write several algorithms providing dramatic speedups.

If you previously grew tired of wondering how long ConnectBorderEdges,
BuildFeaMesh, and BuildChains could possibly take, you'll like what
you see here.  In addition to these three, a bunch of other speedups
were made across the meshing workflow.

While I was in there, I was able to fix a bunch of bugs in and around
FEAMesh.  Most of these were reported by users - thanks James & Bryan.


The other big item you'll notice in this release is we finally have
full Apple Silicon M1/M2 processor support.  The holdup had been our
scripting language - AngelScript.  AngelScript does some low level
stuff such that it includes some assembly code that needs to know
exactly how compilers on a given operating system and processor
platform send data to a subroutine.  This includes things like
do you pass arguments LtoR or RtoL, how many registers there are,
how do you use the registers, what do you do when you run out of
registers, etc.  The main AngelScript author doesn't have an Apple
Silicon machine and has had to rely on others to do this work
(which is outside my range).  Someone finally came along to make
it work, so here we are.  I helped track down one bug that turned
up along the way.

So, if you've purchased a Mac in the last three and a half years or so,
you'll want to check out the new download option.  It should be faster
for you, but everything else should be the same.


You may have noticed that there are a bunch of library updates along
the way.  In addition, there are a bunch of updates to the CMake build
system.  If you build OpenVSP yourself, you'll probably want to blow
away your build directories and start over.  Sorry for the hassle.  If
you typically use -DVSP_USE_SYSTEM_FLTK=TRUE (likely for Linux users),
I suggest you don't do that now.  The FLTK project is about to release
version 1.4.0 and I've bundled a cutting edge version here.  It includes
many improvements that won't be available in a system-installed package
until the final release happens and then the Linux distributions update
to it and then your machine is updated too.  Just use the one I bundle,
you'll get the latest.


Beyond that, there are a good number of small fixes and features tossed
in.  As mentioned earlier, everyone should update.  It is the right thing
to do.

Features:
 - OpenVSP GUI available from Python API
 - Facade allows OpenVSP API to run transparently on separate process
 - GUI parental controls
 - Python API documentation
 - Surface Intersecion, CFDMesh, and FEAmesh much faster
 - Add surface names to Intersect, CFDMesh, and FEAMesh progress output
 - Native Apple M1/M2 support

Library Updates:
 - New AngelScript - full M1 support
 - Removed local modifications to AngelScript for documentation
 - Moved AngelScript build to Libraries, better CMake integration
 - Updated FLTK to 1.4.0-preview version
 - Updated FLTK integration to Modern CMake
 - Added OpenABF - Angle Based Flattening
 - Updates to Code-Eli, performance improvements for meshing
 - Update how Eigen is included in project

Bug Fixes:
 - Fix meshing performance regression from 3.33.0
 - Fix meshing crash regression from 3.33.0
 - Fix on-the-fly updating of meshing lengths with model unit scale
 - Fix not scaling fixed points with model scale
 - Fix not scaling trim planes with model scale (thanks Bryan)
 - Fix FEA crash with subsurfaces and trims (thanks Bryan)
 - Fix FEA crash with empty trim part (thanks James)
 - Fix corruption of Quad Meshes
 - Fix FEA Individualize Rib and Plane routines (thanks James)
 - Fix scroll wheel zoom on Windows
 - Fix Wing insert section update from API.
 - Fix error in K to F unit conversion (thanks sladesladeslade)
 - Fix VSP icon in Ubuntu (thanks Cibin)