#216 g-stl and g-vrmll issues

crash or data loss
Wim Bokkers

Using g-stl and g-vrml result in a crash during conversion (on Windows). Only part of the geometry will be converted.

BOT-primitives will never get converted!


  • Wim Bokkers

    Wim Bokkers - 2009-06-08
    • priority: 5 --> 7
  • Sean Morrison

    Sean Morrison - 2009-06-08

    Is it possible to get an example .g geometry file with one ore more BOTs that provoke the crash? It doesn't need to be a full file, just at least one object that causes the problem.

    Do you believe it to be specific to Windows or is that merely where you observed the problem?

    Are the BOTs solid or plate mode or does it not matter?

  • Wim Bokkers

    Wim Bokkers - 2009-06-08

    It is not the BOTs (actually regions consisting of arb6 primitives, I just heard from a colleague) that will crash the conversion tools. Arb6 solids that were imported using our dxf2g utility seem to be skipped.

    The crash will occur on somewhat complex geometry files.

    I'm not sure whether it is a Windows related problem. We currently only use the Windows platform, so it is merely where we observed the problem.

  • Wim Bokkers

    Wim Bokkers - 2009-06-08

    Solid consiting of arb6 prims.

  • Wim Bokkers

    Wim Bokkers - 2009-06-08

    I attached a file containing arb6 primitives (so the problem is about arb6's and not about BOTs).
    g-stl for this geometry results in the following error traces:

    class_lu_vs_s: loop transits plane of shell/face?

    FAILED in Boolean evaluation: /g_radome/53_radome_fs093r
    {l2s2615.arb6} u {l2s2616.arb6}
    {l2s2617.arb6} u {l2s2618.arb6}
    {(l2s2615.arb6 u l2s2616.arb6)} u {(l2s2617.arb6 u l2s2618.arb6)}
    {l2s2619.arb6} u {l2s2620.arb6}
    {l2s2621.arb6} u {l2s2622.arb6}
    {(l2s2619.arb6 u l2s2620.arb6)} u {(l2s2621.arb6 u l2s2622.arb6)}
    {((l2s2615.arb6 u l2s2616.arb6) u (l2s2617.arb6 u l2s2618.arb6))} u {((l2s2619.
    arb6 u l2s2620.arb6) u (l2s2621.arb6 u l2s2622.arb6))}

    class_lu_vs_s: loop transits plane of shell/face?

    FAILED in Boolean evaluation: /g_radome/53_radome_fs093l
    0 triangles written

  • John Anderson

    John Anderson - 2009-06-08

    No solution, but a couple comments.
    First, it appears that each arb6 in that file has a duplicate. Look at rs2489.arb6 and rs2608.arb6, both in 53_radome_fs030r. This will definitely cause problems, but I doubt that correcting it will be a complete solution.
    Second, the geometry appears to have been a triangulated surface that was converted to a set of arb6 primitives. We used that approach in our patch-g converter, but switched to converting such surfaces to BoT's in fast4-g. The file you provided looks remarkably like something that might have come from the patch-g converter, including a common error in that converter where the arb6 was placed on the wrong side of a plate-mode triangle (look at the arb6's mentioned above).
    One area where our CSG evaluation in the converters struggles is handling adjacent faces that are nearly, but not exactly coplanar. Approximating a curved surface with arb6's will be full of those situations.
    Finally, if the converter that produced this file could be modified to produce solid mode Bot's instead of arb6's, the chances of g-stl succeeding would be increased greatly.

  • Wim Bokkers

    Wim Bokkers - 2009-06-09

    Thank you for looking into this problem.
    The dxf2g utility we use is very old and not touched for more than 10 years. It has been used a lot by our modellers without any complaints. Until now ;-)

    Do you think that the dxf-g utility that comes with brl-cad can be a solution to our problems?

  • John Anderson

    John Anderson - 2009-06-09

    I think that our dxf-g would certainly be worth trying. It should create a BoT when it encounters 3DFACE or POLYLINE mesh.

  • Wim Bokkers

    Wim Bokkers - 2009-06-11

    One last question. Do you think that it is possible to convert a list of arb6 primitives (in a region) to a BoT for *existing* geometries? We need a fix for our existing models in order to make g-stl work for them.

  • Sean Morrison

    Sean Morrison - 2009-08-19

    It's certainly "possible" but not at all simple. At least I can't think of a simple _generalized_ way that would result in solid geometry without a fair bit of work. There's not any existing tool or set of routines that I'm aware of that will do the conversion for you automatically, so you'd have to write some scripts or develop a tool that attempts the conversion.

    Your best bet is to probably write out the vertices for all of the arb6's and then parse out the three vertices that correspond to the actual/original surface. Using those vertices, recreate a BoT using those faces (which are all presumably connected and close space).

    If you have the original dxf-or-whatever models that resulted in the arb6 primitives, you might have an easier time just rerunning a conversion.

  • John Anderson

    John Anderson - 2009-08-23

    I have commited some code that might help you in the "jbrlcad" sub-project of BRL-CAD. This is a java project. Try checking it out, and running ant javadoc in the top level jbrlcad directory, then point your browser at the "build/docs/index.html" file. Look at the javadoc for the Arb6ToBot class. I have tested this on your radome.g (using a tolerance of 6mm), and it seems to work OK.

  • John Anderson

    John Anderson - 2009-08-23
    • assigned_to: nobody --> johnranderson
    • status: open --> closed-accepted
  • Wim Bokkers

    Wim Bokkers - 2009-08-24

    Thank you guys, for your great help!
    I need to find time for taking a look at the Java code. If it works, it will save us hours and hours of work.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks