Query: Scripting API access for SubSurface Intersect (Windows v3.51)

[Jaime García]

Dear OpenVSP Team,

I am currently developing a parametric fuselage generator using a custom .vsppart script in OpenVSP v3.51 on Windows.

I am using the "SubSurface Intersect" feature (SS_INTERSECT) via the GUI to handle the geometry cutouts for both passenger windows and doors. This feature works beautifully for my design needs, but I am struggling to find a way to automate it.

However, I have been unable to find an equivalent function in the AngelScript API to create or assign these intersecting geometries programmatically.

The Problem / Impact on Parametric Design: My script automatically handles the layout of doors and windows, which can easily amount to dozens of individual cutouts. Since the fuselage is fully parametric, any global change—such as modifying the total fuselage length, shifting a cabin section, or altering a door's location—instantly invalidates the manual work.

Having to manually delete and recreate dozens of subsurfaces in the GUI every time a parametric variable changes is highly inefficient, error-prone, and defeats the purpose of an automated script.

My Questions:

1. Is there any existing function or syntax in the current AngelScript API to programmatically assign an intersecting geometry to a subsurface that I might have missed?

2. If it is not currently exposed, is adding API support for SS_INTERSECT on the development roadmap for future releases?

3. Are there any recommended scripting workarounds you would suggest to achieve clean, automated window/door cutouts on a fuselage skin without manual GUI intervention?

I am attaching a screenshot to illustrate the density of the windows and doors in the layout, where automating this step is critical for a truly parametric workflow.

Thank you very much for your time and for your continuous efforts in developing OpenVSP.

Best regards,

Jaime

[Rob McDonald]

This one should actually be in the API...

https://openvsp.org/api_docs/latest/group___sub_surface.html#ga97d2e08bc4399e5e536844a263946c2f

and

https://openvsp.org/api_docs/latest/group___sub_surface.html#ga71dd1ccdf567885ee706fcda51abc686

That said, my main recommendation would be to not do this...

What is the engineering purpose of adding a large number of window / door subsurfaces to the model?  Is it just so it looks cool?  It will not change the OML (i.e. the aerodynamics).  Are you doing a detailed structural analysis such that all the windows are important?

Placement of doors may be more useful, but again -- what analysis are you doing that actually needs a detailed model of the doors?

I'll admit, it is really cool -- but unless you have an engineering purpose for adding this level of complexity to your model and process, it may not be worth doing.

Rob

[Jaime García]

Hi Rob,

Thank you so much for pointing out SetIntersectSubSurfGeomID and IntersectSubSurf! I completely missed them in the documentation, and this is exactly the solution I was looking for.

To answer your question regarding the engineering purpose: you are absolutely right that this level of detail does not alter the OML or affect the aerodynamic analysis. However, the context of this project is educational.

This script is being developed for an undergraduate Fixed-Wing Aircraft Design course (specifically for their Final Degree Thesis). We challenge our students to generate three-view General Arrangement drawings that match the visual fidelity and standards found in official Airport Planning Manuals (APMs). Additionally, they are required to design the internal passenger cabin layout and cargo holds.

Up until now, I had proposed that the students use the CompGeom tool to perform a boolean subtraction of the window volumes. While CompGeom achieved the visual cutout, it generated an incredibly dense mesh with a massive element count, resulting in bloated file sizes and sluggish performance during subsequent operations. Moving to the subsurface approach is an engineering requirement for us because it keeps the OML model elegant, clean, lightweight, and completely dynamic.

Having the windows and doors accurately cut into the fuselage skin serves two critical purposes for them:

1. It ensures their 3-view drawings meet the rigorous visual requirements of an APM document.

2. It acts as a direct visual validation tool to verify that the internal seating pitches, emergency exits, and cross-aisles perfectly align spatially with the external physical openings.

Since they are in a design-and-iterate phase, automating this via the script allows them to change global parameters (like total fuselage length or section shifting) without having to spend hours manually deleting and recreating dozens of subsurfaces in the GUI every time.

Thanks again for your amazing support and for continuing to maintain such a versatile tool!

Best regards,

Jaime

[Rob McDonald]

Sounds good.

