--- edit ---

[Sinan]

--- edit ---

[syedhs]

Hi,

http://www.gamedev.net/topic/625708-use ... try4945393

To be honest, after reading his review, it seems that Ogre is absolute trash, and he enjoys bashing Ogre up, using superlative words and stuffs.
However, as you rightly pointed up, the roadmap does address some of Ogre weakness and revamp some of Ogre design.

And truth to be told, Ogre is not fast either, and certainly not to be compared with Cyrtek and other AAA game engines or even Unity. Ogre is very good for someone who wants complete control of source code, not too high end in term of graphics features but it needs a team or person of certain degree of C++/graphics shader experience to make it a success aka producing a usable product.

I will try to answer items which I am familiar with:-

2) Ogre fails at batching? Reading a bit of the GameKit source code, and I see additional batching code in there. So this is not something that can't be addressed.

Ogre does batch, specifically batches materials. Hash are created from materials which are used to sort materials before feeding them into rendering system, which minimizes render state change. There are also classes like StaticGeometry or more recently, Instancing which reduces batch count a lot if done correctly. Or do it yourself using texture atlas methodology, to further minimize batch count.

4) A lot of people online seem to think C++, object oriented programming is bad. That scares me, OO has nothing to do with performance, the compiler is not gonna know the difference (i.e it's all gonna end up as machine code). However, good design does.

Actually OO is quite related to performance especially in rendering engine where cache miss must be minimized. For code to be performance, the data block which are to be processed (say position/orientation of 1000 entities) need to be in one big block (if possible) so that all data can be loaded into the cache, and therefore be processed very quickly. The 'pipe' between cache <-> processor is very fast compared with processor <-> RAM (actually data need to be loaded from RAM into cache first). So if data is constantly need to be fetched frequently into cache to be processed, it will degrade performance, sometime significantly - this is what cache miss is. And OO code is quite a reverse with DOD (data oriented design) - DOD code is actually the ancient style where C was dominant And DOD is what we aim to minimize cache miss.

And to extract more performance juice, code need to be threaded where it can and as far as performance is concerned, Ogre is not threaded at all. AFAIK, Ogre is threaded in background loading which probably make the scene load faster, but the FPS remains the same.

[Sinan]

--- edit ---

[Knotanalt]

1. Well, so what. You can always make rendering faster but generally it's the low hanging fruit in a sense. Not that it's easy per se but it's easy to quantify. There's many other areas of performance to worry about, and Ogre3D seems to have pretty good rendering speed.

2. More an issue of convenience than performance, but I'm hoping this won't turn out to be an issue with GUI, or it can be resolved. In general GUI has turned out to be a surprisingly big problem with all the engines I've used, though. But if you put everything into an atlas then you should be able to eliminate all batching for GUI. You should be able to do that behind the scenes for your components, as well.

3. But probably not much and goes back to 1)

4. Yes and no, but templates don't qualify as OOP and Ogre seems to use a ton of them, and they can cause issues.

As far as a dinosaur goes, I don't think so. Most of the big engines are very geared to consoles ie PCs of 5+ years ago so you won't do much better with other engines, and the ones affordable without publisher funding are much worse. Most have terrible performance, Unity is certainly worse in that respect than Ogre (or pretty much anything) and ditto for stability and debugging so anyone who says that I can't take too seriously. It seems like there's an endless supply of Unity marketing drones (fanbois?) who say this kind of crap any time an engine discussion on any board comes up, in largely the same words. That engine is POS but on the other hand Unity or two other engines no one would seriously consider and I'm just puttin in there to look impartial are great!

C4 has great performance and perfect rendering but I just got tired of everything being a PITA for no reason, unstable API interface and having poor tools and lacking some features I need so here I am.

[bstone]

4. Yes and no, but templates don't qualify as OOP and Ogre seems to use a ton of them, and they can cause issues.

Oh yeah? Tell me more

[AgentC]

I would like to point to this post by dark_sylinc http://www.ogre3d.org/forums/viewtopic. ... 1&start=29 which confirms that yes, Ogre does have CPU-side performance issues. As long as your batch count is low, and there are not many objects in the scene, it is not a problem. Any absolute figures are hard to give. On the GPU side there's no issue, ie. it's not that Ogre would execute the same shaders any slower than any other 3D engine.

I haven't been able to profile cache misses myself but what I have noticed is that Ogre will reapply the whole renderstate for each object even when you are rendering x objects with the same material, leading to a lot more rendering API calls than would be necessary. Also, when you use shaders, the whole fixed-function renderstate will still be set (in addition to shader state) which means that rendering with shaders will have more CPU overhead per batch, compared to fixed-function.

[Sinan]

--- edit ---

[Knotanalt]

Let me comment more on that since I will hopefully work on scene manager eventually.

The lack of threaded culling makes this even worse.

I don't think you can make this multithreaded. I mean you can but, not in a meaningful way. I'm sure that's no real part of the problem and am pretty sure none of the namedropped engines do that.

Ogre's already struggling to get a high amount of entities in scenes doing main scene's & shadow's rendering in the same thread. When I add env. mapping (one pass, not 6) the amount of cache misses inside the scene manager is gigantic.

In fact I doubt that this is case for other engines, either. Maybe this is doable but you need to concentrate on actual problems to make headway, not to try and add general extra speed boosts.

I'm afraid, as someone suggested, fixing this may require some strong redesign of the Ogre core. For instance, automatic reference counting of pointers goes against a concurrent system.

Goes against almost anything IMO. I've become convinced any kind of resource management tends to put you in a straightjacket. I'm not sure this is the case, though, doubtful but I'd have to think carefully about it to be sure.

Singletons don't help (as it's very easy for programmers to make a mistake and access a singleton when it isn't safe to do so)

Again I don't think this is any kind of issue at all. It's no different than anything other way to reference. The only caveat is the extra indirection leads to some minuscule performance hit which is why I avoid them. Doubly I'd always avoid a singleton that doesn't initialize itself at loadup time, it's just completely pointless. And loading phase is always singlethreaded and happens before main gets called.

But if the scene manager really causes this much issue, it can definitely get fixed.

Especially cache misses, which are a big problem for a node based data structure. Like I mentioned in that thread I have done a linear octree that is all one chunk of memory that's ordered so as to limit cache misses. There's even more optimization you can do on that to make it smaller and better ordered in memory and therefore have fewer cache hits. That should help a lot IF that's REALLY where the time is going.

Also, STL. Really want to remove this garbage, it's just not suitable for a game engine. If you are building everything on that it's a pretty big tax. Keep in mind a good eyeball metric of code speed is the inverse of the code size. Simple is better and STL and Boost are far from simple.

Plus mem manager changeout may help as well. Ogre has its own but I don't know how good it is, and I have my own which is highly optimized and works with multiple threads.

I'll get this all in at some point, assuming I stick with Ogre, but I have a lot of code to port first before I worry too much about performance.

Those seem like the most likely issues, but generally like I said the hard part is to identify the actual problems not just go hog wild optimizing everything. Also search methods on a data structure can be slow so that might be an issue, again if it's really scene manager (seems like it's a bigger area of performance trouble than I'd expect if the other thread is right).

[TheSHEEEP]

I agree with most of what you say, I think especially memory pooling for the scene manager would be something almost any project would profit from. IF it is possible, at all. Not sure if pooling scene nodes, for example, is even possible in our case. Or a good idea as that does make assumptions about the usage, which is actually up to each user. In contrast to full game engines, we shouldn't make too many usage rules or assumptions.

Also, STL. Really want to remove this garbage, it's just not suitable for a game engine. If you are building everything on that it's a pretty big tax. Keep in mind a good eyeball metric of code speed is the inverse of the code size. Simple is better and STL and Boost are far from simple.

I think with that assumption you fell to one of the more common internet myths. STL is by no means slow or garbage (it was at its start, though, so that myth has a true background), it's just very generic, which is why it can be used in almost any case. Of course that comes at a performance cost, but that is still better than writing your own classes for all of it, which would just be a waste of time if you don't know that this is the actual culprit.
Also, there are only very few things faster than boost containers. Try finding a faster unordered_map, for example, without doing the complete thing yourself for your very special case.

The real problem is in what you use something for. An std::vector or boost::unordered_map are good in some cases, and bad in others. So, of course, we could theoretically write all those container classes ourself to optimize them for us. But that would take a ridiculous amount of time, so is completely out of the question.

