Let's do it like this: let's just make them and the corresponding demos optional at installation-time, so that the user may choose whether to install particular add-ons or not. This way it's more user-friendly.
I'm not shure if this is good for the maintainers. The add-ons use a shared ressources folder. So we would need to check, which (of the many files) are used from which add-on and what by the main part. Also in future the shared ressource access can change and there would be a need to update it.
With more options the installer script would be more complex. More problems could happen and different settings have to be checked.
I don't want to say no - I just want to point to the increasing effort for our "Starter Kit".
If you decide to give more options - maybe we offer this:
* full package (like the current SDK)
* minimum installation (check/update depencies, install core binaries and one simple demo) - this could be good for users who have a very slow internet connection or for people who just want to get the current core libraries.
In both cases I would add this to the installer script:
When the installation process is ready - a simple demo should be started automatically.
It could show the mesh
Sinbad (Ogre mascot) including animation (like
this video). Additionally show the text: "The installation was successful". Maybe the demo is still precompiled. Just to show the user, that the installation process was fine.
Another problem that should be addressed is documentation, since MOGRE is seriously lacking of good documentation.
For example once the user installs the SDK there should be a quick start guide and a guide to do common things with MOGRE like converting a Mogre.Image to a System.Drawing.Image and vice versa.
Also there could be an automatically generated HTML documentation like that that is output by doxygen. I propose Beauty to do this since she's very talented at writing.
Yes, documentation is important. In general there are many documentation gaps in the wiki. Not only Mogre related.
I think a good step would be to check all Mogre tutorials, at least the basic ones. I'm shure that there has to do some updates. At least the depencies. The basic tutorials are similar to a quick start guide.
converting a Mogre.Image to a System.Drawing.Image
I suppose this example is not very interesting for beginners. I never needed this. We don't know what beginners want to do. Everybody does other things.
But it would be a good idea to put such snippets to the wiki.
Tiny snippets (like your example) can be inserted to the page
Mogre HOWTO's and Snippets.
When somebody wants to offer a bigger snippet, he can create a new wiki page for that and put a link from
Mogre HOWTO's and Snippets to the new page.
automatically generated HTML documentation
You mean the API?
For this smiley80 still created a tool, which creates the file
CViewVR.xml and at least for one other Mogre library. I suppose smiley80 did publish it somewhere, but I can't remember the place. Maybe a good target place for this could be the MogreSDK repository?
Another fine idea: I could code a SDK maintenance utility combining all common maintenance tasks like building the SDK from a fresh compilation of MOGRE and so on.
Helpful tiny scripts can be nice and useful. Maybe they could be started one by one.
A script for doing "everything" can be well, but there is a bigger need to update it when something changes. Also the error management would be more complicated (if something happens which wasn't expected).
Instead of a "monster script" I would prefere to explain the steps on a wiki page.
Ok, I can't talk about much, because I never looked to Mogre build processes and don't know what's happens there.
A new all-in-one smart autowrapper tool would also be useful for future development.
Bekas (the author of Mogre) wrote, that his wrapper was just a dirty quick hack. If he would do the same job again, then he would do it much more better. But I don't know which details he mean. And I don't know if it's much work. But I think - our people had big problems to update the current wrapper code from Mogre 1.4 to 1.5. Maybe it will be more complex to start over for a new wrapper. Also - would the current Mogre applications be compatible to the new wrapper output?
Additionally I like Marioko's vision to create a new and better MOGRE from scratch. See here: viewtopic.php?p=38113.
I can't talk about this. I have no C++ experience. When I tried to update the MogreNewt wrapper to my own I had much trouble. The lines are looking easy, but it was hard. For example I didn't know for which wrapped function I need * or ^ (managed/unmanaged pointers).
Marioco was working on a tool for autowrapping add-ons. Maybe this was the same project for autowrapping Mogre, too. He is out of the project, but if you really want to do such a job - we could contact him and ask for his code. He never published it, because it was not ready. (......... just in the moment I wrote Marioce a message and invated him to discuss here, too)
Some time ago, I've converted several wiki articles and snippets from the forum (DataStream to MemoryStream, System.Drawing.Image to Mogre.Image, Line3D, ManualObject2D but also some fringe stuff) to an extension methods library. Any interest in putting that into the SDK?
This sounds useful. You created much good stuff! I see it in different posts. Somebody ask and you pick something out of your wizzard hut.
Good would be to have a wiki page for it for documentation purpose. Additionally it would be important to have XML comments in your methods.
By the way - I remember the project
MogreQuickStart. I never used it, but maybe this could be interesting for the SDK??
I just want to point to this possibility.
MogreQuickStart is a .NET class written in Visual Basic 2008. It's goal is to provide a quick entry point to easily write Mogre applications. I developped it for myself to use it in my project (KSEditor), but everyone can use it. It takes in input as an OSM file to load.
http://www.ogre3d.org/tikiwiki/MogreQuickStart
... oh my good now I see there are so much answers here. I'm happy about the talk, although I don't have much time these days. So maybe I don't answer all the time.
I was first thinking about separating the SDK and the addons/samples into two installers. But I can now see the advantage of just having one installer for everything and making some parts of it optional.
Look aside from depency downloads like DirectX, I'm a little bit unfriendly to "online-installers". I have many setup files on my hard disk and I don't like installers "without content" very much. One reason is - for 2 installations I need to download the content twice. An other reason - of the installer wants to download something, maybe the content is not available anymore (or are replaced by newer, but incompatible files).
Ok, online installers also advantages. It's just my personal view.
The optional depency download inside the current SDK installer is fine. One point for you.
do you want to keep the SDK repository at google code or should we move it to mercurial like I proposed in one of my last posts.
If we spit the SDK content, we could do this:
Keep the google SVN (read-only) for lookback / comparison if something doesn't work in the new structure.
Even if Beauty can't write all documentation, it would be good to have somebody to collect all contributions and wiki updates and make sure that everything can be found easily.
This was my daily job for a long time. Now I'm not very active, but this could change again
As for the API documentation, we should focus on the differences between Ogre and Mogre API. I think that most functions can just be understood from reading the (very good) Ogre documentation.
Normally it was fine to just look to the Ogre API. The Mogre members are mostly similar.
Additionally classes are still listed in the wiki (page
MOGRE pure .NET classes).
I think the only valid reason for creating everything new from scratch is to change the wrapper from C++/CLI to P/Invoke to make it compatible with Mono to support other platforms than Windows. I used and modified many different wrappers in the past, from simple C++/CLI wrappers to swig-based wrappers for commercial software and libraries that needed to support Windows and Linux/Mono.
In my opinion Mogre has a very clean structure and is incredible stable in most cases. We should not change a running system, but focus on fixing bugs in the codebase now to create a stable release as soon as possible.
Very good words. Also it's great to hear this assessment from somebody who has much experience with it.
If there is any real plan to create a P/Invoke wrapper - user
boyamer wrote a C# wrapper by hand for his
Alimer Game Engine. He could be asked if somethimes this job is in progress.
User
Wolfmanfx created an autowrapper by SWIG using P/invoke (similar to OgreDotNet). I suppose he didn't publish it.
About one year ago there was also a group of people offering help in revive the OgreDotNet wrapper method (by SWIG). The discussion was in the thread
Mogre and OgreDotNet -- combine forces?
Currently I would say a new autowrapper is no important focus.
I just wanted to let you know about interesting people. So you have contact persons for further plans
I think it would be best to have more than one person to have access to the "mogre" user on bitbucket. This could be accomplished by giving the password for the "mogre" account to all Mogre maintainers.
Nice to see you here, maski
Yes, this is one purpose of a public repository, which is not bind to a special person. We had such a problem about 2 years in the past. The only admin was not reachable for months. A mailing list could be interesting, but I don't know if there will come e-mails. One problem could cause if the mail account dies or nobody has access. How is bitbucket managed? On googlecode.com you can add several admins with their own e-mail address.
But then the building wiki page should be updated.
Yesterday mystoyke created a new page in the wiki:
Building MOGRE 1.7 from source
The most important things are inside there. More he wants to add.
What in hell ... I needed more than 2 hours for just one post. It's huge. But it's for a good aim
By the way - does somebody has experience with the
Axiom engine? It's a full C# port of Ogre and works on Mono. The last update was March 2010. So it's still not outdated.
Is the usage very different to Mogre? If not, maybe there is some stuff we could adopt (e.g. demos).
