Mogre SDK development

kwertz

15-10-2009 12:18:03

Inserted by moderator:
This thread is for improving of the Mogre SDK (currently related to 1.6.4).

The Mogre SDK should be user friendly, especially for newcomers.

It should:
* check for installed Mogre depencies
* offer installation of needed depencies
* install the Mogre SDK (in best case without need of manual system changes)
* contain different libraries
* contain sample applications

In the wiki is the page Mogre SDK development is an overview for the important points and links.

The discussion started in thread Mogre 1.6.4.
Now it follows up here.


Downloads:
* SDK: The newest release of MOGRE SDK you find at http://mogresdk.googlecode.com
* Binary and lib only: here in SVN of Mogre SDK (look to bin and lib directory)

SVN:
* Direct SVN link: http://mogresdk.googlecode.com/svn/trunk
To get write access ask user kwertz.


Moderator note:
Most of the posts were in thread Mogre 1.6.4.
Now they are moved to this thread.

Here the first SDK related post (by user kwertz)
=============================================================


I would like to announce that I created a windows installer for the new MOGRE 1.6.4 Beta bugfix 1.

Download it here: MOGRE SDK 1.6.4 Beta Installer.

The installed folder contains the following files and folders:
  1. D: bin - Contains the MOGRE binaries (debug and release)[/*:m]
  2. D: includes - Contains the include files to compile plugins against MOGRE[/*:m]
  3. D: Lib - Contains the static library files of MOGRE[/*:m]
  4. D: Media - Contains the media files required to run the MOGRE demos which can be compiled with the "BuildSamples.cmd" command script (see below)[/*:m]
  5. D: Samples - Contains the source code of the MOGRE samples[/*:m]
  6. BuildSamples.cmd - Lets you build the MOGRE samples with only one click :)[/*:m]
  7. ChangeLog.txt - This is the change log[/*:m]
  8. License.html - Contains the LGPL license text[/*:m]
  9. MOGRE SDK.url - This is a link to the MOGRE homepage[/*:m]
  10. MogreSamples.sln - The solution containing the sample projects[/*:m]
  11. ReadMe.txt - This provides an overview of the MOGRE SDK. Read it! :D[/*:m][/list:u]

    Please test the installer as well as the installed SDK and give feedback! :)

    For those interested: You can also download the installer script (Inno Setup, not NSIS). In order to do that, please browse to this folder.

GantZ

15-10-2009 19:24:48

well done !, the one click build for sample is really convenient :) .

the Mogre project was really lacking of a decent recent SDK. i also think that we will soon be able to step away from the "beta" release state to a stable release, so we can replace the old 1.4.8 SDK with a new 1.6 one.

just a question, which version of MogreNewt have you include in the project ? it seem to be a rather old one.

kwertz

15-10-2009 20:10:13

The one from the 1.4.8 SDK, but I think it should work with 1.6.4 too.

GantZ

15-10-2009 23:35:39

MogreNewt is specifically linked to an ogre version, so it will not work. also, could you remove the PCZSceneManager and the octreezone plugin ?, this thread remind me they are not working in Mogre ATM.

kwertz

21-10-2009 16:01:30

MogreNewt is specifically linked to an ogre version, so it will not work. also, could you remove the PCZSceneManager and the octreezone plugin ?, this thread remind me they are not working in Mogre ATM.

Okay, update done. Please check if everything is correct now. You can download the new SDK from the usual place.

GantZ

23-10-2009 13:34:24

just check it, everything ok. thanks !

hedphelym

01-11-2009 18:01:46

Check all needed dlls are present in your output folder where compiled exe file placed. I.e. Mogre.dll OgreMain.dll ... Look here for detailed info: http://www.ogre3d.org/addonforums/viewtopic.php?p=65076#p65076

If i install the sdk, then use the "build.bat" it builds everything, and i can then run the exe's directly from the release dir.

i then open the sample solution in my IDE (VS), and compile it (Release x86) , it gives these exceptions.

GantZ

01-11-2009 22:48:35

what is the output folder in the build tab of your VS project properties ? you should have ..\..\bin\release\ (or debug given your configuration) as output folder.

there is a post build event that copy all exe to the bin folder of the sdk, so it could be that when in VS, it try to run the version in the bin folder of the project you try to debug, not the one of the SDK, do you have a .vshost.exe for the sample you try to run in the release dir of the SDK ?

Ricane

03-11-2009 21:04:20

@hedphelym: Got the same problem; the solution for me was to set the "Platform target" to "Any CPU" and the "Output Path" to "..\..\bin\release\" (both in the Properties screen of the projects).

After doing so, everything could be build and executed out of VS.



Regards from Germany,

Ricane

hedphelym

03-11-2009 21:16:07

argh, now i get this instead:


System.Runtime.InteropServices.SEHException was unhandled
Message=External component has thrown an exception.
Source=Mogre
ErrorCode=-2147467259
StackTrace:
at Ogre.ConfigFile.load(ConfigFile* , basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , basic_string<char\,std::char_traits<char>\,std::allocator<char> >* , Boolean )
at Mogre.ConfigFile.Load(String filename, String separators, Boolean trimWhitespace)
at Mogre.Demo.MogreForm.OgreWindow.InitMogre() in C:\MogreSDK 164\Samples\MogreForm\MogreForm.cs:line 65
at Mogre.Demo.MogreForm.MogreForm..ctor() in C:\MogreSDK 164\Samples\MogreForm\MogreForm.cs:line 22
at Mogre.Demo.MogreForm.Program.Main() in C:\MogreSDK 164\Samples\MogreForm\Program.cs:line 17
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:

hedphelym

03-11-2009 21:22:37

took away the post build "copy" event.
pointed the output to :
c:\mogresdk\bin\release

It does now work. :D

kwertz

09-11-2009 23:29:32

Late, isn't it? :)

Okay, I updated the 1.6.4 SDK.

Changes:
  1. Removed "copy ..." command from the post-build events.[/*:m]
  2. Target platform changed to "Any CPU" in file "BuildSamples.cmd".[/*:m]
  3. Created a new file called "BuildSamplesX86.cmd".[/*:m][/list:u]

    I think, this should fix the problems described in the posts above. If it does not, please report the issue/-s (describe them in detail).

hedphelym

09-11-2009 23:38:36

Thanks,
I will try this tomorrow, and report back!

Beauty

16-11-2009 15:59:59

If there isn't an example for Mogre GUIs, it would be nice to add some of them to the SDK.
I suppose many users (also new ones) want to use a GUI system.

Miyagi is looking well and powerful.
Also it's actively developed (by smiley80).
We can ask smiley80 for an example application.
http://www.ogre3d.org/wiki/index.php/Miyagi
viewtopic.php?f=8&t=9025

Alternatives are
ButtonGUI - http://www.ogre3d.org/wiki/index.php/ButtonGUI
MQuickGUI - http://www.ogre3d.org/wiki/index.php/MQuickGUI
MogreBetaGUI - http://www.ogre3d.org/wiki/index.php/MogreBetaGUI (I had problems with it and debugging wasn't easy because of crypted variable names)
Mogre CEGUI - http://www.ogre3d.org/wiki/index.php/Mogre_CEGUI (I think this was outdated)

If I forgot important ones (for Mogre), please tell me.

hedphelym

16-11-2009 16:02:58

I second all of this, it would help us very very much!

Vectrex

16-11-2009 18:15:16

MyGui is looking like a top contender. It's also got the very important Hikari and Awesomium widgits which suddenly makes it way more useful.

Beauty

16-11-2009 18:44:03

MyGui is looking like a top contender. It's also got the very important Hikari and Awesomium widgits which suddenly makes it way more useful.
Is there a MyGui solution for Mogre?
I don't find a wrapper or port in the wiki. (Maybe in forum?)

Awesomium (show content HTML/CSS code) is nice. Is there a (stable?) possibility to use it by Mogre?
Hikari (display Flash content) is also nice for a demo. GantZ wrote a wrapper for it (linked here; stable?, up to date?).

Vectrex

16-11-2009 18:46:16

Yeah the Hikari MOgre works great. I think Awesomium would be highly worth porting as it includes flash AND webkit rendering, which covers just about any gui you could think of. Navi is the Ogre interface to it which is pretty small so I think it'd be simple to port/wrap.

Beauty

16-11-2009 19:02:44

I think Awesomium would be highly worth porting ...

On new projects, generally we should think about what's better.
To make a port or a wrapper for the Ogre version.
A wrapper doesn't need so much code and would be more easy to update.
A port has more flexibility, but needs more work (also for bigger updates).

What's about MyGui - has your prefered Gui a Mogre port/wrapper?
You didn't reply to that.

GantZ

16-11-2009 20:08:36

about hikari for Mogre, it have been updated recently. viewtopic.php?f=8&t=8390 , it's pretty stable, if you except the memory leak problems (we will have to wait for Akarui to avoid that).

about Awesomium, a .NET version already exist, but i don't think it's related to Ogre, and i don't know if it's stable. perhaps it would be a good starting point to integration with Mogre ?
http://awesomiumdotnet.codeplex.com/
http://princeofcode.com/forums/viewtopic.php?f=9&t=213

@Smiley80 having a tool generating the xml doc automatically would be nice :), if your ok with it, could you publish your tool ? i would add it in the autowrap code then. or we could ask Bekas to give you an access to the SVN.

hedphelym

17-11-2009 16:02:06

I was browsing codeplex today, and found this:

[url=http://dotnetinstaller.codeplex.com/



A boostrapper doesn't replace tools like InstallShield, Wise, Visual Studio Setup and Deployment Project or Wix. The goal is to create an application to help users with installing the correct prerequisites. Most real world applications need to install several components to work properly, including Windows Service Packs, Internet Explorer, MDAC or .NET Framework. This kind of applications are most commonly known as bootstrappers. dotNetInstaller is such a bootstrapper.


Thought it was worth a mention because of the wish of having a installer that installs everything.

Beauty

17-11-2009 17:19:05

Thanks for your information.
This is also interesting for people who want to publish her Mogre projects.

anthrax11

19-11-2009 03:17:22


about Awesomium, a .NET version already exist, but i don't think it's related to Ogre, and i don't know if it's stable. perhaps it would be a good starting point to integration with Mogre ?
http://awesomiumdotnet.codeplex.com/
http://princeofcode.com/forums/viewtopic.php?f=9&t=213

Hi, as the author of that project I'd be happy to cooperate here. I'm not too familiar with OgreDotNet or MOgre, but the way AwesomiumDotNet works is that it renders a webpage from Awesomium to a Byte array, everything else is independent of the graphics API. So if the managed Ogre wrapper can provide a pointer to a locked texture or something like that, then it should work as it is. The wrapper hasn't had much use yet, so I'm not sure about the stability. It currently tends to crash every 10th time or so when shutting it down. I'm guessing there's something wrong with the cleanup code.

However, the real problem with Awesomium is that it's going commercial and the official code repository has been taken down. There's a fork of the latest LGPL version, but it doesn't seem to be doing too well, so I'm just waiting to see how things work out before I put a lot of work into the project again.

smiley80

19-11-2009 07:50:26

By the way - how can an installer (or Mogre application) find out if a DirectX Redistributable package is installed? (and which version)
HKLM\Software\Microsoft\DirectX\Version
Although, it doesn't show which version of DirectX 9.0c is installed.

I think the easiest way would be to include and run the web installer:
http://www.microsoft.com/DOWNLOADS/deta ... laylang=en

Beauty

19-11-2009 15:13:05

Thanks anthrax11 for your post. I added your information to the Awesomium page of our wiki.

Beauty

19-11-2009 17:37:11

Okay, I updated the 1.6.4 SDK.
  1. Created a new file called "BuildSamplesX86.cmd".[/*:m][/list:u]

Is it something like a bat file?
What is the intension of this file?

Beauty

19-11-2009 23:43:43

By the way - how can an installer (or Mogre application) find out if a DirectX Redistributable package is installed? (and which version)
HKLM\Software\Microsoft\DirectX\Version
Although, it doesn't show which version of DirectX 9.0c is installed.

I think the easiest way would be to include and run the web installer:
http://www.microsoft.com/DOWNLOADS/deta ... laylang=en


The webinstaller is a good idea. Does it install the redistributable package?
The idea of the registry search is good. I didn't found something helpful for the DirectX version.

But the registry is a way to check if vcredist is installed (and which version).
On my Windows XP it can be found in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserDate\...
name: DisplayName
value: Microsoft Visual C++ 2008 Redistributable - x86 9.0.21022
value: Microsoft Visual C++ 2005 Redistributable
vcredist 2005 maybe is needed for dll file created by Visual Studio 2005
Maybe on other Windows versions it's different.

Beauty

20-11-2009 01:05:31

Ok, boys and girls!
Hours of searching and writing work is done.

In the wiki I created the page Mogre SDK development.

There I added several information about the SDK and installer.
Also the links could be interesting.

Be welcome to use it as a central point for information, suggestions and instructions.
Don't be afrait to edit the page if you can improve it.

update:
Maybe we shall open a new thread - only related to the installer.

Beauty

20-11-2009 01:33:43

Hi,

(after one year again I ask)
I would like to have the source file of the image (layers? vector graphic? font types?) that is included in the installer of MogreSDK.

Beauty

20-11-2009 02:30:06

Update needed for ReadMe.txt in SDK:

-------------------------------------
How to compile MOGRE
-------------------------------------
Visit http://ogre3d.org/wiki/index.php/Buildi ... rom_source

update Link to
http://www.ogre3d.org/wiki/index.php/Bu ... rom_source (related to Mogre 1.6)

-------------------------------------
Who is responsible
-------------------------------------
Copyright (c) 2006-2007 Argiris Kirtzidis
Maintainer (2008): Mario Serrano Leones

We could add the forum names in brackets (Bekas and Marioko)
And add GantZ.


-------------------------------------
Home page
-------------------------------------
http://mogre.sourceforge.net

It's a redirection to our wiki page. Why we don't use this instead?
http://www.ogre3d.org/wiki/index.php/MOGRE



There are some unnecessary line breaks. Maybe remove?


update:
Changes are done
(now I could do it by use of the new SVN)

Beauty

20-11-2009 02:51:52

Does we need this files in the binary folders of the SDK?

* media.cfg ..... (for what?)
* quake3settings.cfg ..... (for what?)
* OIS.dll ..... (Bekas wrote that this file isn't needed for MOIS.dll - maybe this is only related to Mogre 1.6)


There 2 Mogre files in the bin/Debug folder:
* Mogre.dll ..... year 2008
* Mogre_d.dll ..... year 2009

I think the first file can be removed.


The media files are about 18 months old.
Maybe there are newer ones in the current Ogre release?


Are all included Samples running with Mogre 1.6.4?
Some of them should get more information. (e.g. BSP and Dot3Bump - I have no idea what's the aim of it)
Maybe add an info file to the folders or rename them.
The sample ExampleApplication has no good name. Rename?


update:
The file MogreSamples.sln is in root directory.
Maybe move to directory Samples? (and update referenced files)


we could add a file called BuildSamples.txt - to explain the difference between the 3 cmd files.
I suppose x64 is for Win 64bit, x86 for Win 32bit. But I'm not shure (also it's possible that some other people don't know).
What is the difference to BuildSamples.cmd without postfix?
This isn't clear and can make confuse.
Maybe we also move the BuildSamples files to directory Samples?

And it would be good to give the user a notice that all Sample binaries are created in bin/release.
Otherwhise it could be that the user search for it in the Samples tree without finding it.

Beauty

20-11-2009 03:36:36

Improvement-Idea for Samples

First of all:
I started BuildSamples.cmd and then all samples were running in my PC (-:


Generally is would be good to add a simple gui display (by overlay?) to all samples.
So the user knows, which keys he can use.
Example Dot3Bump has such a quick help. And example SkeletalAnimation has text output.

BSP:
* use other start orientation (it's bad that the screen is black at start)
* maybe show that the user can move by WASD and turn by mouse

CelShading:
* has the hidden key R to change visibility type - add as quick help

smiley80

20-11-2009 10:40:36


The webinstaller is a good idea. Does it install the redistributable package?

It installs the DirectX End-User Runtime, that's the same thing the redist installs

Beauty

20-11-2009 12:28:54

I have the experience that my Mogre application don't run if you install the current version of the "normal" DirectX version (9.0c on WinXP).
Only after installing the redistributable package it worked.
Ok, maybe this is, because I always use the Debug binary.
For developers also the debug binaries should run and there is a need for the right DirectX package.
If I'm wrong, please correct me.

smiley80

20-11-2009 13:06:21

The problem is, that Microsoft frequently releases new versions of DirectX 9.0c, but they are called 'DirectX 9.0c'.

Rendersystem_Direct3d9.dll needs d3dx9_40.dll, which is included in the March 2009 release of DirectX 9.0c.

hedphelym

22-11-2009 16:15:15

Hi, I just wanted to share some info I figured out today.

The mogre 1.6.4 has been a major headache for me, to get it to run properly.
Today I used the info in the wiki that Beauty collected (for making sure I had everything correctly installed).

But the key was the following;

I simply expect to open the samples solution, compile and run, (this does not work).

I had to fight a file not found exception, and it was hard to figure out why this happend.
What I did in the end was the following; build solution (let's say the mogreform example),
then this one originally compiles to this dir:
C:\MogreSDK\Samples\MogreForm\bin\x86\Release\

If I change the project build output to the following:
C:\MogreSDK\bin\Release\

It runs fine.
Maybe this can be fixed, so that one does not have to "fix" this manually?

either by copying files from the
C:\MogreSDK\bin\Release\
to
C:\MogreSDK\Samples\[what ever project that's set to be startup]\bin\x86\Release\
or the other way around.. automatically on compile?

kwertz

24-11-2009 21:35:53

Ok, to clear up the confusion:

  1. 'BuildSamples.cmd' lets you build the MOGRE samples for any cpu[/*:m]
  2. 'BuildSamplesX86.cmd' lets you build the samples explicitly for 32-bit processors, so that WOW64 is activated on Windows 64-bit editions.[/*:m][/list:u]

    I cleaned up the SDK a bit. Have a look at it.

    Hi, I just wanted to share some info I figured out today.

    The mogre 1.6.4 has been a major headache for me, to get it to run properly.
    Today I used the info in the wiki that Beauty collected (for making sure I had everything correctly installed).

    But the key was the following;

    I simply expect to open the samples solution, compile and run, (this does not work).

    I had to fight a file not found exception, and it was hard to figure out why this happend.
    What I did in the end was the following; build solution (let's say the mogreform example),
    then this one originally compiles to this dir:
    C:\MogreSDK\Samples\MogreForm\bin\x86\Release\

    If I change the project build output to the following:
    C:\MogreSDK\bin\Release\

    It runs fine.
    Maybe this can be fixed, so that one does not have to "fix" this manually?

    either by copying files from the
    C:\MogreSDK\bin\Release\
    to
    C:\MogreSDK\Samples\[what ever project that's set to be startup]\bin\x86\Release\
    or the other way around.. automatically on compile?


    Fixed (I hope).

    Does we need this files in the binary folders of the SDK?

    * media.cfg ..... (for what?)
    * quake3settings.cfg ..... (for what?)
    * OIS.dll ..... (Bekas wrote that this file isn't needed for MOIS.dll - maybe this is only related to Mogre 1.6)


    There 2 Mogre files in the bin/Debug folder:
    * Mogre.dll ..... year 2008
    * Mogre_d.dll ..... year 2009

    I think the first file can be removed.


    Also fixed.

    I'm thinking about making a Windows Forms application that lets you choose the sample you want to run, so that you don't have tons of executables in the output directory. Instead, all samples are packed into that application (see http://axiomengine.sourceforge.net/). What do you think?

    Like always, I'm awaiting your feedback.

hedphelym

24-11-2009 21:38:51

Just one quick question - When you update, do you update to the same exe as linked in first post?

kwertz

25-11-2009 17:29:15

Yes, I do. Should I keep the old versions?

Beauty

25-11-2009 17:56:11

I'm thinking about making a Windows Forms application that lets you choose the sample you want to run, so that you don't have tons of executables in the output directory. Instead, all samples are packed into that application
I thinks it's not so good to merge all examples. This is not so good for updates or new examples.
But it would be good to add a compiled GUI application in SDK/Samples.
* for building the samples (with x86/64 options and quick notes)
* and for starting each sample (also with a quick note)

Maybe add a ready compiled Mogre depency test application.
If this runs without exception, then all depencies are correct (DirectX version, etc.).
If not, it should catch the exception and show a warning: "Some depencies are missing to run Mogre applications. Install this and that ..."

kwertz

25-11-2009 18:27:11

I'm thinking about making a Windows Forms application that lets you choose the sample you want to run, so that you don't have tons of executables in the output directory. Instead, all samples are packed into that application
I thinks it's not so good to merge all examples. This is not so good for updates or new examples.
But it would be good to add a compiled GUI application in SDK/Samples.
* for building the samples (with x86/64 options and quick notes)
* and for starting each sample (also with a quick note)

Maybe add a ready compiled Mogre depency test application.
If this runs without exception, then all depencies are correct (DirectX version, etc.).
If not, it should catch the exception and show a warning: "Some depencies are missing to run Mogre applications. Install this and that ..."


For the first: Okay, I will try to accomplish it this week.

For the second: Good idea. What programming language should I use for this? I mean, you cannot check for the .NET Framework using a .NET-based application. :lol:
Options would be C++ (but I'm not good at GUI programming with C++), Delphi or PureBasic. Another option would be to let the installer do this (though I don't know whether InnoSetup is able to do that).

Update: I found a good article explaining how to check for the .NET Framework using InnoSetup. Look here: http://www.codeproject.com/KB/install/dotnetfx_innosetup_instal.aspx. I thought, I'd better share it with you.

Beauty

25-11-2009 21:08:00

Ok, a .NET checker using C# isn't possible.
There are 2 possible solutions for this:
* .NET Framework Installer for InnoSetup and
* dotNetInstaller / bootstrapper on codeplex.com
(Which would be better for us? I'm not shure about the (dis)advantages.)


The other depency checks could be done by a C# application.

Maybe we create a checker like this:
A C++ application checks for the needed .NET version.
If it's not on the system, it will tell it to the user. Also it shows a download link for .NET.
If .NET is installed, then the C++ applications calls a secondary C# application.
This trys to start the Mogre test application.

Also we could add 2 binaries of the Mogre test application.
One for release, one for debug.
Because the depencies are a little bit different. (e.g. the debug version needs a Visual Studio or Visual C# express)

smiley80

26-11-2009 13:43:06

FreeBasic to the rescue.
Makes a registry check for .Net and file checks for DirectX and VCRedist. (Only tested on 32bit XP, should also work on Vista and 7)

Any decent installer should also be able to do that, and install the missing components if a check fails.

Edit:
Updated + source code now included

kwertz

26-11-2009 16:13:51

FreeBasic to the rescue.
Makes a registry check for .Net and file checks for DirectX and VCRedist. (Only tested on 32bit XP, should also work on Vista and 7)

Any decent installer should also be able to do that, and install the missing components if a check fails.


Excellent, works on Windows 7 too. Can you post the source code?

kwertz

26-11-2009 17:36:31

Thank you, smiley80!

But, I finally managed to create a tiny C++ application to check for the .NET Framework 2.0.50727. If .NET is installed, the managed C# GUI application is called. If not, the application will show a Windows message box asking the user if he would like to install .NET. If he clicks 'Yes', the .NET Framework installer is called. Well, look at the source code.

You can access the executable as well as the source code here.

kwertz

26-11-2009 20:28:42

I created a full dependency checker with PureBasic. If one dependency is missing, a message box is shown asking the user if he likes to download the dependency. It takes the path to the managed executable as the only command line parameter.

So try it out and give feedback. You can download it here.

Beauty

26-11-2009 21:43:20

Makes a registry check for .Net and file checks for DirectX and VCRedist.
Works on my PC (Win XP, 32bit, admin rights).
There is no souce code in your download link.
If something is missing, then you could print the word "not" in capital letters "NOT". And before "Press any key" could be an empty line :wink:

I got the output: VC++ 2008 SP1 Redist not found.
But my Mogre 1.6 samples are running.
On my PC this is installed: Microsoft Visual C++ 2008 Redistributable - x86 9.0.21022
... Maybe this older version is also working. Or the reason is that I installed Visual C# 2008 Express

Excellent, works on Windows 7 too. Can you post the source code?
Windows 7 with 32 or 64 bit?


All information about your 3 checkers I added to the wiki page Mogre SDK development
This should support a better overview. (hopefully that you update it)

Beauty

26-11-2009 21:58:44

I finally managed to create a tiny C++ application to check for the .NET Framework 2.0.50727. If .NET is installed, the managed C# GUI application is called. If not, the application will show a Windows message box asking the user if he would like to install .NET. If he clicks 'Yes', the .NET Framework installer is called.

I started it, but there was only a command line window for 0.2 seconds. Nothing happened.
Then I started it from command line. The output was:
Usage: netchecker.exe <MOGRE sample GUI executable> <dotnetfx.exe|dotnetfx35setup.exe>

I don't understand how it works.
There was no window. Also I didn't found a second binary file (the C# application).
For command line output would be good to add "press any key to exit". (to keep open the cmd window for longer than 0.2 seconds)
The printed tool title is good (.NET Framework checker for MOGRE). There you could add the related version number (Mogre 1.6.x).

Beauty

26-11-2009 22:17:36

I created a full dependency checker with PureBasic. If one dependency is missing, a message box is shown asking the user if he likes to download the dependency. It takes the path to the managed executable as the only command line parameter.

Without second application as a param there is only the warning "Syntax: depchecker.exe <MOGRE sample GUI executable>".
I don't know which exe I should use for the example GUI.


Generally we should think about the target of the checkers:
* only for setup integration (so params are no problem)
* only as stand alone tool (so it would be nice to have a .bat file or config file, or combine it together with the secondary C# application)
..... * usable for stupid end users (needs click and run application) or developers?
* or make them usable for both aims

kwertz

27-11-2009 14:00:11


Excellent, works on Windows 7 too. Can you post the source code?
Windows 7 with 32 or 64 bit?


All information about your 3 checkers I added to the wiki page Mogre SDK development
This should support a better overview. (hopefully that you update it)


I use Windows 7 64-bit, but I think it runs on both.

An open question is, what checker should we use now? I think, either the one from Smiley80 coded in FreeBasic or my one coded in PureBasic (BUT PureBasic costs money). I think we can forget about the C++ one, because it depends on VCRT, but I will leave it on the server. So FreeBasic would be the best choice. What do you think?

Beauty

27-11-2009 20:54:18

Most important is that it runs seamless together with the installer (and maybe as stand alone checker).
But I can't help with this, because I don't know this languages.

I thought C++ applications runs without problems. Maybe use an other compiler?
Aren't there so many C++ applications that runs on Win XP/Vista/7 without any additional depencies?

Beauty

27-11-2009 21:20:23

This thread is for improving of the Mogre SDK (currently related to 1.6.4).

The Mogre SDK should be user friendly, especially for newcomers.

It should:
* check for installed Mogre depencies
* offer installation of needed depencies
* install the Mogre SDK (in best case without need of manual system changes)
* contain different libraries
* contain sample applications

In the wiki is the page Mogre SDK development is an overview for the important points and links.

The discussion started in thread Mogre 1.6.4.
Now it follows up here.


Downloads:
* SDK: The newest release of MOGRE SDK you find at http://mogresdk.googlecode.com
* Binary and lib only : mogre-v1.6.4-1_bin

SVN:
* Direct SVN link: http://mogresdk.googlecode.com/svn/trunk
To get write access ask user kwertz.

kwertz

27-11-2009 21:40:24

Thank you for creating a separate thread! :)

Maybe we could use the GNU GCC Compiler, but I don't have enough experience to use it.

And for the sample GUI: I think I can finish it on Sunday. Is something like this



okay?

Beauty

28-11-2009 01:44:37

This is nice.
Please use a config file where we can add more demos in the future (without of recompile).
Maybe also add a little window for a demo short description.

kwertz

28-11-2009 11:31:19

Should the configuration file be XML or OGRE's C-like language?

Update: Or something like this (taken from OGRE SVN 9350):


SampleFolder=.
SamplePlugin=Sample_BezierPatch
SamplePlugin=Sample_BSP
SamplePlugin=Sample_CameraTrack
SamplePlugin=Sample_CelShading
SamplePlugin=Sample_Compositor
SamplePlugin=Sample_CubeMapping
SamplePlugin=Sample_DeferredShading
SamplePlugin=Sample_Dot3Bump
SamplePlugin=Sample_DynTex
SamplePlugin=Sample_FacialAnimation
SamplePlugin=Sample_Fresnel
SamplePlugin=Sample_Grass
SamplePlugin=Sample_Instancing
SamplePlugin=Sample_Isosurf
SamplePlugin=Sample_Lighting
SamplePlugin=Sample_ParticleGS
SamplePlugin=Sample_ParticleFX
SamplePlugin=Sample_ShaderSystem
SamplePlugin=Sample_SkeletalAnimation
SamplePlugin=Sample_SkyBox
SamplePlugin=Sample_SkyDome
SamplePlugin=Sample_SkyPlane
SamplePlugin=Sample_Smoke
SamplePlugin=Sample_SphereMapping
SamplePlugin=Sample_Terrain
SamplePlugin=Sample_TextureFX
SamplePlugin=Sample_Transparency
SamplePlugin=Sample_VolumeTex
SamplePlugin=Sample_Water


?

I compiled OGRE 1.8 SVN 9350 and packed it up into a 7z file. You can download it here.
Have a look at it! The demo system is amazing! Something like this would be more than appropriate for the new MOGRE SDK!

Beauty

28-11-2009 17:30:33

The new Ogre demo system was created in a project of “Google summer of code 2009″.
It will be integrated to the next Ogre version 1.7 (not 1.8 as i read).
Here is more info:
http://www.ogre3d.org/2009/08/27/google ... time-is-up

I think I have have to update my DirectX. I can't start SampleBrowser.exe. (couldn't find d3d10.dll)

Generally the demo structure is different. All samples are in one application.
And each samples is compiled to one dll file.
Because of this the demo file is so simple.



I think it's much work to write our demos in the new Ogre manner.

So I would create the demo starter like this:

* each sample is a stand alone application with its own subdirectory
* the dll files (Mogre and Add-ons) are only in MogreSDK/bin (instead of the sample directories)
* we use a starter application for the demos
..... -- Button for checking the Mogre depencies (but don't check for .NET - so we can write the starter in C# - The .NET check should only be done by the SDK installer, not by the demo starter)
..... -- Button for compile the demos
..... -- List with all available demos (including Mogre tutorial projects)
..... -- Short description for the selected demo (e.g. what it shows and which keys can be used)
..... -- Preview picture (nice to have, but not needed. Can be stored in an image file of the demo subdirectory.)
..... -- Links (e.g. to Mogre forum, Mogre wiki page, Mogre tutorials)
* use an XML config file for the demo starter
..... -- XML is easy to parse with XML libraries of .NET
..... -- contains all informations about each demo

Here is my proposal for the config file:
(in an editor with syntax highlighting its looking nicer)
<demoStarter>
<demo>
<name>Fog demo</name>
<directory>fog</directory>
<description>Demostrate fog modes. Use space to switch.</description>
<previewPic>fog/thumbnail.png</previewPic>
<binary>fog/bin/release/fog.exe</binary>
<>...</>
<>...</>
</demo>
<demo>
<name>...</name>
<directory>...</directory>
<description>...</description>
<previewPic>...</previewPic>
<binary>...</binary>
<>...</>
<>...</>
</demo>
</demoStarter>

Beauty

28-11-2009 17:58:32

kwertz, if you like you can add the demo starter to an SVN (e.g. sourceforge, code.google).
Then smiley80, me and maybe others can improve it in an easy way.
Better would be to add it to Mogre SVN, but this also can be done later.

The SVN structure for the Mogre SDK could be:

trunk/installer
trunk/demo starter
trunk/depency checker 1
trunk/depency checker 2
trunk/depency checker 3

Beauty

28-11-2009 20:16:36

I compiled OGRE 1.8 SVN 9350 and packed it up into a 7z file. You can download it here.
Have a look at it! The demo system is amazing!

There is also a nice video about the demo system with commentations of the developer:
http://vimeo.com/6004973

I think it would need very much time to do the same for Mogre. So I just wanted to show you :wink:

kwertz

29-11-2009 15:53:40

I created a new project on Google Code. You can access it here.
I am uploading the contents right now, could take a long time though. I will report back, if it finished. :lol:

And, by the way, is the description okay? ("The MOGRE Software Development Kit is an easy way to build amazing 3D applications/games using the famous managed wrapper for OGRE.")

kwertz

29-11-2009 16:26:33

Okay, it finished sending the content. Have a look. Please report if something is not right.

Beauty

29-11-2009 19:43:35

And, by the way, is the description okay?
I wrote a new one :lol:

Vectrex

29-11-2009 20:50:16

wouldn't MOgre just get all this functionality when it gets wrapped to 1.7?

Beauty

30-11-2009 03:02:01

quake3settings.cfg ..... ok, now I know this file is needed for sample BSP
media.cfg ..... what is the need of this file?


The MOIS.dll file
of bin/Debug has 350 KB
and in bin/Release it has 500 KB

Normally the release files are smaller. Maybe this files are on wrong place and needs to get swapped?


All samples are in MogreSamples.sln.
But for the subproject "ExampleApplication" I found no binary.
Some of the build binary files are in bin/Debug, others in bin/Release. I think it's better when it's only in one of them when you use BuildSamples.cmd to create it.


Task:
Move file MogreSamples.sln to directory Samples? (and update referenced files)
The same for BuildSamples*.* files.

Beauty

30-11-2009 03:37:13

Now I found a solution for ExampleApplication.
It seems to be something like a framework for the other samples.
So we could rename it to ExampleApplicationFramework, which is better to understand.

Is this the same like the MogreFramework.dll which is used for the wiki tutorials?

If not, should we merge the content of both or use seperate dll files?
Later we want to include the tutorials.

The download of MogreFramework is here:
http://www.beauty-of-darkness.de/pub/Mo ... 009-01.rar
For use with Mogre 1.6 there are needed some little edits. Look here:
viewtopic.php?p=57660#p57660

Maybe somebody has a fixed MogreFramework and tutorial files which work fine with Mogre 1.6.4?

Beauty

30-11-2009 04:05:50

I can't start the compiled demo applications of the SVN.
There is a file load exception.

The demos of the binary installer I could start.
Has somebody an idea?
Are there some project changes?

Beauty

30-11-2009 04:13:37

The file ogre.cfg was in a binary directory of the installer.
But in the SVN it's gone.
Is there no need for this file or did we forget to add it?

kwertz

30-11-2009 19:27:38

No, I neither forgot BuildSamplesX64.cmd nor ogre.cfg. Ogre.cfg is dynamically created after you chose the engine configuration settings. BuildSamplesX64.cmd is not needed, because building 64-bit samples against 32-bit MOGRE is a bit weird, isn't it? :D So just forget about it. ;)

kwertz

30-11-2009 19:30:25

Now I found a solution for ExampleApplication.
It seems to be something like a framework for the other samples.
So we could rename it to ExampleApplicationFramework, which is better to understand.

Is this the same like the MogreFramework.dll which is used for the wiki tutorials?

If not, should we merge the content of both or use seperate dll files?
Later we want to include the tutorials.

The download of MogreFramework is here:
http://www.beauty-of-darkness.de/pub/Mo ... 009-01.rar
For use with Mogre 1.6 there are needed some little edits. Look here:
viewtopic.php?p=57660#p57660

Maybe somebody has a fixed MogreFramework and tutorial files which work fine with Mogre 1.6.4?


I would say, MOGRE Framework and ExampleApplication are almost the same. I would prefer to stick with ExampleApplication ...

kwertz

30-11-2009 19:39:35

wouldn't MOgre just get all this functionality when it gets wrapped to 1.7?

We will try to do so. ;)

But until then, it's a long and difficult way for us to go.

Especially the new demo system in OGRE Cthugha by Zi ‘omniter’ Ye (see http://www.ogre3d.org/2009/08/27/google-summer-of-code-2009-projects-coding-time-is-up) could be a bit tricky.

Also, we have to switch the license of MOGRE from LGPL to MIT (to be honest, I haven't read it yet), which may also cause some difficulties.

Nevertheless, we will try to do our best. :)

Beauty

30-11-2009 22:20:55

I asked Julio Jerez (the author of Newton) because of the permission to integrate the newton.dll file to the Mogre SDK (including public SVN).
It is allowed!
The old licence doesn't matter and Julio said we can do whatever we want with it.
Even we are allowed to clain it's from somebody else.

We can forget the old licence of Newton 1.x.
Here is the new "licence":

/* Copyright (c) <2009> <Newton Game Dynamics>
*
* This software is provided 'as-is', without any express or implied
* warranty. In no event will the authors be held liable for any damages
* arising from the use of this software.
*
* Permission is granted to anyone to use this software for any purpose,
* including commercial applications, and to alter it and redistribute it
* freely

*/


So I would say we add MogreNewt to the SDK :)