The biggest speed problems with Ogre I see (and I'm by no means an expert on the internals, so take all of this with caution) are in the rather slowly parsed material scripts (but this is minor as materials are not parsed every frame), the SceneManagers, which is pretty much known and they will get an overhaul (not sure if it was for 1.9 or 2.0) and the lack of (internal!) threading. Especially the introduction of threading to the animation system could yield a large boost. And I'm sure there are other places that would benefit. AFAIK, the plan so far is not to make Ogre thread safe (so you will always have to control Ogre from the same thread), but Ogre itself should - internally - make use of threads more.

[Knotanalt]

First off, to avoid cache misses, you have to separate the occlusion so that it's not node based at all, on two fronts. First you can't have random nodes that connect around or you get cache misses, but your node also has to be simply the spatial info, not a whole blob of data. Which hopefully I am misunderstanding because that would seriously crush the performance. Both of these should be easy to solve once I get into it.

I don't think a "major redesign" is needed at all but then I only spent a couple hours trying to figure out what was going on so far.

I think with that assumption you fell to one of the more common internet myths. STL is by no means slow

The question is, compared to what. Everything is relative. It's faster than java containers and maybe faster than the average programmer can achieve but not very fast compared to what it could be. It falls apart in large projects especially due to having so many templates on templates. Just look how slow ogre compiles. It's ridiculous. And compile time also means you are adding in a lot of code bloat.

People are quick to wave their hands and say how well the compiler optimizes but it does very little in reality, in the ways you would care about for this.

An std::vector or boost::unordered_map are good in some cases, and bad in others. So, of course, we could theoretically write all those container classes ourself to optimize them for us. But that would take a ridiculous amount of time, so is completely out of the question.

Yes, but someone has already done that for you, he just has to integrate it in without completely breaking everything beyond repair.

[Knotanalt]

And actually I guess you should be able to parallelize the culling. Just do it all beforehand for every node, though it should be so fast anyway that it shouldn't matter, unless something is wrong. If the checks are done mixed in with everything else that would also make a bunch of cache misses, if so maybe that's an issue.

[bstone]

Please don't say anything about how slow STL and Boost are because that really shows off the lack of experience you have when it comes to C++ and templates. Just mentioning that they are bad because they are big tells a lot about you. I use STL since 2000 and that includes large projects with nearly 24/7 availability. Furthermore, I'm the kind of the guy who opens and stares at disassembler left and right and I sure know how std::vector looks when it's compiled. STL has never been slow for me and I convinced a lot of coders who thought otherwise. Not going to do that again any time soon though Just a little tip: if it's slow for you then you should double check the way you use it, you're probably doing something globally wrong. But if you are like "I'm 100% sure that if I hand code the for loop for iterating over an array it will be 100x faster than std::vector" then, well... no further questions.

[syedhs]

There was one or two post by a guy from EA (yes, Electronics Arts) regarding STL and alternatives and he is involved in designing and implementing the core engine for EA engine - something like that. And you can search that guy's post (twobits or twobit I don't remember which), but the overall conclusion is STL has good performances in PC games, but not so much in console. So if you are creating games engine or games for PC, then STL is good enough (actually, very good) if you are talking about performance.

[Knotanalt]

Please don't say anything about how slow STL and Boost are because that really shows off the lack of experience you have when it comes to C++ and templates. Just mentioning that they are bad because they are big tells a lot about you. I use STL since 2000 and that includes large projects with nearly 24/7 availability. Furthermore, I'm the kind of the guy who opens and stares at disassembler left and right and I sure know how std::vector looks when it's compiled. STL has never been slow for me and I convinced a lot of coders who thought otherwise. Not going to do that again any time soon though Just a little tip: if it's slow for you then you should double check the way you use it, you're probably doing something globally wrong. But if you are like "I'm 100% sure that if I hand code the for loop for iterating over an array it will be 100x faster than std::vector" then, well... no further questions.

I didn't STOP using them for no reason.

Unless you've made your own and compared performance you don't know what you are talking about or have any place to talk to someone who has. Like I mention I ALREADY have, this is not some theoretical discussion, and I doubt many people can say the same. Performance increase is stunning.

