Hi Larry,

re:
> Maybe a different geometry kernel might help, like Open CASCADE or Coin 3D?

Every different geometry kernel tends to have its own quirks and problems in different areas. So it's possible it could help but it's more like it's exchanging one set of problem areas for a different set of problem areas. It's also an extremely time consuming area of work.

Coin3D would not help at all since I don't think it implements any CAD solids file import, it's a toolkit for different things than that like managing a scene graph.


re:
> Can geometry kernel improvements to importing be made in 5.0?

Hopefully yes but I don't know much right now about what will be the focus areas for MoI v5 so I'm not able to make any promises right now about what will be done for v5.

There have been improvements to importing in every release of MoI though, so it would be pretty unusual if there weren't any for v5 as well. I have a general sense that the most problematic area for imports is in dealing with closed surfaces so it is possible that some attention to that particular area may yield a good improvement.


re:
> Is there a particular CAD model file which is easiest for MOI to handle?

That would be .3dm import, it's the closest to how MoI represents models internally and so involves the least amount of processing and manipulation of trimming boundaries.


re:
> a) by an index variable value range overrun?

Highly unlikely.


> Maybe an index variable is used in a loop somewhere in the import routine for .sat or .step files and the value it reaches
> exceeds the value range of the data type used? Maybe switching all index variables and counters in the code to 64 bit
> integer data types would fix obscure bugs and possibly also this one?

Well a 32-bit integer can hold a count up to 4294967295 and there is no list of entities in your propeller file that comes within very many orders of magnitude of that.


> b) by floating point variables with insufficient accuracy? Maybe there's snapping occurring when the software
> performs array indexing by checking a given float variable's or float array position's value to others before
> deciding whether to add it as a new array position or just as an index to an already existing position, which
> is actually supposed to be slightly different in value but with a difference too small for 32 bit floating precision?
> And so what should be two different positions in the array collapse to a single position?

The file import process uses 64-bit double precision floating point values throughout and so it can't be this problem either.

There can be different kinds of accuracy problems but they're about a "fitting tolerance" accuracy and not low level floating point arithmetic accuracy.


> I have no idea whether freeCAD, 123D Design or eDrawings use double precision or single precision floats but
> if changing all float variables in MOI's code to double precision is an easy change with no complex or problematic
> implications or ramifications, it might be worth it to see whether it fixes the issue.

MoI already uses double precision floating point for all geometry processing, single precision is only used in the display engine when sending display data to the video card.


> There shouldn't be any square plug. I'm not sure which of the surfaces shown in this cross-section view in 123D
> Design are getting turned into that square plug :

The square plug is coming from the "underlying surface", the plane surface that is underneath the trim curves. If you delete it then you can use the show naked edges scripts from the link above to see where the really skinny piece is at:




> I've highlighted what I mean in the following image. The blue lines are seams where vertices
> were duplicated upon export from MOI. The models are were exported 'triangles only'. No ngons are
> used. The blue seams are between triangles that make up the mesh surface. However, there's
> more seams being created than should be necessary. I highlighted the ones I think are redundant in red.

Are you seeing these seams only with MeshMixer or are you also seeing them in other programs as well?

It looks like it's probably an issue specific to MeshMixer where it is not liking to combine very skinny triangles. You could try adjusting your meshing settings on export to reduce the formation of long skinny triangles, the "Divide larger than" setting can help with that:





Hope that helps! - Michael