Page 1 of 1

DG Kernel is new KernelCAD

Posted: Thu Jul 05, 2018 8:41 am
by nickz
Dear all

We have a preview of v6 exclusive for KernelCAD Forum users: ... 64_6_0.msi

The files will be updated weekly at least

As you see we are renaming the suite
More information shortly...

Digital Geometry vs CAD

Posted: Mon Oct 01, 2018 3:49 am
by nickz
Dear all
DG Kernel is getting somewhere, but we still have few things to add and solidify.
I intend to start explaining what is the idea and why the transition.

First of all, why is the name change?

The main reason is that CAD in the product name was a misnomer. We are developing a programming tool. A software which makes CAD programmable. CAD means design. Despite it does not mean a ruler and compass involved, somebody has to click menu options. draw lines, execute operations, etc. This is essentially manual work. Somebody has to think and do it on a very low level.

Geometric kernel on the other hand means automatic generation of objects. So it is practically the opposite.

Kernels are unavoidable not only because of productivity, but because there are many processes, particularly in CAM (see eMotion or Make your move samples in KC 5.2) where the surface is a result of complicated calculation which can only be performed in software.

So the Digital Geometry. It expresses very precisely what we developing and where we are going.

We still intend to develop all sides of rendering and viewer interaction, but DG Kernel not a finished ready to use application. It is a building block for your app or component, specific to your business.

More shortly...

History and Direction

Posted: Thu Nov 01, 2018 12:04 am
by nickz
KernelCAD has started a while ago with a modest idea of software for modelling and simulation of metal cutting tools. This pretty early has turned into a generic CAD kernel. Over the years the software grew and overstretched the initial intended design.

Like in many other software once a while a dramatic structural overhaul is needed. This is another reason for the name change and restructuring

Initially KC was a pure parametric tool with own arc-based type of splines (3DS sections). They are surprisingly flexible and simple. There are also similar SOR and pipes objects, but 3D scanners inevitably bring meshes. They are a quagmire for CAD. We have spend too much effort on it and the BSpline modelling added in v4 did not get enough attention.

With v6 we intend to break away and put classic parametric modelling on top. We intend to provide full set of standard modelling objects, operations and documentation with many coding examples

More shortly...

Interface and Persistence

Posted: Mon Nov 05, 2018 5:45 am
by nickz
Another reason for redesign is the new interface. Old one is becoming a bit of piecemeal. We have refreshed native KC interfaces. For example all IView* interfaces were merged into single IView_DG.

We have also make it uniform across all technologies. It is particularly related to Open Cascade staff, which has some distinct, specific style. I intend to write about OCCT much more a bit later

We also needed to re-implement persistence as it had some old technology, which was slowing down adding persistence for new features. New .mdg models load much faster. They also have text-based, xml-like format. More about it in documentation. It is possible to modify if in an application of by hand in case of something urgent, but this should be avoided for many reasons. One is that we do not open it to be able to change it at any time without any considerations

.glm still can be loaded and saved, but it will be going out of scope gradually

To be continued....

New notions: Entity, Geometry, etc

Posted: Thu Nov 08, 2018 4:39 am
by nickz
We also need to move close to traditional terminology. This was the reason for changing term for a 3D object from section to entity.

We have also realised that we need to separate geometry notion out of other properties of a 3D object. So in DG Kernel we have models which is a hierarchy (tree) of entities. Geometry is the major attribute of an entity. Other attributes are array of children, local frame (location/orientation of the entity) , appearance, name, etc.

Apart from other things this allows sharing geometries at different locations. Another advantage is that type of entity can be easily changed by replacing geometry. This is what often happens in Boolean Operations. It is different from KC where type of geometry was defined by the type of section (MeshSection, etc.)

Implementation of this was pretty smooth as this is a very natural transition. There were other new significant notions and related restructuring we did internally. This was done with further scalability and development in mind.

To be continued ...

Backward compatibility

Posted: Tue Nov 13, 2018 1:41 am
by nickz
We do our best to make it as many features as possible in this 6.0 release, but I am afraid there will be some losses on the margins.

It is good to talk about features in terms of samples. The samples which disappeared in v6 like Emotion, Capture, TwoD, eXplorer, ... are uncertain at this point. Some of them will be added when we finish with the current debugging. Some of them will come back in 6.1 and/or 6.2.

3D Debugger unfortunately is not going to make 6.0 release. It will be possible to debug using installed side by side v5.*. It is so useful we will have to do something in near future.

All KC (v5.*) interfaces related to the supported functionality will still be available. Objects can still be accessed via IModel > GetSection() > ISection, etc. So we will have a kind of "dual" (KC and DG) set of interfaces useable interchangeably

The final list of dropped out features will be in the "What is new" topic in help closer to the release date.

Parametric Modeling

Posted: Thu Nov 15, 2018 3:20 am
by nickz
For Parametric NURBS Modeling we rely on Open Cascade integrated since v4.0. So far it was supported via IKO_* set of interfaces which is very close to the native Open Cascade classes. They are still available.

Open Cascade is an awesome software, but it has its idiosyncrasies. A minor example is that all indices are 1-based. Another is that browsing shape hierarchy is pretty awkward with things like TopExp_Explorer. For a native C++ developer the opaque handles are a significant hurdle. And there are more issues I hope to come back to it another day

Our intension is to modernise, simplify and automate it where possible. We would like to make it a high level functionality. So all IKO_* interfaces have a new counterpart _DG interface without internal OCCT naming specifics.

We have exposed a number of new operations as opposed to KC 5.2. This work will continue at some rate before the final release and in updates (Send us a message to vote for your priorities). A major step to cover the rest of OCCT functionality will be undertaken in DG Kernel 6.1

See the dedicated thread for more on this: ... f=2&t=3100