Mogre and OgreDotNet -- combine forces?
KeithCu
23-02-2009 12:56:45
Hi all;
It appears that both OgreDotNet and Mogre have been semi-abandoned. Well, what to do?
I think in such a scenario, we should use this as an opportunity to combine forces. We really shouldn't have two .Net wrappers around Ogre.
But in my mind, Mogre is fatally flawed: it uses Managed C++, which is a hacky, Microsoft-only language which doesn't work on Mono, and therefore doesn't support Linux and the Mac. One of Ogre's best features is support for multiple OSes, and if a wrapper takes away this feature, then the wrapper will never satisfy Ogre users.
Like Mogre, OgreDotNet is built primarily by automatic tools, using something called Swig which is a very popular tool for generating wrappers. In fact, we have experience in this on our team.
So, we might even be willing to do the main body of the work if you guys join us.
What do you think? Post your comments below.
Kind regards,
-Keith
Jubei
24-02-2009 06:36:28
You are right, and I wish I could contribute towards this endeavor.
Greenjacket
24-02-2009 09:58:43
Hi KeithCu
Sorry for double-posting - I posted this on
viewtopic.php?f=8&t=7320&start=30 by mistake
I'm very interested to read your proposal, and in terms of the OS-agnostic design intention of Ogre I think the idea is wholly laudible and worthy of full support - not being a Mogre or OgreDotNet maintainer of course!
![Smile :)]({SMILIES_PATH}/icon_smile.gif)
To be honest, I would have thought that there is a case for making the outcome an official part of Ogre itself - but of course that's another story.
Here's the 'but' though. Currently we are using Ogre 1.2 with the corresponding Mogre, and we have need to upgrade to Ogre 1.6 (to fix various bugs associated with shader handling, for example). We really need a Mogre for Ogre 1.6. Now, we would be happy to tackle the 'from scratch' Mogre 1.6 development ourselves, but I am not sure as yet from this thread (or the links from it) that we have access to all of the scripts and tools required to tackle such an undertaking, nor are we aware of all the considerations and pitfalls that might befall the novice, what needs to be hand-crafted (and why) etc. Indeed, is there anything else to obtain, or are the links from this thread enough to just go away and do it? Would you consider pointing us in the direction of developing Mogre 1.6?
Perhaps there might be a case for prioritising Mogre 1.6 development over the combined 'MogreDotNet' development, if there is more demand for the Windows variant?
I'd appreciate your thoughts.
cheers
Greenjacket
KeithCu
24-02-2009 10:19:19
Hi Greenjacket;
Thanks for your reply.
The problem with Mogre is that I don't have Windows
![Wink ;-)]({SMILIES_PATH}/icon_wink.gif)
Our product is currently developed using Mono on Linux. We were forced to use OgreDotNet for this reason.
I think an interesting question is whether you can use OgreDotNet, which currently supports Ogre 1.4.9. If you can use it, then you could continue to live with it as a combined entity. Do you want to spend a few hours of hacking and try? If not, no biggie. Right now, we are trying to gather interest, and see if we can agree to push ahead in one codebase to save time. Also, I believe that with Swig it will be easier to maintain Ogre wrappers, and it does have some custom 100% C# classes for niceness and perf, so I think that for most people OgreDotNet would be fine!
Beauty
24-02-2009 11:00:51
I don't know much about the backgrounds.
Just some thoughts and questions ...
* Generally would be good to have:
- an up to date .NET wrapper
- which can be updated without huge expense
- and we need people who have the qualification + pleasure + time
* What I dislike: a parallel development of 2 .NET wrappers
- this would be twice work for the very few maintainers
- incompatible code for the users (that create an application using a compiled dll file)
- the code examples / tutorials are not ready to use for all or has to be created/published for both (not nice)
* Is the source code (for applications) mostly / complete compatible?
(can you use Mogre code by OgreDotNet and reversed?)
* What are the differences / advantages / disadvantages of both? (in detail)
* I suppose the biggest problem for the missing Mogre update is to find a qualified developer
- you need good knowledge in C++/CLI
- you need time
- you need documentation about the internals and building process
(Is it a self made wrapper of Bekas or a modification of a common wrapper?)
(I suppose Bekas included optimizations and usefull additional things.)
* Would it be possible to add Mono support to Mogre?
If yes: Would it be much work?
Why it doesn't work now?
* Most users will only need Ogre for Windows. For other systems there is still the C++ or Python alternative.
But right, it would be nice to have support of other operation systems than windows.
* Generally - how many (less?) people are using Mogre?
In the forum are only a few active people.
Maybe there is only 1 Mogre user in relation to 100 Ogre users?
On the other hand - a stable wrapper for the current Ogre version would be a more convincing reason to think about using .NET.
* A history question: Why the development of OgreDotNet did stop? Did the main developer leave? There should be a reason why most of .NET users swapped to Mogre.
Sorry for double-posting
You can remove it. (This would be nice to avoid answers in both threads)
Currently we are using Ogre 1.2 with the corresponding Mogre
Generally you can use Mogre 1.4. Or did you mean your own project?
Now, we would be happy to tackle the 'from scratch' Mogre 1.6 development ourselves
It could have advantages, but this would be a long and hard way and you need qualified people with huge free time.
Generally very important is:
Wrapper updates should be possible for new people. If the developer(s) are gone the new people needed informations how the internals work and how to build.
This is independent of the wrapper. Generally I would say: an application without good documentation has a bad future.
smiley80
24-02-2009 12:25:43
* Would it be possible to add Mono support to Mogre?
If yes: Would it be much work?
Why it doesn't work now?
Mono doesn't support mixed-mode (managed and native code) assemblies at the moment and probably never will.
Has anyone compared the performance of Mogre, OgreDotNet and Axiom?
Greenjacket
24-02-2009 12:39:32
Hi Greenjacket;
Thanks for your reply.
The problem with Mogre is that I don't have Windows
Our product is currently developed using Mono on Linux. We were forced to use OgreDotNet for this reason.
I think an interesting question is whether you can use OgreDotNet, which currently supports Ogre 1.4.9. If you can use it, then you could continue to live with it as a combined entity. Do you want to spend a few hours of hacking and try? If not, no biggie. Right now, we are trying to gather interest, and see if we can agree to push ahead in one codebase to save time. Also, I believe that with Swig it will be easier to maintain Ogre wrappers, and it does have some custom 100% C# classes for niceness and perf, so I think that for most people OgreDotNet would be fine!
Hi Keith,
The only problem with Linux is that we don't have Linux!
You've raised some more interesting considerations. We did originally look at OgreDotNet, over two years ago now, but the project seemed to stagger along for a while and then Mogre suddenly appeared. The Mogre wrapping process (to an uninformed, ignorant outsider like me
![Wink ;-)]({SMILIES_PATH}/icon_wink.gif)
) seemed relatively quick in comparison with the OgreDotNet upgrade process at the time, and since we are committed to MSVisual Studio/C#/.NET that seemed pretty fortuitous at the time.
Now though, we need some of the bug-fixes and features of Ogre 1.6 so we need to upgrade from the (Ogre 12. + consistent Mogre) combo to Ogre 1.6 + something else. I agree that ideally it would be preferrable to have one wrapper, but we do unfortunately have this short-term need for a wrapper around Ogre 1.6. We'd be very happy to have a crack at it ourselves if we could gather all the relevant information and tools...
However, I don't know anything about the detailed mechanics of the Mogre or OgreDotNet wrapping processes, I have no idea how automated it is, how quick the process is, or how much manual maintenance and re-coding is required, and the background requirements - of either the Mogre or OgreDotNet processes.
So, I'm not quite sure where I go from here. How much effort is it to develop OgreDotNet to Ogre 1.6 and what tools / scripts /procedures / documentation contributions would be required? And it is not clear how much effort remains to complete the Mogre wrap of Ogre 1.6.
Ideally it would be great if we could get some fresh input from the main Mogre developers, to completely define a clean hand-over procedure, the current project status and a forward plan of action to complete the current Mogre wrap of Ogre 1.6; this could help our short-term need and simultaneously also help your project proposal.
Anyway, just a few more thoughts for the mix.
cheers
Greenjacket
KeithCu
24-02-2009 14:43:21
OgreDotNet works on Linux, Mac and Windows. We just develop on Linux now, but we plan on shipping on all 3 OSes.
That is why it is really the better wrapper. It is build using Swig which is a very popular means of wrapping code used all over the place. It is arguably a better way to build than the Mogre weird tools to generate managed C++.
I investigated Axiom as well and it looks interesting but it isn't mature yet.
The OgreDotNet developer stopped because his team switched to Python. But the work he did is good, and we are using it with Ogre 1.4.
Beauty
24-02-2009 15:38:32
Mono doesn't support mixed-mode (managed and native code) assemblies at the moment and probably never will.
I read about somebody who had problems to use some Ogre functions by Mogre.
He told that the only way was to use unsafe code for it.
I don't know about the backgrounds. Maybe problems with wrapping pointers?
Also I don't know if this is a native code problem and if this happens with OgreDotNet.
In the thread
The Future of Mogre (Shoggoth) I asked Bekas for Mogre wrapper informations and suggest to write it to a wiki page.
Maybe the same could be done for OgreDotNet, if there is an interest to update the wrapper.
Bekas
24-02-2009 17:25:44
Hi KeithCu,
It won't come as a surprise that I personally don't like SWIG (otherwise why would I start Mogre, right ?). I wanted very fine-grained control of how the wrapping works and C++/CLI was convenient for the .NET <-> native bridge (very easy to call .NET from native and vice versa, native fields don't need wrapping functions for access by .NET, etc). The downside and the price to pay is, of course, that it's not cross-platform.
Since you are on linux, OgreDotNet (or Axiom) is your only option so I'd recommend to get started on that; once you get a quality up-to-date wrapper working, it'll be much easier to attract people ("build it and they will come" is my moto
![Smile :)]({SMILIES_PATH}/icon_smile.gif)
)
KeithCu
24-02-2009 19:43:40
I don't know the history, but there are people left in the lurch now that Mogre has been abandoned, and a single, less than perfect wrapper is better than 2 abandoned ones.
We are considering fixing up OgreDotNet, but we are considering other things as well so I'm trying to gauge interest. We don't want to be the only people using OgreDotNet.
Beauty
25-02-2009 10:45:03
KeithCu
25-02-2009 14:57:45
Portable .Net doesn't understand Managed C++ either.. The problem is Mogre generates Managed C++ which only MS supports. OgreDotNet generates C#, which Mono and MS's .Net support.
KeithCu
03-03-2009 04:19:36
Hi all;
We've just had a great idea. We are thinking of bringing Python-Ogre to .Net via IronPython. This would allow us to just leverage existing Python wrappers and not have to maintain them. It would make OgreDotNet and Mogre unnecessary and allow us to combine forces with the Python-Ogre team.
Python-Ogre is great because it wraps a bunch of Ogre libraries besides Ogre itself:
OGRE 1.6.0RC1
OIS 1.2
CEGUI 0.6.1
QuickGUI 0.9.7
ODE 0.10.1
OgreOde 1.0
OgreAL 0.3
betagui 1.7
OgreNewt 1.0
Opcode 1.3
PhysX 2.8.1
NxOgre 1.0-21
bullet 2.70
OgreBullet 1.0
theora 0.5.0
plib 1.8.4
ogreforests 0.1
et 2.2
caelum 0.2.1
noise 1.0
particleuniverse 0.8
cadunetree 0.6
ogrepcz 1.0
hydrax 0.3
Is this something you guys would be interested in? We can do any of the work, and you can call it all from C#, on Linux, Mac or Windows.
It makes me think we should kill OgreDotNet and Mogre!
boyamer
03-03-2009 08:19:07
Thats nice KeithCu,you're right,IronPython will let us to use Ogre Python with c#,
nice Idea,there are also samples on the forums of PyOgre!!
Just do it!
Greenjacket
03-03-2009 09:10:52
Hi KeithCU.
Sounds very interesting. We'd just be interested in the graphics side of things though - we have our own physics engine - so would it be easy for us to produce a cut-down version (I presume so, but should ask)?
cheers
Greenjacket
Beauty
03-03-2009 11:11:06
Beauty
03-03-2009 11:41:05
Is everything possible with IronPython what you can do with Python itself?
Maybe the wrapped libraries can be used by Phython, but need something like a second wrapper to use it from .NET.
I don't know the backgrounds - because of this I ask.
Maybe we also can ask PythonOgre users for their experience with IronPython.
We could open a thread in the Python forum and talk there.
Are there examples of IronPython with Ogre?
In the OgrePython wiki I didn't found any page with the word IronPython.
What wrapper technique uses PythonOgre?
SWIG?
boyamer
03-03-2009 11:53:09
KeithCu
03-03-2009 12:00:22
IronPython is a very compatible version of Python.
Once hooked up via IronPython, Python-Ogre should then be callable from other .Net languages.
You won't see much mention if IronPython with Python-Ogre because it is so new, and because I just thought of it!
@Greenjacket, it should be possible to trim Python-Ogre down to just what you need.
GantZ
03-03-2009 19:00:29
interesting thread, my main concern here is performance. C++/CLI could be microsoft only, it's definitely the better choice when it come to keep performance as close as with the original native libs.
what is good with mogre is that it's a really performant wrapper. no cross platform support is the necessary drawback for it.
the idea to use python-ogre is definitely something to try. from my point of view, you will need to create python script to access the engine functions then compile it in a .net library. still, it could be the better solution when it come to having cross platform support with good performance.
KeithCu
03-03-2009 20:15:02
The Python script to access the Ogre engine functions should exist as that is what Python-Ogre is. So it is just a matter of figuring out how to call Python-Ogre via IronPython, from C#.
I wouldn't worry about performance. People have built commercial games using Python-Ogre with all their Python is interpreted. With IronPython, the code will be compiled, so it should in general be faster than standard Python. And this stuff all gets better over time. IronPython 2.0.1 is faster, Mono 2.2 is faster, etc.
We are thinking hard about doing this task as we have the expertise, but we won't get to it for several weeks or up to several months. And whether we have people could help us, test it, etc. will also play into when we do this.
Beauty
03-03-2009 21:11:46
If I know how it works, I would give it a try.
First a simple example, e.g. a tutorial.
If this works fine and I understand it, I would try to replace Mogre with it in my main application.
Theoretically it shouldn't be hard work (except for the Ray classes - these are different to Ogre).
This time I don't plan to cut off Mogre from my application. I don't need the newer features.
Also I need support for Newton 2 for the main focus of my application (simulation of sonar sensors).
But a comparison with the Python way would be interesting to compare.
Also to check if special problems happens with Python, too.
Because there are a few problems where I (and others) doesn't know if the Mogre wrapper is the source of problem or Ogre or another library or a depency.
smiley80
03-03-2009 21:15:48
I love Python (executable pseudocode).
But iirc you can't access IronPython assemblies directly in C# (might change in 4.0 with the new 'dynamic' keyword).
So you would end up creating a wrapper for the wrapper...
KeithCu
03-03-2009 21:52:49
Sorry but Python-Ogre and IronPython is a no starter
In looking at IronPython it turns out that it can't import .pyd files ('C' modules) which is what Python-Ogre is all about -- basically Python-Ogre is a boost-python wrapper directly on the Ogre (and other) modules and the end result are cpython (.pyd) modules that then get imported like a normal python module -- and this is not compatible with IronPython...
Regards
Andy
KeithCu
04-03-2009 10:54:16
Thanks for your explanations.
Actually resolver systems is working on getting this scenario to work, but it is alpha code and only runs on Windows:
http://code.google.com/p/ironclad/
Note, this also doesn't solve the problem of building something callable from .Net.
KeithCu
04-03-2009 11:22:32
Okay,
After researching IronPython more, thanks to the discussion on this alias, it makes me think that using Python-Ogre directly is not a good and feasible idea.
Or, we all give up and move to Python.
![Wink ;-)]({SMILIES_PATH}/icon_wink.gif)
But Python-Ogre seems to mostly be built by one person, and the Python gaming community doesn't seem to be that big. So it might just be that we need to get organized and quit building duplicate wrappers and creating other messes that are just shooting ourselves in the foot and pushing people away from .Net gaming.
I will research this more, but maybe not for a couple of months. But working on Mogre is, in my opinion, a waste of time because it is not cross-platform, and will never be because of Managed C++, which is a hack that is not even respected or widely used inside Microsoft. If we are going to choose which of these two dead wrappers to revive, I would recommend reviving OgreDotNet, unless Mogre can be made to support C#. Or maybe we need a new tool that lets us leverage aspects of Python-Ogre / Py++ design to help us.
There is one other possible option...
The primary strength behind Python-Ogre actually lies in the way the wrappers are created -- Py++ is used (which is a VERY cool tool) and it automatically parses the headers and generates wrappers auto-magically from them -- most of my generation code is simply to handle exceptions and places that need to be hand wrapped..
As an indication it was a 10 minute job to go from Ogre 1.4 to Ogre 1.6 !!!!! And the overall project has reached a maturity level that most of the current development is in adding new libraries (RakNet took 1 week of very much part time work -- probably 4-6 hours total)..
So it might be possible to take some of what we do on Python-Ogre and use it to create CLI wrappers instead...
I'm going to investigate this further (will probably take a couple of weeks)....
Andy
Beauty
04-03-2009 13:45:28
But Python-Ogre seems to mostly be built by one person, and the Python gaming community doesn't seem to be that big.
It's the same for the .NET wrappers.
Mostly developed by only one person and used by less persons (in comparison to C++). And when this developer stop his support, then the project lost his main pillar.
Also we see again, that a good and future orientated software needs a good documentation of the internals. Otherwhise successors will get a headache.
I will research this more, but maybe not for a couple of months.
Thanks for all your research you have done
By the way - what is the focus of your group?
Maybe making games or animation films or Linux development or ...
Do you know each other from the internet (maybe worldwide) or do you know personally (e.g. from school)?
How many people are you?
Just for interest ...
KeithCu
04-03-2009 17:45:18
@Andy:
This is what I was starting to conclude: that we need better a wrapper or wrapper generator, potentially ones that let us leverage the Py++ design, or even the Python-Ogre configuration files for Py++.
@Beauty:
We are working on this:
https://launchpad.net/openracing
Right now, there are 3 of us, but we are a part of the Torcs / Torcs-NG community and hope to join up with them at some point.
smiley80
05-03-2009 20:24:31
I stumbled over this binding generator:
http://imaginary-project.net/doxybind/
I'd only had the time to made a test run, fixed some errors...seems fine so far.
Update:
It appears to have some issues with nested types...
galaktor
04-05-2009 13:04:41
I am very interested in a platform-independent mono/c#-wrapper for ogre! In fact, it is the only factor missing for my platform-independent game-engine project.
AndroidAdam
05-05-2009 17:30:45
I stumbled over this binding generator: http://imaginary-project.net/doxybind/
I'd only had the time to made a test run, fixed some errors...seems fine so far.
Update:
It appears to have some issues with nested types...
Theres a link to a PhysX wrapper they created using that tool, has anyone tried that and saw how it works? Or if it runs on mono.
Edit to avoid double posting:
Would it be possible to compile Ogre to C++/cli (basically what mogre has done) then decompile the IL that is produced from that into C# with a tool like .net reflector? For example, somebody had written a program in vb that I wanted to take a look at in C#, so I simply opened the .exe, chose my disassemble language as C# and it spit out the program in pure C#, compiled and ran exactly the same. It would be like automatically porting Ogre to C#, removing the need for a wrapper all together. I'd try this myself, but I can tell there is going to be some pitfalls, so I wanted to see if you guys could forsee any.
Here's a picture of what I'm smoking about:
I decompiled the Mogre.dll into C# and here's what I got.
galaktor
06-05-2009 14:07:01
I could imagine that this technique would not work that perfectly when decompiling c++/cli, which is (as far as I know about it) basically a mix of managed and unmanaged code in one. I am not very experienced with c++/cli, though...
But it is a very cool idea. Is there any way to automate decompilation?
smiley80
06-05-2009 14:59:52
Theres a link to a PhysX wrapper they created using that tool, has anyone tried that and saw how it works? Or if it runs on mono.
It should run on Mono, because it uses pinvokes.
Would it be possible to compile Ogre to C++/cli (basically what mogre has done) then decompile the IL that is produced from that into C# with a tool like .net reflector?
The problem isn't C++/cli per se. You could run a pure cil assembly written in C++/cli with Mono.
The VS C++ compiler can emit pure cil (/clr:pure or /clr:safe), but that would require to rewrite some portions of Ogre (for instance Ogre contains inline Assembler, which AFAIK isn't supported).
AndroidAdam
06-05-2009 15:12:36
So compiling Ogre with clr:safe would spawn a good deal of errors? Is it enough to disregard this method, or just a few that can be fixed easily enough. It seems to mean that Ogre shouldn't be relying too heavily on the Microsft C runtime seeing as it's cross platform, you'd want to avoid as much platform dependencies as possible.
Edit to avoid double posting:
Another idea occurred to me, it is probably less plausible than the decompiling method I mentioned above, but I thought I'd throw it out here.
J# was a language Microsoft made as an answer to Java, and because they were mad about all the J++ crap, however because everybody just used C# anyway, J# was discontinued, however they left a tool called the Java Language Conversion Assistant over. This tool, the JLCA, converts Java Legacy Code into a legitimate .net app, specifically C#. I don't actually know how Ogre4Java was made, but I believe the JLCA reads Java's equivalent of IL code so I was thinking about the possibility of running an Ogre4Java program through this and getting it as C#.
Here's the best link I could find explaining what this does:
http://www.devx.com/Java/Article/21946/0/page/1
smiley80
08-05-2009 00:11:19
So compiling Ogre with clr:safe would spawn a good deal of errors? Is it enough to disregard this method, or just a few that can be fixed easily enough.
I would rather take a look at
Axiom.
Ogre4j uses something called "Java Native Interface", which is the Java equivalent of p/invokes.
AndroidAdam
08-05-2009 00:39:56
I've looked at Axiom and it's doesn't seem to be actively developed. The company that makes it seems to not be able to finish a project; creating Axion, ditching that and creating RealmForge, ditching that and creating Visual3d.net. I'd like a pure C# of Ogre sure, but unless it can be automatic process, it will always be flawed, OGRE's far too big of a project. The way I see it, the only way for all .net users to be happy with a Managed version of Ogre would be to remove the need for a wrapper altogther.
smiley80
08-05-2009 01:14:17
The last release was 3 month ago. I think, they mainly work on the XNA renderer atm.
According to
this post RealmForge was a fork.
AndroidAdam
08-05-2009 03:05:36
Ah, you are right. I had checked there about a year ago, there had been barely any activity for 2008, it looks like things have picked back up though. However it doesn't seem like they have a very active community, I'd still like to stick with OGRE. But we digress, we should get back to the topic.
AndroidAdam
11-05-2009 17:47:47
Well, I used the JLCA to convert Ogre4Java to C#. It still has a ton of errors, but most of them have to do with the way Java does enums; it's trying to inherit from System.Enum, so that will require a lot of fixing.
Would there be any interest if I put this up on source forge to try and make it compile? Currently there is 750 errors, but 3/4 of those are the above mentioned enum problem, and all the rest are problems with having fields in interfaces, an easy fix.
Bekas
11-05-2009 22:01:39
I don't think what you are trying to do is feasible. Ogre4J is not pure java, it uses the JNI bridge to interface with native Ogre, and although I'm not very familiar with it I'm pretty sure it has nothing to do with .NET's P/Invoke.
Why don't you give a try with SWIG ? I'd expect that the C# SWIG wrapping would be a lot more advanced since the last time Ogre.NET used it.
smiley80
11-05-2009 22:38:23
Yeah, mixed it up with JNA. JNI needs C/C++ gluecode.
danfma
27-05-2009 16:38:21
I will really enjoy that... because I could use C# to develop my games and it will continue multiplataform...
Any helps needed just talk...