Tutorials cleanup

Hi all,

I'm looking to refresh the Mogre tutorials and bring them in-line with the Ogre ones. I'm new to a lot of this and still going over the tutorials myself, but I thought this might be a good opportunity to clean it up. I'd like to finish going through the tutorials first, so it will be another week or two before I start the clean up.

Before I start making any changes, I wanted to get some feedback to make sure I'm on the right track. My plan is:

1. Write a new framework for the tutorials that is similar to the one used in the Ogre tutorials, and make the source code available somewhere (add to the SDK?).
2. Replace tutorial #4 with two tutorials based on MOIS to match Ogre tutorials #4 and #5.
3. Migrate Ogre tutorial #7 using one of the managed Mogre compatible in-game GUI systems available.
4. Migrate Ogre tutorial #8 (Multiple and Dual SceneManagers), which is currently intermediate OgreDotNet tutorial #4.
5. Move current Mogre tutorial #6 elsewhere (either tutorial #9 or another section, i.e outside the scope of the tutorials section).
6. Migrate intermediate tutorials 1-3 properly to Mogre from OgreDotNet.
7. Migrate Ogre intermediate tutorials 4-7 to Mogre.

In addition (or in parallel) to the above I wondering if the Mogre tutorial should be split into C#/VB.NET as they are now, or if the two should be unified and use some kind of a drop-down system where the reader can choose if they want to see the code in C# or in VB.NET?

Let me know what you think.

Hello and welcome, amirabiri!

You're quite bold, starting an overhaul of the tutorials so soon after joining the forums. I like it!


Here's what I think about the ideas you posited:

1. Write a new framework for the tutorials that is similar to the one used in the Ogre tutorials, and make the source code available somewhere (add to the SDK?).
Ehh, I'm sorry to say that I don't like this idea very much. I'd actually prefer to see the tutorial framework gone entirely. I remember having difficulty switching from the tutorial framework when I was learning MOGRE. I think my thoughts at the time were that the tutorials should prepare you for normal use of MOGRE, not for the next few tutorials (after which you'll never use the tute framework again). This might've just been me. Keep in mind that my whole reply is just my opinion, and nothing more.

2. Replace tutorial #4 with two tutorials based on MOIS to match Ogre tutorials #4 and #5.
I love this one! Like with the previous answer, I remember going through the tutorial and eventually using something completely different (MOIS).

3. Migrate Ogre tutorial #7 using one of the managed Mogre compatible in-game GUI systems available.
I like this idea, too. I ended up cobbling together my own GUI system. Maybe if I had known more about MIYAGI or one of the other GUI systems I could've avoided the pain that it brought.

4. Migrate Ogre tutorial #8 (Multiple and Dual SceneManagers), which is currently intermediate OgreDotNet tutorial #4.
I don't know anything about Multiple SceneManagers. So this would be a good tutorial!

5. Move current Mogre tutorial #6 elsewhere (either tutorial #9 or another section, i.e outside the scope of the tutorials section).
Yeah, I can see what you mean on this one. I didn't really find that tutorial neccessary, so I skipped it when I was going through them all. I like the idea of moving it elsewhere. You might want to see what other people (who may have used that tute) think about it, though.

6. Migrate intermediate tutorials 1-3 properly to Mogre from OgreDotNet
Definitely. I was quite confused by that, thinking that I had arrived on the wrong page from the "Intermediate Tutorials" link.

7. Migrate Ogre intermediate tutorials 4-7 to Mogre.
I'd say yes, again because I don't know what they do and would like to learn (and I'd also like for others to learn, as well).


In addition (or in parallel) to the above I wondering if the Mogre tutorial should be split into C#/VB.NET as they are now, or if the two should be unified and use some kind of a drop-down system where the reader can choose if they want to see the code in C# or in VB.NET?

Ehhh, I'd suggest leaving them where they are, for simplicity's sake. What we currently hae is easy to use, and I wouldn't like any VB programmers to give up on MOGRE because they couldn't find the VB.NET tutorials.

Good luck with the tutorial reworking, and with all of your own MOGRE projects!

Just a side note here, but does anyone know why the post a reply box has issues with longer messages & twitches around? I think it has something to do with using the tagging (Quote, Code, List, etc.) buttons. It makes it really hard to edit the end of the post.

You're quite bold, starting an overhaul of the tutorials so soon after joining the forums. I like it! Sorry I should have explained myself better... following this this thread I asked mstoyke what I can do to help, and given that I've only just started the only thing I can do right now is work on the tutorials as I go along, which will probably help me too with the learning process.

However, exactly because I'm new here, I didn't want to "rock the boat" so I compiled a list of what I think I can improve and put it up here to get feedback from the forum.



1. Write a new framework for the tutorials that is similar to the one used in the Ogre tutorials, and make the source code available somewhere (add to the SDK?).
Ehh, I'm sorry to say that I don't like this idea very much. I'd actually prefer to see the tutorial framework gone entirely. I remember having difficulty switching from the tutorial framework when I was learning MOGRE. I think my thoughts at the time were that the tutorials should prepare you for normal use of MOGRE, not for the next few tutorials (after which you'll never use the tute framework again). This might've just been me. Keep in mind that my whole reply is just my opinion, and nothing more. Actually I agree with you here (to a certain extent) - I didn't like the idea that the tutorial framework gives you an environment that is very differet to how you might normally use Mogre. Actually when I was going through the tutorials I didn't use the framework, I just cobbled together some code as I progressed since I wanted to really understand Mogre. However the other side of the story is that the purpose of tutorials is to gradually teach you things while "hiding" the complexity that you are not ready for yet away from you.

An alternative approach to a framework might be that each tutorial will provide a download of all of the code needed to run it. But then there is the risk of when the beginner gets confused and tries to understand what they did wrong by looking at the whole code - there is too much of it for them to look at, and they might be discouraged.

If I write a new framework, my intention would be to make it as simple as possible and as transparent as possible to ease the transition away from it.

I'm not sure what the best balance here is so I'm for this to be decided by a poll or the wiki admins or something like that. I'll apply whatever is decided.


In addition (or in parallel) to the above I wondering if the Mogre tutorial should be split into C#/VB.NET as they are now, or if the two should be unified and use some kind of a drop-down system where the reader can choose if they want to see the code in C# or in VB.NET?
Ehhh, I'd suggest leaving them where they are, for simplicity's sake. What we currently hae is easy to use, and I wouldn't like any VB programmers to give up on MOGRE because they couldn't find the VB.NET tutorials.The problem with two sets is that it's twice the work to maintain and twice the chance of one version falling behind or generally discrepencies popping up. If we amalgamate them and clearly state that all the tuts contain code samples in both C# and VB.NET then we can more easily cater for VB.NET developers (I think).

In addition (or in parallel) to the above I wondering if the Mogre tutorial should be split into C#/VB.NET as they are now, or if the two should be unified and use some kind of a drop-down system where the reader can choose if they want to see the code in C# or in VB.NET?

IMHO it would be great to have a system like on MSDN where you can select between a variety of .NET languages, while looking at the same documentation. Having seperate wiki pages for each language doesn't scale well and there are more languages than C# and VB.NET e.g IronPython (which I use). I don't know whether the wiki supports anything like this out of the box, but I assume someone somewhere has made a tikiwiki extension. A super crazy idea would be to get all the C++, .NET, Java, Python tutorials using the same explanatory text and just different code, but maybe that's a bit over-ambitious.

