stl face deletion

[Mike Vivaldi]

this is a test for messages that are too long

[Mike Vivaldi]

Attached is the VSP, HSTAB_trim <= 2.0 degrees results in deleted faces

[Mike Vivaldi]

Associated STL and image

[Mike Vivaldi]

Additionally COMP GEOM on just the fuselage does not mitigate the issue. Attempting to run COMP GEOM -> convert to NGON does not convert TRIS to QUADs and does not mitigate the issue.
Thanks for all the help in advance,
Mike

[Mike Vivaldi]

Correction HSTAB_TRIM motion set to -2.0 or less results in face deletion. I have not tested positive values

[Rob McDonald]

The face deletion happens because your horizontal tail has the root end cap set to None.  Change it to Flat and it will work fine.

CompGeom uses a ray-shooting algorithm to determine whether a triangle is inside or outside another body.  This requires that all bodies be individually watertight to work properly.  Having an open root cap causes that triangle on the face of the fuselage to be mis-classified.

As discussed in your other thread, convert to NGON is working as expected.  OpenVSP does not know how to reconstruct quads from the tris.

Rob

[Mike Vivaldi]

Hi Rob,

DOH i totally forgot that was an open face....

"As discussed in your other thread, convert to NGON is working as expected.  OpenVSP does not know how to reconstruct quads from the tris." Ah I must have misunderstood what you meant by work around, I thought it was able to reconstruct quads.

I will give it a try. Apologies for the extra thread, I can't post in that thread any more. Every post shows "message too long"

Thanks!

Mike

[Rob McDonald]

No worries.

The NGon mesh isn't really quads -- most of the panels are quads, but they are actually polygons with an arbitrary number of sides (hence N-Gon).

For the most part, it will recover quads except for near intersections.  Near intersections, it is common for the panels to have many edges.  Also, near degeneracies (nose, tail, wingtips, etc) you will find triangles.

To my knowledge, VSPAERO is the only code that can work with this sort of mesh.  I.e. I don't expect the NGon mesh to be useful for anything but VSPAERO.

VSPAERO works on vortex loops (not strictly panels).  Consequently, it can work with tris, quads, and n-gons. So, theoretically it should still work with a triangle mesh.

For some reason, it isn't happy with the fuselage as-is.  I'll see if I can figure out why.

Rob

[Mike Vivaldi]

If you are tracking the index of the vertex then that may be an issue, In blender for resampling a given section I sort by longitudinal location, then vertical. granted this is in 2d and I then mirror across to the other side but blender can get very unhappy in certain operations if the indices are out of order, for instance the mirror happens first, then sort by vertical position. If the proper procedure is followed then bridging between 2 sections is quite trivial.

[Rob McDonald]

I'm rather confused about this comment without any context.

OpenVSP and VSPAERO both treat these meshes as fully unstructured.  The ordering of the points / faces has nothing to do with anything.

Perhaps I misunderstand your comment.

Rob

[Mike Vivaldi]

Sorry Rob, I could have been more clear. I was identifying that one method I know of to restructure meshes requires assigning an index to each vertex and then sorting the points based on position in such a way to correlate normal vectors along faces between adjacent tris and their associated 4 points to recreate the quad.

[Rob McDonald]

Sure, there are lots of ways this could be done.

Before this NGon mesh stuff, VSPAERO would try to clean up tris into quads itself.  It was generally pretty good about recovering simple quads split into two tris (though sometimes it would get confused and pair up regions in the 'wrong' way).

However, the simple case is not the tough part.

Here is a typical CompGeom intersection between a wing and a pod.  Notice the ugly slivers near the intersection.

There are ways to try to clean this up, but it isn't trivial.

However, OpenVSP has an advantage.  We created the tris from quads in the first place.

When I split the tris into quads, I give every try a number -- iQuad.  It is simply an integer that counts which quad the triangle came from.  There are other identifying numbers too -- such as tag, that identifies which surface and subsurface the tri came from.

When tris are intersected, intermediate nodes and edges are created.  The intersected tris are then split into multiple smaller tris that obey the intersection edges.  During this split, all the 'child' tris inherit their parent's identifying information.

Interior tris are identified and discarded -- leaving us with the mesh we get from CompGeom -- with ugly tris at the intersections.

Now, to convert this into an NGon mesh, I simply consider every edge in the mesh.  If an edge is manifold (has two faces), and those faces have identical tag and iQuad, then I remove that edge -- merging those two faces.  Tris become quads and quads become NGons.

This results in the NGon mesh like this:

The great thing about this is that it is essentially exact -- with no heuristics required.  I simply have to track iQuad through the whole process and then manipulate the topology of the mesh to clean it up.  There are no tolerances, to computations, no iteration, etc.  It makes for a very fast conversion.

There are other more complex things going on during the NGon conversion -- but this is the core of the algorithm.

The only catch -- you must identify iQuad for every triangle before you perform the intersection etc.

If you want two neighboring tris to eventually get merged, they must have the same iQuad value from the start.

Rob

[Mike Vivaldi]

Hi Rob,

Thanks for the detailed explanation, and I fully see the benefits of the Ngon model. Is there a way to import a model that VSP would support Ngon creation later? I ask because as much as I would love to build the fuselage in OpenVSP rebuilding the fuselage section profiles by creating and then importing background images from the blender file seemed like I risked losing some of the known geometry dimensions. A lot of the reconstruction required a fair bit of analytical geometry and I didn't want to risk losing that. My prior vsp model although very close to the real geometry, displayed divergent results near the vstab. That instability disappeared with the actual geometry.

Thanks!

Mike

[Rob McDonald]

If you import a Xsec (*.hrm) or Plot3D (*.p3d) file as wireframe (not as a mesh), then OpenVSP will be able to convert that geometry to a mesh that will be able to recover the wireframe in the NGon process going to VSPAERO.

In addition, the wireframe geometry includes some features to skip mesh rows / columns, transpose, and some other things that may come in handy.

All that said, VSPAERO should work fine with the mesh imported as a triangle mesh -- I know it doesn't work now, but hopefully I can figure out the problem and get it fixed.

Again, you should look at the Fit Model tool.  It is really the best way to generate a native OpenVSP geometry to match a legacy model.

Finally, I really doubt that a subtle difference in your fuselage would cause major problems in a VSPAERO solution.  I would look at the geometry to see if there was something else wrong with it that was the real underlying cause of the problem you saw.

Rob