Ogre on Windows

[x3n]

I tried to compile the ogre engine on windows. It didn't worked with the source version because of several missing dependencies (like quicktime and other crap), but it worked with the precompiled SDK. The SDK includes all needed libraries for compiling an ogre-engine-project, but it's (obviously) not possible to change the sourcecode of the engine.

I followed the "build ogre-SDK with mingw in eclipse"-tutorial and it worked without problems (it's important to uninstall mingw and install the modified "mingw c++ toolbox" version, which is specially compiled for ogre, look into the tutorial for further informations).

I compiled a simple bsp-example-code in about 10 seconds and it worked fine. Now I'm playing with the uncountable possibilities of this engine, but it's very difficult as I have absolutely no knowledge about ogre.

From what I see know it will be much work to build orxonox v2 on ogre, because ogre has many features we implemented on our own (bps, camera, particles, ...), so we'll have to replace them with ogre. But it's still much easier than it would be with a totally new game engine (ogre is only a graphics-engine).

I hope it's possible to work with the SDK because its very easy to start coding something for orxonox (install eclipse, mingw, msys and the ogre SDK, check out the orxonox svn rep, download our projectfile for eclipse and start coding, thats much easier than it was with orxonox v1 and dependencies like qt). Building ogre from source will be much more work, because there are several dependencies. I found a source with precompiled libraries, but it didn't worked, maybe because they're outdated. If we really need to compile it on our own, this will cause much work.


Finally a screenshot of the latest hangar-bsp-level in ogre (Direct3D rendering), 1024x768x32 and 4xAntialiasing (click for larger image):

[Nowic]

Looks great! Please add your evaluation to: http://dev.orxonox.net/wiki/3DEngineEvaluation

Many Linux distribution have ogre packages too. But I don't know if they aren't outdated.

http://packages.debian.org/source/sid/ogre
http://packages.ubuntu.com/feisty/source/ogre

[patrick]

Guys you do awesome work! I will enjoy contributing Irrlicht engine topics.

[nicolasc]

Many Linux distribution have ogre packages too. But I don't know if they aren't outdated.

Fair point, but I guess you will have that problem with every engine you choose.

Gentoo, Debian (sid and lenny), ubuntu (upcoming gutsy) seem to be pretty up to date.

I guess we have to add some requirements to the install description, and howto for configuring a proper environment.

I personally need to still get in running on linux. there are some configuration issues left to deal with.

cheers
nico

[x3n]

I've spent several hours playing with ogre. It's a really cool engine. For example I hacked a flashlight into the tutorial code, so a 3D model that gets lightened by the flashlight casts a shadow on all models behind.

But I encountered some problems too. The BSP level runs very quickly with Direct3D 9 rendering (~DirectX 9), but with OpenGL it's 10 times slower. That's no problem on windows, as all windows users have DirectX. But if OpenGL works that bad on linux too, we'll have to take another engine.

More problems: The BSP implementation seems to be really old. In fact it's only a "Q3 bsp level importer" which is good for us, as we use the same format, but its about 7 years old and therefore has not much actual features (the flashlight didn't worked with the bsp model ).
You might have noticed that the hangar level is way too bright with ogre (to compare: The hangar in orxonox). I guess it's displayed correctly in ogre and it was all the time too dark in orxonox, but I've found no possibility to change the illumination of the bsp model in ogre (even orxonox had more features). I could simply change the lights in GTK Radiant, but this example shows the poor implementation of BSP in ogre.

I've read in the ogre forums that they consider to drop the BSP support in future, "because the Q3 level format is outdated". They're right, but BSP is not just used by Q3. It's maybe the most common format for all indoor levels.
Ogre seems to be more an outdoor engine than an indoor one. It's great for games like "Ankh" or "Jack Keane" where the developers just put some meshes from 3dsmax together.

My conclusion:
Ogre is a great engine for outdoor games. This includes the spaceship part of orxonox which is maybe 75% of our game. It works too with BSP (at least on windows, I hope nico will report his experiences on linux soon), but we won't be able to build a next doom/halflife with it, as the indoor support is rather bad.
BSP levels run maybe 2-3 times fast than with our old engine, that's good, but there's probably no chance to implement actual features like dynamic lights, bumpmaps and projectors. Maybe it IS possible, but I found no simple way in the past few hours. It might be a good idea to ask in the forum if it's really like that, but I first want to read your experiences with other engines (and nicos with ogre on linux).

[beni]

Your work is very nice. I'm really looking forward to moving pictures. We have two possibilities if we would choose Ogre:
1. Drop BSP as well and try to build indoor levels with normal formats (should be possible, right?)
2. Try to implement the features from Orxonox in Ogre so we can use the BSP how we were used to.

[x3n]

