What is the easiest version of Ogre to get running?

[Bob2000]

Hello, I am looking to use Ogre graphics for an application, but I have had some trouble getting a few different versions up and running. I have tried v13.5.3 but had to deal with some weird class reference issues. I have also tried 1.10 because it was recommended on another forum, but its documentation is probably a little out of date by now. I am self-taught, and not extremely savvy in c++, so what's the best version or setup in 2023 for getting everything up and running?

PS - Using a NuGet package manager is not off the table for me.

[rpgplayerrobin]

Here are my notes on how to build Ogre:

If anything goes wrong (it shouldn't), check for new information here: https://ogrecave.github.io/ogre/api/lat ... -ogre.html

Go to https://github.com/OGRECave/ogre/releases and download the latest source release.
If you want an older release, go to: https://github.com/OGRECave/ogre/releases and download it instead.

Extract it to C:\OgreSDK\ogre.

Open CMake and use these settings:
Where is the source code: C:/OgreSDK/ogre
Where to build the binaries: C:/OgreSDK/ogre/build
Press Configure and choose Visual Studio 2017 with x64.

Check the log and look for this to see if everything is correct:
-- The following external packages were located on your system.
-- This installation will have the extra features provided by these packages.

• freetype
• OpenGL
• OpenGL ES 2.x
• DirectX9
• DirectX11
• pugixml
• zlib
• Assimp
• SDL2

Press Configure again.
Press Generate and close CMake.

Open the Ogre sln file.

Compile the ALL_BUILD project in debug.
Some unimportant projects might fail.

Compile the ALL_BUILD project in release.
No projects should fail.

Compile the INSTALL project in release only (and only once, never again).

[Zonder]

You mention NuGet are you using .NET then?

[blitzcoder]

I'm trying to do some quick test with Ogre using Visual Studio through NuGet.

The most latest package there is v1.8.3, but there are no accompanying examples to try it with.

https://www.nuget.org/packages/ogre3d/

[rpgplayerrobin]

It seems Mogre is very outdated and not supported anymore from this link: https://wiki.ogre3d.org/MOGRE

It seems that Ogre 1.11 and later has bindings for C# instead, that makes Mogre completely depricated:
https://www.ogre3d.org/2018/12/20/ogre- ... al-release

Though I am not exactly sure how to build it, but there are some instructions here that might help:
https://github.com/OGRECave/ogre/tree/m ... les/Csharp
https://hellholegames.wordpress.com/201 ... evelopers/

But it seems that version also does not have any samples for C#, but I am not 100% sure.

If you are not stuck to C# I would just recommend using C++ instead if you already have Visual Studio, there are many samples there and the code is tested very well compared to the C# version.
Also, C++ supports more platforms than just Windows, and it is faster than C# as well.

[blitzcoder]

@rpgplayerrobin

Thanks for the info.

Yes, I'm talking about the C++ packages and NuGet is not specifically all .Net.

I have my previous setups and installations, but they are built with VS2010s and 2008s.

Note: the package there is also labelled 1.8.3, but the release is 1.8.1.
https://www.nuget.org/packages/ogre3d/#release-body-tab

[rpgplayerrobin]

Ah I see! I thought it was only for C#.

What is the Ogre version and Visual Studio version you want to use?
Because all Ogre versions do not support all Visual Studio versions.

For example, I use Visual Studio 2012 for a Ogre 1.9 project.
But for Ogre 1.11+ projects I have to use a higher version of Visual Studio, and there I use Visual Studio 2017.

Instead of using the old 1.8 version of Ogre through NuGet, head over to any of these links instead:
Current: https://www.ogre3d.org/download/sdk/sdk-ogre
Very old versions: https://github.com/OGRECave/ogre/releases?page=7

[blitzcoder]

Right now and so far I got back to download and build the 1.7.1 + MinGW samples again w/o a hitch.

I would prefer using GCC/MinGW this time and hopefully porting my VS Ogre projects, though I'd willing to try with 2017 prebuilds when I get a chance.

For example, I use Visual Studio 2012 for a Ogre 1.9 project.

Nice and yes, I can push into 1.9 or even the 1.1x once I got something going again. It's been almost a couple of years since I did some Ogre stuff.

I have VS2013 which I see is caught in the middle and don't have any prebuilt versions available, or perhaps the 1.9x VS2012 sdk builds could work?

[rpgplayerrobin]

I have VS2013 which I see is caught in the middle and don't have any prebuilt versions available, or perhaps the 1.9x VS2012 sdk builds could work?

I have no idea if that would work.
The general rule is to use the exact same build method for everything, otherwise you might encounter errors or crashes that are only because you did not build with the correct version of Visual Studio.
So if the 1.9 SDK is built with Visual Studio 2012, I would not try another Visual Studio version than that. But you can try.

I even had problems using the same version of Visual Studio 2017 when building Ogre and my own project with it, because on some projects I used a different "Windows SDK Version" (found in General under project properties) than what I built Ogre with.

So if I were you, I would just instead just build Ogre myself and have the exact same compiler and version for both your project and for your Ogre version.
That way, you can also solve bugs in Ogre, because there are many bugs that has been found since Ogre 1.9.
Or you can just upgrade from Ogre 1.9 and never look back.

Some of the major bugs that has been fixed since Ogre 1.9 that I remember right now:

• Particle emitters did not have a uniform random direction, even when specifying 180 degrees. You can try this yourself by just making a particle emitter with 180 degrees and a lot of particles coming from it. Instead of it looking like a perfect sphere it looks like a line, since the direction is not uniform.

• Lights and shadows had a lot of bugs, like the shadow map did not follow the same index as the light itself (because it sorted them wrong), and that the orientation of the light (for spotlights) did not correctly follow the shadow (it instead used setDirection instead of setOrientation).

• Ogre used OIS for input instead of the new way of doing it (SDL2 input). That meant that a lot of key inputs were extremely hard to handle, like "ÅÄÖ" and stuff like "^". Many inputs were also stopped outside of the application because of OIS, and I still cannot write "^" anywhere on my computer if I have the old Ogre 1.9 application running in the background. It has to specifically be handled in many ways and OIS was really not a good system.

• Ogre used a lot of CG for shaders, but CG has a lot of issues. Before I completely removed CG from my game I used it a lot and I had to fix the automatically generated glsl shaders that CG made, in my user code, since it just compiled them wrong for many of my shaders.

• Also, Ogre 1.9 does not have any support for Direct3D11, which means it lacks a lot of things you can do if you only support Direct3D11 in your application.

[blitzcoder]

Thanks for the heads up with the bug list, this will be handy and helpful to fast track with a lot of ogre stuff.

I just need to go back to basics first and jump start some projects off the shelf. I see, planning with DX9 only for now.

[blitzcoder]

Ogre used OIS for input instead of the new way of doing it (SDL2 input).

OIS seems to be still maintained with the latest update 10 months ago:

https://wgois.github.io/OIS/
https://github.com/wgois/OIS

I just did a quick cmake test and it seem to now require Windows SDK instead of the old DirectX SDK.

Dependencies: DirectX SDK (now part of the Windows SDK)

[paroj]

is there a particular reason why you stick to Ogre 1.7? Ogre 13 should be mostly API compatible when you set
OGRE_RESOURCEMANGER_STRICT=0
OGRE_NODELESS_POSITIONING=1
https://ogrecave.github.io/ogre/api/lat ... otoc_md270

[rpgplayerrobin]

is there a particular reason why you stick to Ogre 1.7? Ogre 13 should be mostly API compatible when you set
OGRE_RESOURCEMANGER_STRICT=0
OGRE_NODELESS_POSITIONING=1
https://ogrecave.github.io/ogre/api/lat ... otoc_md270

I mean, I get it. It takes a while to upgrade and fix things to the new way of doing it in the new version.
Almost every time I have done it, it has taken over 10 hours to even get it up and running, like any of my previous posts regarding upgrading:
viewtopic.php?p=536120#p536120
viewtopic.php?p=552800#p552800
viewtopic.php?p=552600#p552600

Between some versions it even requires a new IDE, like using Visual Studio 2017 instead of Visual Studio 2012 (if I remember correctly, Ogre 1.9 uses 32-bit and Ogre 1.10+ uses 64-bit and C++11).

I even have a game made by me and my brother on Steam that is still using Ogre 1.9 because it would just take too much time upgrading it to the newer version (and that we see no point currently in upgrading it):
https://store.steampowered.com/app/921070/Spellwake/
It is a very ugly game though since we are both just programmers

But if you go all-in on a project, with a full team, the newer versions should be used instead of 10+ years old versions like we are using for Spellwake.

[blitzcoder]

is there a particular reason why you stick to Ogre 1.7?

Mostly I'm just picking up where I left off for some ogre stuff that I did way back and they are build with 1.7 and a few with 8 and 9.

rpgplayerrobin also got a point there.

Ogre 13 should be mostly API compatible when you set
OGRE_RESOURCEMANGER_STRICT=0
OGRE_NODELESS_POSITIONING=1
https://ogrecave.github.io/ogre/api/lat ... otoc_md270

eventually I would need to update gradually so that's good to know and some valuable info, thanks.

[blitzcoder]

@paroj

Does Ogre3D 1.1x now compile with MinGW64 64-bit?

just tried with 1.9, but getting the same error here: viewtopic.php?t=79937

[paroj]

Does Ogre3D 1.1x now compile with MinGW64 64-bit?

yes

[blitzcoder]

Does Ogre3D 1.1x now compile with MinGW64 64-bit?

yes

Good to know.

[professor_oats]

Here are my notes on how to build Ogre:

Hi! I am trying to follow this process of building OGRE but in the configure step the CMAKE always hangs/freezes
when building freetype. Then if I cancel and rebuild it hangs/freezes at SDL.

Until now I have managed to get a solid build of freetype at one point and then added SDL2 to the build/out manually.

I would like to get it working since I only managed to build for Release last time.
I am pondering whether the configure actually hangs/freezes or if I am just impatient but
on my processor it shouldn't take hours.

Any suggestions?

I am building for Windows 10.

[professor_oats]

Quick update:
My current process in building is to build freetype and SDL2 first - it works and finishes quick.
Now the train of thought is to take these singular builds and put them into the build folder of OGRE,
and then I kind of would like to generate a ogre.sln that includes the builds of freetype and SDL2 so I
compile the ALL_BUILD and then INSTALL.

I think this is the best solution and an alternative, in case it is unmanaged, I think of compiling the freetype and SDL2
separately with debug and release and I guess that gives the .dll that can do debug and release and just add it to the OGRE project files
afterwards? #headache

[professor_oats]

I think it shall be all good for now.
I got debug for the sdk + dependencies except Assimp and Bullet. It's a good starting point.