The roadmap to 1.9 and 2.0

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: The roadmap to 1.9 and 2.0

Post by bstone »

That's what I was talking about. The alternative of having Root replace the singletons will be painful for many things. Deadly coupling, screams of those who want just to read a mesh from a file without getting render windows popping up all over the place. That's just to feel the taste and then you add a salty bit of extra configuration hell on top of that. :) No free cheese in that direction. I personally would keep Root away from things that can live perfectly without it.
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: The roadmap to 1.9 and 2.0

Post by lunkhound »

I've been a console developer for awhile (PS3) but now doing my own thing with Ogre, and one thing I'd like to see is Ogre become more viable on consoles. This is very closely aligned with making Ogre more friendly to mobile devices, i.e. reducing memory requirements, and also leveraging SIMD instruction sets like Neon and Altivec. The existing vector math classes in Ogre will perform poorly on PS3/Xbox360 because they don't use SIMD at all, but its a bit tricky to use SIMD because you *really* don't want to mix SIMD and regular float types. You get a big performance hit because the SIMD unit and the FPU can't talk directly, all transfers have to go through memory. To get good performance, its important to keep everything in SIMD registers, so a solution is to have a SIMD-scalar type that works like a float but internally is a SIMD vector with the same value in all its components.
An example of this technique can be found in the open sourced Sony Vector Math Library (discussed and linked here http://bulletphysics.org/Bullet/phpBB3/ ... =18&t=1322 on the Bullet forums), look at the type "floatInVec" for an example. This also implies that access to components of vector types go through accessor functions (i.e. no public x, y, z data members). The Sony library appears to have been written to work on Altivec and then ported to SSE. I assume it could be ported to Neon as well.
I'm not sure what the plan to add Neon support entails, but if it were done in such a way as to enable adding support for other SIMD architectures like Altivec with relative ease, I would be very pleased. :D

Chris
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The roadmap to 1.9 and 2.0

Post by CABAListic »

A potential problem with such a data type that I found in a personal experiment is that it requires *every* object that has a member variable of that SSE type to be in aligned memory. Which means that you cannot use the standard new on any class that uses - directly or indirectly, at any level - the SSE type. All these classes would have to be created with an aligned memory allocator, or else the code segfaults. While this may be fine in contained projects, I don't think we can impose such a restriction on Ogre user code.

Or maybe I did something wrong and there's a way to avoid that...
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: The roadmap to 1.9 and 2.0

Post by masterfalcon »

At the moment, plans for NEON are to bring it up to speed with SSE, specifically skinning. We also need to investigate other areas where SIMD would be beneficial.
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: The roadmap to 1.9 and 2.0

Post by lunkhound »

Yes the alignment is a bit annoying. It would be nice if operator-new knew about alignment. The simplest approach I know of is to just have the global operator new align everything to 16 byte boundaries by default. Everything just works. There is some memory overhead if you're doing lots of small allocations, but that's usually a bad idea anyway. And if necessary there could be a way to override the default alignment case by case.

@masterfalcon: Ah so a much more limited scope change then. That makes sense, it would be a quite painful task to retrofit all of the existing code to go fully SIMD.
dragutux
Halfling
Posts: 56
Joined: Thu Nov 19, 2009 9:39 am
x 12

Re: The roadmap to 1.9 and 2.0

Post by dragutux »

excuse me but i'm going to state a very obvious point that is to be added with top priority..

but when are you guy's going to think about implementing solutions for floating point precisions issues ?
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: The roadmap to 1.9 and 2.0

Post by bstone »

dragutux wrote:but when are you guy's going to think about implementing solutions for floating point precisions issues ?
OGRE_DOUBLE_PRECISION and camera relative rendering is already there. What else do you think has to be implemented?
User avatar
madmarx
OGRE Expert User
OGRE Expert User
Posts: 1671
Joined: Mon Jan 21, 2008 10:26 pm
x 50

Re: The roadmap to 1.9 and 2.0

Post by madmarx »

dragutux wrote:but when are you guy's going to think about implementing solutions for floating point precisions issues ?
Just use the TTMath library as Real, if double precision is not enough for you. I did it in 2010 (and sorry, I can't share the source :mrgreen: ).
But there is no need to concentrate on that right now.

The actual concepts of scenemanager and resource/resourcesgroups are too complexes to be re-used. I am for a huge cleaning first + the team provide just the new concepts, and the community work on the implementation. If someone outside the team provide its own concepts, it won't be accepted until he implements everything from the core, including the glue and replacement of before. That is why I suppose the team should provide the concepts, or make a "call for concepts". The work of team would be more in saying what goes in and out, and how will the different elements work together, and making sure the concepts will integrate well. Or I may be completely wrong ?

BTW I wrote a threading library for windows (with mutex/read write things etc...), that work for void(void)) function. It's just 1 header + 1 cpp. It is also possible to port it to *nix I think. But it does not provide any 'modern multithreading' things like future/lockfree/openmp.
Tutorials + Ogre searchable API + more for Ogre1.7 : http://sourceforge.net/projects/so3dtools/
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: The roadmap to 1.9 and 2.0

Post by lunkhound »

More thoughts on the SIMD stuff.
Rather than adding a separate code path for mesh skinning implemented in Neon intrinsics (or assembly or whatever), how about adding a SIMD abstraction layer (possibly with a vector math library built on top that sits alongside the existing vector math). Areas like mesh skinning that are performance sensitive could use the SIMD classes to do the heavy lifting. It would be less code to maintain, it would be easier to add SIMD to areas that could benefit. More bang for buck.

It looks like Ogre currently has about 2000 lines of SSE intrinsics. It would be nice to replace that with something that can be reused across the various SIMD architectures rather than add another separate code path of a thousand lines of Neon intrinsics. Altivec and SSE are similar enough for such an abstraction layer to work, but I'm not that familiar with Neon. Assuming the Neon architecture is amenable (i.e. wouldn't compromise performance significantly), I'd like to see some kind of SIMD abstraction layer in Ogre.

