SAT parser contribution

[JMLX42]

Follow up on #1158

Since I need SAT parsing in C/C++, I'm going to attempt to port this to C/C++.
And since it is my understanding that DWG files might contain SAT data, it might probably be better to use C.
Still, I was wondering what would be the best course of action project wise:

• A separate SAT parsing library that libredwg might leverage
• A pull request to add SAT parsing to libredwg

Please let me know.

[rurban]

We dont know yet. For creating SAT primitives we do need something, for now we are using templates. Which should be enough, even if it doesn't work yet. GH #1137
But parsing we probably wont need. That's really more a special case for solid modelers.

[JMLX42]

We dont know yet. For creating SAT primitives we do need something, for now we are using templates. Which should be enough, even if it doesn't work yet. GH #1137 But parsing we probably wont need. That's really more a special case for solid modelers.

I'm not sure what templates are in this context. Could you please elaborate?

Do you mean there is no need for a (complete) parser for rendering (as opposed to modelling)?

I was under the impression the SAT content would need to be evaluated and meshed via OpenCascade.

[rurban]

We only need to be able to create some primitives, like this BOX here:

libredwg/src/dwg_api.c

Line 29275 in b0616cc

dwg_add_BOX (Dwg_Object_BLOCK_HEADER *restrict blkhdr,

The boolean operations and constraints are then described via DWG objects. (Which is a horrible and inelegant format, but that's life). It's C++, not LISP.

The rest should be done either within the ACIS or some other 3D kernel. Best yours, because it's GPL.

We don't need to understand what's in it, because we don't want to create the surfaces and wires by ourselves. That must be the job of a 3rd party 3d kernel. If someone needs that.
We don't model nor render, we just do the IO.

[JMLX42]

So the SAT content only describes primitives, not 1. operations and no 2. construction tree? Both 1 and 2 are in DWG? That sounds nuts. DWG already contains the primitives. Maybe it did not at the time?

Or do you mean that libredwg doesn't need a complete SAT parser, but an app that needs rendering (like mine) does need it?

[rurban]

Yes, the SAT describes just the end result of the ACIS kernel computations, but the ops are modeled separately, in a DWG tree. They did it twice, first with AME (old ACIS) and single floats. Then a second time, because with low angle diffs (thin sheets) they lost precision, and upped their ACIS kernel with their extensions (history), kept the modelling in the DWG also ("better" tree), which they let do in Czech. I don't like their tree at all, it's hugely inefficient and complicated. Not even academic. But it keeps out the competition for sure.

For rendering we already have the faces and edges by ACIS, and they are stored separately in the 3d objects. So for rendering we don't even need a kernel, just for modeling.