Ogre Forums

jacmoe wrote:Why TBB?
I've always been into the POCO libraries - it's been a while since I visited the project:

[2014-12-22] Release 1.6.0 is the culmination of the work done on GitHub over the last two years, including five development releases. It includes major new features from new contributors, like the JSON and MongoDB libraries, much improved Data library, CMake support, as well as numerous other new features and fixes. A big Thank You to everyone who contributed to this release.

Sounds like music to my eyes. CMake!
It has all the useful things from Boost, and is not quirky and intrusive.
They have extensive multithreading, process management, networking .. http://pocoproject.org/features.html
However, Stealth977 loves to re-invent all the things - and that's probably why I am sticking to Ogitor.

Well you made stay between in two dillemas, POCO or TBB, i started to use POCO to replace Boost in my projects because started to get bloated and heavy. TBB i used it in OGRE 1.9 and 1.8 as my thread library,instead of Boost and native threads.

But one thing about the Smoke Demo is get rid of SpinLock class and Win32 API calls.

@hydexon:

I had a long post written earlier today, just to realize my fiber connection is lost by the end of the post, due to an area wide maintenance. Anyway, a short version is:

Multi-threading is like using a wormhole, to travel vast distances : it has rules of its own, normal physics rules wont apply once you are in it...

So, I know many ways of implementing fast and efficient messaging systems, but when it comes to fully muti-threaded environments, 99.9% wont work. So I will remind you something:
Every OS uses similar approach, function names change but design doesnt. Most would agree that there is a reason why they do it that way, or they sure know how to store function pointers and call methods directly, it is not usable in a real multi-thread environment, but again it very much depends on how you gonna multi-thread, fully or partially...

hydexon wrote:TBB i used it in OGRE 1.9 and 1.8 as my thread library,instead of Boost and native threads.

I just wish that Intel didn't own it and that it wasn't under that horrible frankenstein license.
I thought it was deprecated?

jacmoe wrote:

hydexon wrote:TBB i used it in OGRE 1.9 and 1.8 as my thread library,instead of Boost and native threads.

I just wish that Intel didn't own it and that it wasn't under that horrible frankenstein license.
I thought it was deprecated?

Still using it, i don't know the disadvantages to use it with the "OSS" license, i don't have any problem with that, it's basically the same license when you use the libc++ std of GNU, the Commercial License only applies if you want private support...

jacmoe wrote:Why TBB?
I've always been into the POCO libraries - it's been a while since I visited the project:

[2014-12-22] Release 1.6.0 is the culmination of the work done on GitHub over the last two years, including five development releases. It includes major new features from new contributors, like the JSON and MongoDB libraries, much improved Data library, CMake support, as well as numerous other new features and fixes. A big Thank You to everyone who contributed to this release.

Sounds like music to my eyes. CMake!
It has all the useful things from Boost, and is not quirky and intrusive.
They have extensive multithreading, process management, networking .. http://pocoproject.org/features.html
However, Stealth977 loves to re-invent all the things - and that's probably why I am sticking to Ogitor.

EDIT:@Jacmoe you're right, seems POCO an excellent alternative to replace the Win32 specific-APIs and TBB used by Smoke and POCO can benefit Ogitor instead unsing Boost, instead to using TBB, there's the components you need specially, and making it platform independient.... This link can help a bit

Another Poco fan here. I use it in particular for the easy threading (although I prefer OpenMP when possible) and file system handling. Things like directory iteration are so easy.
Nice documentation too.

I like POCO for the same reasons that I like Qt: beautiful code and great documentation
However, as Ismail 'stealth977' said to me yesterday: I have a tendency to apply a toolbox when I need a hammer.

jacmoe wrote:I like POCO for the same reasons that I like Qt: beautiful code and great documentation

I don't know POCO but I don't like Qt. It's working well on Linux systems but the windows part is a lot of pain (awful memory usage, hard coded paths in qmake, etc.). But I'll support the development of the new Ogitor.

We are not using qmake nor the VS Qt plugin, we use CMake which is instant pain-removal
Thanks for supporting us, Transporter. Very appreciated!

jacmoe wrote:We are not using qmake nor the VS Qt plugin, we use CMake which is instant pain-removal
Thanks for supporting us, Transporter. Very appreciated!

Sure you're using qmake! CMake is calling qmake to get the hard coded library paths. I really hate this part because you can't move any files/foldes without destroying the Qt dev environment. Yes you can fix it by a file called qt.conf but this is not working every time. But you are right, the documentation is better than Ogre's.

It took me a while to realize that life will be easier if I treat the generated build directory as temporary out-put only.
I like that it's out-of-source (generally) because that helps that notion.
It's quite fast to just generate a new build directory so moving things about is not an issue for me.
I am not sure why CMake does that, but I consider that a small price to pay for not having to mess around with tons of arcane build systems..
I also find that it helps to get ready for deployment: because the build directory needs to be populated with assets every time it's generated from scratch - and External Projects are great for that - you will notice run-time environment issues during development.

I use TBB for it's high-performance central task manager and it's concurrent containers. As soon as they are available in boost I'll remove TBB...if it doesn't hit my game's perfs (Boost don't really focus on performance).
I didn't consider poco instead of TBB because from the initial research I did it didn't seem to match my need, but I didn't try either.

The problem is not moving the source or moving the build directory. The problem is moving the Qt dev files - or just copy them to a new computer if you don't have admin rights to install Qt. The hard coded path will not fit anymore. I like CMake very much, because I know the pain if you have autoconf an a couple of make files. But back to topic ...

I prefere boost, because I'm using boost for a lot of things and I would like to keep down the number of different dependencies. If I should choose between TBB and POCO, I would choose POCO because of the boost license and the included network modules.

My nice-to-have list:

• instance manager
• compositor/shader editor
• geometry importer

if you want to move away from boost for threading why dont you move to the STL? basicially boost:thread just becomes std::thread. As for TBB: it might come with C++14 to the STL as well: http://www.open-std.org/jtc1/sc22/wg21/ ... /n3554.pdf

paroj wrote:if you want to move away from boost for threading why dont you move to the STL? basicially boost:thread just becomes std::thread. As for TBB: it might come with C++14 to the STL as well: http://www.open-std.org/jtc1/sc22/wg21/ ... /n3554.pdf

A third party library is still necessary, because a few people are still using old compiler without C++11 features.

paroj wrote:if you want to move away from boost for threading why dont you move to the STL? basicially boost:thread just becomes std::thread. As for TBB: it might come with C++14 to the STL as well: http://www.open-std.org/jtc1/sc22/wg21/ ... /n3554.pdf

It's definitely not enough. I use boost because the VC implem of chrono is slow, and boost provide extensions like future<>.then(). TBB provides concurrent containers and an actually fast central thread pool (the one in asio is SLOW).
std::async is BAD and will certainly be deprecated. I hope it will be replaced by this https://github.com/chriskohlhoff/executors
I'm following the standard evolutions and trust me when I say we'll have to wait C++17 to finally have a good set of high level constructs for concurrent and parallel programming in the standard libary.
Meanwhile, the only way I found to get good performance while combining high level constructs is to mix these libraries.

Also the paper you cite is not part of C++14 (which was released last year, without these additions). It's part of the concurrency TS which have been recently released and can be implemented by library providers if they can.

Small Test Video, testing Physics, Audio and Scripting...

[youtube]_hebklS2f8c[/youtube]

And I know axis widgets are not following the object when in run mode didn't have time to fix it...

Does Ogitor source compile with CMake 3.1.2?

It works with 2.8.12.


Where is OGF (The engine framework behind Ogitor) source in Ogitor repository?

CMake latest should work.
Find all our stuff here: https://bitbucket.org/ogitor

Wow, the video is great!

i've compiled it with transportrer's prebuild ogre snapshot( msvc2010 ) and qt5.4....it crashed....
later on i've compiled SCAPE with the same configuration it also crashed...
debuging shows heap corruption asserts( on iterator creation...i think...)
i guess it's most likely something with msvc project configuration mix...
any hints beside building ogre myself?

btw: nice work on the cmake external dependencies...pulling source and stuff...its a good way to keep builds updated
this feature should definitely make it to ogre cmake build scripts...
may i ask why not put all of ogitor source as an external "dependency" leaving only one .cmake file to download?

@frostbyte

you compiled it and it crashed launching editor or opening test.ofs?

opening and new project...editor runs fine...
maybe its a problem with transporter's snapshot( but samplebrowser work... )

I will look into it, currently since it is bleeding edge, we make use of the freedom to extend/change file format to experiment which maybe causing some problems...I will try and see what we missed in new project(probably it is a property type change from signed to unsigned and OGF::Any is asserting for wrong type cast)

thanks...thats why i suggest you put also ogitor source as an external dependency...i just hate to download and build it again and again and...
this cmake external project thing can function as my own cool little continuous build automation server...

Well I uploaded new test.ofs and checked Project->New all works fine at current build... A call stack dump would be nice if it still crashes...

EDIT:

I also need to remind you that Ogitor v2 atm works mostly manual, we dont have option to add new meshes/materials etc and all needs to be put into project manually (in /shared/media/*, scene_only resource path is not active yet), also when adding new objects, Ogitor doesnt put them right infront of camera yat, so they start at position Vector3::Zero you need to enter coordinates through property browser)

Basicly, since we are experimenting with new systems and not adding much EDITOR functionality, it is quite bleeding edge and it is not much end user friendly at the moment...