Little more about the way the new DGKC .NET control works:
The control is implemented as a DGKC C# class:
At the fourth level the base class is System.Windows.Forms.Control.
Code: Select all
[DisplayName("DG Kernel Control")]
[Description("3D modeling and computing component.")]
public partial class DGKC : UserControl
ThreeState_DG m_eDesignMode = ThreeState_DG.Unknown;
So, at the top level it is a .NET control, with all the normal functionality. Little deeper DG Kernel specific execution goes into the common core shared by all (native) controls of the suite. The core is implemented in modern C++. We do this transition as soon as possible.
This is the way it has to be. .NET is cool and productive for development, but for the heavy lifting where extremely complicated algorithms handling millions of elements are executed it has to be the native code.
Implementing algorithms in .NET would be completely wrong. Why so? Ah, do not get me started... CLI code is only lightly compiled. At runtime there are tons of third party code is being loaded. Its JIT compilation would result in frequent unresponsiveness. Loading the large data structures like meshes consumes lots of memory collected randomly much later, which is practically a memory leak...
Do not get me wrong. We love .NET. Life would be miserable without it. What I am saying is that .NET is not intended for implementing core CAD.
"Pure" .NET 3D software does not exist because DirectX, OpenGL, and other lowest level graphic libraries are all implemented in C++.
C++ is also the standard for 3D, CAD and geometry handling components. This allows us to avoid inventing a bicycle and do our own contribution instead. It gives us flexibility. There is still lots of unexposed functionality to do. So we always say: "Talk to us. What you need might be quick and easy to deliver."