DG Kernel and Open Cascade
Posted: Thu Nov 29, 2018 7:32 am
Dear all
Open Cascade (OCCT) is the core of the parametric bspline modelling in DG Kernel, so it deserves a separate thread. I will be expanding this with time when I have some clear and useful thoughts to share. So, please check it again some time later.
In v6 we have decided to part with the native OCCT interface for a number of reasons. The main one is to make it more familiar to software developers as opposed to mathematicians.
One basic difference is that indexing in DG Kernel is 0-based. More fundamental differences are:
- Identity problem
- Shared as opposed to value objects
More details:
Identity Problem
It is tightly related to passing object by value. The main thing is that OCCT does not have a separate object for, say and edge. Or rather it is so hidden in the guts so it is practically inaccessible.
Because everything is copied by value, every shape keeps own copy of its sub-shapes. So a cube, for an example, has 24 TopoDS_Edge instances and no single object for geometrically coinciding edges. Instead OCCT offers IsSame() and GetHash(), but this makes it a bit awkward, say if you need to map an edge to some custom data. Hash is something, but it changes with location. So in reality geometric edge is a set of equivalent, up to IsSame(), edge instances.
Sharing objects
Our approach we believe is clearer to developers. An edge (IBRepEdge_DG) is reference to an edge shared by adjacent faces. So a cube has the expected 12 edges and 8 vertices (not 24)
More soon
Open Cascade (OCCT) is the core of the parametric bspline modelling in DG Kernel, so it deserves a separate thread. I will be expanding this with time when I have some clear and useful thoughts to share. So, please check it again some time later.
In v6 we have decided to part with the native OCCT interface for a number of reasons. The main one is to make it more familiar to software developers as opposed to mathematicians.
One basic difference is that indexing in DG Kernel is 0-based. More fundamental differences are:
- Identity problem
- Shared as opposed to value objects
More details:
Identity Problem
It is tightly related to passing object by value. The main thing is that OCCT does not have a separate object for, say and edge. Or rather it is so hidden in the guts so it is practically inaccessible.
Because everything is copied by value, every shape keeps own copy of its sub-shapes. So a cube, for an example, has 24 TopoDS_Edge instances and no single object for geometrically coinciding edges. Instead OCCT offers IsSame() and GetHash(), but this makes it a bit awkward, say if you need to map an edge to some custom data. Hash is something, but it changes with location. So in reality geometric edge is a set of equivalent, up to IsSame(), edge instances.
Sharing objects
Our approach we believe is clearer to developers. An edge (IBRepEdge_DG) is reference to an edge shared by adjacent faces. So a cube has the expected 12 edges and 8 vertices (not 24)
More soon