Chris
User avatar
areay
Bugbear
Posts: 819
Joined: Wed May 05, 2010 4:59 am
Location: Auckland, NZ
x 69

Re: The roadmap to 1.9 and 2.0

Post by areay »

Thank you CABAListic, as a Ogre user this is exactly what I wanted to see; the public reaffirment of your team's commitment to keep Ogre current and kicking ass. You guys are doing a magnificient job and this roadmap gives us users a clear idea of what you're planning. Thanks a lot :D
CABAListic wrote: Finish our new-generation render systems.
Brilliant, this is the most important thing for me. I think that the OpenGL performance is a little behind where DirectX is for Ogre at the moment and the big rewrites planned should even that up. My humble prediction is that OpenGL will become more important to Ogre as the support for mobile increases as all the mobile devices use it (close enough anyway) and possibly the rumored Steam-console too.
CABAListic wrote: Improved support for current mobile platforms].
As an Indie developer, the write-once, run-many nature of Ogre really appeals to me so I'm happy to see that it's being given a high priority
CABAListic wrote: A state cache for the rendersystems to avoid unnecessary state changes.
Choice, more performance can't hurt.
CABAListic wrote: Clean up Ogre core and possibly move features to separate components/plugins.
I'm ambivalent about this but as others have already said, will make your jobs easier in the long run and ties in to the mobile platform support like you mentioned.
iFire
Gnoblar
Posts: 24
Joined: Mon Sep 26, 2005 6:39 am
x 1

Re: The roadmap to 1.9 and 2.0

Post by iFire »

Can you explain why Intel TBB's license is tainted?

According to my reading when you use the combination of Ogre3d and TBB your code remains whatever license you want.
Why is TBB licensed under GPL v2 with the libstdC++ Runtime Exception?
Because GPL v2, and the libstdC++ Runtime Exception, are frequently used in the open source community and they are widely accepted and well understood. For complete descriptions please visit the official GNU website for GPL v2 and the Runtime Exception.
Although GPL v3 was considered for the OSS license of TBB it was not available at the time the product was open-sourced.
Source: https://threadingbuildingblocks.org/wik ... =Licensing
The source code is distributed under the GNU General Public License version 2, with the so-called “Runtime Exception” as follows (or see any header or implementation file):

As a special exception, you may use this file as part of a free software
library without restriction. Specifically, if other files instantiate
templates or use macros or inline functions from this file, or you compile
this file and link it with other files to produce an executable, this
file does not by itself cause the resulting executable to be covered by
the GNU General Public License. This exception does not however
invalidate any other reasons why the executable file might be covered by
the GNU General Public License.

Hopefully that text is self-explanatory. If it isn't, you need to speak to your lawyer, or the Free Software Foundation.
Source: http://gcc.gnu.org/onlinedocs/libstdc++ ... 01s02.html

The text says this file does not by itself cause the resulting executable to be covered by the GNU General Public License.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The roadmap to 1.9 and 2.0

Post by CABAListic »

Yes, but unfortunately the name GPL is enough to dissuade a lot of companies (or their lawyers) to use anything licensed under it no matter what exceptions they may have named. It's just like that - GPL has a bad reputation in the business, and if we impose it on our users by depending on TBB, that may prove detrimental to commercial Ogre projects.

At least that's what I've been told. Personally I like tbb and think it would be the best threading choice out there, so it's kind of annoying. I hope Intel might reconsider their choice of license - if you want a liberal license, don't choose anything with GPL in its name.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: The roadmap to 1.9 and 2.0

Post by jacmoe »

Corporate greed.
IMO, they know this very well. They offer commercial licenses.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
Thoran
Halfling
Posts: 94
Joined: Mon Dec 01, 2008 2:04 pm
Location: Germany
x 1
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Thoran »

A few words from my side about the threading library: I am against bundling Ogre to one threading library, as many users of Ogre also use other 3rd party libs that rely on a threading library. With the ability of Ogre to select between threading libraries this is a way of keeping one single threading library throughout all dependencies that ones application/game might link against. In my case for example I am using a 3rd party networking library that is based on top of OpenThreads, which already made me think on extending the Ogre core for support of OpenThreads at least for me. However yet I am not aware about the complexity of Ogre's threading and thus also not sure of performance drawbacks of abstracting from the threading libraries to support them all. But my opinion is that it is at least worth a solid think-through in the beginning if such a threading-library abstraction does make sense especially with regards to a potential re-write of the threading core in Ogre itself.

Thoran
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Wolfmanfx »

I think we as a community have to stop to see everything as a possible problem. Everything which is to generic is possible unperformant (i am talking about overengneering) - the tbb license is not bad we are allowed to distribue the binaries.
Btw threading support could be a optional feature so nobody is forced to use it. And maybe just maybe we could use tbb in the beginning to think about what todo and not to much how we do.
User avatar
zarfius
Gnome
Posts: 367
Joined: Wed Jan 03, 2007 12:44 pm
Location: Brisbane, Australia
x 13
Contact:

Re: The roadmap to 1.9 and 2.0

Post by zarfius »

I just wanted to say I'm pretty excited about these plans, esspecially the focus on Android because I was just thinking the other day that Ogre might not be the right choice if I want to make an Android game sometime in the future.

I'd also like to touch on a possibly controversial topic so fogive me if I'm out of line here. Something that has bothered me for a while about Ogre is how the math classes (Vector2, Vector3, Quaternion, etc) are integrated into the core. The reason it bothers me is because I've often wanted to write a stand alone library (geometry generation for example) but always find I need to have a dependency on Ogre just for them even though the library I'm developing has nothing to do with rendering. To put a little more context around the problem, I should also mention that I'm actually using Mogre so maybe it doesn't apply so much in the C++ world. Maybe the problem is more to do with Mogr than Ogre but I'm still curious if there has been any thought into splitting out the math classes from Ogre as well?
Craftwork Games - hand crafted entertainment.
http://www.craftworkgames.com/
User avatar
Thoran
Halfling
Posts: 94
Joined: Mon Dec 01, 2008 2:04 pm
Location: Germany
x 1
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Thoran »