Beauty

01-12-2009 13:25:33

It would be nice if the installer reminds to update the driver of graphic card.
Additionally it should show links of related download pages.
The URLs of download pages for Nvidia / AMD / Intel I added to this section of the SDK wiki page.

Beauty

01-12-2009 13:30:32

In thread Miyagi 1.0 beta 4c - GUI I asked this:
The media files I would like to add to the MogreSDK.
Am I allowed to do so? I have no idea about the licences. Or if it's public domain.
Some things could be allowed only when adding an extra comment or licence file.
You'll need the F# CTP May 2009 release (I mentioned that in this thread, but forgot to add it to the readme).

You can add the media files, as long as you DON'T attribute me.

What do you think?
Should we add some/all media files to the SDK?
At least some of them are needed for a Miyagi GUI example.

Beauty

01-12-2009 17:36:24

I think it would be good to add help files in chm format.
* for Mogre
* for MogreNewt
(The SDK installer of the old Mogre 1.4.6 version contains such a file for the OGRE API Reference.)


Also we could add useful links to the program folder in the start menu:
* Mogre wiki site
* Mogre forum
* local help files (*.chm)
* OGRE Manual
* www.ogre3d.org
* Mogre Tutorials


The installer should offer the option to edit the
* installation path
* path of start menu (or make no entry)
If the installer still contains this options, please ignore this. (I don't remember these facts.)

Beauty

01-12-2009 17:50:56

In the misc directory I would add the current versions of
* MeshMagick.exe
* OgreMaterialUpgrade.exe
* OgreMeshUpgrade.exe
* OgreXmlConverter.exe

Aware to get the newest version.
Because the downloads in www.ogre3d.org/download/tools often are not up to date.

Or maybe add it to the path sdk_fs\bin?
This could be comfortable if the bin path is added to the system environment variable path.
On the other hand such a mix could be confusing.

kwertz

01-12-2009 20:27:35

Good idea. I would create a subfolder in 'sdk_fs/bin' for the command line tools and add this one to the system path variable.

In thread Miyagi 1.0 beta 4c - GUI I asked this:
The media files I would like to add to the MogreSDK.
Am I allowed to do so? I have no idea about the licences. Or if it's public domain.
Some things could be allowed only when adding an extra comment or licence file.
You'll need the F# CTP May 2009 release (I mentioned that in this thread, but forgot to add it to the readme).

You can add the media files, as long as you DON'T attribute me.

What do you think?
Should we add some/all media files to the SDK?
At least some of them are needed for a Miyagi GUI example.


Wait, you are about to add Miyagi to the SDK? I'm unsure if that's a good idea since it is still a beta unless I'm not mistaken. And I think we should not oversize the SDK.

koirat

01-12-2009 23:34:47

In my opinion size does not matter !!! :P.
Since it's not to be downloaded all the time.
I do not know about the server/transfer issues.
So one vote for Miyagi.

BTW. great work/idea with Mogre SDK.

AndroidAdam

02-12-2009 01:07:19

In my opinion size does not matter !!! :P.

BTW. great work/idea with Mogre SDK.


Size does matter. It affects download time as well as hard drive space. Watch it that you don't bloat the SDK. Either that or put up two SDKs, one just the Mogre basics and another that includes all of the extra utilities. Perhaps you can simply have links to the listed utilities.

Beauty

02-12-2009 05:25:01

Miyagi is in use for several months now and smiley80 gives support.
Also everybody is welcome to add an example of an other GUI system.
I think it would be a blame if we have no GUI example(s) in the SDK.
GUIs are common used.

Because of the size - if we could add only the needed files for the GUI then it's not so much.
Generally I think it's good for newcomers when they have several ressource files. So they don't have to search for some and can play with it.
Ok, maybe we should not add tons of ressources, but for the examples we should ignore the size when it's moderate.

When I compare to other needed software - just the service pack 1 for Visual Studio 2008 has 1000MB which are to download. The MSDN library has about 2GB size.
Well, for people with slow connection it's not nice. But they just need to download it one time. With ISDN or phone modem for 100MB you would need about 5 hours. That's ok, maybe one night downloading. (In bad case they have to pay money per minute. But then they generally have a bad internet life.)

Maybe we can offer 2 download packages:
* complete Mogre SDK (with installer)
* plain library files (just a zip/rar for well known developers/updaters)

kwertz

02-12-2009 14:54:11

Another idea: perhaps we could split the MOGRE SDK into two or more separate "packages". One contains the MOGRE base files and samples (the current SDK contents) and the other one additional things, such as Miyagi, MMOC etc.

kwertz

02-12-2009 15:01:18

I forgot: if there is anyone, who has a good idea for the SDK and therefore wants to join the project at Google Code, he/she should write a PM to me or to Beauty. Don't be shy! :D

Beauty

02-12-2009 21:55:42

Me again because of the help files in chm format.
The chm format is common for help files on Windows systems.
The souce is the xml file of a project (e.g. Mogre.xml, MogreNewt.xml) and you can create it by use of [b]Sandcastle[/b] and [b]SHFB[/b].

Beauty

02-12-2009 22:09:17

Another idea: perhaps we could split the MOGRE SDK into two or more separate "packages". One contains the MOGRE base files and samples (the current SDK contents) and the other one additional things, such as Miyagi, MMOC etc.
Currently there is not much more than the current SDK examples. Generally adding Miyagi isn't much space, but very useful.
Seperate SDKs with installer etc. would need more effort to create, update and test.
I would say, we just make one SDK and don't add big sized ressources which the examples doesn't need.

First point is to get a good and working SDK. After installation the demos should run without additional manual work (as needed for older MogreSDKs and descripted in tutorial 0).

Later we still can split the SDK.

kwertz

03-12-2009 19:25:00

Good news! I just finished coding the sample browser. You can get it from the latest SVN trunk, but don't forget to give feedback. ;)

kwertz

09-12-2009 14:10:37

I released the second version of the sample browser! It features multi-threaded configuration deserialization at start-up and some minor fixes.
As ever, you can either grab it from the latest SVN trunk or download the new SDK installer based on revision 19 (the current).

Have fun and give feedback! :)