1. Write a new framework for the tutorials that is similar to the one used in the Ogre tutorials, and make the source code available somewhere (add to the SDK?).
It is very satisfying for a new user to get something 3D on screen quickly, hence I think it is important that at the start of the tutorials there is a lot of code given to the user without explanation - whether this is as a "TutorialFramework" of something to copy and paste out of the wiki. The beauty of having a framework is that the user doesn't have to even look at that code. I don't know it there's anything actually wrong with the current framework else than it not being distributed properly. Ideally the SDK would come with all the tutorial stuff in it.


Good luck re-doing the tutorials - it's long overdue, especially the references to OgreDotNet.

IMHO it would be great to have a system like on MSDN where you can select between a variety of .NET languages, while looking at the same documentation.
Tiki Wiki has tabs (http://doc.tikiwiki.org/tiki-index.php?page=PluginTabs), but for some reason the tab content seems to be always centered in the Ogre wiki.

So I've studied the two tutorial frameworks now (the Ogre one and the Mogre one), and here are my conclusions:

The two frameworks are actually much closer then I initially thought. Both of them basically load the .cfg files, pop the config window, then initialize Ogre with a bunch of small virtual methods you can override and enter the render loop. Both framworks give you an out of the box camera control, some keyboard bindings and a debug overlay.

However there are some differences between them:

1. The Mogre tutorial framework is completely self-contained, while the Ogre one uses OgreBites which is the sample framework that comes with the SDK (which is a different thing to the tutorial framework... o.O).[/*:m]
   
2. The Ogre framework provides something about a tray manager which I didn't quite understand what it is, but I can't find any mention of it in the Mogre one.[/*:m]
   
3. The Mogre framework has a splash screen while it's loading.[/*:m]
   
4. The Ogre framework uses OIS for input handling while the Mogre one use windows forms input.[/*:m]
   
5. The Mogre framework actually exists inside a windows form. This is something that threw me off when I was doing the tutorials, since the RenderWindow is different to the application window (class-wise), eventhough they are in fact referring to the same window. I guess this was done for the Windows forms input.[/*:m]
   
6. The Ogre tutorial framework fits into two pairs of .cpp/.h failes, one of which is almost empty (the subclass, which the user is meant to modify). The Mogre framework on the other hand contains windows, resources, images etc. It's spread across around 20 files and is very Visual Studio-specific (.designer files, .resx files, properties, etc).[/*:m][/list:u]
   
   Personally I agree with WarehouseJim - the tutorial framework should allow a user to hit the ground running and compile-and-run something simple in 5 minutes. However I would add to that that I think that the user should also have the option of delving into the tutorial framework's code easily to see these things and learn from it or tweak it - I think that's very helpful. However to do that the framework must be very simple.
   
   Given the above my inclination is to take out the windows forms stuff and the splash screen and all of the other Visual Studio stuff like .resx files, properties, etc. Cut down the framework to a simple bare minimum that fits into 1-3 simple class files. This will sacrifice some eye candy in favour of clarify and simplicity. Hopefully MOIS for .NET 4.0 will be ready soon so there won't be any problem with removing the windows forms stuff and using MOIS instead.
   
   What do you think?

Have you checked out the code at http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=9887? It's only 3 classes so might be half way to what you're wanting to do.

I don't think that MOIS Vs WindowsForms is that important, but I would agree that MOIS is a better and more flexible option for managing user input.

I can't remember what eye candy there is exactly, but the overlays with FPS etc are quite a nice touch and allow people to experiment and see the effects quite easily, so I'd be inclined to keep them. The loading bars I don't think are important. I think the overlays are defined in different files distributed with the SDK (loaded as resources or something like that), so the complexity is nicely hidden from the user.

Another thing is that I remember it being quite hard to get all your *.cfg files sorted and the right dlls referenced. A good solution might be to have Visual Studio projects with all the dll's included /referenced distributed within the SDK and two projects per tutorial, one with the start state and one with the end state of the code for the tutorial.

I have the code of the MogreFramework, that's what I based my analysis on. I don't remember how I found it but I do remember I came across more than one 404 in the process.

I've more or less finished writing the new framework, I'm finalizing it now. It's basically a melt of the MogreFramework with the Ogre tutorials framework with simplicity in mind.

By "eye candy" I was referring to the loading bars. The other stuff (overlays + ability to change modes) I think is quite important for the learning process. This is actually what I'm "finalizing" now.

RE MOIS remember that two of the basic Ogre tutorials are dedicated to OIS. Those are skipped and replaced with just one WF-input based tutorial. I think that beats the point - the purpose is to teach people how to use Mogre in combination with MOIS, not with WF, hence the tutorial framework's code should refelect that fact I think.

I like the idea of distributing a VS project file because indeed between the .cfg files and the .dlls it can get quite tricky. However between the .dll's and the media files, we'll be looking at 50MB download... I'm thinking either I cut down the media to the minimum used in each tutorial (which can be an annoying task to do, plus reduces the ability of the user to "play around" with the result), or an alternative approach of one download for the project, and then small downloads of the start / end code of the tutorial as suggested per tutorial. The latter approach is supported by the fact that with the framework the tutorial class remains very small and straightforward and it's dead obvious where you should drop the code.

I'll upload the result tonight when I finish it and I'd be keen to get some feedback. If I get the "thumbs up" from the community I'll then start migrating and refreshing the tutorials.

Another thing is that I remember it being quite hard to get all your *.cfg files sorted and the right dlls referenced. A good solution might be to have Visual Studio projects with all the dll's included /referenced distributed within the SDK and two projects per tutorial, one with the start state and one with the end state of the code for the tutorial.
Take a look at my quick start project repository, everything you need is already in the right place and all you need to do is compile the example project and run it.

I like the idea of distributing a VS project file because indeed between the .cfg files and the .dlls it can get quite tricky. However between the .dll's and the media files, we'll be looking at 50MB download...

In the age of downloading films, 50MB probably isn't prohibitive any more. If it's distributed within the Mogre SDK, and references the existing stuff within the SDK, then it would be fairly small. The SDK is currently 29.5MB as an installer. I assume most newbies would want to download the SDK anyway.

I've finished writing a new tutorial framework and I would like to start working on the tutorials. However I have a coupe of small problems:

1. I don't seem to be able to login to the wiki or enter edit mode. I'm trying to use the forum username & password as stated but that didn't work... what am I missing?[/*:m]
   
2. I wonder where I should upload things to? Should I treat the Mogre Tutorials framework as a separate project and open a repository for it, or shoud I clone the SDK repo and make the framework part of the SDK?[/*:m]
   
3. Related to the above: where should I upload the "tutorial project" we discussed to? (i.e a ready download with compiled .dlls, media files etc - not just the sources).[/*:m][/list:u]

OK I think I figured it out.

I've created a "Mogre.TutorialsFramework" repository on bitbucket: https://bitbucket.org/amirabiri/mogre.tutorialframework.

I will now populate it with a full ready-to-use download of VS 2010 and 2008 solutions.

Then there is just the question of creating a wiki page that explains how to use it, similar to the Ogre one.

So how do I write/modify a tutorial...?

I'm looking to refresh the Mogre tutorials and bring them in-line with the Ogre ones. I'm new to a lot of this and still going over the tutorials myself, but I thought this might be a good opportunity to clean it up. I'd like to finish going through the tutorials first, so it will be another week or two before I start the clean up.
It's very nice that you want to help us to update and extend our tutorials. Unfortunately they weren't checked for a longer time.
Also it can be helpful that you are a newcomer, because the tutorials are especially for newcomers and so you can see which points are confusing or doesn't work.


1. Write a new framework for the tutorials that is similar to the one used in the Ogre tutorials, and make the source code available somewhere (add to the SDK?)
This is a nice sounding idea, but I think this would need very much work. The Ogre demo framework was a Google Summer of Code project and a fulltime job of a person for about 4 months.
The main goal was a fine presentation plattform to show what can be done by the Ogre engine.
Mogre newcomers can also run this C++ "demo application" to see what's possible. Generally Mogre can do the same things as the C++ demos show, because it's the same engine.
For our small Mogre community it should be enough to have common demo applications. Many of them use the content of ExampleApplication (formerly MogreFramework), which hides some basic things like Mogre initialization, viewport creation, movable camera, etc.
I don't mean it would be have such a shining demo framework by analogy with the C++ demo framework. But it costs much effort and there are other things which are more important.

2. Replace tutorial #4 with two tutorials based on MOIS to match Ogre tutorials #4 and #5.
To replace means to delete something?
Even if you move the current Mogre tutorial content to an other page, then there is a problem with links from the forum or wiki which point to this page and it's native content.

In my eyes it's not important to have 1:1 ports from the Ogre and Mogre tutorials.
Ok, there can be 1:1 ports, but there is no need to have the same tutorial number.
For new tutorials I would use the next free number and don't catch a current one. (Means: Currently we have 6 basic tutorials, so the next would be #7.)
My suggestion: When one Mogre tutorial is an 1:1 copy of an Ogre tutorial and the numbers are different, then add a notice to the page head. For example "This tutorial is related to the Ogre tutorial 123."

Some things in the Mogre world are different. For example for the input you have different choices (MOIS, SlimDX, XNA, ...).
So it could be possible to create a wiki page (tutorial?) which shows the different possebilities. A comparison of pro/cons and code snippets how to integrate.


3. Migrate Ogre tutorial #7 using one of the managed Mogre compatible in-game GUI systems available.
A GUI tutorial would be nice. Additionally (or as alternative) there could be non-tutorial wiki pages about each common Mogre GUI system.
* Miyagi has a wiki page, but less content. No code snippets or advanced information. (Much of such things can be grabbed from its forum thread.)
* MyGUI is powerful, has tools and is usable for Mogre (as mstoyke said). Unfortunately I never saw further information about in the wiki or forum (related to Mogre). For this I created a new wiki page, but it needs content. Mogre MyGUI wrapper


5. Move current Mogre tutorial #6 elsewhere (either tutorial #9 or another section, i.e outside the scope of the tutorials section).
What happens when there will be an Ogre basic tutorial #9 in the future? Do you want to move it to an other page again?
It's again the problem of the links which are pointing to a wiki page in relation of the estimated content.
I don't want to hit you - I just tell you my thoughs.


6. Migrate intermediate tutorials 1-3 properly to Mogre from OgreDotNet.
7. Migrate Ogre intermediate tutorials 4-7 to Mogre.
I think the OgreDotNet tutorials are a good base. Maybe it's not much work to convert them to Mogre.
A port of the other intermediate tutorials would be a good enrichment.


In addition (or in parallel) to the above I wondering if the Mogre tutorial should be split into C#/VB.NET as they are now, or if the two should be unified and use some kind of a drop-down system where the reader can choose if they want to see the code in C# or in VB.NET?
I think it's better to keep them seperated. So immediately you see at the tutorials overview what's available.
A drop down menue for switching isn't possible with the wiki software (I suppose) and it would be no good overview. Also the people could overlook/miss it. This could be a way when there is an 1:1 copy of all tutorials (also in the future), but this isn't the fact. There aren't VB ports and maybe the content is a little bit different.


Let me know what you think.
I did and I hope you aren't shocked.
I don't want to kill you or your ideas.
I just write what I think about - and it's my own point of view (not the view of the whole Mogre community).
I'm very happy about your help offer!


The other posts I didn't read yet. I'll do it later.

5. Move current Mogre tutorial #6 elsewhere (either tutorial #9 or another section, i.e outside the scope of the tutorials section).
Yeah, I can see what you mean on this one. I didn't really find that tutorial neccessary, so I skipped it when I was going through them all. I like the idea of moving it elsewhere. You might want to see what other people (who may have used that tute) think about it, though.
For me it was a helpful tutorial and it becomed the base of my main Mogre application. So please don't delete it.
I don't use a Mogre GUI system, I just use common controls of Windows.Forms. For my application it's a good choice.

Actually I agree with you here (to a certain extent) - I didn't like the idea that the tutorial framework gives you an environment that is very differet to how you might normally use Mogre. Actually when I was going through the tutorials I didn't use the framework, I just cobbled together some code as I progressed since I wanted to really understand Mogre. However the other side of the story is that the purpose of tutorials is to gradually teach you things while "hiding" the complexity that you are not ready for yet away from you.
Yes, the reason of the framework is to give newcomers an easy start. They should learn step by step and quickly be able to see a result.

Maybe it would be better, when we don't use a compiled library for that. Instead we could tell the newcomers, to add the needed *.cs files and *.resx to the project. (together 7 files) So there is no problem of incompatible dll files and the newcomers can have a look to its content. But there is no need to understand the content, when they start to learn from the tutorials. Additionally the people could modify the code when it's embedded as *.cs files instead of a linked dll library.
The source code of the MogreFramework you find here.
Maybe we should add a prefix to the files names. E.g. MogreFramework.OgreWindow.cs. So it would be more clear for newcomers when they add the files to their projects.

Alternatively maybe we could switch to a similar project called ExampleApplication, which is the base of our demo applications in the Mogre SDK. The source code is here.
I don't know about the detailed differences between MogreFramework and ExampleApplication. But if we can use the ExampleApplication as base for the basic tutorials, then maybe it's more friendly for newcomers, because it would be the same base as the demos use. (which are also examples to learn how to do something by code)
Just an idea.


An alternative approach to a framework might be that each tutorial will provide a download of all of the code needed to run it.
Our wiki has the great possibility to attach files to wiki pages. So it's on the right place and will not get lost (e.g. like many dead links in the forum and wiki).
By the way: The source code of each(?) finished tutorial in on a seperate page. It's linked at the bottom of each tutorial.


the overlays with FPS etc are quite a nice touch and allow people to experiment and see the effects quite easily, so I'd be inclined to keep them.
I suppose this is not part of a *.resx file. I think it uses the content of OgreCore.zip, which you find in MogreSDK\Media\packs.


In the basic tutorial 0 is written, the user should update his resource.cfg file to get global paths to the MogreSDK.
I think better would be to instuct:
Copy this and that files/directories from the MogreSDK to your project and keep the relative paths of the resource.cfg file.
As alternative we could instruct the tutorial reader to create their VS projects in a subdirectory of the MogreSDK. Then they can use relative paths to the resources without creating a copy of them.
I don't like global paths, because it causes trouble when you want to run an application on an other computer. Better is to have everything in subdirectories of the own project. But this is my personal point of view.

Good would be, when all needed stuff (for the tutorials) is inside the MogreSDK.
The loading bar images we could add to the MogreSDK binary path as zip archive (if we want to keep it).


I've more or less finished writing the new framework, I'm finalizing it now.
Good boy.
But please don't delete the old MogreFramework from the repository. Maybe someone wants to get it in the future. So we should have a public backup.


By the way - I saw dead links in a tutorial refering to http://www.idleengineer.net. This was the website of Clay Culver who wrote the tutorials some years ago. Unfortunately the website is dead (and the domain was grabbed by a spammer) and Clay doesn't have any old stuff on his computer. I asked him some months ago and got his answer just a few days ago. So all links refering to http://www.idleengineer.net you can delete.


I don't seem to be able to login to the wiki or enter edit mode. I'm trying to use the forum username & password as stated but that didn't work... what am I missing?
3 years ago I had the same problem. Then I found out the reason. I was registered here in the Add-ons forum, but not in the Ogre main forum. After doing that I could log in to the wiki.

For start of the wiki work, have a look to this page:
http://www.ogre3d.org/tikiwiki/Wiki (also linked from the start page by the name Wiki Portal)
On the head menu of the wiki you find the entry Ogre Wiki Help. There is much useful information.

If you have questions or need help with the wiki I can help you.
Alternatively you could ask user jacmoe - he did the huge job to convert the wiki from MediaWiki software to the TikiWiki software. He's a wiki guru.


amirabiri, what's your personal background?
Are you a student, programmer, etc.?
What kind of experiences do you have in programming, game development, ... ?
Just write a little bit about yourself - this would be interesting for us.


For today I wrote enough. I'm tired.

So how do I write/modify a tutorial...?
If you can't log in, write a message to jacmoe.
For editing you can use the edit button at top of each wiki page (when you are logged in).

Notes how to create a new wiki page you find in Help - Pages and Structures.
As I said - many useful information about wiki work you find in the help section of the wiki menu.

amirabiri created a new wiki page:
Mogre Wiki Tutorial Framework

It's nice - thanks
Don't forget to link to it when you are ready (from the Mogre start page or tutorial page)

You're ahead of me there Beauty, it wasn't finished yet . I was going to link to it when it's ready to get some feedback.

I've noticed you editted and styled it and fixed a couple of errors - thanks! .

Also I've tried to use the tikiwiki tabs with code block. Generally it almost works, but the CSS used on this site screws it up a little. Here's an example.

jacmoe is the right person for such things.
You can post this issue in this thread. Maybe he knows or applies or search for a solution.
Now I know what you mean with Code Switching on one page. I was thinking something else.
It would be good if the user doesn't has to change the code language for each snippet. When you write a post about tabbing/switching - do also ask, if there is a possebility to swich the language of all snippets of a page by just one link/button.

OK, I've finished writing a new Mogre Wiki Tutorial Framework and I've written a new version of the Mogre Basic Tutorial 1 which works against it. In the process I have used both the current Ogre Basic Tutorial 1 and the current Mogre Basic Tutorial 1. There are slight changes - I've tried to come closer to the Ogre tutorial, but I've borrowed some Mogre-specific comments from the Mogre one. Still the two versions of the Mogre tutorials are almost identical and the main differences are the initial code snippets.

None of this is published yet, as this is the point where I'd like to get some feedback form the forum. Feel free to shoot straight, I don't take offence easily . Worst case scenario I will silently abandon this effort ... . In particular I think I may have some inaccurecies in the last parts "The Ogre/Mogre Environment" and "Configurations". Also some peer review of the tutorials framework's code by experienced Mogre/Ogre developers would be good.

If I get a thumbs up here I will then want to replace the current tutorial with the new one, and then start the process of migrating/changing the other tutorials as well. I also plan to create VB.NET versions of the tutorial framework download and have equivalent code snippets for it, provided we can find a solution to the Code Tabs problem.

A couple of words about the framework - it's basically a melt of the Ogre wiki tutorials framework with some elements from the previous tutorials framework. My objectives where to 1) come closer to the Ogre tutorials framework so that the tutorials can come closer so that it's easier to use Ogre resources and documentation with Mogre and 2) to simplify matters as much as possible for a newcomer. I knowingly sacrificed some "better practices" of development in favour of these goals (i.e inheritence vs. composition).

I don't know if the authors of the previous framework are still active, if you're out there I hope you're OK with me borrowing some of your code. If that's a problem please contact me via PM so we can discuss.

OK, I've finished writing a new Mogre Wiki Tutorial Framework and I've written a new version of the Mogre Basic Tutorial 1
good work. I didn't try your rewritten framework, but I'm happy about your effort and suppose it's working well.


If I get a thumbs up here I will then want to replace the current tutorial with the new one, and then start the process of migrating/changing the other tutorials as well. I also plan to create VB.NET versions of the tutorial framework download and have equivalent code snippets for it, provided we can find a solution to the Code Tabs problem.
I saw you were still starting to rewrite further tutorials.
The tabbing seems to work well on my computer (Firefox 3.6.9, WinXP). It's better than I thought.
If there are still problems, please report it to jacmoe. (Yes, I repeat myself.)


I don't know if the authors of the previous framework are still active, if you're out there I hope you're OK with me borrowing some of your code. If that's a problem please contact me via PM so we can discuss.
As far as I know the author was Clay Culver, who had to leave this project, because when he started to work at Microsoft, it was forbidden to be envolved to open source projects. I asked him for old Mogre stuff (e.g. downloads or further tutorials on his private webspace), but unfortunately everything is gone.
He wasn't active here for years, but last week he wrote a post. Maybe he's back again.
But don't worry. I don't think he will disturb you. I suppose we are all happy that you update our tutorials. So you have a big pro vote on things that you do.

Thanks Beauty, that good news .

So should I interpret the silence as approval? Can I flick the switch and start migrating the remaining tutorials?

i have just check out briefly the tutorial and the source code, it's fine for a basic tutorial. about the souce code, good job separating input and camera from the base application class, this was a little mess before

i have spotted a little mistake in the tutorial, in The Ogre/Mogre Environment, the main library part, the cg dll is not needed by the main library, only the Plugin_CgProgramManager need it. About the mogre.framework package, you don't need to include ois.dll in the zip, it have been statically linked with the mois.dll (apart if it's a different version than the last vs2008 sdk).

Also, it would be a interesting to speak about the vs2008 redist package dependencies, since it's mandatory, and perhaps the difference between vs2008 and vs2010 dll dependencies (since it change the way applications are deployed).

I would also add a little reminder about the fact that mogre and ogre dll must be in the same directory (there is other solution to make it work with path system variables, but it's probably too complex for a basic tutorial), since i can't count the number of time people have trouble with theirs application because they haven't copied in their bin folder the ogremain lib. a section with most common errors made would be nice too (with error codes and screenshots). What do you think ?

Thanks for the feedback

I was just about to compile new bundles for the framework .zip files, so I will include the changes you suggest (cg.dll / ois.dll).

I will fix the comment about cg.dll in the tutorial.

RE your other comments, I think we can summarize and say that three things should exist:

1. Installation instructions.[/*:m]
   
2. Troubleshooting common problems.[/*:m]
   
3. Screenshots.[/*:m][/list:o]
   
   I think the same dir and redist comments belong in both (1) and (2). The question is if there should be a separate wiki page for installation, or perhaps both a separate page + some mention of it in the first tutorial. It's probably good to include a "common problems" section in tut 1.
   
   RE screenshots I'm more than happy to do so but that would require more time, specially as we want to support CS/VB - 2008/2010 (i.e 4 sets).
   
   I think I will finish everything I've got "open" so far (Tutorial #3, VB.NET code, code tabs, upload new zips, test things thoroughly etc), and then go back to installation instructions / troubleshooting and in the end add screenshots before moving on to the next tutorials.

I think the same dir and redist comments belong in both (1) and (2). The question is if there should be a separate wiki page for installation, or perhaps both a separate page + some mention of it in the first tutorial. It's probably good to include a "common problems" section in tut 1.
In the past there was the basic tutorial 0 related for installation and depency instructions and a simple check (by running the MogreFramework without any content).
Now the depency check will be done by our MogreSDK setup.
But sometimes people seems to have problems or maybe it could be that some people miss to install all depencies.
For this case it would be useful to list the common depencies.

Here I listed the depencies for use with Visual Studio 2008. If they needs an update, please tell me:
http://code.google.com/p/mogresdk/sourc ... nstall.txt
Maybe on page basic tutorial 0 or page mogreframework we should write about the different depencies for VS 2008 and 2010. Additionally add download links.
I suppose it's possible to use a mixture of VS2008 and VS2010 dll files. For this I suppose it's needed to install vcredist for both versions. (Not needed if Visual Studio 20xx is installed (VS2008 needs also the Service Pack 1).)

Maybe vcredist only works for release versions of Mogre.
Sorry, I don't know so many details. I just know it's a little bit complex.
When you have questions - please ask. We will find somebody who knows

I just checked out the new tutorials and they're looking pretty awesome!
I'm envious of your work ethic and amount of free time.

Good job so far!

I finally managed to take a look at the tutorials. Awesome work so far, amirabiri.

Great job, amirabiri! I just went over tutorial 1 and I think it's a very good starting point for Mogre newcomers. Also the framework works flawlessly (I downloaded the VS 2010 version).

Maybe it would be good to have a Mogre version of these wiki pages:
* Creating a simple first-person camera system
* 3rd person camera system tutorial

They aren't listed on the Ogre tutorials page (they are linked from nowhere!). Unfortunatelly I couldn't add them, because I didn't found out how to edit the boxes of the Ogre tutorials page.

I suppose it would be useful to have a Mogre version of these tutorial pages.
I know this needs time and somebody who do the job, but I just want to suggest this.

I just took a look on the new tutorials but I think they are great especially the code tabs. Really good work so far!
I also tried to run the new framework (VS 2010) and it worked without any problems. I specially like the fact that MOIS is now included because I think for a game it's more likely to use than Windows.Forms input. But that's maybe a personal thing...

Maybe you, amirabiri, could post a list about which tutorials you alraedy have done and which should be done in the next time because I really would like to help if possible. You can add the ones Beauty just mentioned.

Wow, that's very positive feedback... . Thanks you all.

I'll take it to mean that I can apply my changes to the existing tutorials. I'll start doing that now.

McDonte, I'll PM you so we can coordinate the work.

I looked to your framework source now. It's looking fine and has a good overview.
Also it's good for newcomers that you offer download packages which includes a ready-to-use VS solution.

The framework internals is in the linked file Mogre.TutorialFramework.dll.
It was compiled by 4 *.cs files.
Instead of the precompiled dll file I would add the source code files of it.
For a better overview you can put them in a subdirectory, named "TutorialFramework".

The advantage of this way:
Aside the tutorial job, the newcomers can look into the code.
There they can see what's happen inside of the framework and how it's done.
Also they can modify parts of it (e.g. cam settings) to see what happens.
Its great for learning by playing.
Even for myself - just now I learned how to get displayed the Ogre overlay (logo, fps, etc.).

Additionally newcomers several times asked to use the framework for their own applications. It was not easy to explain, that they should use their own code for it, because the framework is not very flexible for common tasks.
When the users have the framework code inside of the tutorial - then they quickly can modify it for their own needs.
The source code is a better base than a precompiled dll file.

Ok, now I talked enough about.





In my case the ninja mesh (of tutorial 2) is a little bit boring.
Instead we could add the new funny mesh Ogre, which is our new official Ogre mascot.
Video:
http://vimeo.com/8815075
Information:
http://www.ogre3d.org/2010/01/19/we-hav ... ial-mascot
Download:
It's in the Ogre 1.7.x SDK in the file Sinbad.zip which you find in the SDK subdirectory media/packs.
update: Just in this minute I added this zip file to our MogreSDK repository. Now you can download it directly:
[b]Sinbad.zip[/b]

I don't know if you like the idea, but additionally you could include one extra line of code to the tutorial for enabling the animations.

// after this line
Entity ent = mSceneMgr.CreateEntity("sinbad", "sinbad.mesh"); // instead of ninja.mesh
// add this line
Tutorial.StartSinbadAnimation(ent);

The method StartSinbadAnimation() is part of the TutorialFramework and stores a reference to the sinbad entity internally.
When the application is running, then it enables the animation. And after each few seconds, it switches to an other animation automatically.
This would be funny for newcomers and a good motivation to learn more.

I never used animations.
Maybe it's just one line of code to start the dancing animation.
In this case we wouldn't need the method StartSindbadAnimation().

In the tutorial you could write this:

Entity ent = mSceneMgr.CreateEntity("sinbad", "sinbad.mesh"); // instead of ninja.mesh

// add this line for a funny dancing Sinbad model (-:
ent.StartAnimation("walking");
SORRY - I don't know the right code for animation start

I was going for parallelism with the Ogre tutorials because that way it's easy to use Ogre resources with Mogre (documentation, etc) and easier to maintain the Mogre tutorials and keep them up-to-date with the Ogre development and tutorials.

RE the framework I've placed a link to the source code in the framework page. I was reluctant to include the source code with the "binary" download as it might confuse a newcomer. When they wish to see the source code they will easily find it on the wiki page of the framework, which is the first thing they are visiting anyway.

I also mention on the wiki page of the framework that it should not be used for normal applications. Perhaps more can be added about that.

Genearlly speaking I intend to enrish the tutorials framework wiki page with the comments mentioned in this thread as I progress with the work on the tutorials.

I was going for parallelism with the Ogre tutorials because that way it's easy to use Ogre resources with Mogre (documentation, etc) and easier to maintain the Mogre tutorials and keep them up-to-date with the Ogre development and tutorials.
The sinbad.zip file is still inside of the Ogre SDK.
Also I would suggest: replace the ninja model in both - the Ogre and Mogre tutorials.
And the funny dancing animation could be included to both, too. (I suppose it's just one extra line of code.)


I was reluctant to include the source code with the "binary" download as it might confuse a newcomer.
My thoughs about this: the source code is "hidden" inside of a subdirectory.
Maybe you (or I) write a note to the Mogre Wiki Tutorial Framework page that/how it's possible to embedd the source code inside of the project (instead of the linked dll file).

But well - all my suggestions are only my personal point of view.

Basic tutorials 1-3 are now fully refreshed and converted to the new tutorials framework. This includes:

# Using the new tutorials framework, code snippets modified accordingly.
# Fully tested against the framework .zip downloads.
# Full C# / VB.NET parallelism throughout the who text and code sinppets (in tabs).
# Many minor changes in wording or code as found appropriate, as well as small fixes such as broken links, missing images, etc.

Have a look if you get a chance and let me know if you find any errors or have any other feedback.

Basic Tutorial 4 has been migrated.

This time I actually deviated a bit from the Ogre/Mogre ones. In retrospect I don't think that the Ogre tutorials #4 and #5 are as good as the first three. In particular I decided to have both unbuffered and buffered input handling in the same tutorial. So the new basic tutorial #4 covers frame listeners and MOIS (unbuffered and then buffered). It also attempts to do less than the Ogre one and instead concentrates on teaching the reader certain things with smaller code snippets.

The tutorial framework was slightly modified to support a couple of things in the new tutorial, but the changes are minor and should be compatible with the previous tutorials (partially tested).

Please feel free to give me any feedback you may have on this.

You spend much time for a useful aim.

I didn't read it, just glanced through, but it seems to be good work!
Also I think it's a good idea to handle both input types (buffered / unbuffered) into one tutorial.

Maybe it would be useful, to add SlimDX as alternative (covered in an extra section)?
Is there any advantage or main difference in using SlimDX instead of MOIS as input library?
I can't say this, because I have very less experience with MOIS or SlimDX. (For input I just use event handlers of Windows.Forms.)

Currently I read a little bit about Billboards and want to create a test application (based on the new MogreTutorialFramework).
Also I think about to put related information and the test application to a wiki page.
Maybe it would be useful to write it in tutorial style?
Although it's not the best idea to write a tutorial when I don't know much about this topic.
What do you think about this idea?

Well I'm still learning myself, but then again I'm mostly translating the work of previous authors who where more familiar with the subject than myself when they wrote it. I consider myself to be a good tutor as I've edcuated junior developers many times in my career and I enjoy doing so, so I allow myself to fill in a few gaps here and there when I feel I got a firm grasp on something but I think I can explain it better to the next guy. But mostly I just follow the existing resources.

If you are not sure you could write it and put it up in a wiki page not linked to yet for the forum to review before making it public (as I did and I got some useful feedback from the more experienced forum members).

In terms of what goes where my personal view is that the "tutorials" should be a linear path of gradually learning parts of the whole. When one emerges at the end of this course, they ought to be ready for the realm of "how to"s or "advanced topics" or whatever we want to call them. These don't need to be learned in any particular order or not at all and can be picked up when needed. For every topic that I write about I ask myself to which part of this evolutionary curve it belongs to.

Using alternative libraries (SlimDX in this case) is definitely something worth having articles for. I would not want to confuse a newcomer with too many alternatives (sometimes it's for us to be dictated too at first... ). So I would pick one in each category for the purpose of the tutorials. OIS/MOIS seems like a good choice to me in the input category but I'm happy to change the tutorials if there are better alternatives for learning purposes.

However, when it comes to advanced topics I think it would be good to have a rich set of articles covering alternative libraries in each category. I will be adding such things when I get to that point.

While we're on this subject, does anyone have any suggestions for the in-game GUI tutorial for Mogre? I'm assuming I would have to find an alternative to CEGUI? The best candidate for the basic tutorial would be the simplest one to learn.

Yes, first I will create a page, which isn't called a tutorial, just an information collection.
To make a tutorial out of it (or as additional) page would be a second step.


Related to the GUI question:

Long time ago I tried MogreBetaGUI, but had problems with it. And debugging was difficult, because it has only cryptic variable/function names.

In the 3 years of being here, I saw only one actively developed and supported GUI system for Mogre:
Miyagi (by user smiley80)
Unfortunately much information and all code snippets is hidden in its long forum thread. I want to read the whole thread and put the useful parts to the wiki page (which I created for the case of a better overview).

mstoyke wrote he has good experiences with MyGUI by use of the .NET
wrapper (which is an official part of the MyGUI project). There are usable tools for MyGUI, e.g. for graphical GUI creation. Maybe there is also a good usage support by the Ogre community. I don't know if there are big code differences for usage by Mogre. But I never saw any Mogre related code snippet in this forum.

Hikari is a special case and no good target for a beginner tutorial. With Hikari you can embedd Adobe Flash, e.g. for embedding a GUI, which was created by an other (Flash) tool.

There is also MQuickGUI, but I don't remember any discussion about it. (Maybe I missed them?) It's sad to see, that somebody put much effort into porting a whole GUI system and then nobody seems to use it. 3 years ago it was added to the Mogre SVN (with a few followed commits), but since then there was no code update. On the wiki page I read there are still some adjustments needed. The author GermanDZ didn't logged in to this forum for 1 year. I suppose it's a dead project.

In my case, currently we have 2 usable options for usage with Mogre. Not much, but we have it.
I remember the time in 2007/2008 - I couldn't find an easy way to use a GUI system, although I just wanted to display text. As alternative I used a TextBox of Windows.Forms instead, which I put over my renderpanel (for Ogre display). This solution wasn't very beautiful, but stopped my trouble.
So, today we should be happy to have usable GUI systems.
(In my eyes a GUI system is a major need for most 3D applications.)


There was also an interesting GUI system, based on HTML/CSS, which is a common way for "website GUI" creation. Many programmers should know this languages and there are usable tools for creating.
But I don't know if this way is currently available for Mogre. Also in this moment I don't remember its name.
This is nothing for a beginner tutorial, but an interesting GUI option.

The 2D content rendering add-ons [i]Gorilla[/i] and [i]Canvas[/i] are also interesting, although they are no GUI systems. They are optimized for high speed and especially Canvas can display beautiful styled text. Both are new projects and currently not available by Mogre, but maybe in the future (if somebody port or wrap it for his own project).


Off topic:
Sometimes I think I spend really too much time for forum discussions and wiki pages. Then I think it would be better to use that time for practial Ogre work (applications) instead of only reading and talking about.
On the other hand my public work could be more useful for the community.
Well, I will see. Today I don't experiment with Billboards as I wanted to. Maybe tomorrow.
(Just some thoughts which were coming out of me ...)

Bug report:
I made first steps in using the Tutorial Framework and I found an important bug.

After starting I got a BadImageFormatException.
The file or assembly Mogre, Version=1.7.1.0 ... was not found.

Because of my Mogre forum "reading experiences" I found the reason quickly.
In the build settings the target plattform is set to Any CPU.
This choice must be x84 (for debug and release).
If not, then on 64bit Windows you can't run the application.

At my tests related to the Billboard creation I was disturbed, that I didn't see XML comments for properties, methods and especially its parameters.

Task:
Add the file Mogre.xml from here (SVN of our MogreSDK) to the debug and release directory of the TutorialFramework.
Then the XML descriptions are available.

For my billboard tests the TutorialFramework was really fine!
I just needed to insert a tiny code snippet, and had run.
(Ok, I also created a texture image and a material file.)

If somebody needs the source code, then look to this post. A material file snippet was posted 2 posts before.
There is also a tiny screenshot.

Now it's really time for sleeping!
But I will do it with a most happy feeling - thanks for the helping framework


Suggestion for the TutorialFramework:

In the class BaseApplication you could create the method ShowHelp().
This will display a text (as overlay?), about all key definitions. (ASDW, QE, G, Esc, ...)

Bug report:
I made first steps in using the Tutorial Framework and I found an important bug.

After starting I got a BadImageFormatException.
The file or assembly Mogre, Version=1.7.1.0 ... was not found.

Because of my Mogre forum "reading experiences" I found the reason quickly.
In the build settings the target plattform is set to Any CPU.
This choice must be x84 (for debug and release).
If not, then on 64bit Windows you can't run the application.
Hmm this might be a bit of a problem as according to this different CPU targets are not supported by the 2008 visual studio expresses (you are using 2008 right?). However I did manage to make it say "x86" in the configuration manager somehow so I'm not sure maybe it will work after all.

I'll make this change and post here after I've uploaded the new project zip files.

At my tests related to the Billboard creation I was disturbed, that I didn't see XML comments for properties, methods and especially its parameters.

Task:
Add the file Mogre.xml from here (SVN of our MogreSDK) to the debug and release directory of the TutorialFramework.
Then the XML descriptions are available.
Hey that's neat I didn't know that's available! I'll integrate that soon.

For my billboard tests the TutorialFramework was really fine!
I just needed to insert a tiny code snippet, and had run.
(Ok, I also created a texture image and a material file.)

Tell me which files to add and I'll add them. I intentionally cut down the Media folder of the pre-made projects to reduce the overall size with the intention of adding new requirements for each new tutorial if needed.

Suggestion for the TutorialFramework:

In the class BaseApplication you could create the method ShowHelp().
This will display a text (as overlay?), about all key definitions. (ASDW, QE, G, Esc, ...)
That's a good idea, I'll add that too.

i have spotted a little mistake in the tutorial, in The Ogre/Mogre Environment, the main library part, the cg dll is not needed by the main library, only the Plugin_CgProgramManager need it. About the mogre.framework package, you don't need to include ois.dll in the zip, it have been statically linked with the mois.dll (apart if it's a different version than the last vs2008 sdk).

Also, it would be a interesting to speak about the vs2008 redist package dependencies, since it's mandatory, and perhaps the difference between vs2008 and vs2010 dll dependencies (since it change the way applications are deployed).
These changes are now applied tothe tutorial and the framework. Feel free to have a look and let me know if you find more things.

I've modified and re-uploaded the premade tutorials framework projects.

This includes two of the changes you requested Beuty: Mogre.xml is present and used by intellisense and all projects are set to x86 platform.

Addtionally the VB.NET code stub was cleaned up (Module? who did that...).

Have a look and let me know if it's OK.

Tutorial 5 is now finished.

I've again slightly deviated in this case, but it very close to the Ogre version.

On a different note, I'd like to start cleaning up the temporary wiki page that I've used while working on these tutorials, but I don't seem to have the right privileges. Can anyone help?

These wiki pages ought to be removed:
Mogre New Basic Tutorial 1
New Mogre Basic Tutorial 2
Mogre New Basic Tutorial 3
Mogre New Basic Tutorial 4
Mogre New Basic Tutorial 5

i have spotted a little mistake in the tutorial, in The Ogre/Mogre Environment, the main library part, the cg dll is not needed by the main library, only the Plugin_CgProgramManager need it. About the mogre.framework package, you don't need to include ois.dll in the zip, it have been statically linked with the mois.dll (apart if it's a different version than the last vs2008 sdk).

Also, it would be a interesting to speak about the vs2008 redist package dependencies, since it's mandatory, and perhaps the difference between vs2008 and vs2010 dll dependencies (since it change the way applications are deployed).

These changes are now applied tothe tutorial and the framework. Feel free to have a look and let me know if you find more things.

Ok for me, the Mogre and the .NET Framework is well made, questions / problems related to compilation platform (x86, x64) will probably be brought up a lot in the future, since more and more user switch to 64 bit os. i will check out the other tutorial later.

different CPU targets are not supported by the 2008 visual studio expresses (you are using 2008 right?). However I did manage to make it say "x86" in the configuration manager somehow so I'm not sure maybe it will work after all.
Oh, interesting to know this difference.
I suppose VS express can open solutions with x86 setting.
If this setting will be respected or ignored we need to check.
Yes, I still use VS 2008, although I have the possibility to download and install VS 2010. (This I can do, because my university has a agreement with Microsoft. It's just a question of time when I do the change.)



Add the file Mogre.xml
Hey that's neat I didn't know that's available! I'll integrate that soon.
This discussion is also related for improvements of the TutorialFramework - isn't it?


Tell me which files to add and I'll add them.
I just wanted to say - your framework is nice for simple prototyping - also aside from the tutorials.
My added material is just a simple test, not nice. If I write a tutorial about billboards, then I would add it. Not before.



There are some warnings in the ogre.log files. (The same as 2 years ago.)
* Model(s) need a version update
* Font blue highway not found
or similar. The reasons could be fixed, because such warnings are just confusing newcomers.
For the first there is a command-line tool. Maybe in the OgreCommandLineTools bundle?
For the second - maybe a font is missing (so add/remove/replace it) or there is a bug in the config files.

Yes I know, the media folder needs a cleanup. It might not be trivial work to go through them and figure out what's needed and what isn't and what needs updating. I was planning to do that when I finish the basic tutorials so that way I can test exactly against the needed resources.

I suppose VS express can open solutions with x86 setting.
If this setting will be respected or ignored we need to check.

You can tweak the csproj solution by hand, it will then allow you to choose your own platform configuration settings, check this blog post about this "hack" :

http://coffeedrivendevelopment.blogspot ... press.html

Tutorial 5 is now finished.
In the section about the RenderSystem setup it would be useful to add a note/source for the AntiAliasing and Vsync option. I suppose these are interesting - also for newcomers.

Some time ago I added an example code snipptet to Mogre Howto wiki page:
// Create Render Window
mRoot.Initialise(false, "Main Ogre Window");
NameValuePairList misc = new NameValuePairList();
misc["externalWindowHandle"] = Handle.ToString();
misc["FSAA"] = "4"; // anti aliasing factor (0, 2, 4 ...)
misc["vsync"] = "true"; // by Ogre default: false
mWindow = mRoot.CreateRenderWindow("Main RenderWindow", 800, 600, false, misc);
But maybe there is a more simple way. (The idea I got by your tutorial 5 code.)
renderSystem.SetConfigOption("FSAA", "4"); // anti aliasing factor (0, 2, 4 ...)
renderSystem.SetConfigOption("vsync", "true"); // by Ogre default: false
Mstoyke wrote, vsync is especially important for flat screens. (although I don't know if this is related to common case or only when the application should display smoth animations)
The Anti Aliasing is for a better display result. (For this add the note: if the factor is to high, you'll get an application crash.)

In section Creating a Scene of tutorial 5 you create a light with the variable name "l". In my eyes this is a bad var name, because it's looking like "1" (the number one). Just write light.
If the Ogre tutorial also writes l, then you can correct it there, too.

I the render loop section, maybe you can mention, that there is a second way:
Instead of mRoot.StartRendering() and the frame listeners the programmer could write his own render loop by use of root.RenderOneFrame().
Currently we have a discussion about an optimized render loop. If you are interested, look here (be aware - it's a long thead now). In this post is an inproved example for C#. Well, this is to much for a beginner tutorial. I just mean, maybe we could just say that there is a second option (root.RenderOneFrame()).
It's your choice if you mention it.


I'd like to start cleaning up the temporary wiki page that I've used while working on these tutorials, but I don't seem to have the right privileges.
In the old wiki I had higher rights, e.g. for deleting pages. I suppose with the current wiki software I can't do so.
Ask jacmoe - he can do the tasks.


since more and more user switch to 64 bit os
Nice to see, that you still give us support
As I read in a computer magazin, today the most new desktop PCs will be selled with Win7 64bit (only related to Germany??). Only discount shops (which main purpose is selling food!) offer their PCs with 32bit systems, because they are afraid of support requests related to old peripheral equipment.
So, support of 64bit systems is common practice.
(Just a little footnote)


It might not be trivial work to go through them and figure out what's needed and what isn't and what needs updating.
Maybe for this you could use the Process Monitor. It's a tool of the (free) Sysinternals collection. (The programmer and his great tools were buyed by Microsoft, but they are still offered for free.)
Set the filter of Process Monitor to show only files with read access, which were done by Mogre related processes.
But in the case that the Ogre RessourceManager reads ALL files by default (at initialization time), then you need to figure it out manually.
E.g. remove all files and look to the Warnings of Ogre.log.
For this case you could use my code snippet for additional loggers. This I use in my main application for a second log file, which only contains warnings and errors. A big improvement for the overview.

On the other hand - after compressing the resource size of the current TutorialFramework is only 3MB. So there isn't much sense to spend too much time in searching for unused files.

... questions / problems related to compilation platform (x86, x64) will probably be brought up a lot in the future, since more and more user switch to 64 bit os.
I agree, that this will cause more confusion in the future. That's why I still recommend x86 (32bit!) to everybody using Ogre/Mogre if there is no real good reason for a 64bit build. Even today 64bit for most games is mainly a marketing "gag". I've never seen anything done in a 64bit game that could not be done with a 32bit version. This will change over time, but I think it will be true at least for a few more years.

So if you want less problems with the platform (Mogre) to have more time for creating cool stuff with it (games, demos, ...), just stick with 32bit. It will run on both, 32bit and 64bit systems and will cause much less problems when you try to use different libraries together (see also: "gamestack" thread)

Just my opinion, so if somebody can show me a (non-scientific) application for Mogre that can only work with a 64bit version I will be very interested to see if I will change my mind

In the section about the RenderSystem setup it would be useful to add a note/source for the AntiAliasing and Vsync option. I suppose these are interesting - also for newcomers.

Some time ago I added an example code snipptet to Mogre Howto wiki page:
// Create Render Window
mRoot.Initialise(false, "Main Ogre Window");
NameValuePairList misc = new NameValuePairList();
misc["externalWindowHandle"] = Handle.ToString();
misc["FSAA"] = "4"; // anti aliasing factor (0, 2, 4 ...)
misc["vsync"] = "true"; // by Ogre default: false
mWindow = mRoot.CreateRenderWindow("Main RenderWindow", 800, 600, false, misc);
But maybe there is a more simple way. (The idea I got by your tutorial 5 code.)
renderSystem.SetConfigOption("FSAA", "4"); // anti aliasing factor (0, 2, 4 ...)
renderSystem.SetConfigOption("vsync", "true"); // by Ogre default: false
Mstoyke wrote, vsync is especially important for flat screens. (although I don't know if this is related to common case or only when the application should display smoth animations)
The Anti Aliasing is for a better display result. (For this add the note: if the factor is to high, you'll get an application crash.)
Is there a place in the Ogre documentation that discusses the options? If so we should link to it rather than re-write the wheel I think. It's also general important concepts about 3D so might be slightly out of scope for a tutorial about Mogre, but worth mentioning with an external references (similar to vector math or events in C# mentioned somewhere in the tutorials).

RE settings the options I personally have an aversion from key-value pair and dictionaty objects (it's cheating and inefficient!). But beyond my personal issues I don't think there is anything wrong with your way.

In section Creating a Scene of tutorial 5 you create a light with the variable name "l". In my eyes this is a bad var name, because it's looking like "1" (the number one). Just write light.
If the Ogre tutorial also writes l, then you can correct it there, too.
You are right the only reason for it is that I copied and translated the Ogre one. I'll change the Mogre one, but I don't feel confident enough yet to start changing Ogre documentation...

I the render loop section, maybe you can mention, that there is a second way:
Instead of mRoot.StartRendering() and the frame listeners the programmer could write his own render loop by use of root.RenderOneFrame().
Currently we have a discussion about an optimized render loop. If you are interested, look here (be aware - it's a long thead now). In this post is an inproved example for C#. Well, this is to much for a beginner tutorial. I just mean, maybe we could just say that there is a second option (root.RenderOneFrame()).
It's your choice if you mention it.
Erm... I did mention that... look at the bottom of the section

RE settings the options I personally have an aversion from key-value pair and dictionaty objects (it's cheating and inefficient!). But beyond my personal issues I don't think there is anything wrong with your way.
The NameValuePairList is used by Ogre for initialization options and my preferred way to provide them to the renderwindow. Key/value pairs are a flexible way to provide options, but they are error-prone because you need runtime checks instead of compile-time checks that "normal" parameters provide.

Don't worry about inefficient code in initialization or shutdown functions, they are usually not worth optimizing, because they are only called a few times (or once).

The NameValuePairList is used by Ogre for initialization options and my preferred way to provide them to the renderwindow. Key/value pairs are a flexible way to provide options, but they are error-prone because you need runtime checks instead of compile-time checks that "normal" parameters provide.

Don't worry about inefficient code in initialization or shutdown functions, they are usually not worth optimizing, because they are only called a few times (or once).
Yes I know this is why I said my personal issues (RE efficiency) .

Having said that I prefer DTOs for the same reason you mentioned: type safety and error checking at compile time.

The TutorialFramework is great for quick prototyping and experiments with Ogre features.
(For example with the TutorialFramework I found out how to use Billboards and Overlays.)

But for this experiments, it's very harry to click OK in the Ogre Setup Window for each start.
So I looked for a comfortable solution how to start without setup window and published it in the wiki:
http://www.ogre3d.org/tikiwiki/Mogre+Wi ... tup_window

Maybe it's useful for somebody.
This forum post is just to let you know

I've just added/replaced tutorial #6 with a new tutorial about overlays. If you get the chance to look at it please give me any feedback you may have.

This concludes the planned cleanup of the basic tutorials. We are now into refreshing the old intermediate tutorials. However I think that the overlays topic really doesn't belong in the "basic" area and neither does the topic of embedding Mogre in Windows.Forms, so later I will move them.

McDonte has done some good work on a new version of the intermediate tutorial #1 which I will soon upload.

Oh nice
A few weeks ago i started to make first tests with overlays.
I also want to offer one (or more?) code snippets. (e.g. a method to load an image file and put it into an overlay)

What's about the old Mogre Basic Tutorial 6?
Wasn't it about application creation without the tutorial framework?
Did you delete it or move it to an other page?
I would prefer to keep the old tutorial in the wiki (on a different page).

I left it with a link called "Embedding Mogre in Windows.Forms" which was the title of the tutorial. I just didn't feel that's really a tutorial, but more of a "guide" that belongs to a later section that does not exist yet. This relates to my other thread about the general structure of the wiki.

And if needed, there http://dhost.info/haima/ogre/index.html you can find my simple "Create Overlay" software, it
just converts data from VC#, text and image positions made with its form editor, it parses that saved .cs file and creates .overlay and .material files.

Simple "Create Overlay" software, it
just converts data from VC#, text and image positions made with its form editor, it parses that saved .cs file and creates .overlay file.

Oh, that sounds great!
This would also be usable for common Ogre (C++) users.
(Even when they never used C#, it should be easy enough to call the C# form editor)

I propose to create a public repository (e.g. on code.google.com) to make it save for long term use.
This prevents getting lost, when the website goes offline (after months or years) or a website crash (as happened for some other Mogre stuff on a private host a few weeks ago.)
Also it would be more easy for others to include improvements (to a central place).

After repository creation I would create a forum topic in the showcase section, where many Ogre users will see it.
I suppose you will find users and maybe supporters in this way. And it will help other people.

Optionally we could create a wiki page about this project with some details (features, screenshot, instructions, ...).


By the way:
Does the conversion use pixel relations or relative relations?

@mikael
On your website I found fresh dll files for CeGUI.
I only remember very old Mogre examples using CeGUI.
Do you know if it's usable with Mogre 1.7, too? (Maybe you only use it for Axiom.)
In this case it would be nice, when you create a new forum topic (and/or a wiki page) with some instructions how to embedd it. And maybe a comparison to other GUI systems (e.g. Miyagi, MyGUI) to show (dis-)advantages.

I left it with a link called "Embedding Mogre in Windows.Forms" which was the title of the tutorial. I just didn't feel that's really a tutorial, but more of a "guide" that belongs to a later section that does not exist yet. This relates to my other thread about the general structure of the wiki.
Thanks for keeping this page!
Did you get admin rights for the wiki now?
If you aren't able to rename pages, please ask jacmoe for rights. (I don't have rename rights.)

Maybe you like to create a further box on the tutorials page with the name guides?
Just as an idea. But do as you like. I'm shure you will do a good job!

A note for your wiki work:
I recognized, that line breaks are ignored inside of boxes (e.g. in the boxes which includes the tutorial links).
If you need a line break there, you can use this wiki code:
%%%

Another idea for the Guides section: a tutorial how to set up Managed Hydrax. Now we have it so it would be great if everybody could use it easily.

Yes it is my intention when we finish with the basic stuff to dedicate a guide for each Mogre addon (MGui, MquickGui, MHydrax, etc).

Lots of work ahead of us

In the build settings the target plattform is set to Any CPU.
This choice must be x84 (for debug and release).

I've modified and re-uploaded the premade tutorials framework projects.

This includes two of the changes you requested Beauty: Mogre.xml is present and used by intellisense and all projects are set to x86 platform.

I just downloaded the package "Visual C# 2008 / .NET 2.0-3.5" again and recognized, that the target problem is still available. (I didn't check the other packages.)
Amirabiri, it would be nice if you look again to your 4 framework packages and update all which still have an "Any CPU" setting.