OpenVSP 3.39.0 Released

[Rob McDonald]

Coming less than a month after the prior release, I thought about holding off on this release until there was more to go with it. After all, this release really consists of just one feature and a handful of bug fixes.

However, when I've shown the new feature to users, they want it released yesterday -- or sooner if possible. Who am I to argue?

OpenVSP (and its predecessors) have long had the ability to place a 2D image as a background to be used as a guide when setting up a model.  This version takes that idea to the next level. Instead of the image appearing as a static background, it is placed in the model such that it can pan and zoom appropriately. Likewise, there is no limit to the number of reference images that can be used.



Describing this feature doesn't succumb to the written word -- so look for a video from me or Brandon in the near future.

Aside from that, there are a couple of bug fixes mixed in. We're still working through the aftermath of the DrawObj m_GeomChanged enforcement from a few versions back. A CFDMesh tolerance has been tightened so cusped airfoils won't get smooshed. And some continued build system improvements to help with portability to more diverse platforms.

We've also updated (again) to the latest FLTK 1.4.0-pre release. The FLTK dev team is on a big push to 1.4 and I'm trying to make sure there aren't any surprises when it goes final.

Features:
- 3D Background images

Library Updates:
- Update to latest FLTK dev as they approach 1.4.0
- Build LibXml2 with -PIC
- Update GLEW build integration to match modern GLEW

Bug Fixes:
- Move Documentation build to MacOS from Ubuntu to get latest Swig
- Drop MacOS-11 build, move to MacOS-12
- Use gcc-11 on MacOS for ADEPT and OMP builds
- Fix MeshGeom DrawObj issue
- Tighten tolerance in MatchBorderNodes - Thanks Andy.

[Grant Hiller]

Hi Rob,

Thanks very much for pushing out the release of the 3D background feature, I've been using it today and it's great!

I have, however, run into an issue that after I save and close OpenVSP, the next time I open it, the background images come up as black, and it looks like it's lost the path to the image. See screenshot below. I then have to go and browse for the image on each background for it to load them again; then they appear fine. The positioning/scaling etc. is saved properly.

Could you please take a look into this?

I'm running 3.39 for Python 3.11 on Windows 11.

The image is stored in a subfolder to where the vsp3 model is stored.

Regards,

Grant.

[Tim Swait]

Thanks for this, I've upgraded but it's still basically unusable for me through the GUI as it's so slow (many seconds, sometimes tens of seconds) to update whenever I move a slider. Using Ubuntu 22.04, all updated, all standard. 

Are old versions archived somewhere accessible? (no releases are listed on Github) I may try going back to 3.36 as that was the last version that worked for me in the GUI.

[Grant Hiller]

Tim,

See the old downloads section of the website, here:

https://openvsp.org/download_old.php

[Tim Swait]

Thank you, I'm back on 3.36 now and it's working nicely, the model changes instantly as I move the sliders (and the text in the menus is far more readable).

[Rob McDonald]

Thanks for this heads up.

I must have messed up the relative path stuff somehow for Windows.  It is supposed to 'just work'...

To be clear, your set up is:

/some/path/to/model.vsp3

/some/path/to/images/top.png

/some/path/to/images/front.png

/some/path/to/images/side.png

Or similar (except for Windows paths)?

Rob

[Rob McDonald]

Tim,

I believe your machine is having a problem with X11 vs. Wayland.  The Linux world is moving the fundamental GUI technology from X11 (which has been the standard for approximately forever) to a new replacement called Wayland.

Right now, different distributions, programs, libraries, and programming frameworks are all handling the transition from X11 to Wayland at their own independent pace.  OpenVSP and FLTK are not immune to that.

I do not have this problem on Ubuntu 22.04.  I keep updating to the latest/greatest FLTK to see if an update fixes the problem.

Unfortunately, I don't have a productive way to debug your problem.

Rob

[Tim Swait]

Thank you for your efforts Rob. I'll keep trying the new releases as they come out and reporting whether they work, but I'll have to stick with 3.36 as a 'daily driver' for now. There is a new LTS version of Ubuntu out now (24.04), I'll probably be upgrading my system to that in a few weeks, I normally go onto the new LTS releases a couple of months after they come out.

[Rob McDonald]

I saw 24.04 -- I tried to build a version for it in GitHub, but a runner never became available, so I don't think it is actually supported yet.