Beauty

09-12-2009 14:13:24

just a quick note:
Nice would be an example with an imposing particle example.

Here are some infos:
http://www.ogre3d.org/wiki/index.php/ParticleFX_plugin
http://www.ogre3d.org/wiki/index.php/Pa ... ccelerator

smiley80

09-12-2009 14:20:34

viewtopic.php?f=8&t=10133&start=0

hedphelym

11-12-2009 19:32:38

hi, thanks for all the effort put into this sdk.

I downloaded the sdk, installed in default location, also downloaded "additional samples", unpacked it.
Everything compiled and worked straight away!

Awesome!

Beauty

16-12-2009 20:59:20

hedphelym, can you write us some information about your operation system?
e.g. WinXP/Vista/7, 32/64 bit
DirectX / OpenGL ...Did you test both?
Which graphic card you have?
Just for curious information :wink:

hedphelym

16-12-2009 21:06:18

CPU: AMD Athlon 64x2 Dual Core Processor 4600+ 2.40 Ghz
RAM: 8GB
OS: Windows 7 x64 professional
GPU: Geforce GTS 250
(Tested Direct3D only.)

Dev.Enviroment: Visualstudio 2008 SP1 incl all updates.

Beauty

21-12-2009 14:40:33

For the installer script I added an info page. It will be shown after installation and contains (clickable) download links for the depencies.

To improve the depency checker, I tried out the dotNetInstaller.
But with it I see a problem: The country language of the choosed dotNet installer is fixed.
So the user can't choose his own language.
And I thinks it's no good idea for a German (or other) user to install the english version of .NET.
http://dotnetinstaller.codeplex.com
Maybe it's possible with the bootstrapper to show a language dialog, but I didn't found out.

Related to the depencies - does the end user needs SP1 or SP2 for the .NET 2.0 framework?
Or is is ok to just have the .NET framework without service pack?


Here I found a code snippet for .NET detection by Inno Setup.
Maybe we can modify / use it for our installer script.
http://www.vincenzo.net/isxkb/index.php ... _framework

More information about .NET detection is here:
http://support.microsoft.com/?scid=kb%3 ... 1&x=7&y=11

Good would be a check like this:

Check if .NET 2.0 is installed
... if not, show window:
MOGRE needs .NET 2.0, but it's not installed.
Click OK to open the download page.
Choose your language, download the file and run (install) it manually.
[OK] [Cancel]


Check if DirectX is installed
... if not, show window:
MOGRE needs DirectX, but it's not installed.
Click OK to open the download page.
Choose your language, download the file and run (install) it manually.
[OK] [Cancel]

... if DirectX is still installed, check if it's up to date
...... if not, show window:
DirectX is installed, but needs an update.
Click OK to open the download page.
Choose your language, download the file and run (install) it manually.
[OK] [Cancel]


Additionally we could add checks for
* Service Pack 1 for Visual Studio 2008 (if VS 2008 is installed)
* VC++ 2008 SP1 Redist (if VS 2008 is not installed)

Beauty

21-12-2009 15:22:45

The .NET Framework 1.1/2.0/3.5 Installer for InnoSetup is also interesting.
There seems to be a solution for different languages.
In file scripts\products\dotnetfx20sp1lp.iss is a language check, but I'm not shure if the detection is automatic or if all wanted languages has to be included to the installer script.

http://www.codeproject.com/KB/install/d ... nstal.aspx

Also I think this project is a good example how we could do it with the other Mogre depencies.

By the way - if somebody has a 64 bit windows - I suppose we have to download/install a different .NET file. Is it right?

kwertz

23-12-2009 17:58:43

If you download and execute the .NET Framework web installer, the right assemblies are installed automatically. That is, if you have a 64-bit Windows, the 64-bit assemblies are downloaded, installed and NGEN'ed. If you have a 32-bit Windows, the 32-bit assemblies are downloaded.

Beauty

23-12-2009 18:41:11

In the .NET Framework 1.1/2.0/3.5 Installer for InnoSetup is no option for the web installer. When you set up a configuration for the installer you have to choose between explicite packages. (e.g. .NET 2.0 for x86 in english)
For this I tried the wizzard. Without wizzard I didn't found out how to do.
(Maybe we should read the related comments on codeproject.com.)

Maybe we should include the web installers for .NET and DirectX into the SDK package?
Web installers have small size. And if the depencies are still installed I suppose the web installers will tell, that all is fine.

smiley80

26-12-2009 13:01:28


The MOIS.dll file
of bin/Debug has 350 KB
and in bin/Release it has 500 KB

The smaller one seems to be from an older release and doesn't statically link ois.
And if it can't find ois.dll somewhere, you'll get this.

Beauty

26-12-2009 22:24:50

Thanks for the note.
I did remove OIS.dll from the SDK, because I read that it's not longer needed.
I searched for the string ois.dll in the debug/release versions of MOIS.dll. Then I saw that you are right.
MOIS I don't like to compile myself (because of my bad C++ knowledge and problems in the past).
Maybe someone can update the MOIS SVN? So that mois.dll contains ois.dll by default project settings?
Also I would like to add these dll versions to the SDK. (Especially the Debug version)

I could add the release version to the debug directory, but somewhere you wrote, that this can cause problems.
So I would like to make it correct.

Beauty

27-12-2009 12:41:09

I improved the installer script a little bit.
The SDK isn't rebuild, check the SVN.

What does this line of installer script?
[Run]
Filename: {win}\Microsoft.NET\Framework\v2.0.50727\ngen.exe; Parameters: "install ""{app}\bin\Release\browser.exe"""; WorkingDir: {app}; StatusMsg: Optimizing performance for your system ...; Flags: runhidden


Maybe we could add a task to the installer to run build.cmd?
Good would be to ask the user if he want to do it?
The installation of Mogre SDK is ready.
Now the installer tries to compile the samples.
[OK] [Cancel]

By the way - will this work when the user didn't install the depencies?

GantZ

27-12-2009 17:00:15

Maybe someone can update the MOIS SVN? So that mois.dll contains ois.dll by default project settings?

i will check that, i was assuming that the project properties of mois already allow ois to be statically linked with mois. by your account, it's not the case. it should n' t be too long to change.

[EDIT]
i have upload to svn the updated project file for mois :) . if you prefer, i can also upload the dll along with the pdb (debug and release) here.

Beauty

29-12-2009 16:43:08

This would be nice. Then I can include it to the Mogre SDK.
Maybe it could be needful to add a bin directory to the MOIS SVN.
Then we could add a direct download link from the wiki.
Often such download links are on private websites and unfortunalely after longer time many links get dead.

By the way: With the new wiki (TikiWiki) it's possible to attach files to a page.
Then we can add the compiled files there. A great thing!

GantZ and Smiley80 - you both are very helpful to the (small) Mogre community.
If you like, you can get access to the SVN of the Mogre SDK.
This would be more easy to update its libraries (in directory trunk/sdk_fs/bin).
Just write a pm to kwertz.

GantZ

29-12-2009 19:25:37

well, rather than adding a bin directory to the MOIS svn, i think it's better that i commit MOIS dll directly to the MogreSDK svn like you say. on a more general way, it's better to keep the Mogre repository to store source files only and to use the mogreSDK one to store the compiled libraries. i will pm kwertz to get an access to the MogreSDK svn.

GantZ

30-12-2009 18:19:52

i have just upload mois .dll's to the mogresdk svn :)

i would also like to add the pdb files from mogre, ogremain and mois. a lot of users seem to be interested in this. but something bug me, since it quite a huge upload (more than 100 Mo), i don't know if it's better to send them raw or compress it (i gain around 75% in size when compress with 7z).

Having it raw would be convenient, but perhaps it's possible to decompress it when building the sdk.

Beauty

02-01-2010 18:02:42

I think it's possible to decompress libraries automaticly by running the installer script.
We can add a post task to decompress 7zip or rar files which are in binary directories.
So you just need to upload the compressed files and when somebody installs the MogreSDK the files are all decompressed.

GantZ

03-01-2010 19:06:45

ok, i will upload the pdb compressed then (my connection will thank me for this one :)). i will upload it with the new 1.6.5 binaries (should be ready soon)

kwertz

05-01-2010 13:39:43

Look here for the new SDK release.

Bekas

08-01-2010 11:05:13

Hey, great work on the Mogre SDK project!

Any thoughts on merging the effort into the main Mogre project ?
If this is to become the "official" Mogre SDK it will be confusing to have it on a separate project outside of the main one.

It can be its own sub-tree, like MogreNewt, so people that are only interested in the source do not have to svn checkout anything from it (and inversely people only interested in the SDK, examples etc. can only checkout the SDK sub-tree)

Thoughts ?

kwertz

09-01-2010 00:06:57

Wouldn't be bad... but a separate project is easier to manage, don't you think?
I can't decide... merging with the main project means abandoning the GC SDK project.
GantZ, Beauty, what do you think?

GantZ

10-01-2010 18:06:26

here an extract of a mail i send to bekas about this :

i think that we could keep the current mogre svn as the source svn (where all the source code for mogre along with the source of the supported addons reside) and have a specific svn for the sdk (with exemples source code, installation script and the latest binary and lib). the mogre svn already got a lot of things in it. and the sdk need that we have media files in the svn for building it, this is not necessary for the mogre source.

also, i think that people who could contribute to examples in the sdk haven't usually the need to get the mogre source (mainly, they are people who don't use c++ or c++/cli).

still, i could upload the final version on sourceforge as the official SDK release (to avoid confusing people who just download the sdk)


in fact, i'm afraid that there is already too much things on the mogre svn. and the goal of the sdk project is to provide more than just mogre but also mogre addons with examples.

i also think that we need someone active as the project manager of mogre on sourceforge. currently, i'm just labeled as a developper, and there is no one who could give rights to the svn of mogre. we could still pm bekas, but it would be good to have someone else that have full rights on the project.

in short, i'm not against the separated project thing. also, i think it's confusing for the revision number on svn. you don't know if the sdk , the source or and addons have been updated.

Bekas

11-01-2010 09:28:06

i also think that we need someone active as the project manager of mogre on sourceforge. currently, i'm just labeled as a developper, and there is no one who could give rights to the svn of mogre. we could still pm bekas, but it would be good to have someone else that have full rights on the project.
Oops, fixed that :wink: (made you project manager of Mogre, great conversation starter for hitting on girls).

in short, i'm not against the separated project thing. also, i think it's confusing for the revision number on svn. you don't know if the sdk , the source or and addons have been updated.
I offered for discussion merging the projects mostly for the purpose of "tying" them more together, so that they are maintained together.
e.g the "ideal" patch to Mogre would also make sure that the SDK examples can at least still compile.

If you guys think it will create more headaches than benefits then separate projects may be better.

GantZ

11-01-2010 11:03:53

Oops, fixed that :wink: (made you project manager of Mogre, great conversation starter for hitting on girls).

thanks for that :)


e.g the "ideal" patch to Mogre would also make sure that the SDK examples can at least still compile.

we could keep the example of mogre (and mogre only, not the addons) on the mogre svn, so that we can add example compilation stage on a batch build file after mogre build to check error.

also, i liked the fact that you have removed the generated source code from the svn, i think it was unnecessary to keep it since it's generated anyway. that's why i'm reluctant to add back binary files, pdb and all the includes stuff in the mogre svn.

Bekas

11-01-2010 11:37:34

also, i liked the fact that you have removed the generated source code from the svn, i think it was unnecessary to keep it since it's generated anyway. that's why i'm reluctant to add back binary files, pdb and all the includes stuff in the mogre svn.
I admit I haven't looked much into the SDK project, why is there a need to add these stuff to SVN, can't the SDK project comprise of source and script files, and have everything else generated using a script/batch process ?

Bekas

11-01-2010 11:45:19

