We may need someone to take over ODN.

EagleEye

29-10-2005 17:14:22

OgreDotNet is adrift without a main developer.

I must admit that I am a VB.NET guy, and I can't really do much with the completion of ODN, because it requires familiarity with C# and C++, and SWIG.

So, we need someone who is willing to pick up where Maleficus left off, and continue the project, who would be willing to put in the time and effort, and get this darn thing done.

Anyone willing to step up to the plate?

Nachtwind

30-10-2005 08:41:01

I would like to help wherever possible, but unfortunately i can't do much .Net yet... i may ask arround some people i know that use Ogre#...
But i would still like to offer a service of daily ogre build... maybe this could benefit to the project...

Kanma

02-11-2005 13:21:41

I didn't have a lot of free spare time (three other projects and my wife), but if nobody else wants to do it, it can be better than nothing...

But don't expect three updates per day then ^^

Nachtwind

02-11-2005 15:45:45

hmm... if there is someone there who might explain swig to me i would try myself on the interfaces...

EagleEye

02-11-2005 23:17:02

hmm... if there is someone there who might explain swig to me i would try myself on the interfaces...

SWIG is basically an automated wrapper utility... www.swig.org I believe...

I've been trying to figure out how it works based on what's already been done, but I haven't been having much luck. Part of my problem is my lack of C# knowledge... I'm a VB person, so the learning curve is doubly steep for me.

mamba

03-11-2005 11:21:53

Hi,

I also have at the moment not so much time.

- My Problem is that I start only with VS2005. I do not go back and buy
VS2003.
- I've used and changed some wrappers for c->c# but I never used
swig for automatically doing this.
- And the next thing is that there is no working project with VS2005.
I am also able to work in linux - but I did'nt recompile the mono stuff -
so it is also not working for me right now.

If I have a good starting point then I'll join to your group.

Mamba

Kanma

06-11-2005 15:23:13

Part of my problem is my lack of C# knowledge... I'm a VB person, so the learning curve is doubly steep for me.

Don't underestimate the C++ side of the work either (templates magic and things like that) ^^

Maybe we could turn it into a team effort? Have a look at what is existing and what is lacking, and split the job?

Nachtwind

06-11-2005 20:24:52

if there is need i would like to participate with the things stated above: Daily Builds and a bit Interfaces (Though i am not that good in C++ i think)...
And a teameffort would be interestering.

rastaman

07-11-2005 22:14:37

We definitly need new leader ship here. like others have sead maybe the whole comunity working on it. I'm not using ogrenet for any project right now but i do want to get back into this, I like C# more than C++.

I am also able to work in linux - but I did'nt recompile the mono stuff -
so it is also not working for me right now.

