Jump to content

  • Log In with Google      Sign In   
  • Create Account


Graphics engines and middleware.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Simon_Roth   Members   -  Reputation: 149

Like
0Likes
Like

Posted 08 November 2011 - 01:04 PM

Hi

I'm currently studying the state of graphics engines and middleware to decide on the direction for a major indie title I will be working on. The current engine of the studio is a well known, stable, commercial engine, but has been left behind in the DirectX 8-9 era and would need to be significantly rewritten to hit the requirements of our new project. We are looking at things like many dynamic moving light sources (so probably differed lighting), soft shadowed point lights, large amounts of reflections and a heavy emphasis on costly post effects such as motion vector driven blur.

Currently I am thinking of just writing my own renderer from scratch. This doesn't phase me, and due to the very specific brief of the project, I can literally build what I need.

That said, it would be foolish not to consider every other option. What rendering engines do people recommend?

I've looked at Ogre and it seems promising, however I havnt seen it proven commercially. I'd worry that integration would also be a pain in the ass, since we'd need to mash it in with the current engine.

Any pointers would be great. I'm considering anything from small open source solutions (preferably MIT license or similar since releasing source can raise problems) to larger commercial systems, such as Englighten(standalone). Platforms are PC, Ipad and perhaps consoles depending on platform holder whims.

Cheers

-Simon

Sponsor:

#2 PolyVox   Members   -  Reputation: 708

Like
1Likes
Like

Posted 08 November 2011 - 05:24 PM

I would also be interested in knowing about any lightweight open-source graphics engines. I'm not so interested in full game engines as there are lots of those, and I'd rather handle integration myself. Some ones that I've found include:

Horde3D
Visualization Library (Ignore 'visualisation' in the name - it actually appears quite low level)
Linderdaum (more restrictive license)

#3 Simon_Roth   Members   -  Reputation: 149

Like
0Likes
Like

Posted 09 November 2011 - 04:15 PM

I would also be interested in knowing about any lightweight open-source graphics engines. I'm not so interested in full game engines as there are lots of those, and I'd rather handle integration myself. Some ones that I've found include:

Horde3D
Visualization Library (Ignore 'visualisation' in the name - it actually appears quite low level)
Linderdaum (more restrictive license)


Cool those are useful thanks.

I've found out today that Torchlight is using Ogre and Hand circus used it on their indie titles. Whilst they are hardly huge developers, its useful to see it in production and working well.

Heres what I've jotted down this evening on the pros and cons of Ogre I've seen at a quick glance.

Ogre:


Positives features

Multiplatform abstraction. The code base would be platform agnostic, and allow DirectX and OpenGl builds. This will be of specific help for more difficult platforms such as the Ipad.

The code base is mature.

The source is free and documented.

The licensing is an MIT license, which is flexible and does not require source code redistribution.

There are some third party tools that integrate with the engine, to allow asset loading etc. These could replace the need for using <redacted engine> formats and remove the need for conversion in engine. These tools are unofficial however so may not be entirely useful.

Negative features

By specification, features must be implemented on both DirectX and OpenGl, this leads to a situation where specific technologies fail to overlap and gaps are left in the API.

The multiplatform abstraction is large and consists of two major classes. These are almost impenetrable so would leave us in a difficult position were we to need lower level functionality or hacks for the Ipad. It also create a lot of redundant function calls, eating CPU cycles unnecessarily changing state.

The animation system is robust, however does not include physics based animation. This would lead to issues of integration when a 3rd party solution is found, potentially requiring much work.

The scene management would be largely obsolete as the game and <redacted engine> will provide that and is matured in the in-house development pipeline.

As a personal observation and its maintainers. Few of the developers involved work in rendering technology in the games industry. This means that the engine may make assumptions on its use that are incorrect in real time development. Eg proper object abstraction vs performance.

If we modify the engine we may have to spend time committing our code back to the main project or risk creating a fork that is incompatible with the trunk patches and updates.

Although many small independent projects have been released using the engine, few AAA quality projects have employed it. Torchlight is one such game. The graphical style does not use dynamic lighting and is heavily dependant on high quality art assets. Indeed early developer posts indicated that a fix function pipeline was used.



#4 L. Spiro   Crossbones+   -  Reputation: 12334

Like
2Likes
Like

Posted 09 November 2011 - 07:01 PM

I would roll my own.
And this is not just due to my biased desire to write game engines, but because you said yourself that it is possible to do exactly what you want on your own, and that eliminates the risks, hassles, and limitations of other renderers.
Plus the fact that you mentioned iPad. It isn't like you are going to be writing a Frostbite 2 renderer.

This is something small enough to manage in-house and directly meet your needs, and furthermore give you a foundation on which you can improve as you see fit in the future.


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#5 quiltkickkiller   Members   -  Reputation: 96

Like
0Likes
Like

Posted 09 November 2011 - 08:15 PM

I would roll my own.
And this is not just due to my biased desire to write game engines, but because you said yourself that it is possible to do exactly what you want on your own, and that eliminates the risks, hassles, and limitations of other renderers.
Plus the fact that you mentioned iPad. It isn't like you are going to be writing a Frostbite 2 renderer.

This is something small enough to manage in-house and directly meet your needs, and furthermore give you a foundation on which you can improve as you see fit in the future.


L. Spiro


I agree. I'd rather code from scratch rather than use so much middleware help. As difficult as it sounds, it's more convenient for you.

#6 Ingenu   Members   -  Reputation: 812

Like
-1Likes
Like

Posted 10 November 2011 - 03:42 AM

Check Unity 3D, if it doesn't suite your needs, write your own.
(And go for simplicity, advantage of Unity 3D is that you have the tools...)


-* So many things to do, so little time to spend. *-

#7 AgentC   Members   -  Reputation: 1233

Like
1Likes
Like

Posted 10 November 2011 - 08:56 AM

At least in the field of permissively licensed open source, graphics-only engines, and particularly if it would need to support advanced features like you listed, I honestly am not aware of anything good or flexible enough to recommend.

Ogre3D, in my opinion, would need a major cleanup for its legacy of fixed-function support, outdated shadow techniques, and plain inefficiency when it comes to issuing rendering API commands (debug an Ogre scene with PIX and you'll see). Getting it to render deferred does not come naturally. Plus it really, really likes to throw exceptions for easy problems (like querying for a nonexistent bone or animation) while for anything more devious, such as trying to parent nodes cyclically, or losing track if you already attached/detached an object from a scene node, it will crash.

I admit, doing those kinds of things are severe API usage errors, but when for example exposing Ogre to script, catching them in the engine code itself would be preferable than having to catch them in a script wrapper to prevent a script from crashing the whole program.

Every time you add a boolean member variable, God kills a kitten. Every time you create a Manager class, God kills a kitten. Every time you create a Singleton...

Urho3D (engine)  Hessian (C64 game project)





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS