Port to Winform and SharpGL?

Hello,

First of all, I would like to say that GREAT JOB. I have checked the demo apps and it is very impresive work.

I was wondering if it is possible to easy port this library to Winform and SharpGL?

I dont know too much about WPF.

Thanks in advance.

This library targets WPF only and is based on the System.Windows.Media.Media3D classes.
Sorry, there are no plans to port to Windows forms and OpenGL.

Is SharpGL even being maintained by anyone any longer?

Well, but there is a DirectX 11 version with SharpDX coming up, isn't it?

Yes, WPF+SharpDX/DX11 (and maybe Windows Store App+SharpDX) is the direction I would like to see this project moving!
Keep up the good work on the sharpdx fork, Przem!

It a pity that is not plan to port it to winform at least. The last time that SharpGL was updated was on Jan 30, 2013.

I looked around very fast the source code of Helix 3D toolkit, and I found get my lest a little lost. I am not familiar with WPF. Do you think that it will be very hard to port to Winform + SharpGL or SharlpDX?

Maybe I can start the porting the code.

It would be interesting to port the functionality that could be platform independent (importers/exporters, camera manipulation, geometry classes) to a portable class library. The same code could then be used for both WPF, SharpDX, OpenTK and SharpGL based projects!

Objo, I dont mind to start that project. If you give me some hint and guidance. I will do it without problem.

I would like to see the file importers/exporters refactored to be platform independent, and sharing the same design pattern. The geometry / mesh generation classes are probably not so good candidates, since these should use the platform's Point/Vector structures for performance...
Feel free to start a fork on this! I wish I had time to follow up, but I'm focusing on other tasks at the moment.

I did some preliminary work on this kind of thing (geometry/mesh generation) with an intern about four years ago, and I still have the C# code he did. It seems to me that platform independence could probably be done with a helper static class, making attached methods, one for each kind of library.

Does the architecture make sense in terms of Helix?

It would be great to see different solutions how this can be achieved without duplicating code on the different platforms! I have not been thinking of a static class with attached methods, please post some examples.

I think performance is important for the mesh generating code. I think this means that platform specific data types (e.g. point, quaternions, transformations) should be used as much as possible, but it is possible that the platform specific data types do not need to be exposed in the public interfaces.

Pardon my incorrect use of jargon: What I meant was "Extension methods". Enabled by the .NET Framework, an extension method is decorated with the [Extension] attribute (which might only be a VB.NET requirement), declared static, and takes as its first argument an argument of the type which it extends. For example (from MSDN documentation):

namespace ExtensionMethods
{
    public static class MyExtensions
    {
        public static int WordCount(this String str)
        {
            return str.Split(new char[] { ' ', '.', '?' }, 
                             StringSplitOptions.RemoveEmptyEntries).Length;
        }
    }   
}

Which is then used by declaring using ExtensionMethods and:

string s = "Hello Extension Methods";
int i = s.WordCount();

I note that you have four such classes in the code base which I have (privately) forked for my own use.

What strikes me as interesting is that almost every 3D implementation uses a unique type name for its points, quaternions, and transformations, but the actual structure of the structs or class data have to be identical or nearly so. For games, performance of mesh generators is not vital; under the only architectures I can think of, most of those are loaded or preloaded before a high framerate is needed in the game. For engineering use cases, a high triangle count plus a relatively low framerate (mouse gesture animations, mostly) are the order of the day.

Frankly, for most mesh generation, I'm writing my own code against my data models and emitting the WPF formatted arrays and assigning them to the various Visual3Ds I use from the Helix library. So what I'm thinking about is extension methods like "ToOpenGL--structure--" or "ToSharpDX--whatever--" which would take the WPF structures native to Helix and emit the ones compatible with the other libraries. With a modern i5 or i7 and TPL it wouldn't even be computationally time consuming to execute such functions unless the facet counts were in the millions.

For my engineering based low-frame-rate, medium-delay-tolerant use cases, such an approach would not be so bad. I may give this more thought; the OpenTk stuff looks very, very compelling for non-WPF reasons.