the current cvs of mono has a fix for that fixed statement problem. But you don't have to rebuild mono just chang in the Math3D lib the functions that use unsafe statment, MOVE unsafe to the function declareation. Like in Vector3.cs the [] operator
unsafe public float this[int index]
I posted about the latest build scripts in thread http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=21 and emaled them to Maleficus but have not herd from him.
I would submit a patch for the Math3D changes but it look like nothing will happen :(

Clay

04-12-2005 07:41:48

I'm willing to take over the development of ODN after the 19th of december if there is still a need for someone to do so.

Qualifications
I am an avid C++ and SWIG developer, I am competent with C# (not quite an expert), and I've maintained PyOgre (another SWIG based Ogre binding) for the last year.

Plan
If I am maintainer I would probably merge the OgreDotNet source tree and the PyOgre source tree so that you can compile either by simply doing: #define PYTHON_BUILD for python or #define CS_BUILD for C#.

Reasons for this
The pyogre source tree already has 90% of Ogre library wrapped. This means that after pyogre is sectioned off into Python and C# sections, adding bindings for python should also add bindings for C#. Anything that is python specific or C# specific can be put inside #def gaurds so that it only affects one library or the other. This should speed up development on both libraries because you are getting my commits, fog's commits, and dermot's commits to pyogre, along with all commits the OgreDotNet community makes.

What would happen if I am maintainer
General Plan:
  1. I'll spend a few weeks updating the PyOgre SVN to accomodate C# development.[/*:m]
  2. After the PyOgre source can handle other langauges, I'll begin to merge the current OgreDotNet source into an SVN branch.[/*:m]
  3. After this branch becomes usable (IE can run the current Ogre.Net demos) we will start expanding the library.[/*:m]
  4. I will try to adhere to the standard PyOgre release schedule for OgreDotNet (biweekly incremental releases, releases for major versions within three weeks usually).[/*:m]
  5. When the library is in a usable state, I will start porting demos to C# and I will also start porting my tutorials to OgreDotNet.[/*:m][/list:o]

    Organization:
    1. Current OgreDotNet developers will get SVN access to the PyOgre repository. (Who has CVS access to OgreDotNet? Is it just you EagleEye?)[/*:m]
    2. Contributers who regularly submit quality code will be offered SVN access by invitation.[/*:m]
    3. If the original maintainer decides he would like to pick it back up I will step down and pass it back to him. He and I will work out what to do with the code base if this happens.[/*:m][/list:u]

      What now?
      Of course I'm not going to just take over OgreDotNet. I'll only do so if the community here thinks what I have outlined above is a good idea. I'll also try to contact the original maintainer to let him know what's going on if I become maintainer.

      What do you all think?

EagleEye

04-12-2005 18:51:27

You may want to investigate what we have done with ODN so far. Much of it is already wrapped. We've also seperated out much of the math functions in to our own Math3D.DLL, so math functions don't have to cross the wrapper.

I'm not comfortable with merging the source trees. I'd like to keep them seperate.

Otherwise, your experience and knowledge are very welcome.

Clay

04-12-2005 19:50:27

You may want to investigate what we have done with ODN so far. Much of it is already wrapped. We've also seperated out much of the math functions in to our own Math3D.DLL, so math functions don't have to cross the wrapper.
What was the reasoning for this? I'm not sure I understand the benefit.

EagleEye

05-12-2005 05:20:05

You may want to investigate what we have done with ODN so far. Much of it is already wrapped. We've also seperated out much of the math functions in to our own Math3D.DLL, so math functions don't have to cross the wrapper.
What was the reasoning for this? I'm not sure I understand the benefit.


Math functions are used quite often. Every time something crosses the wrapper, there's an additional overhead. The math functions are pretty straightforward, and were easy to port over. So what we have is a hybrid port/wrapper. Math3D.DLL is also portable to other applications, so it can be used in other stuff.

Clay

05-12-2005 07:18:43

Makes sense.

This could easily be done even if we merge the source trees. The math functions would be removed from a C# build, and have a seperate project for ODN Math that is built along side it (much like what is done now). I'm not really suggesting writing ODN or changing the dynamics of the library to run slower, just to make it so that one SWIG based ogre bindings can generate multiple language targets.

EagleEye

05-12-2005 07:50:28

Again, I reitterate... check out the ODN project so far, and see how far it's progressed...

It seems like what you're proposing is to throw out everything that's been done and start over.

adamhill

05-12-2005 17:37:22

Clay,

What about possibly compiling the durrent PyOgre stuff with Iron Python? It is a .NET 2.0 only solution but it would save the pain of modifying the wrappers. In the end you will get .NET assemblies as well.

adam...

rastaman

05-12-2005 20:41:50

It seems like what you're proposing is to throw out everything that's been done and start over.

I don't think so. Most of it is duplication anyway the other part is probably C# specific. I mean we are all headed for the same goal, wrapping Ogre. To the end user it should not make much difference.

Clay: it may not be easy, swig's c# support it not a mature as python. For instance there is no std_list.i I'v been trying to convert std_vector.i over to use std::list. Need it for RaySceneQuerey. I don't want to make a custom wrap around it.


In any case Clay, your help with OgreDotNet would be appreciated.

Clay

06-12-2005 03:36:42

Sorry, I'm right in the middle of a rediculously large project which is due wensday and a paper due thursday. I'll post a more fully fleshed out reply thursday.

Again, I reitterate... check out the ODN project so far, and see how far it's progressed...

It seems like what you're proposing is to throw out everything that's been done and start over.

I promise you this is not what I'm aiming for. I'm literally looking to merge the two source trees and clean up the result. This means that I would be rewriting the build process and adding .i files which PyOgre has but C# does not, but not rewriting the whole thing. I would never sign up for rewriting the entire codebase.

I have looked at the source tree, but I've been so busy these last few weeks I'm not fully up to speed on it. Let me get back to you in a few days with specifics.

What about possibly compiling the durrent PyOgre stuff with Iron Python? It is a .NET 2.0 only solution but it would save the pain of modifying the wrappers. In the end you will get .NET assemblies as well.
That's not actually a possibility for PyOgre since it relies on the Python/C API (which is not compatible with IronPython). The best that would probably be done is to compile OgreDotNet and allow IronPython to import the ODN C# library (which I think IronPython can already do, but I'm not sure).

As far as I know you can still use PyOgre itself with iron python, but you would have to include Python24.dll with the distribution.

Clay: it may not be easy, swig's c# support it not a mature as python. For instance there is no std_list.i I'v been trying to convert std_vector.i over to use std::list. Need it for RaySceneQuerey. I don't want to make a custom wrap around it.
Yikes. Are any of the other std containers missing?

You might also try creating a C# class which takes in an std::list<T> class and has a simple: getFirst, getNext interface as a proof of concept. Not the cleanest in the world but it would work. I have not had a lot of experience meshing templated C++ code with C#. That will not be fun.

What you are doing (modifying std_vector.i) is probably the "correct" approach to take but difficult to do.

I'll take a look at it after finals.

rastaman

08-12-2005 02:21:21

Yikes. Are any of the other std containers missing?

You might also try creating a C# class which takes in an std::list<T> class and has a simple: getFirst, getNext interface as a proof of concept. Not the cleanest in the world but it would work. I have not had a lot of experience meshing templated C++ code with C#. That will not be fun.

What you are doing (modifying std_vector.i) is probably the "correct" approach to take but difficult to do.

I'll take a look at it after finals.


std_set.i is missing, I don't know it if will be needed.

the std_vector.i that i converted already creates a class that derives from System.Collections.IEnumerable, and has functions like ArrayList.
yes I've finished it and tested a bit.
I also had to make a change in vector to use it with a pointer like vector<cVal*>. it has "const CTYPE &" in places, but that const & gives me compile errors. had to change it to just "CTYPE". in both std_vector and std_list. I asked on the swig-user email list about it , because it may be a problem in how i did the pointer type mapping. But no one has replied yet.

you can take a look at what I did here its a small test