And here we are, why I never actually end up helping out with projects. People start arguing with me the second I say anything they don't comprehend or goes against their indoctrination. What a waste of my time and energy nonsense like this is. Grow up man and don't post crap like this at me, seriously.

I'm 100% sure that if I hand code the for loop for iterating over an array it will be 100x faster than std::vector" then, well... no further questions.

Right back at you about telling statements, if that's what you think makes for optimization. But I'll leave it there and just put you in my ignore list because I have no time for this idiocy.

[Knotanalt]

Anyway in the past I made a bunch of sculpting and other tools for maya in the form of C++ plugins. Eventually I found all their code too slow and all STL code too slow and replaced everything. Code that's fine for holding and sorting and searching 1000 elements is not fine for 400 000 000 elements and performance difference is staggering when you get to that level. And same applies to engines to a degree. User code with STL is probably mostly fine but you don't want your engine working like that, believe me (or don't, you probably won't, but your response will not be seen by ME at any rate).

I doubt that's the big time sink. It's probably that the scene manager does too much and switches between tasks a lot, but it will probably help to get rid of that.

[bstone]

Code that's fine for holding and sorting and searching 1000 elements is not fine for 400 000 000 elements and performance difference is staggering when you get to that level. And same applies to engines to a degree.

No doubt, but I'm sure that had nothing to do with STL. More like changing the underlying structures and algorithms, e.g. switching from std::map<> to your own version of map, sort of boost::unordered_map<>. That's another story, isn't it?

[masterfalcon]

Ok you guys. Let's keep the pissing match out of the public forum ok? Keep it civil and on topic.

As has been said, the performance can vary widely depending on the application. So if you have proof that replacing STL use in Ogre offers significant gains then please present the results.

[Klaim]

There was one or two post by a guy from EA (yes, Electronics Arts) regarding STL and alternatives and he is involved in designing and implementing the core engine for EA engine - something like that. And you can search that guy's post (twobits or twobit I don't remember which), but the overall conclusion is STL has good performances in PC games, but not so much in console. So if you are creating games engine or games for PC, then STL is good enough (actually, very good) if you are talking about performance.

Most or better fixes are in the new C++11 STL. If they are not, you can find them in the boost.Container library. Like containers allocating no memory when empty.

[bstone]

Also, pay attention to what syedhs said. The guy from EA who worked on their own STL spinoff is not a boy. And if you read what he said back when about EASTL then you will see that his major complaints was mainly about the inflexible allocators, reducing vector capacity (could be done but looked weird) and in-place construction (solved in C++11). Yeah, EASTL outperformed STL on consoles, but those have specific architecture and are beasts by themselves. And yes, something like intrusive_list can be much faster than std::list<> when applied strategically but that doesn't mean std::list<> is slow - it's more like comparing oranges to apples.

[Knotanalt]

Ok you guys. Let's keep the pissing match out of the public forum ok? Keep it civil and on topic.

As has been said, the performance can vary widely depending on the application. So if you have proof that replacing STL use in Ogre offers significant gains then please present the results.

Sorry I got annoyed but there's no programmer on earth who has so much more experience they can talk to me like that, and in a serious discussion I wouldn't expect that regardless.

I know from the past even when I post proof I will get flack but I'll eventually share what I do with everyone if I stick with ogre.

[bstone]

As has been said, the performance can vary widely depending on the application. So if you have proof that replacing STL use in Ogre offers significant gains then please present the results.

Good point. I don't think that just coming up and saying "I want to help and the first thing I will do is removing STL from Ogre" does any good to the project. Didn't want to start a pissing match. Sorry about that. The lack of arguments drive me nuts sometimes. Will hold the horses next time.

[zarlox]

Agreed that arguing over the STL won't resolve or conclude anything.

Anyway, my 2 cents on the STL containers is that you should always make sure to use the proper container for your requirement. If you are gonna add items continously at runtime, don't go with a vector, not even with a deque. If you need a fast access to elements, don't go with list. If you push big items, make sure they have move constructor/assignation or just keep a list of pointers to the dynamically allocated objects.

Finding the right memory allocation and container flexibility for your needs is always the priority.

[Faranwath]

my 2 cents on the STL containers is that you should always make sure to use the proper container for your requirement

Item 1 from Scott Meyer's "Effective STL" comes to mind.