Even without a scripted process to produce everything automatically, the SDK project can still assume to get the binaries, pdb files, etc, from the Mogre sub-directory, right ?

GantZ

11-01-2010 15:35:08

well, i think it simplify the process of building the sdk. building mogre could be quite long, even when you use a batch script. so i assume it have been made this way so that people working on the sdk don't have to worry about this step.

after some though, i think that the sdk location depend of what we want to put in it. if it's just to have some samples and the binary and lib like it was before with some enhancement then it's fine to keep it with mogre source. but if we want to expand it and add other addons like mhydrax, some gui library and more content. (like in python-ogre sdk for example) it could be better to have a separate svn for this.

Bekas

11-01-2010 19:14:24

after some though, i think that the sdk location depend of what we want to put in it. if it's just to have some samples and the binary and lib like it was before with some enhancement then it's fine to keep it with mogre source. but if we want to expand it and add other addons like mhydrax, some gui library and more content. (like in python-ogre sdk for example) it could be better to have a separate svn for this.
Good point, I'm not particularly fond of sticking everything into the mogre svn, so maybe the separate SDK project can be a central hub for the addons ?

Beauty

12-01-2010 13:19:25

Look here for the new SDK release.

The installer offers to optionally download some debug files.
This I tried and something was downloaded.
But in the SDK directories I didn't found it. (And also no *.7z file.)
Maybe there is a bug in the installer script?

