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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wim,
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
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.
Solid consiting of arb6 prims.
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
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.
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?
I think that our dxf-g would certainly be worth trying. It should create a BoT when it encounters 3DFACE or POLYLINE mesh.
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.
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.
Wim,
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.
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.