I believe Ubuntu can be configured to run with Wayland or X11.  You might try running your machine the 'other' way.  It might even be a choice from the login screen.

Rob

[Rob McDonald]

I spent some time with this today -- it seems to be working properly for me.

Can you please verify what you're seeing and then jot down exactly what steps you can go through to replicate the bug?

Best,

Rob

[Grant Hiller]

Hi Rob,

I went through this again today and had the same issue. To answer your questions, my process is:

1. Open OpenVSP (located in .. \Documents\OpenVSP\OpenVSP-3.39.0-win64)

2. Open file (located in ..\Documents\Work\Stralis\Beechcraft\Bonanza) – all background images appear blacked out.
3. Go to 3Dbackground – note that the file path is pointing to the folder (not the .png file itself), and not to the subfolder where the images are stored (and were added from when I saved it originally)
4. For each view, browse to the image (located in ..Documents\Work\Stralis\Beechcraft\Bonanza\Pictures), and assign the image to each view. Images appear as expected.
5. Save file.
6. Exit OpenVSP.
7. Start OpenVSP – images appear as blacked out again.

8. Background3D file path is to the folder itself, not the .png file, as happened in #3 above.

Notes:
1. The model was created with an earlier version of OpenVSP (i.e. 3.38).

2. I have the native file chooser selected under Preferences.

I then did a couple of tests on my end to see what could be going on...

Test 1:

1. Create a new model, with just a wing.

2. Saved model

3. Add a background image (.png) from the subfolder. Image appears as expected.

4. Save model

5. Closed OpenVSP

6. Opened OpenVSP - image appeared blacked out.

7. Background3D file path is to the folder itself, not the .png file

Test 2:

1. Create a new model, with just a wing

2. Saved model

3. Add a background image, this time from the same folder as the model is saved in. Image appears as expected.

4. Saved model.

5. Closed OpenVSP

6. Opened OpenVSP - image appeared blacked out.

7. Background3D file path is to the folder itself, not the .png file

I saved a couple of screenshots in the attached pptx file.

I hope this helps. Let me know if you have any other questions.

Grant.

[Rob McDonald]

Thanks, I'm still not having any trouble.

I've instrumented a build to dump out some print messages that should help me see what is going on in your case.  The messages should print out to the black console screen that opens behind OpenVSP.

You should be able to download this build here:

https://github.com/ramcdona/OpenVSP/actions/runs/9074067533

Please run through one of these scenarios and then copy and paste what appears in the console into an email to me with a description of the process you went through.  It will print one set of messages when you save a file with a 3D background -- and another set of messages when you open a file with a 3D background.

Note that this build does not include VSPAERO.  It compiles a lot faster that way.  If you need VSPAERO with this debug build for some reason, just copy the files over from the regular 3.39.0 zip file.

Thanks for the help,

Rob

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/ed1c34eb-0917-47a3-9342-15962da36a53n%40googlegroups.com.

[Brandon Litherland]

I'll have to dust off the microphone for this one, Rob. :D

[Rob McDonald]

I have a candidate to fix this problem.  Please try out the build at this link:

https://github.com/ramcdona/OpenVSP/actions/runs/9083735336

Let me know if it works.  If it does not, this build also includes the debug messages, please include some of those messages with a followup bug report.

Rob

[Grant Hiller]

Good morning Rob,

I can confirm that the problem has been fixed with the above build you provided (https://github.com/ramcdona/OpenVSP/actions/runs/9083735336), with the caveat that I had to reload the images before they appeared again. When I saved, closed, and reopened the model, the images loaded properly on startup too. I can also confirm it worked when I built a new model with just a wing component, added background images, saved, exited, and reopened.

Appreciate your help in developing a fix for this :).

Regards,

Grant

[Rob McDonald]

Thanks for the confirmation.

I should have mentioned -- the initial re-load to 'fix' the files was expected.  The bug was when the file names were written to file (reading was OK).  So existing files need 'fixing'.

Thanks again,

This is now available as 3.39.1 -- without the debugging messages.

Rob

[Tim Swait]

I've been using 3.36 for some time, but thought I'd try 3.39.1 again, so just reinstalled it. It now works for me (text is normal size, sliders resize geometry almost instantly). No idea why, I've been installing Ubuntu system updates as they come out, maybe one of those over the last month has done something.

[Brandon Litherland]

Can you post a list of which updates you installed since the last time you tried VSP?  That could help identify which update may have sorted out the issue.

[Tim Swait]

I've just tried it again and it's back to taking 10 seconds or more to update the model when I move a slider, and I haven't installed any system updates since yesterday, so I don't know why it briefly worked yesterday!

[Brandon Litherland]

Is this for any particular parameter or for all parameters?  Do you have any Prop components with lots of control points in the Blade curves?

[Tim Swait]

It seems to be for all parameters. Actually, I have now realised that it's only a problem for certain files. This is why I thought it was working normally yesterday, it does work normally for some files, for other files it is still very slow. But 3.36 was fine with these files. The problematic files don't look particularly complex. I've made a video showing a screen grab here, you can see the difference between a file that works (taking a blank file and clicking 'Add Wing') and one that doesn't. I've attached the one that is very slow to update on my machine, is it equally slow on yours? It doesn't appear a particularly complex geometry and no, there are no Prop components.

[Rob McDonald]

Tim,

Thanks for posting the file with trouble.

I see it has a wing with many sections -- and it has file airfoils at every station.  Those aren't deal breakers, but they might be clues.

Would you mind opening the slow file, then adding a default wing -- and modify the default wing?  Is it still slow, or is it just editing the complex wing is slow?

Can you try each of the versions between 3.36.0  and 3.39.1 to confirm exactly when the slowdown was introduced?  There aren't a ton of versions to try here, but when doing this, it is most efficiently done through bisection -- try the one in the middle to narrow down on the change.

Rob

On Tue, Jun 18, 2024 at 2:13 PM Tim Swait <tims...@gmail.com> wrote:

It seems to be for all parameters. Actually, I have now realised that it's only a problem for certain files. This is why I thought it was working normally yesterday, it does work normally for some files, for other files it is still very slow. But 3.36 was fine with these files. The problematic files don't look particularly complex. I've made a video showing a screen grab here, you can see the difference between a file that works (taking a blank file and clicking 'Add Wing') and one that doesn't. I've attached the one that is very slow to update on my machine, is it equally slow on yours? It doesn't appear a particularly complex geometry and no, there are no Prop components.

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/3abeb7a5-1921-4fb4-b35d-c1389687b9f9n%40googlegroups.com.

[Cibin Joseph]

I've noticed wings/props take time to update dimensions when you use an AF_FILE, probably because it's recalculating the coordinates. This applies even for a single AF_FILE cross-section. If you switch to an ellipse cross-section, the slow down disappears.

Might be the reason for the slow down in Tim's case. I just took a quick look at the files he shared and that seems to be happening.

Cibin

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/CAEppYpHSVqjEdBwmCifkg9fAmHgQDQzuAtB%2BT0M24g90nt6fkQ%40mail.gmail.com.

[Tim Swait]

Hi Rob,

- Version 3.36.0 works great, the "VGon" wing in my model updates almost instantaneously. If I create another 'Wing' geometry then this also updates instantaneously. Now I'm looking at this very carefully, I can see the newly created Wing is slightly smoother in updating when I waggle the sliders about furiously, the more complex geometry from file is slightly jumpier, but it's not something I would have even noticed if I wasn't looking for it, basically it's fine.

- Version 3.37.0 is where the trouble starts. In this version the complex geometry from the file (VGon) is basically unusably slow to update as described above and shown in the screencast. If I create a new 'Wing' geom then this updates acceptably quickly, however now I'm really looking for it then if I really waggle the sliders up and down fast then it is jumpier than in 3.36 (about the same as the complex geometry was in 3.36)

- Version 3.37.0 is also where the fonts in the menus become tiny and pixelated. I don't know if this is related.

- As said previously, this is Ubuntu 22.04. I don't think this is Wayland related. On the login screen I've found the option to start either an x11 or a Wayland session. This makes no difference, the performance is terrible in both (and the fonts are tiny and pixelated in both for whatever that's worth).

Can someone else using the Ubuntu version please try the 'Avian_Puma.vsp' file I attached earlier in the thread and try moving a slider (for example  GeomBrowser>VGon>Plan>Span) and see if it updates near instantly or if it takes many seconds?

[Rob McDonald]

I've just reviewed the changes for 3.37.0 and I don't see anything that should have caused a performance regeression.

Are you able to build OpenVSP yourself?  If so, there are some tests I could have you try.

The most likely culprit is the update of FLTK to the 1.4.0 pre-release version.  That is certainly what is causing the small ugly fonts.

Rob

[Tim Swait]

I can certainly have a go!