Page 1 of 1

DG Kernel and Open Cascade

Posted: Thu Nov 29, 2018 7:32 am
by nickz
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

The value of OCCT

Posted: Mon Dec 03, 2018 2:04 am
by nickz
It is easy to fall into criticising OCCT and I am guilty of that too. We have to remember though the enormity and complexity of the task. CAD/CAM is everywhere these days. Nothing being manufactured without modelling at least, or better simulation. So a geometric kernel means virtual manufacturing of everything.

Any commercial kernel costs 100K plus pa, which rules out practically any small business. So how good, say is OCCT.s documentation is irrelevant for them. It I simply the only option for lots of projects.

So heads off to people who made it open and keep maintaining and developing it

How open is Open Cascade

Posted: Tue Dec 04, 2018 4:46 am
by nickz
Some people are questioning this, but we did not have problem finding (eventually :)) the relevant code.

The opaque handles design seems to be geared for very restrictive access, which does not really make good sense in open source software, but it is matter of getting used to it. This probably is a consequence of the fact that OCCT was not designed to be open from the start.

In my view the main problem is in the size and complexity. Somewhat surprisingly having source code actually does not make that much difference. One has to be real CAD development pro to just figure out how things work, which can take years. This is true generally for any large system

Interface

Posted: Wed Dec 05, 2018 7:01 am
by nickz
Formally in v6 we have actually three interfaces to OCCT:

- The new DG interface set
- KC interface set, which closely follows OCCT API
- And also via ITechnology_DG (see http://www.dynoinsight.com/Help/VC/OcctBridge.aspx ) one has access to the actual underlying OCCT API

The last option is most useful for C++ developers, but it can also be consumed in .net via small managed C++ proxy dll. (Get it touch if you need help with that)

The second option might be useful for backward compatibility or if you have good prior experience with OCCT

All sets can be mixed and used simultaneously

Added Value

Posted: Sun Dec 09, 2018 6:50 am
by nickz
With DG Kernel we are trying to smooth sharp corners of OCCT, modernise it a little, make it more compact and simple.
Examples:
http://www.dynoinsight.com/Help/V6_0/In ... pe_DG.aspx
http://www.dynoinsight.com/Help/V6_0/In ... ce_DG.aspx
http://www.dynoinsight.com/Help/V6_0/In ... ce_DG.aspx

The DG interface covers the most popular functionality, but not the whole OCCT. We intend to keep on with it in the next minor version(s). We would love to hear from you regarding your priorities

Ideally we would like to make DGL a higher level software with many automated/aggregated features.