You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
generating UUID v5 identifier in STEP pre-processor #424
Apologies for slightly off-topic issue.
We are working on a project to support CAD-CAD data exchange and update of a model.
We are planning to facilitate the exchange by using UUID v5 idenfitiers on specific STEP objects and aggregtes of STEP objects.
We are expecting to use the path from "the" root node of the CAD object tree to the current object as the "name" input to the UUIDv5 generator.
We are expecting to let the enterprise to set the value for the "namespace" input to the UUIDv5 generator.
The intent is that the resulting STEP file could be read back in to the originating CAD system and unchanged CAD objects would not be re-created by the post-processor.
If there is interest in this capability, please let me know.
Cool Tom! We implemented something loosely similar in BRL-CAD for cache objects using UUIDv5's, though I opted to use a binary serialization instead of the object name instead of relying on namespacing. I didn't tie that work to STEP though, only to our format.
In any regard, that's of course all not answering your question. I think what you're suggesting sounds interesting, personally. I'm not sure what it means in terms of STEPcode tools or API -- perhaps there could be a STEPentity iterator for computing and storing the uuid on entities, and/or another iterator for two STEPfile instances that calculates and compares? Or are you suggesting some new processing tool that would be bundled with STEPcode? What did you have in mind?
Glad to hear!
The CAD-CAD use case requires that unmodified data doesn't cause a re-write of the internal CAD model when ingested.
A generic STEPentity iterator will result in a multi-rooted tree. Maybe that is ok, but that is why we are focused on iterating over the internal CAD model as that "should" be a single-rooted tree. ;-)
To me that implies persistent storage internally in the CAD system of the mapping from objects to STEP entities.
I don't really have any specific thing in mind. I was hoping to kick off a conversation and get confirmation that the techincal approach of traversing a path from the root of the CAD tree to an object is robust.
And once we get down to the object, we are intending to capture the objects "below" that object in an aggregate.
So that a feature that has a complex representation would not only be identified at the feature object but also all its data values over in the representation.
Activity
brlcad commentedon Aug 16, 2021
Cool Tom! We implemented something loosely similar in BRL-CAD for cache objects using UUIDv5's, though I opted to use a binary serialization instead of the object name instead of relying on namespacing. I didn't tie that work to STEP though, only to our format.
In any regard, that's of course all not answering your question. I think what you're suggesting sounds interesting, personally. I'm not sure what it means in terms of STEPcode tools or API -- perhaps there could be a STEPentity iterator for computing and storing the uuid on entities, and/or another iterator for two STEPfile instances that calculates and compares? Or are you suggesting some new processing tool that would be bundled with STEPcode? What did you have in mind?
TRThurman commentedon Aug 16, 2021
Glad to hear!
The CAD-CAD use case requires that unmodified data doesn't cause a re-write of the internal CAD model when ingested.
A generic STEPentity iterator will result in a multi-rooted tree. Maybe that is ok, but that is why we are focused on iterating over the internal CAD model as that "should" be a single-rooted tree. ;-)
To me that implies persistent storage internally in the CAD system of the mapping from objects to STEP entities.
I don't really have any specific thing in mind. I was hoping to kick off a conversation and get confirmation that the techincal approach of traversing a path from the root of the CAD tree to an object is robust.
And once we get down to the object, we are intending to capture the objects "below" that object in an aggregate.
So that a feature that has a complex representation would not only be identified at the feature object but also all its data values over in the representation.