Replies: 2 comments 4 replies
-
|
Salut, This is the HELIX from 2000/Helix.dwg Its CLASS is so any type 517 is the HELIX, which is a subclass of a SPLINE. The AcDbHelix specialization has these fields after the AcDbSpline: // AcDbHelix
BITCODE_BL major_version; /*!< DXF 90: 27 */
BITCODE_BL maint_version; /*!< DXF 91: 1 */
BITCODE_3BD axis_base_pt; /*!< DXF 10 */
BITCODE_3BD start_pt; /*!< DXF 11 */
BITCODE_3BD axis_vector; /*!< DXF 12 */
BITCODE_BD radius; /*!< DXF 40 */
BITCODE_BD turns; /*!< DXF 41 */
BITCODE_BD turn_height; /*!< DXF 42 */
BITCODE_B handedness; /*!< DXF 290: 0: left, 1: right (twist) */
BITCODE_RC constraint_type; /*!< DXF 280: 0: turn_height, 1: turns, 2: height */ |
Beta Was this translation helpful? Give feedback.
-
But do we agree Reading the logs you provided, I did not manage to understand what I overlooked.
So it's the HELIX "class" number which is 517, not its type? But so far I have been reading entities and their type. And their is a HELIX "type". But yet again it's not 517. Can you please elaborate? |
Beta Was this translation helpful? Give feedback.
-
How do you get those logs? That would greatly help me. Regards, |
Beta Was this translation helpful? Give feedback.
-
|
After a bit more investigation, here is what I came up with. The confusion arises from how LibreDWG handles object types:
This explains why in our converter, we should be checking fixedtype rather than type when looking for HELIX entities. The DWG_TYPE_HELIX enum exists for internal consistency and type safety, even though the actual DWG file contains type 517. Is this accurate? |
Beta Was this translation helpful? Give feedback.
-
|
obj->type is the number stored in the dwg, which is fixed for <500, and for >500 it's the index in the CLASS list (minus 500), which we call variable type. So 517 is the 17th class, but more importantly the class with number 517. Therefore I came up with fixedtype, which we map from type to a fixed enum. It's easier to check for this fixedtype field, even if the actual number is different for all variable types. If an object has a type >500, you need to lookup its class index. (or CLASS.number) The log is generated with Very happy to help with OpenCascade! |
Beta Was this translation helpful? Give feedback.
-
Perfect. Makes sense. Since I am using OpenCascade for the meshing and Assimp for the export to glTF, I am using C++. So I've used C++23 + concepts to have per-revision implementations/quirks resolution at compile time. I'll see if/how I can express the type/class ID thing using types / compile time notation.
Wow. I don't want to know why this ever existed! Glad I don't have to deal with this.
Thank you! I'll release the code as soon as I can. I'm not sure how I'll test my implementation though. Since I have the glTF 2.0 exporter and the renderer already I might leverage that. But I'm also exporting DWG metadata using |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello there!
First of all, thank you for the fantastic work!
I am working on an OpenCascade based tool to create glTF 2.0
.glbfiles from DWG files.I intend to open source this code under (A)GPL 3.
Anyway, to make sure my implementation works as well as possible, I am relying on the
.dwgsamples.One of them -
Helix.dwg- caught my eye.I expect it to contain a
DWG_TYPE_HELIX. But when reading the file, I get the517entity type. Which matchesACSH_SPHERE_CLASS. And as far as I can tell there is not a singleDWG_TYPE_HELIXentity/object.Am I missing something?
Regards,
Beta Was this translation helpful? Give feedback.
All reactions