Dear all
We have a preview of v6 exclusive for KernelCAD Forum users:
http://www.dynoinsight.com/Prod/V6_0/DGKernel_6_0.msi
http://www.dynoinsight.com/Prod/V6_0/DG ... 64_6_0.msi
The files will be updated weekly at least
As you see we are renaming the suite
More information shortly...
DG Kernel is new KernelCAD
Digital Geometry vs CAD
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...
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
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...
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
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....
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
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 ...
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
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.
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
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: http://www.dynoinsight.com/phpBB3/viewt ... f=2&t=3100
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: http://www.dynoinsight.com/phpBB3/viewt ... f=2&t=3100