A dialog with 3 options (I think: yes, no, abort) was a little bit confusing.
(Related to .Net installation?? I don't remember right.)
This dialog could be improved.

Also there was a problem with the sample browser.
This also could be improved.
(I know, it's only on early state. Sorry that I didn't help for this. I have a time and laziness problem.)

I also recognized that newcomers have problems with the outdated tutorials, especially basic tutorial 0.
One problem is the outdated file MogreFramework.dll.
For backward compatibility to the tutorials we could add this file to the SDK (compiled to the right Mogre version) and additionally we could offer a download link for it.
More information about I wrote here:
viewtopic.php?f=8&t=11918


Any thoughts on merging the effort into the main Mogre project ?
If this is to become the "official" Mogre SDK it will be confusing to have it on a separate project outside of the main one.


Hi Bekas, nice to see you :D
Yes, you can say this is the "official" MogreSDK now.
We want to make easy the life of newcomers.
When they have only troubles on their start, then they will go away instead of (maybe) merge to our small(?) Mogre community.

In general you are right. It would be good to have everything on one place.
For me it doesn't matter if we manage our SDK files at google or sourceforge.
My main intension was just to create a public SVN place for it.
The current Mogre SVN seems to be a little bit untidy (for me, but I'm not often in there).
Maybe this could be changed.

Wouldn't be bad... but a separate project is easier to manage, don't you think?
Related to the source code it would be just an other subtree.
Maybe offering download files (especially binary) has a less better overview?
I don't know so much about.


also, i think it's confusing for the revision number on svn. you don't know if the sdk , the source or and addons have been updated.
This is an interesting point. Not so important, but better for the log overview.


e.g the "ideal" patch to Mogre would also make sure that the SDK examples can at least still compile.
we could keep the example of mogre (and mogre only, not the addons) on the mogre svn, so that we can add example compilation stage on a batch build file after mogre build to check error.

On the one hand an automatic compile check of the Mogre samples would be useful.
On the other hand I think it's not so nice when we have samples in the SDK SVN and other samples in the Mogre SVN.
I think it's good to have all samples in one SVN (in the SDK SVN when we keep it).
Redundant code of samples in both SVNs would be confusing and bad for updates etc.


why is there a need to add these stuff to SVN
Binary files in an SVN are nice as optionally downloads.
One more point:
I never build Mogre from souce. It always was a pain for me to compile C++ stuff, because I have no C++ knowledge and don't know how to solve the problems.
When I update/inprove the MogreSDK, I'm happy that I can include the ready compiled binary files (that are uploaded by others).
Also we don't need to rebuild Mogre binaries when we make changes in the SDK.
So I think it's a good idea to keep them.
(This is just my personal opinion.)


maybe the separate SDK project can be a central hub for the addons ?
My intension is to add the binaries of all important Mogre add-ons to the SDK (and it's SVN).
Also every add-on should have example application.
When somebody installes the SDK he should see our Gui systems, MHydrax etc. by the example applications.
This demonstrates the possibilities and the users can look to the source code how it's done.

In the past I often had to search for binary files, example code, needed ressource files. Also I had problems with different versions.
For example you can't run a GUI example code (e.g. from the wiki) when you don't have the material files.
In some wiki pages the files are linked, but sometimes they are dead, because they were uploaded just on a personal website or a limited file hoster.
So it would be good when newcomers have everything important in the SDK.

kwertz

12-01-2010 14:44:06

I agree to what Beauty wrote. MOGRE should run without any demotivating errors, because otherwise people will throw MOGRE off their hard disks.

I also recognized that newcomers have problems with the outdated tutorials, especially basic tutorial 0.
One problem is the outdated file MogreFramework.dll.
For backward compatibility to the tutorials we could add this file to the SDK (compiled to the right Mogre version) and additionally we could offer a download link for it.
More information about I wrote here:
viewtopic.php?f=8&t=11918


No, I don't think so. You can use ExampleApplication.dll for that purpose. It provides similar functionality.


The installer offers to optionally download some debug files.
This I tried and something was downloaded.
But in the SDK directories I didn't found it. (And also no *.7z file.)
Maybe there is a bug in the installer script?


It's not a bug - it's a feature! ^^ :D
The install process for the pdb files is the following:
  1. At first, the 7z files containing the pdb ones, 7z.exe (7-zip command line tool) and 7z.dll are downloaded to a temporary directory[/*:m]
  2. Then, after the actual SDK has been installed, 7z.exe is called to extract the pdb files (~ 260 MB. Quite large, aren't they?)[/*:m]
  3. Finally, the temporary directory is deleted[/*:m][/list:u]

    Also there was a problem with the sample browser.
    This also could be improved.


    Could you explain that to me? I don't know of what sort of problem you are talking about...

    A dialog with 3 options (I think: yes, no, abort) was a little bit confusing.
    (Related to .Net installation?? I don't remember right.)
    This dialog could be improved.


    I don't remember right.
    You probably don't remember it right, because you didn't read it right. ;)
    But I admit it's a bit confusing indeed. :D

Beauty

12-01-2010 16:09:12

I added the MogreFramework to the SDK SVN.

Now it can be updated in a comfortable way:
Added MogreFramework
* location is in directory "misc"
* linked to sdk_fs\bin\Release\Mogre.dll
* binary output is sdk_fs\bin\...
* added MogreFramework.dll to sdk_fs\bin\...
* added ressource files to OgreHead.ico and splash.jpg to media directory
. . . . . (if they are needed, then they can be found by the default resources.cfg file of SDK)
* the updated MogreFramework was NOT TESTED with tutorial files
--> just compile the MogreFramework project and the binaries of the SDK will be updated to the current Mogre version (you don't need to copy files manually)
--> don't forget to compile in Debug AND Release mode


Changes in MogreFramework:
* disabled local copy for linked file Mogre.dll (don't copy/overwrite it to sdk_fs/bin/...)
* disabled debugging information for debug mode (don't create pdb files in sdk_fs/bin/...)
--> only the file MogreFramework.dll will be written to directory sdk_fs/bin/...


Maybe the target plattform has to be changed from Any CPU to x86 to work with 64bit Windows?
For debug gode I disabled the debugging information to avoid creation of MogreFramework.pdb in the binary directory of SDK. I hope this is ok.
(What happens when there is an exception? Will the user get a helping information, e.g. the related method name?)

Beauty

12-01-2010 17:00:16

No, I don't think so. You can use ExampleApplication.dll for that purpose. It provides similar functionality
Right, but the problem is that many users doesn't know.
I suppose many newcomers try the Mogre basic tutorials, especially the tutorial 0.
Currently they aren't updated and there is written, the users need the MogreFramework.

My opinion: As long as there is at least one tutorial in the wiki which needs the MogreFramework as depency we should add it to the SDK.
I hope somebody will check and update the tutorials (in the new wiki (TikiWiki), not in the old one (MediaWiki)!).
When they are all updated and use ExampleApplication.dll instead of MogreFramework.dll then we can remove it from the SDK.

By the way - I still added the MogreFramework to the SVN.
Your answer I read later.


Then, after the actual SDK has been installed, 7z.exe is called to extract the pdb files (~ 260 MB. Quite large, aren't they?)
I tested the option and the installer downloaded the file, but on my computer is no Mogre.pdb file. (only 2 very old ones)
So maybe the installer just deleted the temporary files and didn't copy it to the SDK directory.


Could you explain that to me? I don't know of what sort of problem you are talking about...
I don't remember the details. It was no error, it was the usability.
Maybe I read the short description and when I wanted to start, the application did exit.
Something like that.
One day I want to check it again and tell you details. Or I improve it by self doing.

Beauty

12-01-2010 17:04:23

Related to the depency checker and build sample dialog:

You probably don't remember it right, because you didn't read it right. ;)
But I admit it's a bit confusing indeed. :D

I did read the dialog text about 3 times to understand what's the difference of clicking a button.
Something was unclear.

...
Now I did run the SDK installer again. The confusing user promt is this:
Your system configuration passed all checks. Do you want to build the samples now?
In order to build the samples, you have to install the .NET Framework 3.5 because of MSBuild.

Click on 'Yes' to do this. In case you don't want to do it now because you already installed it and want to build the samples, click on 'No'.
If you neither want to install the .NET Framework 3.5 nor want to build the samples, click on 'Cancel'."


Click on 'Yes' to do this.
What does it mean? Build samples or install .NET 3.5 or both?
This was my main confusing question.
Now I know, but it's realy no nice dialog.
(I don't hit you by telling this - I just give feedback and try to improve your basically good installer work.)

I don't know what's MSBuild. Maybe other user doesn't know it, too.
So we could add it in brackets or just remove it from the text.

After searching in the installer script file I found this text in the application checker (application.cpp).
So it would be possible to improve the style "question".
Or maybe make seperate dialogs.

Here is my proposal:

Your system configuration passed all checks.

Do you want to build the samples now?

When the user clicks yes, then check if .NET 3.5 is still installed.
If .NET is not installed then show the next dialog:

In order to build the samples, you need the .NET Framework 3.5 (needed for MSBuild).
But it's currently not installed.

Do you want to install the .NET Framework 3.5?
[OK] [Abort]


If the user clicks abort, then show this information:

The Mogre samples are not build.
But you can do it later manually.

smiley80

12-01-2010 18:16:31

As long as the samples don't use any C# 3.0 features, you can build them with .net 2.0.
Just make a copy of the solution file, change its version to 9.00 and use that to build the samples.

Btw. it seems that CleanSamples runs for the debug config, while BuildSamples uses the release config.

Beauty

12-01-2010 18:28:24

Yes, it would be nice when the samples are configured to .NET 2.0.
So we don't need the confusing dialog.
If a sample uses a .NET 3.x feature, I suppose we can find a way to do the same with 2.0.

GantZ

12-01-2010 19:30:16



maybe the separate SDK project can be a central hub for the addons ?

My intension is to add the binaries of all important Mogre add-ons to the SDK (and it's SVN).
Also every add-on should have example application.
When somebody installes the SDK he should see our Gui systems, MHydrax etc. by the example applications.
This demonstrates the possibilities and the users can look to the source code how it's done.


I also think that the aim of this SDK is clearly to offer more content that the previous one in the addons area. in a way, having something like the python-ogre sdk would be good. but in this case, it will start to grow quite a lot, so having a separate svn for this is better.

also, even if i'm on the sdk project, the people involved in the sdk and mogre source are not the same. i do more work on the source code while kwertz and beauty work on the sdk. even if i help to add content to the sdk, i will probably concentrate on mogre source (and addons) rather than on the SDK.

i still think that the mogre svn should keep source only (without samples that get relocated on the sdk svn) and sdk centralize example source code, documentation, binary and lib of the project, what do you think ?

kwertz

14-01-2010 16:46:54


I did read the dialog text about 3 times to understand what's the difference of clicking a button.
Something was unclear.

The problem why I wrote such a weird dialog is that I don't know how to check for .NET 3.5 properly. :lol:
I will improve that.
But Beauty, if you have a bit of C++ knowledge and Win32 API, you are allowed to do it also. It's a community project.
And if anyone else is willing to contribute to the SDK, he/she should write a PM to me. I'm always happy about newcomers. :)

Btw. it seems that CleanSamples runs for the debug config, while BuildSamples uses the release config.
Oops, that was unintended! :oops:
Let me fix that!
EDIT: Done! ;)

BTW, I'm currently developing a fake HDR compositor for MOGRE based on this article: http://www.ogre3d.org/wiki/index.php/Faking_HDR.
The GPU programs (shaders) will be ported to Cg so that either OpenGL or Direct3D can be used.
I prefer fake HDR because it makes HDR-ish effects possible on non 64-bit cards (or 48-bit???) and is more graphically stunning, I think.
I think of creating an example for the SDK from it.
If anyone wants to proof-read the Cg code I already wrote, here you can download it: http://l4nm4n.users.sourceforge.net/skyblue/data/uploads/fakehdr_programs.zip.

Beauty

14-01-2010 23:34:24

The problem why I wrote such a weird dialog is that I don't know how to check for .NET 3.5 properly.
I saw it some weeks ago on a website. (Related to the .NET 2.0 query.)
Now I searched for 15 minutes, but can't find the page again.
It was a registry check for a unique key/value.
Maybe on microsoft.com.
Sorry, I don't find it.

But Beauty, if you have a bit of C++ knowledge and Win32 API, you are allowed to do it also. It's a community project.
I have very less knowledge about C++ and no idea about Win32 API.
So I can't help in this case.

kwertz

15-01-2010 18:38:48

I saw it some weeks ago on a website. (Related to the .NET 2.0 query.)
Now I searched for 15 minutes, but can't find the page again.
It was a registry check for a unique key/value.
Maybe on microsoft.com.
Sorry, I don't find it.

Okay, thank you anyways. I will try to accomplish that myself this weekend.


I have very less knowledge about C++ and no idea about Win32 API.
So I can't help in this case.

Also okay. I didn't want to command you. That was just a proposal. I didn't know that you aren't good at it.

Bekas

15-01-2010 23:05:59

e.g the "ideal" patch to Mogre would also make sure that the SDK examples can at least still compile.
we could keep the example of mogre (and mogre only, not the addons) on the mogre svn, so that we can add example compilation stage on a batch build file after mogre build to check error.

On the one hand an automatic compile check of the Mogre samples would be useful.
On the other hand I think it's not so nice when we have samples in the SDK SVN and other samples in the Mogre SVN.
I think it's good to have all samples in one SVN (in the SDK SVN when we keep it).
Redundant code of samples in both SVNs would be confusing and bad for updates etc.

Very true, but no samples in Mogre's SVN seems unpractical. One needs to test changes and features of Mogre, you need samples for that. And going over to the separate Mogre SDK project for testing changes in Mogre's SVN is inconvenient.

why is there a need to add these stuff to SVN
Binary files in an SVN are nice as optionally downloads.
One more point:
I never build Mogre from souce. It always was a pain for me to compile C++ stuff, because I have no C++ knowledge and don't know how to solve the problems.
When I update/inprove the MogreSDK, I'm happy that I can include the ready compiled binary files (that are uploaded by others).
Also we don't need to rebuild Mogre binaries when we make changes in the SDK.
So I think it's a good idea to keep them.
(This is just my personal opinion.)

I think this can be easily fixed without having to upload the binaries on SVN; how about if the Mogre SDK project was based on binaries that sourceforge Mogre released (e.g. in a simple 7z form). A script could just download the binaries and unpack them (in order to have Mogre SDK ready for compilation).

kwertz

17-01-2010 12:58:23

I think I'll need to code a SDK maintenance tool (for building the SDK directly from the binaries etc.) ;)

Anyways, I completed to create a dynamic cube mapping example for MOGRE.
Here is the code of the DynamicCubeMapper class (works like a charm, I get around ~900 fps!):


using System;
using System.Runtime.InteropServices;

namespace Mogre.DynamicCubeMapping
{
class DynamicCubeMapper
{
private SceneManager _sceneManager;
private readonly Camera _cubeCamera;
private readonly RenderTarget[] _targets = new RenderTarget[6];
private readonly Entity[] _entitiesToExclude;

public DynamicCubeMapper(SceneManager sceneManager, params Entity[] entitiesToExclude)
{
if (sceneManager == null) throw new ArgumentNullException("sceneManager");

TestGpuCapabilities(Root.Singleton.RenderSystem.Capabilities);

_sceneManager = sceneManager;
_entitiesToExclude = entitiesToExclude;

// Create the camera used to render to our cubemap
_cubeCamera = sceneManager.CreateCamera("CubeMappingCamera");
_cubeCamera.FOVy = new Degree(90);
_cubeCamera.AspectRatio = 1;
_cubeCamera.SetFixedYawAxis(false);
_cubeCamera.NearClipDistance = 5;

// Create our dynamic cube map texture
var dynTexture = TextureManager.Singleton.CreateManual("DynCubeMap",
ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME,
TextureType.TEX_TYPE_CUBE_MAP, 128, 128, 0,
PixelFormat.PF_R8G8B8,
(int) TextureUsage.TU_RENDERTARGET);

// Assign our camera to all 6 render targets of the texture (1 for each direction)
for (uint i = 0; i < 6; i++)
{
_targets[i] = dynTexture.GetBuffer(i).GetRenderTarget();
var vp = _targets[i].AddViewport(_cubeCamera);
vp.OverlaysEnabled = false;

_targets[i].PreRenderTargetUpdate += PreRenderTargetUpdate;
_targets[i].PostRenderTargetUpdate += PostRenderTargetUpdate;

_targets[i].IsAutoUpdated = false;
}

Root.Singleton.FrameStarted += FrameStarted;
Root.Singleton.FrameEnded += FrameEnded;

Enabled = true;
//Root.Singleton.FrameRenderingQueued += FrameRenderingQueued;
}

bool FrameEnded(FrameEvent evt)
{
// For testing the output
//_targets[0].WriteContentsToFile("face1.png");
//_targets[1].WriteContentsToFile("face2.png");
//_targets[2].WriteContentsToFile("face3.png");
//_targets[3].WriteContentsToFile("face4.png");
//_targets[4].WriteContentsToFile("face5.png");
//_targets[5].WriteContentsToFile("face6.png");
return true;
}

public event EventHandler<UpdateEventArgs> PreUpdate;
public event EventHandler<UpdateEventArgs> PostUpdate;
public class UpdateEventArgs : EventArgs
{
public UpdateEventArgs(Camera cubeCamera)
{
CubeCamera = cubeCamera;
}

public Camera CubeCamera { get; private set; }
}

private int _thisFrame;
bool FrameStarted(FrameEvent evt)
{
if (_thisFrame != _updateInterval)
_thisFrame++;
else
_thisFrame = 1;

if (_thisFrame % _updateInterval == 0 && Enabled)
foreach (var target in _targets)
target.Update();

return true;
}

private int _updateInterval = 1;
public int UpdateInterval
{
get
{
return _updateInterval;
}
set
{
if (value <= 0) throw new ArgumentOutOfRangeException("value");

_updateInterval = value;
}
}

public bool Enabled { get; set; }

~DynamicCubeMapper()
{
if (TextureManager.Singleton != null)
TextureManager.Singleton.Remove("DynCubeMap");
}

static void TestGpuCapabilities(RenderSystemCapabilities capabilities)
{
if (!capabilities.HasCapability(Capabilities.RSC_CUBEMAPPING))
throw new NotSupportedException(
"Your graphics card does not support cube mapping, so you cannot run this application. Sorry!");
}

void PostRenderTargetUpdate(RenderTargetEvent_NativePtr evt)
{
if (evt.source == _targets[5] && PostUpdate != null) PostUpdate(this, new UpdateEventArgs(_cubeCamera));

foreach (var entity in _entitiesToExclude)
entity.Visible = true;
}

void PreRenderTargetUpdate(RenderTargetEvent_NativePtr evt)
{
if (evt.source == _targets[0] && PreUpdate != null) PreUpdate(this, new UpdateEventArgs(_cubeCamera));

// Hide the given entities (characters etc.)
foreach (var entity in _entitiesToExclude)
entity.Visible = false;

// Point the camera in the right direction based on which face of the cubemap this is
_cubeCamera.Orientation = Quaternion.IDENTITY;

if (evt.source == _targets[0]) _cubeCamera.Yaw(new Degree(-90));
else if (evt.source == _targets[1]) _cubeCamera.Yaw(new Degree(90));
else if (evt.source == _targets[2]) _cubeCamera.Pitch(new Degree(90));
else if (evt.source == _targets[3]) _cubeCamera.Pitch(new Degree(-90));
//else if (evt.source == _targets[4]) _cubeCamera.Yaw(new Degree(-180));
else if (evt.source == _targets[5]) _cubeCamera.Yaw(new Degree(180));
}
}
}


You can download the entire demo here: http://l4nm4n.users.sourceforge.net/skyblue/data/uploads/mogre_dynamiccubemapping.zip. To use it, you have to choose the OpenGL Rendering Subsystem, because the shader for the refracting object (the object to which the cubemap is applied) is written in GLSL.

Do you think it would fit into the SDK?

Also, I managed to improve the dependency checker. Have a look at it (get it here)!

Beauty

17-01-2010 15:42:44

Also, I managed to improve the dependency checker. Have a look at it (get it here)!
Good - you found out how to check for .NET 3.5 :D


When .NET 3.5 is not installed there comes this message:
The .NET Framework 3.5 required to run MOGRE could not be found.
Do you want to download it?
I changed the text to:
MOGRE needs at least the .NET Framework 2.0.
But for automatically build of the MOGRE samples you need .NET 3.5.
Do you want to download the .NET Framework 3.5 now?



Also I changed this text:
DirectX 9.0c, which is required to run MOGRE, could not be found.
Do you want to download it?
to
DirectX is outdated or not installed.
For MOGRE you need at least DirectX 9.0c of March 2009.
Do you want to download the latest revision of DirectX 9.0c?



And this
The Microsoft Visual C++ 2008 SP1 runtime required to run MOGRE could not be found.
Do you want to download it?
to
It's recommended to install the "Microsoft Visual C++ 2008 SP1 Redistributable Package".
Do you want to download it?



And some more tiny text edits.
The source I committed to SVN.


But I have a problem C++. (I hate all the damn C++ problems.)
The compiler doesn't accept my concatenated strings.
MessageBox(NULL, "MOGRE needs at least the .NET Framework 2.0.\n"
+ "But for automatically build of the MOGRE samples you need .NET 3.5.\n"
+ "Do you want to download the .NET Framework 3.5 now?",
"Dependency missing", MB_YESNO | MB_ICONQUESTION)

Also using new String("..." + "...") doesn't work.
Are there ideas how to concatenate the strings?



Will the downloaded depencies be installed automaticly after download?
(I suppose no.)

Beauty

17-01-2010 15:49:10

Anyways, I completed to create a dynamic cube mapping example for MOGRE.
Here is the code of the DynamicCubeMapper class (works like a charm, I get around ~900 fps!):

Nice to have one more example :D
Additionally we could add as Mogre snippit to the (new) wiki.


~DynamicCubeMapper()
{
if (TextureManager.Singleton != null)
TextureManager.Singleton.Remove("DynCubeMap");
}

I never saw a ~destructor in C# applications.
I just know to use .Dispose() methods for this.
Is there a need or advantage for it?

update:
Great demo!
It's a fantastic 360° x 360° view :shock:
Like an interactive panorama picture.
This would be a good addition to the samples.

Beauty

17-01-2010 16:36:54

3 times I started the DynamicCubeMapper demo.
2 times the application freezed, when I pushed Esc to exit.
Alt+Tab didn't work.
Only by pushing Strg+Shift+Esc I could open the Task Manager and then kill the application.
People who doesn't know this shortcut needs to power of the computer.
They will not like it.
Maybe I can debug the application if this problem don't happen on your computer.


Also I improved the images files. So they are not so dark.
Here is the download (image files only):
Mogre_DynamicCubeMapping__media_brighter2+contrast.rar
Better would be to brighter the original media files by a HDR photo editor.

By the way - we should not hitchhike this thread.
When there comes more talk about I'll move the related posts to a new thread.
Now I can do this, because I got a moderator in the Mogre forum 8)

Beauty

17-01-2010 17:12:13

I think this can be easily fixed without having to upload the binaries on SVN; how about if the Mogre SDK project was based on binaries that sourceforge Mogre released (e.g. in a simple 7z form). A script could just download the binaries and unpack them (in order to have Mogre SDK ready for compilation).
So you don't have to upload the binary itself, but an archive file which contains it :lol:

Advantage of compressing would be to reduce the upload time.
So there is still a need to upload the binary files, it could be updated directly to the SDK SVN.
The SDK installer script needs the binary, the Mogre SVN doesn't need it. So the SDK SVN would be a good place.
On the other hand - for people who compile Mogre it would be more easy to just update them by SVN to the Mogre SVN.

So again - we will see how we will manage it :wink:

Beauty

17-01-2010 17:59:14

Very true, but no samples in Mogre's SVN seems unpractical. One needs to test changes and features of Mogre, you need samples for that. And going over to the separate Mogre SDK project for testing changes in Mogre's SVN is inconvenient.
A good point. So it's better to leave the basic samples in the Mogre SVN.
We will see which way we solve this problem.

Maybe we can write/add a command line tool to the SDK SVN, which updates the files from Mogre SVN.
On the other hand there could be problems when using SVN inside of an other SVN managed directory.
I don't know if there are options for the SVN commandline which forbid to create a local database in .SVN directory. (I mean an option to "just download" from the Mogre SVN.)
Also we would add a big notice to the related directories in SDK SVN (e.g. "don't edit files, do it in Mogre SVN").
The result would be redundant files, but better to manage updates.

Or after downloading the files from Mogre SVN we add them to an archive file (e.g. 7zip).
Then the temporarily saved souce files will be deletet.
The installer script includes the archive file and when the end user installs the SDK the sample archive will be extrackted.

This sounds a little bit complicated, but it's just an idea.

kwertz

18-01-2010 12:31:27

Beauty, I understand that you don't like C++. ;) Me neither, but for writing little programs and hacks, it is very practical and the compiler creates really tiny and portable executables (at least if you use tlibc). Besides that, it is the basic element of OGRE and MOGRE and even Microsoft Windows. So please don't speak so badly about it. :) And please note that C++ is not C#, so you can't just plus the strings together, because they are pointers. You generally can't add a pointer to another in C++.

And by the way, here is the code to concatenate a string and an integer (should work with string + string too). It is taken from the window.h file found in the dependency checker folder:

char wndCount[100];
_windowCount++;
int i = _windowCount;
wsprintf(wndCount, "twindow_%i", i);
char* Win32ClassName = wndCount;


Maybe you'll find it useful and create a method from it. Or have a look at OGRE's String class.

UPDATE: Have a look at this page: http://cs.smu.ca/~porter/csc/ref/c_cpp_strings.html. But I'm not sure whether it works with tlibc.

To Bekas (you are the project manager, aren't you?): I tried to compile MOGRE myself yesterday and it just won't work no matter how I try to get it working. Could you give me some hints? I am using the automatic script and the linker always throws an error that it cannot find OgreMain.lib or OgreMain_d.lib. All in all, building MOGRE is a very complicated process. In contrast to that, the actual OGRE compiles straight away on my machine. Couldn't you simplify the process a bit, so that one doesn't have to care about every little detail?

Beauty

18-01-2010 14:40:57

Beauty, I understand that you don't like C++. [...] So please don't speak so badly about it. :)
I do not damn C++ at all. And I know the big importance, spread and about its history.
I just damn the time when I have trouble with it. The reason is my bad C++ knowledge, so even tiny things are big trouble for me. I'm feeling like a beginner of programming at all when I try to do C++ stuff.
Your example code I don't understand (even I was a Perl programmer). Thanks for the links - I will read and bookmark them. Maybe I need it in the future.


To Bekas (you are the project manager, aren't you?):
Bekas is the father of Mogre and was the maintainer. Now he is in retirement.
I'm happy to see him here from time to time. Especially his upgrade from Mogre 1.4 to 1.6 was a good and needful help, because others couldn't solve all the problems. (One reason was that the autowrapper wasn't documentated and additionally only less people know about C++/CLI - the glue between Ogre and Mogre)

In case of your problems, currently GantZ is the main contact person :wink:


I tried to compile MOGRE myself
Do you know the wiki help page Building_MOGRE_1.6_from_source?
It describes the compile process. Unfortunately the section of manual build is not updated (still related to 1.4).
But maybe it help you. And if you solve you problems you are welcome to update the wiki page.

Beauty

18-01-2010 16:03:37

for writing little programs and hacks, it is very practical and the compiler creates really tiny and portable executables
Maybe you are interested to look to the script language AutoIt.
It's a great language for little tools and have powerful functions that you don't find in plain C++.
For example it's totally easy to telecontrol application windows by a few lines. The compiled exe files are tiny, too. (And just for info: the compiler is written in C++)
Here is an example (in the sister language AutoHotkey) to click away adverticement popups of the free virus scanner Antivir. Thats all. (Note: this is the title of the German version - if you use it in an other language, edit the window title.)
myWindowTitle = Notifier von Avira AntiVir Personal - Free Antivirus
Loop
{
WinWait, %myWindowTitle%
IfWinNotActive, %myWindowTitle%
WinActivate, %myWindowTitle%
WinWaitActive, %myWindowTitle%
Sleep, 500
WinClose, %myWindowTitle%
}

kwertz

18-01-2010 16:25:05

I heard of AutoIt... but I have never used it. I will have a look at this.

kwertz

21-01-2010 17:08:45

So what about the Dynamic Cubemapping example? Shall I include it in the SDK? Does it need modifications?
Also I am working on an example showing off a technique called "Fake HDR" as you can read in one of my previous posts.
I would need a proof-reader/tester, because I'm not sure whether the implementation is right ... Then I will move on to
creating materials and a compositor for it.

P.S.: Beauty, I discovered a new promising programming language called "D", which combines the benefits of C#, C++ and Java.
I thought you might be interested in it. Also, the language can easily be learned from scratch. Have a look at it here.
I'm thinking about porting our dependency checker to D. What do you think?

Beauty

21-01-2010 18:39:33

Yes, I think it's good to add several tiny example applications.
They demostrate the possibilities and show how it's done.
So your Dynamic Cubemapping would be a nice candidate (but before please bugfix the freeze, which happens after pushing the Esc button).
Also your HRD fake would be a candidate.

Generally the checker could use any language which needs only Windows as depency.
But I think C++ is a good choice for this.
So you don't need to port the code and many Mogre people knows this language.
And in general your checker works. My review comments are more part of the nice to have section.
On the other hand - if you like to make experiments with other languages, this would be a handy example to play.

Currently I'm not interested to learn other programming languages. After 3 years of intensive use of C# I still have to learn basics for several things. (.NET has so much content areas) So I spend my time to this language.

All the last days I burn my fingers with public projects, that extends the OpenFileDialog of Windows.Forms.
This should display the content of my saved scene files (screenshot, vehicles, sensors, ...) immediately when the user select a file in the OpenFileDialog. My UserControl (similar to a Form with GUI elements) for XML parsing and display is ready, but there are strange problems with the public extender projects. This is my current focus, so I don't spend much time to something else.
If somebody is interested to know more, look Extended OpenFileDialog on codeproject.com.

kwertz

22-01-2010 16:25:03

I got it managed to write a full article showing how to do Dynamic Cubemapping using MOGRE. Have a look at it here.

kwertz

22-01-2010 16:26:37

Beauty, I cannot reproduce the bug you seem to have found. Have you tried to debug the example in non-fullscreen mode?

kwertz

22-01-2010 20:15:07

Hey look! I made a video of the Dynamic Cubemapping example. It's live on YouTube here.

boyamer

25-01-2010 22:30:34

Downloaded demo,would you mind make CG or HLSL shaders for cubemaping?

Thanks

kwertz

27-01-2010 10:49:08

@boyamer: Though the shader is not the main thing that is demonstrated, I will try to port the GLSL code to Cg.
I think I can accomplish it today.

boyamer

27-01-2010 11:12:26

yep i know,would be great to see directx support too..
good work indeed.

kwertz

27-01-2010 14:46:45

Here is the code:

Vertex Shader:

const float EtaR = 0.65;
const float EtaG = 0.67; // Ratio of indices of refraction
const float EtaB = 0.69;
const float FresnelPower = 5.0;

const float F = ((1.0 - EtaG) * (1.0 - EtaG)) / ((1.0 + EtaG) * (1.0 + EtaG));

varying float3 Reflect;
varying float3 RefractR;
varying float3 RefractG;
varying float3 RefractB;
varying float Ratio;

uniform float4x4 modelViewMatrix;
uniform float3x3 normalMatrix;
uniform float4x4 textureMatrix;

float4 main(float4 position: POSITION, float3 normal: NORMAL) : POSITION
{
float4 ecPosition = mul(modelViewMatrix, position);
float3 ecPosition3 = ecPosition.xyz / ecPosition.w;

float3 i = normalize(ecPosition3);
float3 n = normalize(mul(normalMatrix, normal));

Ratio = F + (1.0 - F) * pow((1.0 - dot(-i, n)), FresnelPower);

RefractR = refract(i, n, EtaR);
RefractR = float3(mul(textureMatrix, float4(RefractR, 1.0)));

RefractG = refract(i, n, EtaG);
RefractG = float3(mul(textureMatrix, float4(RefractG, 1.0)));

RefractB = refract(i, n, EtaB);
RefractB = float3(mul(textureMatrix, float4(RefractB, 1.0)));

Reflect = reflect(i, n);
RefractR = float3(mul(textureMatrix, float4(Reflect, 1.0)));

return ecPosition;
}


Fragment Shader:

varying float3 Reflect;
varying float3 RefractR;
varying float3 RefractG;
varying float3 RefractB;
varying float Ratio;

uniform samplerCUBE Cubemap;

float4 main() : COLOR
{
float3 refractColor, reflectColor;

refractColor.r = float3(texCUBE(Cubemap, RefractR)).r;
refractColor.g = float3(texCUBE(Cubemap, RefractG)).g;
refractColor.b = float3(texCUBE(Cubemap, RefractB)).b;

reflectColor = float3(texCUBE(Cubemap, Reflect));

float3 color = mix(refractColor, reflectColor, Ratio);

return float4(color, 1.0);
}


Vertex shader gives an exception during compilation, but the fragment shader works fine. Any ideas?

smiley80

27-01-2010 17:37:07

const float F = ((1.0 - EtaG) * (1.0 - EtaG)) / ((1.0 + EtaG) * (1.0 + EtaG));
IIRC, you can't do that in C (and Cg stands for "C for Graphics").
Replace EtaG with the literal or remove const and move it into the main function.

kwertz

27-01-2010 18:29:51

Thanks smiley80! Works now!

I decided to precalculate the value via Derive and replaced the line with:
const float F = 0.044995408;

kwertz

27-01-2010 19:26:20

I'm running into problems again.


Compiler error: invalid parameters in orangebook.material(12): setting of constant failed
Compiler error: invalid parameters in orangebook.material(13): setting of constant failed
Compiler error: invalid parameters in orangebook.material(18): setting of constant failed


Here is my material file:

material OrangeBook/ChromaticAberration
{
technique
{
pass
{
lighting off

vertex_program_ref OrangeBook/Programs/ChromaticAberrationVP
{
param_named_auto modelViewMatrix worldview_matrix
param_named_auto transposeWorldViewMatrix transpose_worldview_matrix
param_named_auto textureMatrix texture_matrix 0
}

fragment_program_ref OrangeBook/Programs/ChromaticAberrationFP
{
param_named Cubemap int 0
}

texture_unit
{
// will be filled in at runtime
cubic_texture DynCubeMap combinedUVW
tex_address_mode clamp
env_map cubic_reflection
}
}
}
}

material VindelalvenSkyBox
{
technique
{
pass
{
lighting off
depth_write off

texture_unit
{
// will be filled in at runtime
cubic_texture posz.jpg negz.jpg negx.jpg posx.jpg posy.jpg negy.jpg separateUV
}
}
}
}


The program definitions:

vertex_program OrangeBook/Programs/ChromaticAberrationVP cg
{
source chromatic_aberration_vp.cg
entry_point main
profiles vs_2_0 arbvp1
}

fragment_program OrangeBook/Programs/ChromaticAberrationFP cg
{
source chromatic_aberration_fp.cg
entry_point main
profiles ps_2_0 arbfp1
}


And the updated vertex shader code:

const float EtaR = 0.65;
const float EtaG = 0.67; // Ratio of indices of refraction
const float EtaB = 0.69;
const float FresnelPower = 5.0;

const float F = 0.044995408;

varying float3 Reflect;
varying float3 RefractR;
varying float3 RefractG;
varying float3 RefractB;
varying float Ratio;

uniform float4x4 modelViewMatrix;
uniform float4x4 transposeWorldViewMatrix;
uniform float4x4 textureMatrix;

float4 main(float4 position: POSITION, float3 normal: NORMAL) : POSITION
{
float3x3 normalMatrix = float3x3(transposeWorldViewMatrix);

//float F = ((1.0 - EtaG) * (1.0 - EtaG)) / ((1.0 + EtaG) * (1.0 + EtaG));

float4 ecPosition = mul(modelViewMatrix, position);
float3 ecPosition3 = ecPosition.xyz / ecPosition.w;

float3 i = normalize(ecPosition3);
float3 n = normalize(mul(normalMatrix, normal));

Ratio = F + (1.0 - F) * pow((1.0 - dot(-i, n)), FresnelPower);

RefractR = refract(i, n, EtaR);
RefractR = float3(mul(textureMatrix, float4(RefractR, 1.0)));

RefractG = refract(i, n, EtaG);
RefractG = float3(mul(textureMatrix, float4(RefractG, 1.0)));

RefractB = refract(i, n, EtaB);
RefractB = float3(mul(textureMatrix, float4(RefractB, 1.0)));

Reflect = reflect(i, n);
RefractR = float3(mul(textureMatrix, float4(Reflect, 1.0)));

return ecPosition;
}

kwertz

29-01-2010 11:31:58

As I see, OGRE v1.7 RC1 has been released.
GantZ, do you have time to release MOGRE for this new version? And, could you please instruct me how to build MOGRE, I get approximately >3000 errors (I did everything as described on the wiki page).

Thank you.

GantZ

29-01-2010 13:04:36

I'm in the middle of switching to a new PC config right now (and it's not as easy as i'd like :( ), so i cannot compile a new mogre version right now . i want to wait for the final ogre 1.7 version to be released, so that we go a completely stable version. about the build thing, don't use the wiki instructions, they are not up to date, prefer following the instructions here :

http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=10937#p63491

i will get a shot at building a new version next week (just for testing purpose) , but i think we should wait for sinbad to release the final 1.7 version (shouldn't be too long).

kwertz

29-01-2010 17:14:24

I think it's good to let you know that I created tags for the different versions of the MOGRE SDK. Just in case you didn't notice that. It is more comfortable for those wanting a specific version of the SDK.

kwertz

29-01-2010 19:16:01

@GantZ: thanks to you, I am finally able to compile MOGRE myself. Would anyone mind to update the wiki page?

boyamer

12-02-2010 22:28:37

kwertz
Would you mind make a pack or commit the dynamic cubemap to the svn with CG,HLSL and GLSL Shaders?
WOuld be usefull

Thanks

kwertz

14-02-2010 19:23:39

I think I'm stuck at these errors. Anyone willing to give me a suggestion?
@boyamer: As long as the sample is not fully functional (the CG code doesn't work), I will not commit it. Sorry.

ydrol

19-04-2010 09:11:29

Hi,

I installed using the MogreSDK installer. Just an FYI that there seems to be a problem with the debug .dlls

I followed the suggestion at: http://89.151.96.106/addonforums/viewto ... 18&start=0 and copied the release dlls and renamed, this fixed my problem.

18:00:17: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library C:\MogreSDK\bin\Debug\RenderSystem_Direct3D9_d. System Error: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
in DynLib::load at ..\src\OgreDynLib.cpp (line 81)

Errors were with:
RenderSystem_Direct3D9_d
RenderSystem_GL_d.dll
Plugin_ParticleFX_d.dll
Plugin_BSPSceneManager_d.dll
Plugin_OctreeSceneManager_d.dll
Plugin_CgProgramManager_d.dll

The sizes of the _d versions were much larger than the release versions.

Running 1.6.5 with mogreframework compiled for 1.6.5. (I also note I had to search high and low for this, any chance on having it included in the installer?)

If you have any questions about this, let me know.. Just trying to provide some feedback! Thanks for all the effort into making this as easy as possible to get into.

kwertz

22-04-2010 18:51:28

Thanks, we appreciate your feedback. If I understand you correctly, this is a problem with the MogreFramework, not Mogre itself. Please note that the MogreFramework is considered as being obsolete and should not be used any longer. We only included it in the SVN to provide backwards compatibility. I already discussed making a better framework (a port of OgreBites) with GantZ. We will keep you informed. The new framework will be included in the next release or maybe after next release depending on our development speed and on possible complications. You may use ExampleApplication from {SDK directory}\Samples\ExampleApplication as a replacement in the meantime.

ydrol

24-04-2010 07:46:12

Oh ok, fair enough. I'm still making my way through the tutorials currently so I think I will have to keep using MogreFramework.

token

26-04-2010 23:45:59

Hello all,

First of all thx for the 1.7 SDK. I am urrently fiddeling a bit around with it. My interest came to this Ogre 1.7 deferred rendering compositor from the Ogre samples:

http://www.ogre3d.org/wiki/index.php/Deferred_Shading

I am currently trying to port it to c# but ran into some problems. For example in the sample code there are some lines like

compMan.registerCompositorLogic("SSAOLogic", new SSAOLogic);
compMan.registerCustomCompositionPass("DeferredLight", new DeferredLightCompositionPass);


where compMan is just a ref to the CompositeManager singleton. In Mogre I lack these functions and also stuff like the CompositeLogic class and more. Are those not yet implemented and need to be wrapped or dont you need them in Mogre ?

Greets

GantZ

27-04-2010 08:35:05

Could you provide a complete list of which classes / functions you can't found ? It's possible some of the new classes introduced by 1.7 haven't be included in the wrapping stage. I will compile a new version around 1.7.1 soon, so i could include them.

token

27-04-2010 13:05:04

Thank you, I will try to compose a list the next evenings :)

Beauty

17-06-2010 00:37:32

User smiley80 created a demo application which shows a webcam picture stream in Ogre.
It would be nice if Kwertz (or somebody else) add it to the SDK.

Here you find the download:
viewtopic.php?p=72311#p72311

Maybe some people can test it?
It would be good to know if it works on different systems. I can't do, because I don't have a webcam.
If there are problems, please write the details to the linked thread, not here.

Beauty

17-06-2010 22:01:54

In the SVN at path sdk_fs\bin\Debug is the file Mogre.dll.
It's some months old and I suppose it's outdated and not needed in the Debug directory. It's just confusing and could cause trouble when people link to this file.
I think it's better to remove the file, but I was not shure about.
If I'm right, then just delete it :wink:

An other thing:
I updated my SVN directory for the MogreSDK. Then there was an error.
This also happens with the current TortoiseSVN version.
It transfers 18MB without a message (like update/add/delete file) and then there comes an error:
REPORT of '/svn/!svn/vcc/default': 200 OK (https://mogresdk.googlecode.com)
What's wrong? Any idea?

mstoyke

18-06-2010 00:34:11

I'm not sure about this, but I think that GantZ has switched the project to a Mercurial repository some time ago. You should try it, for me it worked for VS2008. If you're interested in VS2010 version you could get the code from my Mercurial repositories at bitbucket.

I will have to add some instructions how to compile them in the near future, but they compile if you get it right :) I will soon take some time to update some information in the wiki (promised :) ) but right now I'm too busy to put much effort into Mogre.

Beauty

18-06-2010 13:08:06

I suppose GantZ switched only the Mogre souce code repository to Mercurial.
The maintainer of the MogreSDK (with binaries, installer, demos) is Qwertz. (Or did it changed in the last months?)

I will soon take some time to update some information in the wiki (promised :) )
This would be great.
Most important is to update the current Mogre depencies in the wiki.
Checking / Updating the basic tutorials would also be good.
(Note: Tutorial 0 contains the installation instructions and depencies.)

GantZ

22-06-2010 14:31:00

I suppose GantZ switched only the Mogre souce code repository to Mercurial.

That's right, only the mogre source (and it's plugins) reside in the mercurial repository now. i have remove all the data related to the sdk on the mercurial repository.

The maintainer of the MogreSDK (with binaries, installer, demos) is Qwertz. (Or did it changed in the last months?)

dunno, i haven't heard from him for month now, if someone want to take care of the sdk, feel free to do so.

Beauty

23-06-2010 09:58:12

I added the webcam demo to the SDK SVN.
When somebody has no webcam, he see a video stream of a tiny avi file instead.
It runs as standalone (use download of smiley80), but my try to integrate it to the SDK failed.
Details are written in the webcam thread.

By the way - Qwertz last write access to the SVN was in May (update to Mogre 1.7)

deadlock

23-07-2010 16:05:18

System.TypeLoadException wurde nicht behandelt.
Message="Could not load type 'Mogre.OgreException' from assembly 'mogre, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'."
Source="mogre"
TypeName="Mogre.OgreException"
StackTrace:
at Test.Program.Main()
at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException:



Hi Guys!

I discovered MOGRE yesterday and was starting with the Basic Tutorial 0 but I dont get it to work. It gives me the above mentioned Error. The Code is exactly the same from the Tutorial. I use Mogre 1.7.1 with the shipped MogreFramework.dll in Visual C# Express 2008 @ Windows 7 x64. I changed the PlatformTarget to x86 so there should be no issues because of 32/64bit dependencies.

Can someone help me?

Beauty

26-07-2010 12:39:32

Hi deadlock,

nice that you tried our Mogre wrapper :D

Unfortunately our tutorials are outdated and need some updates.

Did you install the MogreSDK?
If not - where did you get the binary files?
The MogreSDK is a good way to start with Mogre. It installs the needed depencies and contains all needed dll files (with the right version depencies).
Here you can download the current SDK version: http://mogresdk.googlecode.com/files/Mo ... ta_r72.exe

The SDK contains also some demo applications.
For your own application you can copy all content of the MogreSDK binary directory to the binary directory of your application.
Then link to the Mogre.dll file in your appliaction binary directory. So all depencies should be found.

Apart from these files you need the newest DirectX 9 release.
Also you need either the Visual C++ 2008 redistributable package or Visual Studio 2008 including Service Pack 1.
The MogreSDK installer checks/installs this system depencies.

Your compilation target should be x86 (32 bit) - also for 64 bit Windows. (I can't tell you why, but I read it from other users.)

Are there warnings or errors in the file ogre.log?
If yes, please post it.


I hope I could help you.
Please give us a feedback. This is needed to improve our SDK.
When you have trouble with the SDK (installation or use) or even if everything is fine.

deadlock

26-07-2010 18:39:34

OK. Lets tell it in a better way.

-I installed the 1.7.1 (R32) SDK
-I did everything like its stated in the tutorial
-I changes the project to 32Bit (Open the project.vcproj in Notepad and add the Line <PlatformTarget>x86</PlatformTarget>)
-I dont get Errors when Im in VC#
-VC++ 2005,2008 & 2008 +SP1 is installed , VC#2008SP1 installed
-The DependencyCheck says that VC++2008 is missing but its not. The Samples work pretty fine (and actually the have a nice performance on my laptop).

The Error appears when the project is build an starts to run.

The Error is not appering wehn you change the standard tutorial code :using System;
using System.Collections.Generic;
using System.Windows.Forms;
using Mogre;
using MogreFramework;

namespace Test
{
static class Program
{
[STAThread]
static void Main()
{
OgreWindow win = new OgreWindow();

try
{
win.Go();
}
catch (System.Runtime.InteropServices.SEHException)
{
if (OgreException.IsThrown)
MessageBox.Show(OgreException.LastException.FullDescription,
"An Ogre exception has occurred!");
else
throw;
}
}
}
}


to(simply commented the part with the OgreException out):

using System;
using System.Collections.Generic;
using System.Windows.Forms;
using Mogre;
using MogreFramework;

namespace Test
{
static class Program
{
[STAThread]
static void Main()
{
OgreWindow win = new OgreWindow();

try
{
win.Go();
}
catch (System.Runtime.InteropServices.SEHException)
{
//if (OgreException.IsThrown)
//MessageBox.Show(OgreException.LastException.FullDescription,
//"An Ogre exception has occurred!");
//else
throw;
}
}
}
}



So something must be wrong with the import of the OgreException object/class ?!?!

As I said in the first post i use Visual C# 2008 Express and the new Mogre 1.7.1 thread only mentiones Visual Studio 2008 or higher. May this be a problem?

Beauty

26-07-2010 21:45:42

The last 3 posts (title: MOGRE 1.7.1 Could not load type 'Mogre.OgreException') I moved from a single thread to here.
I suppose it's good to discuss the problem here to find out the problems and to improve our SDK installer.

Thanks to deadlock for his detailed report :)

mstoyke

26-07-2010 23:46:12

I would like to know if you still have this problem if you replace the Mogre & Ogre binaries with the ones I just released on the sourceforge page. Could you download this file from sourceforge and check if you still get the exception with these binaries?

Beauty

27-07-2010 10:25:37

Are this your .NET 4.0 binaries?
(Although your officially published libraries are for VS2010)

mstoyke

27-07-2010 13:54:39

No, the link in my post references to the VS2008 version of the binaries. The VS2010 version would not be comaptible with the rest of the Mogre SDK.

Beauty

27-07-2010 15:20:38

What the people think (especially quertz) which type of SDK we want to offer in the future.


The first difference is Visual Studio 2008 / 2010.
I suppose VS 2010 is the future.
Negative: Currently the newton library has problems with VS 2010 (as I read in the Newton forum).
Are there also other libraries which could cause problems?


The second difference is .NET 2.0 / 4.0.
A mixed use of libraries can be possible (as I had read), but this is not recommend (as I had read).
So the add-on libraries should be recompiled. If this works well I can't say.
Would there be advantages of offering a .NET 2.0 Mogre version?
(Apart from the point that more users has to install the .NET 4.0 framework.)


To maintain different packages would need more effort.
Also we would need to think about how we would manage the SVN file structure.


Here I have an idea:

* Maintain and offer only one SDK type (e.g. VS 2010 + .NET 2.0)

* For users who are interested in other types:
. . . . . * Keep the current SDK installer as download (MogreSDK_1.7.1_beta_r72.exe)
. . . . . * ( maybe also offer the whole content in a static zip archive? )
. . . . . * offer different plain binary packages as downloadable zip archives
. . . . . . . . . . * Example package: Mogre + other libraries ... related to Mogre 1.7.1, .NET 2.0
. . . . . . . . . . * Example package: Mogre + other libraries ... related to Mogre 1.7.1, .NET 4.0
. . . . . . . . . . * Example package: one add-on library (including related Mogre library to avoid version trouble)
. . . . . * So it's easy to offer other types / binary combinations without much maintain effort

I hope you understand how I mean.


I think it's good to discuss this point.
Because there are different ways (VS + .NET versions) and we need to decide which way we want to go.

deadlock

27-07-2010 18:58:52

I would like to know if you still have this problem if you replace the Mogre & Ogre binaries with the ones I just released on the sourceforge page. Could you download this file from sourceforge and check if you still get the exception with these binaries?

I did as you said and replaced the old binaries with the new ones. But same Error occures. I will test on another User Account in W"indows and give you all my feedback about anything I can find out.

It seems that Im the only one who experiences this kind of Error.

mstoyke

27-07-2010 19:25:23

I did as you said and replaced the old binaries with the new ones. But same Error occures. I will test on another User Account in W"indows and give you all my feedback about anything I can find out.

It seems that Im the only one who experiences this kind of Error.


That's odd.

I just tried to run some code that uses OgreException and it works like expected. Do you have the opportunity to run your project on another machine? I would like to know if it's your project setup or the machine configuration that is causing this kind of problem.

mstoyke

27-07-2010 19:37:07

Beauty, for the moment I want to provide both packages to the users. VS2008/Framework 2.0 and VS2010/Framework 4.0. The SDK can still use the VS2008 projects for some time, until the dependencies and add-ons are ported to suport the VS2010 build of Mogre.

The VS2010 profile will soon be the primary build target, but the supported .NET framework might be important if we decide to create a dual wrapper setup that support P/Invoke and C++/CLI from the same code generator. Using P/Invoke only makes sense if we want to create a wrapper that can run on Mono. And the Mono project is far from supporting Framework 4 to an acceptable extend.

For my personal projects I had to decide for each of 'em if I want to target only Windows (can use 4.0) or if I also wanted to use it with Mono (must stay with 2.0).

deadlock

27-07-2010 19:52:11

Ok I know a bit more then a few minutes ago.

I placed a breakpoint at the beginning of the class and ran the code.

The problem still exists (but in a different way) but it seems to be in the using directive. I checked my folder permissions and it still happens.
The Error I get now looks like this:


@mstoyke
I will try it on another machine (virtual and normal) as soon as I can. Right now Im in exams and only have a few minutes a day for coding :?

Beauty

28-07-2010 11:06:55

It seems that Im the only one who experiences this kind of Error.
I suppose also other people has problems, but are to lazy to report them. Instead they just skip Mogre and use C++ Ogre or search for an other 3D library.
The SDK was downloaded many hundred times (as mstoyke said), but nearly nobody give a feedback. So it's difficult to know what's the current quality of our SDK.

The Samples work pretty fine.
Strange. Maybe there is a problem with the file MogreFramework.dll?
In tutorial 0 some time ago I added direct download links of this file. But these are related to older Mogre versions and outdated now (I suppose).
Also now I see, one download link is broken, because of a bug in the new wiki software. Just in the moment I reported this problem and hope it will be fixed soon.

Try to use a MogreFramework.dll file from an SDK demo application instead. (I hope the functionality of the current version is the same.)
Please report about success or fails.

Do you have the opportunity to run your project on another machine?
Maybe deadlock can put the tutorial project to an archive (including binary directories) and offer it as download link. Then we can check if this is a problem inside the project. When it runs, then it's a problem of computer depencies. When it doesn't run, then we can look for the problems source.

GantZ

28-07-2010 20:50:35

@deadlock

check that you have the ogremain.dll file where is you exe (and your mogre dll). usually, you get this error (the hresult one) when mogre can't find the ogremain.dll. (must be in the same folder)

Beauty

29-07-2010 10:06:26

Now I remember an older problem I had which caused much headache.
This happened after installing a newer MogreSDK version.
(Note: This was 2 years ago. The SDK of today has a complete new installer and different content.)

My application didn't work and I got exceptions for every start.
Then I found out, that for each run, the Mogre.dll file was replaced in my local binary directory.
I can't remember the reason. Maybe Visual Studio took the Mogre.dll file of an other directory and put this to my local binary directory. (VS replaced the version which I wanted to use.) I suppose then the Mogre.dll file and the OgreMain.dll file were in different versions and caused conflicts.

The solution was:
In the link properties of the Mogre.dll file I changed local copy to true.
Then VS stopped to replace the dll file and my problems were gone.

Maybe this helps also in your case ...

deadlock

29-07-2010 17:27:15

Hi again Guys!

First of all thanks for your soppurt and beloved help :D
I tried all of your solution attempts without getting further.

Today I have a bit time to investigate the HRESULT error. I will edit this post when I can come up with some new facts.

I didnt had the time to test Mogre on another machine because my DesktopPC is keyboardless (soda and keyboards dont match).

Lets go on with the things I found out right now.
I messed arround with the code a bit to get further information about what creates the HRESULT error @ 0x8007007E. I use this code:
using System;
using System.Collections.Generic;
using System.Windows.Forms;
using Mogre;
using MogreFramework;
using System.IO;

namespace mogre_test
{
static class Program
{

public static OgreWindow win = null;
[STAThread]
static void Main()
{ //============================================
/* Here comes just a Check to see if the SDK and the Project contain the right file
Console.WriteLine("Mogre_d.dll & Mogre.dll");
if (File.Exists("C:/Users/deadlock/Documents/MogreSDK/bin/Debug/Mogre_d.dll") && File.Exists("C:/Users/deadlock/Documents/MogreSDK/bin/Release/Mogre.dll"))
{

Console.WriteLine("Check");
}
Console.WriteLine("Project binaries");
if (File.Exists("C:/Users/deadlock/Documents/Visual Studio 2008/Projects/mogre_test/mogre_test/bin/Debug/Mogre.dll") && File.Exists("C:/Users/deadlock/Documents/Visual Studio 2008/Projects/mogre_test/mogre_test/bin/Release/Mogre.dll"))
{
Console.WriteLine("Check");
}
*/

//=======================================================
//Here comes the normal tutorial Code in a changed way to catch all need :D
try
{
win = new OgreWindow();

}
catch(FileNotFoundException ex)
{
MessageBox.Show("Something is wrong here" + ex.Message);
//If this Box isnt shown , the dlls work fine
//and the imported code can create the new OgreWindow
}
try
{
if (win != null)
//Check again if the created Window is not empty
{

try
{
MessageBox.Show("Here occurs the Error\nClick OK to view handles code", "FileNotFoundException");
//This is not something to get Information
//I just used this to find out where the errors source is
win.Go();
}
catch (FileNotFoundException ex1)
{
//Error Output
MessageBox.Show(ex1.GetType() + "\n" + ex1.Source + "\n" + ex1.Message + "\n" + ex1.StackTrace + "\n"
+ ex1.TargetSite + "\n" + ex1.Data + "\n" + ex1.FusionLog
, "Errors");

}
}
}
catch (FileNotFoundException ex)
{
MessageBox.Show(ex.Source + "\n" + ex.FusionLog, "Another FNFException");
//if (OgreException.IsThrown)
//MessageBox.Show(OgreException.LastException.File + "\n" + OgreException.LastException.FullDescription + "\n" +
//OgreException.LastException.Source + "\n", "OgreException");
//else
throw;
}



}
}
}

But again I need to quote out the OgreException part. Else there appears a FileNotFoundException which cant be catched ( see the last catch?)

I nearly going crazy on this one :shock:

Beauty

29-07-2010 18:02:55

Just in the moment I got an idea and remember an old discussion.

Something about the Ogre exception was removed from Mogre some time ago (maybe because it was removed in C++ Ogre??).
Then I asked to put it in again and the last maintainer said he did put it in again.
I suppose it was the property OgreException.IsThrown.

Maybe now the needed member is lost again.
Check if this member is still in the current Mogre version. (I use Mogre 1.6 and there the same check works well.)

deadlock

29-07-2010 18:23:35

At the Mogre 1.7.1 SDK the OgreException.IsThrown is still available ( you can access it while coding and it is listed in the Object manager window).

Beauty

30-07-2010 11:27:28

Maybe the wrapper content has to be updated (because of a possible change in the current Ogre library)?

I found the old discussion.
It was related to the 1.6.2 version of Mogre.
Also note that OgreException.IsThrown has been removed, use OgreException.LastException != null instead.
Is there a specific reason for removing?
I suppose the property would be not much overhead.
Also it would be good for a better backward compatibility and old code snippets.


Also Beauty has a good point about backward compatibility, I've added the IsThrown back, which just does a "LastException != null" now.
The reason I removed it was that It didn't work as it was supposed to (it never did actually); the idea was that it would become false automatically after you handled the exception but it actually remained true all the time after the first Ogre exception, so if you would get another SEHException, isThrown was true even if it didn't originate from an Ogre exception.

Now, you are supposed to clear the cached Ogre exception information (LastException) using OgreException.ClearLastException(). (in reality it doesn't matter much since 99.99% if you get a SEHException, it was because of an Ogre exception).

To elaborate more about OgreException, this has nothing in common with how you handle exceptions in C++ Ogre, this is an ugly workaround due to Ogre exceptions not having a way to "become" .NET exceptions.

deadlock

30-07-2010 11:55:28

I changed the OgreException.IsTrown to OgreException.LestException != null but the same Error occurs.

I think it has to do something with the MogreFramework.dll . Maybe there is a version check (due to dependencies?). And the MogreFramework.dll is wrong compiled against 1.7.1?

I will try the 1.6 version later this day. So we can backtrace the error.

Beauty

30-07-2010 12:32:41

Maybe the MogreFramework.dll was not compiled against 1.7.1 and is related to an older Mogre version??

deadlock

30-07-2010 14:36:48

After 2 hours of trying to correctly compile the MogreFramework.dll to the Mogre.dll 1.7.1 the same Error again :(

I will give 1.4 and 1.6 a try. But not know. I'm curently frustrated.

mstoyke

30-07-2010 15:00:08

Ok, maybe I can find some time this weekend to look into this matter. If you could just send me a zip file of your project files, sourcecode and compiled binaries, I could try it on my machine.

I would like to know how many people actually need a working MogreFramework.dll for their projects. If demand is high, I could put this on a higher priority on my to-do list.

deadlock

30-07-2010 15:46:50

I uploaded everything to my webspace.

The mogre_test_(incl.Mogre.dll.and.MogreFramwork.dll).rar is the project Folder and in the root there are also the binaries that come with Mogre1.7.1 (those are the ones I use)-

The Release.rar contains the build project. I forgott to do that :roll:

Here you go:
mogre_test...
http://garage-inc.bplaced.net/C%23/mogre_test_(incl.Mogre.dll.and.MogreFramework.dll).rar
Release.rar
http://garage-inc.bplaced.net/C%23/Release.rar


Thanks for looking into the project.

BTW: we (Beauty,mstoyke & I) are germans. Maybe we could meet up in IRC or ICQ (whatever) to discuss this. If we find a solution we can publish it and update the wiki. :idea:

Edit: I posted the links with C%23 in the first place....no clue why you have problems

Beauty

30-07-2010 16:25:48

The forum or my browser has a problem with the encoded char "#".
So replace it by "%23" in the URL to download the files.

mstoyke

30-07-2010 18:42:14

I unpacked all files in Release.rar, then I copied all DLLs that you can find in the Release folder of this binary release into the Release folder that you sent me, overwriting the Mogre.dll with the one from the binary release.
Then I changed you .cfg files like this:

plugin.cfg

# Defines plugins to load

# Define plugin folder
PluginFolder=.

# Define plugins
Plugin=RenderSystem_Direct3D9
Plugin=RenderSystem_GL
Plugin=Plugin_ParticleFX
Plugin=Plugin_BSPSceneManager
Plugin=Plugin_OctreeSceneManager
Plugin=Plugin_CgProgramManager


resources.cfg

# Resource locations to be added to the 'boostrap' path
# This also contains the minimum you need to use the Ogre example framework
[Bootstrap]

# Resource locations to be added to the default path
[General]


The program mogre_test.exe started fine and I got an empty Ogre window after the splashscreen.

Edit: You might also want to look into this: http://www.ogre3d.org/addonforums/viewtopic.php?f=8&t=13160

Beauty

13-08-2010 16:47:03

Now I installed Windows 7 prof 64bit on my computer and run the setup file of MogreSDK 1.7.1 beta r72.
It works well. Also I see that the depency checker has a new GUI.
Unfortunately it's not so clear to understand.

After the first display all 3 checkboxes were checked.
The text say I should click Check.
Then there comes a warning note.
Back again in the main window (of the checker) the checkbox of DirectX 9.0c is unchecked now.
I clicked Check again and I got the same warning note.
Then I found out, that I have to click to the checkbox (or the text?) to call the download page of this depency.
This is not very self-explanatory. I suppose some users are confused and just close the checker window -- which means the depencies are not installed.

I have an idea how the checker GUI can get a better overview.
For this I created a suggestion. See pictures below.
I hope the used GUI system can display colored text, because this is useful.

Maybe the title should get the version number of the related Mogre version (e.g. 1.7.1).

Beauty

13-08-2010 16:50:49

This one will be shown after the first check.

Alternatively the first check could happen automatically after starting the checker application.

The first steps button should open a wiki page which contains information about the Mogre structure (bitbucket, sourceforge), invoke the user to do the basic tutorials, where to find information (Main forum, Mogre forum, Wiki), etc.

Beauty

04-09-2010 14:17:25

User GantZ created a demo for Hikari. With this you can embedd Adobe Flash to Mogre, e.g. to create GUIs.

He uploaded it to the SVN repository of our MogreSDK.
It would be nice if somebody can embedd it to the example browser and the installer.

Here is the code:
http://code.google.com/p/mogresdk/sourc ... les/Hikari
The dll file:
http://code.google.com/p/mogresdk/sourc ... in/Release

Here is a wiki page (the content was also created by GantZ):
http://www.ogre3d.org/tikiwiki/Hikari+Wrapper+for+MOGRE

For questions related to the Hikari wrapper you can use the thread HikariWrapper version 0.3.

koirat

23-11-2010 13:02:15

Is there somewhere MogreSDK compiled for x86 platform ?

Beauty

20-12-2010 00:21:40

You mean the demo applications, which can be compiled after installing the MogreSDK?
If you need them, I can compile and upload it for you.

hedphelym

20-12-2010 06:26:22

Hi Beauty,

The mogre + PhysX SDK tutorial and project can be published, it would be nice is my name \ website was mentioned (if possible).


Should I zip everything and send to you so that you can add it where it should be?
I do not have the source code at this time, since my server data got lost last week.
I will recreate the project with latest mogre, and latest physx.

I will also make more examples on how you can use physx (recreate some of the projects in the SDK (joints etc)).

It will take a couple of days, because I need to clean up the code and comment it, and make sure everything is OK in the project (have not compiled it for many months).


Thank you for contacting me about this, it inspired me to continue on this.

I will contact you as soon as everything is working.
(I might also update to latest mogre \ physx .net sdk).

hedphelym

20-12-2010 07:18:48

another question..

Is there any tutorials on how to "wrap" c++ stuff?
There is some very nice addons which would be very nice to have access to.
(SkyX for example).

http://www.ogre3d.org/forums/viewtopic.php?t=48414&f=11

I have not looked too much into wrapping, simply because I do not know enough
about how one does this.

Beauty

20-12-2010 15:03:14

The mogre + PhysX SDK tutorial and project can be published, it would be nice is my name \ website was mentioned (if possible).

Because the other people doesn't know. I found a demo application for Mogre and PhysX on a private website. Then I asked the author if we can add this to the repository of our MogreSDK.
Here is the URL of the demo description: http://stigatle.net/index.php/mogre


Should I zip everything and send to you so that you can add it where it should be?
I do not have the source code at this time, since my server data got lost last week.
I will recreate the project with latest mogre, and latest physx.

I will also make more examples on how you can use physx (recreate some of the projects in the SDK (joints etc)).

Server crashes and missing backups are bad. Sorry for that. But you see, it's one more reason to put the stuff into our repository :mrgreen:

Of course you can add personal advertisment to your demo. E.g. as a tiny text, which is shown in your render window.

I would say, user kwertz should give you access to the SVN of the MogreSDK.
Please talk with him about the details. (In which directory of the SVN you put it, how to embedd it to the SDK installer, etc.)
Additionally you can create a new thread for testing your demo(s). So we can be shure that it will work on different computers.

If you like, you could also add some information (basic knowledge, code snippets, etc.) to the Ogre wiki.
If you need wiki help, I can do it.


It will take a couple of days
[...]
Thank you for contacting me about this, it inspired me to continue on this.

Don't care about how lonk it takes. Do it when you like to do it :wink:
(But please don't forget it.)

Beauty

20-12-2010 15:03:47

Is there any tutorials on how to "wrap" c++ stuff?

The old Mogre maintainer Marioko wanted to write a tutorial for that, but then he had no more time and leaved this project.
Unfortunately there is no Mogre related guide. Mogre uses the C++/CLI technique.
Details you can read on Wikipedia or somewhere else in the web.
http://en.wikipedia.org/wiki/C%2B%2B/CLI

An other possible way is the P/invoke technique:
http://en.wikipedia.org/wiki/P/Invoke

A very old thread in the Mogre forum contains links to C++/CLI turorials and an e-book. Unfortunately I couldn't find it now.

If you try to develop a wrapper and have specific questions/problems, there is a good chance that someone could help you.
Also a look to the Mogre source code could help to see how wrapping works.



There is some very nice addons which would be very nice to have access to.
(SkyX for example).

User boyamer wrote a wrapper for SkyX some time ago.
I created a tiny wiki page, but currently it contains no further information.
http://www.ogre3d.org/tikiwiki/SkyX+Wrapper+for+MOGRE
Look to this forum thread for the SkyX wrapper:
viewtopic.php?f=8&t=13172

hedphelym

20-12-2010 15:52:12

Here's the first screenshot :)
Works great.. I need to work some more on it though, because some scaling is wrong etc.

Either way, it runs!

Latest mogre, latest physx candy wrapper.



[attachment=1]latest_mogre_latest_physx.jpg[/attachment]

Edit:
Added spheres today too..:

[attachment=0]Spheres_cubes_Mogre_Physx.jpg[/attachment]


Next up is "mesh cooking" where you use a custom ogre mesh and make it enabled in physx.

Beauty

26-12-2010 13:10:06

A newer post related to a special PhysX problem I moved to the forum topic Mogre + PhysX.
Here you can read the post, if you are interested in details.
(This SDK topic is still huge, so I don't want to get it more blowed up by such details.)

Everybody who has experience with PhysX, is welcome to follow the forum topic Mogre + PhysX, which I declared to the official support topic. Just click to Subscribe topic at the bottom of that thread to get notice about all PhysX related posts.

Beauty

26-12-2010 13:18:34

On an other topic I found a feedback (bug report), which could help to improve the SDK installer.

and from my experience - after installing SDK and running it, you need to set it to "release", if not it cannot find correct dll's and produce the error message above. (I also noticed that in his screenshot he had debug mode enabled).

CodeKrash

02-01-2011 20:31:36

[attachment=0]VideoCaptureExample2.rar[/attachment]
[attachment=2]VideoCaptureExample.rar[/attachment]

DirectShow.NET

This example application shows yet another way to sample Bitmap objects from a video input device. The following are hints for Bitmap to texture application. I may prototype an example integration with Mogre if it is requested, or if i obsess over its non existence enough.

[attachment=1]Cheeto.jpg[/attachment]

public byte[] ConvertImageToRgbValues(Bitmap image)
{
System.Drawing.Imaging.BitmapData bmpData = image.LockBits(
new System.Drawing.Rectangle(0, 0, image.Width, image.Height),
System.Drawing.Imaging.ImageLockMode.ReadOnly,
System.Drawing.Imaging.PixelFormat.Format32bppArgb);
IntPtr ptr = bmpData.Scan0;
int bytes = System.Math.Abs(bmpData.Stride) * image.Height;
byte[] rgbValues = new byte[bytes];
Marshal.Copy(ptr, rgbValues, 0, bytes);
image.UnlockBits(bmpData);
return rgbValues;
}
public unsafe void Replace2(byte[] bytes, string textureName)
{
if (this.IndexOf(textureName) < 0) throw new ArgumentException("The texture \"" + textureName + "\"doesn't exist");
TexturePtr pTexture = this[textureName];
HardwarePixelBufferSharedPtr texBuffer = pTexture.GetBuffer();
texBuffer.Lock(HardwareBuffer.LockOptions.HBL_DISCARD);
PixelBox pb = texBuffer.CurrentLock;
Marshal.Copy(bytes, 0, pb.data, bytes.Length);
texBuffer.Unlock();
texBuffer.Dispose();
}
public unsafe void Replace3(byte[] bytes, string textureName)
{
using (ResourcePtr rpt = TextureManager.Singleton.GetByName(textureName))
{
using (TexturePtr texture = rpt)
{
HardwarePixelBufferSharedPtr texBuffer = texture.GetBuffer();
texBuffer.Lock(HardwareBuffer.LockOptions.HBL_DISCARD);
PixelBox pb = texBuffer.CurrentLock;

Marshal.Copy(bytes, 0, pb.data, bytes.Length);

texBuffer.Unlock();
texBuffer.Dispose();
}
}
}

hedphelym

02-01-2011 20:48:16

That would be very nice if you could do so.

CodeKrash

03-01-2011 04:20:58

np!, now i can integrate it in one since I sufficiently modified the example.

CodeKrash

03-01-2011 05:39:06

Here you are! Of Course you need a copy of DirectShow.Net and The Tutorial Framework
I didn't notice any jittering - even while doing the memory copy inside of a framestarting hook! :D

[attachment=2]VideoInputDevice.zip[/attachment]
[attachment=1]Tutorial.zip[/attachment]
[attachment=0]Untitled.jpg[/attachment]

hedphelym

03-01-2011 06:38:29

Very cool, I'll look at it when I get home from work :)

Thanks for taking the time to do this. :)

Beauty

03-01-2011 09:05:50

Thanks for the demo and the interesting link to DirectShowNet :D

Beauty

07-01-2011 22:18:37

In an other forum topic somebody wrote a bug report related to the MogreSDK Sample Browser.

Then he found the reason, which are related to 64 bit systems.
It would be nice when somebody updates the source code. So that this bug will fixed for the next SDK build.

To Fix this I had to:

open the samples solution
set to release/x86
rebuild solution

smiley80

08-01-2011 01:12:37

Should be fixed now.

amirabiri

19-01-2011 01:09:53

Hi,

I think we need to improve the Mogre SDK to include the generated Mogre header files and any other files required to write C++/CLI code against the Mogre classes.

Currently the SDK is a bit of a mix - it contains the Mogre managed dlls together with Ogre's dlls so basically the whole thing can be dropped into a C# project and used. However the SDK then contains a ton of other stuff - all of the Ogre sources basically - which are of no use to a C# project using Mogre, and by themselves are of no use either for a C++/CLI project because to use Mogre from C++/CLI the Mogre headers are also needed.

I think there are a couple of points to consider here:
1) What is the ultimate purpose of the Mogre SDK? Is it supposed to be a complete all-in-one bundle of both Mogre and Ogre, or perhaps Ogre should be bundled separately.
2) Is the Mogre SDK aimed at C# developers who want to use Mogre, or should the SDK also serve C++/CLI developers who want to wrap plugins?

I think if the answer is that Mogre is aimed at C# developers, i.e plugin developers should download all the sources separately, then the Ogre sources should be excluded from the Mogre SDK. On the other hand if the Mogre SDK is aimed at both C# and C++/CLI plugin developers then the SDK should include all files necessary to wrap a plugin.

smiley80

19-01-2011 04:48:40

You don't need Mogre's header files. You can add it as a reference to your C++/CLI project like any other .NET assembly.

Beauty

19-01-2011 10:43:09

I'm interested to refresh the SDK and add the new demos.
Is there a documentation for the single steps?

amirabiri

21-01-2011 12:10:38

You don't need Mogre's header files. You can add it as a reference to your C++/CLI project like any other .NET assembly.Of course! you are right how stupid of me...

I was able to get my "new MHydrax" to compile and load successfully against the Mogre SDK, but there were some caveats:
  1. The boost library is missing from the Mogre SDK so I had to use the one from the Ogre SDK. I just copied it to Mogre SDK/includes and Mogre SDK/lib and it compiled brilliantly.[/*:m]
  2. The Mogre SDK only contains the .NET 2.0 assemblies for Mogre, MOIS and MogreNewt. However mstoyke published binaries for .NET 4.0 and I wanted to compile my MHydrax for .NET 4.0. So I used dropped those into the Mogre SDK folder and compiled against them and they also compile nicely.[/*:m][/list:u]

    So to sum up to compile a Mogre plugin for .NET 4.0 my Mogre SDK folder eventually looks as follows:
    Mogre SDK/
    bin/
    Debug.NET2/
    Debug.NET4/
    Release.NET2/
    Release.NET4/
    includes/
    boost/ <-- new, there are other subfolders here as well which I haven't touched.
    lib/
    Debug.NET2/
    Debug.NET4/
    Release.NET2/
    Release.NET4/
    boost...lib <-- boost lib files here in the root of the lib/ folder


    Then from the C++/CLI project I set the additional lib folders to Mogre SDK/lib/$(Configuration).

    One question though, if I add let's say the Mogre.dll from bin/Debug.NET2 as a reference to the C++/CLI project, would that create a problem when I want to compile for Release? Can I then use the resulting .dll from a .NET4 project (i.e with it at runtime work with a .NET 4.0 Mogre.dll eventough it was compiled against a .NET 2.0 Mogre.dll?)

Beauty

21-01-2011 19:55:03

Nice to hear that Hydrax works now.
Also I like that you want to polish up the SDK.

In the Hydrax thread I read that boost can be enabled or disabled. Maybe this can also be done for other parts of Ogre or add-ons.
What's different when boost is used/disabled?
Is there some functionality missing without boost?
(I don't know much about boost. Just that the project offers some free libraries. But I don't understand why we need it, when we can disable it e.g. for Hydrax compilation and Hydrax still works without boost.)

amirabiri

22-01-2011 11:15:20

boost is a collection of various c++ libraries for different purposes which is intended to serve as sort of an "enhanced standard library" in addition to the C++ standard library. In other words it's just a collection of common useful libraries that C++ applications can use.

Ogre's code makes use of boost but in an optional manner, i.e you can turn it off at compile time. However it is turned on by default and I'm guessing that that's done on purpose since it's considered better than the alternatives for those parts of the code where it is used. Because of this I tried to compile Hydrax with it on.

amirabiri

09-02-2011 00:04:43

OK now that I've managed to break the barrier of compiling Mogre, and building my own little "SDK" directory (which is basically like the real one except the Samples are excluded, the include dir is organized slightly differently and includes the OIS headers, and it uses my compiled binaries and includes their .pdb files), and since now I have 4 SDKs: (Ogre, Mogre official, Mogre main my compilation, Mogre TerrainAndPaging my compilation) and since I am now working on various Mogre projects in parallel using different binaries (The tutorials, tutorials framework, tutorials ready projects, MHydrax, my own project and various small "testing" projects) and since generally I've been using Mogre now for a while I was of some changes that I would have liked to see in the SDK and tried playing around with some of these ideas.

The following suggestions are aimed to help newcomers:
  1. Include both VS 2008 and VS 2010 binaries in the SDK (i.e .NET2 and .NET4).[/*:m]
  2. Add Mogre and MOIS to the global assembly cache.[/*:m]
  3. Add Mogre and MOIS to the "Add Reference" window in Visual C#.[/*:m]
  4. Include the tutorials framework used in the tutorials in the SDK.[/*:m]
  5. Create VS project templates for Mogre (empty Mogre project, Mogre tutorials project, Mogre quickstart project, etc).[/*:m][/list:u]

    By adding these to the SDK we can eliminate any ambiguity and confusion for newcomers to Mogre. Instead of referring to various different download locations in different areas of the wiki or the forum, we can just refer to one location and include instructions on the wiki on how to set up a project using the SDK. Tutorials can then more easily start with "create a new Mogre tutorials project" etc. We can (and should) still include instructions on the wiki for how to manually set up a Mogre project and of course how to build a deployment package (that will not require the assemblies to be present in the GAC).

    In terms of implementing these points I have played around with it a bit and I think it's all doable. I am happy to discuss it further. Also some of the points above can cancel each other out, for example if the Mogre project template place all the necessary dlls in the new project directory, there is no need to use the GAC (although that GAC still gives the advantage of saving much disk space).


    The next section is about further eliminating the ambiguity of "which of these binary download links should I use?" and make it easy to use different versions of Mogre (i.e different Mogre SDK versions) in parallel. For example having both the default Mogre SDK and a "TerrainAndPaging" Mogre SDK installed and having the ability to choose which to use. This in turn can help us get feedback for new branches, beta version, etc.
    1. Include the respective versions MOIS with all versions of the SDK or:[/*:m]
    2. Separate MOIS into another installer package which installs MOIS for both VS 2008 and VS 2010 (*)[/*:m]
    3. Make available a version of the SDK for "beta" or branches, for example a version of the SDK based on the TerrainAndPaging branch.[/*:m]
    4. To help implement all of the above: create command line scripts that allow full automation of the Mogre build process (**).[/*:m][/list:u]
      (*) This might be preferable as there is no need for a "TerrainAndPaging" version of MOIS for example.
      (**) This is actually the root of many of these things for me: after compiling Mogre I wanted to automate the process with command line scripts initially so that I can easily repeat the process which is lengthy and currently requires a lot of manual intervention. But later this can be used to run builds in the background on some build server so that for example there is always a fresh version to download after each code commit.


      This last section is intended to help Mogre addon developers.
      1. Include OIS in Mogre SDK includes directory, or if separating MOIS into its own SDK put it there.[/*:m]
      2. Include correct OgreConfiguration.h in SDK that matches exactly how the SDK was compiled.[/*:m]
      3. Include any additional libraries used such that the SDK can be used by plugin/addon developers for Mogre.
        (in other words the above two points mean that if boost was used to compile the Mogre SDK, include its .lib and .h in files in the SDK).[/*:m]
      4. Include all .lib files in the SDK[/*:m]
      5. Separate .lib files from .dll files.[/*:m]
      6. Create a second "development" SDK that adds on top of the first the .pdb files from the compilation.[/*:m][/list:u]
        The last point is very important for plugin developers because it means that they will be able to step into Mogre and Ogre code when debugging native exceptions, which are otherwise a bitch to debug. I'm suggesting this as a separate download because the .pdbs are huge - just the OgreMain.pdb is 100MB and altogether they are 350MB.


        I am not just making a shopping list here - I would like to help with all of this. Specifically the build automation and the Add Reference/project template/GAC which as I mentioned above I already started tinkering with. I wanted to start by raising these suggestions and seeing what all of you think and of course specially the SDK maintainers.

mstoyke

09-02-2011 11:56:50

Argghhl, I just lost a 20-minutes-of-writing post to answer this... Damn internet connection here...
To make it short: Bitbucket -> has new repo / Amirabiri -> has write access
More on this later, gotta go back to work now...

TL;DR: new SDK soon ;)

Beauty

09-02-2011 23:29:02

4 SDKs: (Ogre, Mogre official, Mogre main my compilation, Mogre TerrainAndPaging my compilation)
Maybe it's a little bit confusing for newcomers to have these different types?

What means "Ogre" version? C++ instead of .NET?

What's the difference between official and "my compilation"?
Newcomers should know how to decide.

Maybe many new people think:
Terrain? Nice, I want to try it, so I choose the last SDK.
It's looking like Terrain isn't possible with the other SDK version.
As far as I know the new terrain and paging system is similar to an alpha state. (Not finished, still contains problems.)
So if you offer this version, maybe put "experimental" into it's name or description.


Add Mogre and MOIS to the global assembly cache
I never had thoughts about an ASC. I even didn't recognized that there it is (although I use it).
Maybe this is more easy for newcomers.
On the other hand, I think it's no too difficult to tell newcomers to add references to needed DLL files. This should be common .NET knowledge.
There should be reminders on the related wiki pages and could be additionally to a famous place in the application templates (e.g. main method).
A disadvantage of a "globally linked" Mogre library can be:
When you want to use different DLL versions of Mogre for different VS projects. (e.g. 1.6 for one, 1.7 for an other, a self compiled version for a third, ...)
I think disk space doesn't matter today. (hard drives have many many GBs and Mogre just need some MBs)

The MOIS binary I would add to each SDK. If somebody needs it, he can add a link.

Templates are a good idea. In the templates, the binaries can be still linked.
In my opinion this is better than to add one Mogre dll to the GAC.


The SDK version I would seperate like this:
  1. a basic SDK (target: small download size; Only demos and add-ons with less size amount (*) )[/*:m]
  2. a full (or extended) SDK (contains many useful demos and add-ons, independent of its size)[/*:m][/list:u]

    (*) Especially media files of an add-on or a demo can blow up the SDK size

    The resource files in the SDK could be seperated into basic and additional directories. This would be more easy for integrating them to the related SDK version. Also maintaining could be more easy. (It's better than a "to copy" lists for each build script.)
    Alternatively / additionally create a seperated resource directory for each add-on, which contains media files which are only used by the relevant add-on. This would be very clear.

    Some huge components (e.g. demos / add-ons / pdb files, etc) can be offered additionally by the installer. (The current SDK installer offers to download+install the pdb files at installation time.)
    Or as seperate download file (as you told).

    Disadvantages of component "outsourcing" could be:
    1. For each SDK is a need for a related component. When we have 3 SDKs of each Mogre 1.x.x version, then we would need for each optional component a seperate download link (because of the depency to different Mogre file versions). This could get complex and unclear. For the users and the maintainers.[/*:m]
    2. Don't make it more complex than needed.[/*:m]
    3. Can be much work for creation and documation (e.g. embedd and describe links in the wiki).[/*:m][/list:u]


      run builds in the background on some build server

      The SDKs I wouldn't update too often. Maybe only for each Mogre 1.x.y version or after adding very important components.
      For fresh binaries I just would as "plain binary" packages, not as whole SDK.
      Before publishing a new built SDK all demos / add-ons should be checked (run without exception).
      For SDKs we need no nightly builds. :lol:

      In my eyes an SDK should give newcomers an easy start:
      1. Install depencies[/*:m]
      2. include precompiled DLL files[/*:m]
      3. show demos (for looking and code playing) [/*:m]
      4. offer all needed resource files[/*:m][/list:u]


        However, to have build scripts for the SDK is a fine thing.
        Good would be if it can handle conflicts. (e.g. an add-on doesn't like a newer Mogre version)
        In this case there should be a clear note to the source (which add-on) and a chance to build the rest (e.g. exclude an add-on by a parameter).
        Please don't forget the documentation (inside of the build script source code).

        Maybe for each add-on we could add a check application.
        (Run a special demo with fresh compiled binaries;
        The demo should do some actions and quit the application with a "success" note in a log-file. If the test fails, you don't have a "success" report.
        Easy way: just create an empty .success file. Before calling the checker application, all .success files should be deleted.)


        This post contains just some spontan thoughts of my mind.
        I hope most of them are understandable.
        I'm no guru, so maybe some points are bad points.

Beauty

09-02-2011 23:37:08

Argghhl, I just lost a 20-minutes-of-writing post to answer this
I know just terrible moments!!
Even for my last post this happened again. The back button in my Firefox could retrieve my post content.
Additionally a backup I put to the clipboard before pushing the "preview button".

On my home computer and at work I installed the great Firefox extension
Lazarus: Form Recovery
Never lose anything you type into a web form again! Lazarus securely auto-saves all forms as you type, so after a crash, server timeout, or whatever, you can go back to the form, right click, "recover form", and breathe a sigh of relief.
https://addons.mozilla.org/de/firefox/a ... m-recovery

Just great - one of my most important Firefox add-ons !!

Install it now
and just forget it (no pre-configuration needed).
You will remember automatically when you need it.
-> Right click -> choose recover option -> be happy

Beauty

13-02-2011 00:01:06

OK now that I've managed to break the barrier of compiling Mogre
Some posts about the Mogre build process and amirabiris tool I moved to a new forum topic:
Mogre.Builder - a tool for easy, automatic build of Mogre

Beauty

15-02-2011 22:30:23

Today I noticed that there is a demo application of the GUI system Miyagi.
It presents different GUI elements and you can figure out how they "feel".
This we could (should?) add to the SDK, because it's a powerful Mogre add-on.
I suppose many people like to get to know this GUI.

The binary download here:
http://sourceforge.net/projects/miyagi/ ... p/download

If you like to add this, I think smiley80 will give us the demo source code. (Maybe it's still published.)

smiley80

16-02-2011 09:16:37

Source code lives here:
http://miyagi.hg.sourceforge.net/hgweb/ ... s/Examples

umityildiz

07-06-2011 19:51:45

Ogre v1.7.3 is ready! The new version will be ready when mogre?

Beauty

31-07-2011 13:06:44

A newcomer had problems with Mogre. Then we found out the reason:

He uses Visual Studio 2010 and doesn't has VS 2008.
So he needs the "Microsoft Visual C++ 2008 SP1 Redistributable Package" (with/without SP1 ??).
The SDK depency checker didn't find out, that vcredist 2008 is not installed.
We should improve that point.

Update: Added issue to bug tracker.

smiley80

31-07-2011 14:15:26

Honestly, I think we should ditch the dependency checker. Instead, the SDK installer just (optionally) executes the respective installers.

Beauty

31-07-2011 20:02:57

This could be an alternative.

The DirectX webinstaller is tiny (0.3MB) and vcredist is only 4MB.
So we could include it directly to the Installer (and just offer to execute).
I suppose if the components are still installed, their setup will just quit.

Beauty

11-04-2012 21:00:02

Task:
Add Miyagi example to the SDK (by user Avalox)
viewtopic.php?p=98806#p98806

MouseTaylor

06-07-2012 21:39:20

Question, is there any development done on the next version of Mogre3D?
Since the Ogre SDK is already live with verison 1.8 and with 1.9 &2.0 announced, Mogre is lagging behind.

Any knowledge about this?

T.

Patrunjelu

04-08-2012 18:11:27

Hi,

This the thread to post (possible) Mogre bugs, right? I tried running the code found here:
http://www.ogre3d.org/tikiwiki/tiki-ind ... Tutorial+5
under OpenGL, and when it's time to dispose of all resources and exit the application, an AccessViolation exception is thrown:

System.AccessViolationException was unhandled
Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Source=Mogre
StackTrace:
at Ogre.Root.{dtor}(Root* )
at Mogre.Root.!Root()
at Mogre.Root.Dispose(Boolean )
at Mogre.Root.Finalize()
InnerException:


further exception info in the screenshot:
http://i48.tinypic.com/ir6no4.jpg

While using Direct3D9, no exceptions are thrown, i.e. everything works perfectly. I'm running the latest (beta) version available on the website, under Windows 7 Professional x64.
I'm not sure if this is a Mogre related bug, an OpenGL related bug, or a Mogre->OpenGL interface related bug. You're the experts here :)
In case I can help you with any other kind of info, let me know.

Brocan

20-11-2012 10:36:23

Any plans to support Ogre 1.8 soon? Someone is working on it?

Unfortunately i haven't enough experience with C# and wrappers to do myself :cry:

durium

11-05-2013 00:57:24

@Patrunjelu I ran into the same problem and the solution is to add
this.mRoot.Dispose();
in the Shutdown function

@Beauty or @amirabiri (since he owns the Mogre.TutorialFramework repository) could you add this to the Mogre.TutorialFramework class so that the mini-framework doesn't crash on shutdown ?

Lexer

14-04-2014 13:10:07

I'm going to have a look at MOgre Source, and see if I can update it to 1.9.
I have all the C++/CLI knowledge, now I need to find time to work on it. So right now it's "I may update it, but don't get too hopeful" :wink:


Beauty, any advises, infos are welcomed. I've just sent a pm.