Wolfmanfx wrote: - the tbb license is not bad we are allowed to distribue the binaries.
CABAListic wrote:Yes, but unfortunately the name GPL is enough to dissuade a lot of companies (or their lawyers) to use anything licensed under it no matter what exceptions they may have named. It's just like that - GPL has a bad reputation in the business, and if we impose it on our users by depending on TBB, that may prove detrimental to commercial Ogre projects.
I second CABAListic's statement and don't get me wrong I also think TBB is a good threading library, but in the end it most likely will scare off a lot of commercial projects if TBB is the only option left.
Wolfmanfx wrote:Everything which is to generic is possible unperformant (i am talking about overengneering)
I don't imply over-engineering, but I think it would do Ogre good if the threading is cleaned-up and redesigned anyways to think about a solid clean, light abstraction for threading support, to support more than one threading library.

Thoran
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Jabberwocky »

Regarding "which threading library":

Abstracting away from a single threading lib seems like a good idea if:
1. it's reasonable to program and maintain
2. the abstraction doesn't significantly affect performance

But if either of these are not true, then I think we need to choose and focus on a single threading lib. Even in this case, care could be taken to keep the thread-lib dependent code in as few files as possible. Then, for those Ogre users who wish to use another threading lib, they can modify the Ogre code themselves as they see fit. Most users who would care about Ogre's threading guts probably have some expertise in threading code themselves.

Flexibility is a good thing for Ogre to offer, but must be balanced with maintenance and performance concerns.
Image
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: The roadmap to 1.9 and 2.0

Post by Kojack »

but I'm still curious if there has been any thought into splitting out the math classes from Ogre as well?
Many times. :)
It's probably the first (and easiest) thing to be split out when ogre starts to get modularised.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The roadmap to 1.9 and 2.0

Post by CABAListic »

I wouldn't say easiest, the scripting system is far easier to remove because virtually no code alterations are necessary. The math code is somewhat problematic due to being tied in with Ogre::Real. A possible (and imho sensible) way to make it work is to make the math library template-based so that it's agnostic towards float or double. We could then typedef default instances for float and double and Ogre can typedef with Ogre::Real.
Or we can move the Ogre::Real #define to the math library, would probably make sense, anyway. Still, using templates might be a nice touch, particularly since it would also allow us to specialise math types and functions for SIMD or NEON calculations in a second step.

Either way, it's a little more work than one might expect at first glance, I think :)
User avatar
zarfius
Gnome
Posts: 367
Joined: Wed Jan 03, 2007 12:44 pm
Location: Brisbane, Australia
x 13
Contact:

Re: The roadmap to 1.9 and 2.0

Post by zarfius »

Kojack wrote:It's probably the first (and easiest) thing to be split out when ogre starts to get modularised.
Good to know :)
CABAListic wrote:Or we can move the Ogre::Real #define to the math library, would probably make sense, anyway. Still, using templates might be a nice touch, particularly since it would also allow us to specialise math types and functions for SIMD or NEON calculations in a second step.
Yeah, I think moving Ogre::Real to the math library would be an acceptable start, it makes sense to use templates though if there are no performance downsides. I have't done much C++ for the past couple of years but I'd be willing to take this task on. I've always thought the Ogre math library is one of the best out there and making it stand alone could make it shine.
Craftwork Games - hand crafted entertainment.
http://www.craftworkgames.com/
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Klaim »

Yeah, I think moving Ogre::Real to the math library would be an acceptable start, it makes sense to use templates though if there are no performance downsides.
Compile times might get worse...
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The roadmap to 1.9 and 2.0

Post by CABAListic »

For relatively straight-forward template usage there should be little to no increase in compile time. It's the crazy stuff libraries like STL and Boost do that is detrimental to compile time...
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Klaim »

Yes it shouldn't be so problematic. Almost all the code but the constants are already inlined anyway.
User avatar
Mikachu
Gnoll
Posts: 603
Joined: Thu Jul 28, 2005 4:11 pm
Location: Nice, France
x 35

Re: The roadmap to 1.9 and 2.0

Post by Mikachu »

Jabberwocky wrote:Even in this case, care could be taken to keep the thread-lib dependent code in as few files as possible.
I'm not an expert in that field, but it seems to me that thread-lib dependent code is very small :
AFAIK, it's just a few #defines in OgreMain/include/threading
OgreProcedural - Procedural Geometry for Ogre3D
Post Reply