The intersect subsurfaces feature is very new and hasn't been massively stress tested.  I'm actually surprised it scales well enough to handle all the windows on a fuselage.  You're on the bleeding edge here -- you'll be the first to know where it breaks.

Rob

[Jaime García]

Hi Rob,

Thanks for the heads-up. I completely agree—it has definitely been a "bleeding edge" experience getting this to work reliably!

To give you some perspective on the performance, I’ve been working on optimizing the logic, but the automation process itself does take about 5 minutes to run on my machine. However, the trade-off is absolutely worth it for the end result. Unlike the CompGeom approach, which creates incredibly dense meshes and makes the files sluggish to manipulate, the subsurface method keeps the geometry very lightweight. The final file size only increases by a few megabytes, which is negligible compared to the massive overhead I was seeing previously.

I am fully prepared for the fact that this might break under specific edge cases. I’ll keep a close eye on it as the students start testing more complex configurations, and I will be sure to report back if I find any specific scenarios where it fails.

Thanks again for the support and for keeping the API evolving—it’s making a big difference for our design workflow.

Best regards,

Jaime

[Rob McDonald]

Is that 5 minutes just to synthesize the subsurface windows/doors?  Or is it 5 minutes for some iterative process where the individual steps are substantially faster?

If the subsurface synthesization step takes five minutes, then I probably need to profile that too...

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 visit https://groups.google.com/d/msgid/openvsp/f0d934d0-78e5-4338-97e0-c5f3f7bfc4d8n%40googlegroups.com.

[Jaime García]

Hi Rob,

Thanks for asking. To clarify, the ~5 minutes runtime is the total execution time of the entire script from start to finish, rather than a single slow intersection function.

Here is what happens during those 5 minutes:

1. Isolation: First, the script disables all complex interior components (cabin layouts, cargo holds, galleys, etc.) to leave the fuselage as a clean, simple cylinder. This significantly speeds up the subsequent intersection math.
2. Procedural Construction (The bottleneck): The script loops through all windows (in the default example there are 114 windows) and doors (10 by default). For every single opening, it generates a fresh STACK geometry component, programmatically alters its cross-sections to rounded rectangles, modifies their dimensions (width, height, radius), and resets skinning parameters.
3. Subsurface Setup: For each generated cutter, a subsurface of type SS_INTERSECT is created on the fuselage and linked to it using SetIntersectSubSurfGeomID.
4. Execution & Cleanup: We call Update() to rebuild the model, then loop through all subsurfaces to run IntersectSubSurf(). Finally, we delete all the temporary cutter geometries (DeleteGeom) to leave the VSP file clean and lightweight.

It seems the primary bottleneck is procedurally constructing and modifying the cross-sections of dozens of independent STACK geometries inside the loop.

Thank to your response in the other topic,  to optimize this, I am thinking of creating a single "template" window component, copying it to the clipboard, and then pasting and translating it inside the loop. This would bypass the repeated section-building overhead.

Do you think using CopyGeomToClipboard and PasteGeomClipboard would be a reliable way to optimize this in the API?

Best regards,
Jaime

[Jaime García]

Hi Rob,

Following up on my previous message, I’ve implemented the clipboard method and ran several clean, isolated tests (restarting OpenVSP, creating a fresh custom geometry, and executing the script) to rule out any memory leaks from previous sessions.

The average time differences (Deltas) between the Clipboard method and the original version (build every component) are highly revealing. Here is the exact breakdown:

Script Phase                                              Delta Time (clipboard vs. Original)

Component Identification                      0.0s

Delete Prior Subsurfaces                        0.0s

Read Geometry Parameters                  0.0s

Isolate Outer Skin                                     0.0s

Auxiliary Geometry Construction         -307.5s (Huge Saving)

Mesh Generation (Update)                     +0.5s

Intersections                                             +78.5s (Overhead)

Auxiliary Deletion                                     +73.5s (Overhead)

Restoring Interior Geometry                  +71.5s (Overhead)

NET SAVING (Total Execution)                -83.5s (Faster)

I am really happy with the time savings in the geometry generation, but a little puzzle about the extra time inverted in the other parts of the code. (find attached the vspscript with the clipboard method).

Let me know your thoughts on these findings!

Best regards,

Jaime