Don't get me wrong, it's faster then our old engine (ok, at the moment there are no particles and rotors in it, but it's still faster). ogre has ~50 fps on the screenshot above while orxonox is somewhere around 15-20 fps or even lower (orxonox claims to run at 30 fps, but Fraps said 15 ).

But BSP in ogre is no revelation ("offenbarung"), it's not the non plus ultra graphics engine that runs at 200 fps with shadows and bumpmaps and a dozen dynamic lights.

I don't know what you expect from the new engine, but I'd like to have dynamic lights and shadows in the indoor levels. Sneaking with a flickering flashlight at low batteries through a deserted spacestation full of unknown creatures and mean alien technology, surrounded by frightening sounds and then - plop - the flashlight wents out and all you can see is a pair of glowing eyes coming nearer... That would be a lot of fun (or fear ), but from what I see now it's probably not (easy) possible with ogre.

So, to modify your 2 points, our possibilities when choosing ogre are:
1. drop bsp and build indoor levels in a different format (but I HATE blender )
2. abandon our doom4 visions and let the game as it is.

[x3n]

I downloaded and compiled the Irrlicht engine on windows (wow, that was REALLY easy, I had nothing more to do than opening the Code::Blocks project file and start compiling). The BSP implementation in Irrlicht is as easy as in ogre, but it was much slower. Maybe that's just because Irrlicht seems to have a problem with the large hangar level ("Could not draw triangles, too many primitives(83612), maxium is 65535"), so it clipped away some triangles which might result in leaks and therefore the bsp format is useless, but neither orxonox nor ogre had such limitations, so my first impression is: ogre > irrlicht.

I'll do further tests (shadows ) tomorrow, so stay tuned.


The hangar level in Irrlicht on windows (click to enlarge image):


As you can see it's as dark as in orxonox (that's good, so probably ogre is too bright), but the contrast ist higher.

[x3n]

And this is the same level displayed by the graphics engine "G3D" (I only downloaded the binary and started the BSP demo, so I can't say anything about compiling). As you can see it's even brighter than ogre. The lightmaps look sometimes strange, but it's the first engine that displays most of the transparent textures correctly (compare the texture of the bridge in all 4 screenshots). I had only ~30 fps, thats as good (or bad) as Irrlicht, but in other parts of the level G3D was much faster than Irrlicht (and had no strange limitations), so: Ogre > G3D > Irrlicht.



(click to enlarge)


List of all screenshots:
- Orxonox (original)
- Ogre
- Irrlicht
- G3D

[bensch]

Awesome work guys, so, might it just be, that ogre and g3d are just rendering the lighting properties differently? Maybe they just have a multiplication factor in their lighting properties?

Rebuilding or adaptin the ogre BSP renderer for the needs of Orxonox.v2 might be a cool topic for someone more involved in coding work, and helping the community is probably the best way to get into a new engine

Anyways, awesome work!!

[patrick]

I agree with Bensch. If you find out that Ogre3d really is superior to all other engines, we might consider helping them work on the bsp level format.

I see much potential in bsp since it supports material description in text format which allows very simple extension. And we have such awesome levels already built in bsp... it would be a huge loss for Orxonox!

What would be the logical follower to the bsp level format?

[hofzge]

Way to go! I just wanted to thank x3n for his awesome work! Thanks!

I have no idea if bsp is an up-to-date thing, but as patrick pointed out, it would be a big loss, if the levels had to be dumped...

[x3n]

Thanks for your feedback

Yes, it might be very interesting to enhance the BSP implementation in Ogre (or in another engine).

As Patrick pointed out it's easily possible to play with the materials in a BSP file, so it might be easy to add bumpmaps and other cool effects (I like environment maps for shiny materials).

What would be the logical follower to the bsp level format?

Well, I'm not 100% sure but I think that today maps are built in the following way:
1) Build a simple BSP map to separate rooms and corridors
2) Create meshes with a 3D tool (blender/maya/3dsmax)
3) Put the meshes into the BSP map

Those meshes are wallings, floors, machines, everything organic (vegetables, alien technology, ...) and simpler things like handrails or pipes and cables. Or in other words: 99% of what you see in an actual first person shooter.

The BSP map is only in the background. The meshes are attached to the BSP map, which means: If a part of the BSP map is not rendered (for example a room behind a wall) the meshes in it are hidden too.

We could build orxonox maps like that, but I guess none of the engine above is able to do this by default. But the much bigger problem is: Who builds the meshes in blender? I won't, I'm no designer, to be honest: I don't like blender. I'm almost unable to handle it. I can build bsp maps by chance, but that's all. Maybe I could do it with another editor that's less blender-like and more bsp-editor-like, but that's another topic.

[patrick]

We could build orxonox maps like that, but I guess none of the engine above is able to do this by default. But the much bigger problem is: Who builds the meshes in blender?

x3n pointed it out: Simplicity should be our strength. My vote is to stick to bsp maps.

x3n: Only some remarks about bsp+ogre:
- is it possible that ogre doesn't support light-maps from bsp files? this could be the reason why it's so shiny. This could potentially also boost the bsp performance.
- performance: in the ogre engine you use 4x antialiasing and the performance is nevertheless almost double compared to other engines? That would be even more impressing...

[x3n]

My vote is to stick to bsp maps.

+1

- is it possible that ogre doesn't support light-maps from bsp files? this could be the reason why it's so shiny. This could potentially also boost the bsp performance.

No, the lightmaps are displayed. You can see some shadow structure on the walls and the floor and, even more important: The green light is visible (without lightmaps there would be no color on the walls).

- performance: in the ogre engine you use 4x antialiasing and the performance is nevertheless almost double compared to other engines? That would be even more impressing...

I think antialiasing runs completely on the graphics card and therefore it costs only ~2-3 fps (I tested it).


The big issue with ogre is the performance with OpenGL (~20% of Direct3D) on windows. I pray OpenGL runs better on Linux.

I might add that I've tested Irrlicht only with OpenGL, because the Direct3D support didn't worked yesterday (Irrlicht complained about some missing libraries) and I have no idea which renderer was used by G3D, so maybe my ranking would look completely different with other renderers. Further tests are necessary.