New Graphics Engine for Orxonox

[patrick]

Shoud we change to a new Graphics Engine? If we want to get professional: I think yes. Let's use a library that supports all our current features and models and adds all the other nice to have features to it!
(look at this thread for more informations, reasons).

I suggest creating a task-force that evaluates how much work it will take to replace the old system with the new engine and shows pros and cons.
Objectives for task force:
- how much work will it take to replace engine
- pros/cons of replacing engine
- which open source engines are available, suggest two possibilities to the orxonox community.


I'm in, who wants to join the "New Graphics Engine Task Force" too? I think one/two more person would be good.

[beni]

Without much thinking I would agree: Yes, we should consider a new graphics engine for Orxonox. Although in my opinion graphics aren't what makes a game a great game, the optics is the first thing you "see" when you're playing a new game. It's all about the presentation and the show and that's graphics.
Of course I'm open to change my opinion, if we find out, that the cons outweigh the pros.

Good idea with the task force. I think I'm not in for it, though, because I haven't been working on or with any part of the graphics engine yet, but I would love to learn more about it.

[x3n]

Hm... hard question.

In my opinion, an new grafics engine brings pros and cons.

+ The game gets faster
+ More features (bump mapping, glowing, ...)
+ Less bugs (transparency (will forever be a problem with our engine I think), z-Buffer (remember the turret-explosion problem at the end of this semester))

- Having "our own engine" makes orxonox exceptional
- After the reimplementation of the world entities and the grafics engine (oh, and the sound engine is unfinished too), we'll have in fact a new game - this will be MUCH work. And that can't be done by PPS-students, that's for sure.
- A new and better grafics engine means: no more 1000 polys restriction for models - 10'000 at least, why not 100'000 for the players ship? Who is willing to do so much work?
- Bump maps and shaders everywhere in the FPS level; but I have no idea if this is possible with the GTK-radiant. Oh, and the textures will have to be 1024x1024 + special layers for all sorts of shaders.


Conclusion: A better grafics engine is a good idea, as it brings a lot of new possibilities and less problems.
But it's also a lot of work if we want to use this features and remember - we already have way too less designers. Actual game-studios have approximately 90% designers and 10% coders.


As I said: Hard question...

[Marc]

I got the link to this post from Nicolas


So I hope its ok if I write here my point of view:

While a new engine would offer new stuff, this does not mean that one has to use it. Already the possibility of any other engine for the following things is already more than a simple reason to consider the switch:

- Better format support. MDx is nice but is the worst possible choice for a space shooter where in object hiearchy would be needed
- Larger community -> better tested, bug fixed and especially better toolset and art pipeline.
- More potential for the programers to actually program something instead of just running around going mad because the engine inconsistency force him to fake and trick and bypass the way things are meant to be handling.
I spend 50% and more of my time fixing and faking stuff instead of implementing the character system and weapon systems together with Nicolas.

As I've seen how some of the things caused some major problems in the winter PPS, I would suggest having a look at irrlicht, as it is a tested crossplattform 3D engine, with great format support and very useful format support as well as some special tools (like irrEdit which would allow real levels and graphic people to design them, not XML hack)

OGRE would be nice as well but has 2 drawbacks.
1. Its hard to get into it and especially to integrate it into Orxonox
2. Its only graphics, nothing more. As Orxonox problems are larger than just the graphics backend, this would cause further extra work ...

[beni]

Reading your posts I guess the pros and cons depend on the engine we want to use for replacement. Of course there is the general question if we want to replace it in the first place, but I think we need more than just two suggestions from the task force.
I'd like a little research about the most common graphic engines around regarding support, accessibility, cross platform possibilities and also how much we have to replace in the end, only a few new libraries we can use or major changes in the structure. I guess those first two points patrick mentioned should be handled for each considered engine.

[patrick]

Thanks for all your feedback (especially for marc to come back to us for this ). From your feedback I can see, that there is interest in replacing the engine.

For me the most important reason to switch engine: we will have a stable, well documented, easy to learn, easy to work on engine.

Beni is right, we need to take a more generic approach to this problem. My suggestion of how to move on:

1. look up all possible open source engines available
2. define criterias used to estimate which engine is best suited for us
3. get suggestions from experts: write/read in different forums about this topics, ask the developers themselfs
4. read engine documentations, specifications, features. compare to our criterias
5. estimate which classes in Orxonox are most critical to graphics engine changes, which will be replaced, which could become ambiguous, which need to be updated. This will allow us to distribute the work for this change more easily
6. suggest _one_ engine to community (second candidate is our old engine)
7. vote about it
8. create a more detailed work plan
9. train developers to use new engine (show tutorials)
10. assign tasks to developers

So who's with the task force team? I need 1-2 people that have about 4h time in the next week to have an irc/skype session about points (1..2), then we will assign engines to people in the task force (point 3, 4). We'll have another irc/skype meeting after point 4. point 5 is done by myself and volunteers. We will meet again for point 6 one week later (irc, skype or bbq ).

join the force

[Nowic]

I don't think changing the engine is a good decision for this project. Of course less bugs, a good documentation and a big community are great, but:

- Most open source engines have all the features that we'll ever need already implemented. So what coding challenges will be left for us and the students? Only scripting game logics?

- Are we (and the students) able to create content for these advanced engine features? No, we can't! We don't have enough artists and time. So Orxonox wouldn't look much better.

But you seem to be very motivated... so some engine suggestions:

* http://www.crystalspace3d.org/ 1.0 released, mature, C++, used by commercial game developpers too, LGPL license, great blender integration. see: viewtopic.php?t=89 (Blender as a Game Developement Environment)

* http://sauerbraten.org/ Cube 2 Engine (Sauerbraten) with realtime ingame level editing features. (zlib license)

* http://www.ogre3d.org/ Already mentioned, LGPL, C++

* http://irrlicht.sourceforge.net/ Irrlicht Engine, zlib license, C++

* http://en.wikipedia.org/wiki/Quake_III_engine Quake 3 engine, GPL

* http://g3d-cpp.sourceforge.net/ G3D, BSD license, C++

* http://nebuladevice.cubik.org license?, C++

nowic

[patrick]

Hi nowic. I understand what you mean. But after some years of engine programming, I have seen how much work it takes to reach our level and more: I know how much it will take us to get to the next level.

Now, that Bensch has left the team and I am doing my master thesis, without documentation it can become very frustrating to develop orxonox. A standardized, well documented engine will definitely help everyone and make life easier. And I'm also very much interested to see how other open source projects are looking into this engine development problem

There are still enough things to implement. I would say the things that actually make a game. Of course we won't exploit all features of a new graphics engine. But it's good to know, that we could do that if we wanted to...

[patrick]

This is a very good source for all sorts of different libraries related to gaming:

http://www.twilightsembrace.com/personal/gamelibs.php

[patrick]

An example of how simple it could be to open a BSP and walk in it:
http://irrlicht.sourceforge.net/tut002.html

[beni]

An example of how simple it could be to open a BSP and walk in it:
http://irrlicht.sourceforge.net/tut002.html

Well that's irrlicht. It may not be that simple with Ogre or Crystal Space. But we'll see this at the think tank.

[patrick]

Let's focus on three engines:
- crystal space
- ogre
- irrlicht

They are all awesome, so let's compare them at the convention.

[beni]

As far as I know we have following people working on those engines on those OS:

Nowic - Crystal Space - Linux (Ubuntu)
x3n - Ogre - Windows
nico - Ogre - Linux ?
Beni - Crystal Space - Windows

Although I don't know if hofzge works on Crystal Space on Windows. In this case I can work on Irrlicht of course.

[patrick]

Well organized!

I don't think that Hofzge is working on Crystal Space on Windows, since he doesn't like coding work too much. Please correct me if I'm wrong.

I will also be able to take a look at eigher
- Crystal Space + Windows
or
- Irrlicht + Windows

Beni: tell me what you prefer to work on, I will take the other

[hofzge]

This is very much the truth. altough I have installed Crystal Space and Cygwin, I have not yet tried to get it working, as I don't like computers so much. They are in every way inferior to handheld game consoles of the 80ies.
I will try to get it to work, but nothing else, as I have a manual for that...