OgreBullet CMake buildable
I've made repository with patched OgreBullet. Now you can build it with cmake and link with your project using Find module.
In additional I've made it buildable with bullet 2.81.
Now I'm fixing some bugs in OgreBullet and maybe in the future I will be able to maintain Linux support with deb packaging.
P.S. It has not been fully tested yet. So any feedback, feature requests (thread, email or pull request) and suggestions are welcome.
Upd (22.03.13): Now with demos!
when i run the demo, the heap allocation error is occur.
do you faced with this?
(will attach log soon)
i was get last sources from git, build up Collisions and Dynamics libraries, attached it, project compiled well, run, picture drown, and in example application it hang with that error.
error on this line:
_ASSERTE(_pFirstBlock == pHead) in xstring.h
its called from ExampleFrameListener.h
guiCurr->setCaption(currFps + StringConverter::toString(stats.lastFPS));
dont know why it happens. all demo works ok. when i attach nxogre it works, when attach newton it mostly works. strange
Please, give more info about error. When it occurs? In toString or while concatenation? What value has lastFPS at the crash moment?
sorry for long-time reply.
it does not show fps at all, it just draw scene, draw frame of fps box, and crash.
i build ogre from source-code, build bullet sdk and ogreBullet. all on x64 PC...
here is stack...
> Dynamics_Demos_d.exe!_free_dbg_nolock(void * pUserData, int nBlockUse) Line 1424 C++
Dynamics_Demos_d.exe!_free_dbg(void * pUserData, int nBlockUse) Line 1265 C++
Dynamics_Demos_d.exe!operator delete(void * pUserData) Line 54 C++
Dynamics_Demos_d.exe!std::allocator<std::_Container_proxy>::deallocate(std::_Container_proxy * _Ptr, unsigned int __formal) Line 586 C++
Dynamics_Demos_d.exe!std::_String_alloc<0,std::_String_base_types<char,std::allocator<char> > >::_Free_proxy() Line 683 C++
Dynamics_Demos_d.exe!std::_String_alloc<0,std::_String_base_types<char,std::allocator<char> > >::~_String_alloc<0,std::_String_base_types<char,std::allocator<char> > >() Line 656 C++
Dynamics_Demos_d.exe!std::basic_string<char,std::char_traits<char>,std::allocator<char> >::~basic_string<char,std::char_traits<char>,std::allocator<char> >() Line 965 C++
Dynamics_Demos_d.exe!ExampleFrameListener::updateStats() Line 72 C++
Dynamics_Demos_d.exe!ExampleFrameListener::frameEnded(const Ogre::FrameEvent & evt) Line 383 C++
Dynamics_Demos_d.exe!OgreBullet_Collision_testFrameListener::frameEnded(const Ogre::FrameEvent & evt) Line 126 C++
will try today on 32 bit PC with precompiled SDK...
Have you unpacked Media.tar.gz into binary folder?
Hi, yep, unpacked already.
well, the program work fine if overlay output disabled ) dont know why, will check later, thanks.
As you can see this component has name BetaGUI and used only in demos. In addition I'm not ogrebullet developer so I didn't write its code. Maybe it will be better to migrate from BetaGUI to Gorilla or something like this in the future. If you will implement this it will be cool. I will be happy to apply your patches.
Let me know if it solved a problem.
I'm having a lot of undefined references issues (with BetaUI.cpp) when compiling OgreBullet on Linux with Ogre 1.9. It works fine out of the box with Ogre 1.8. Have you tried if your code works for Ogre 1.9?
Undefined ref linker error appears when you have definition of function and have not implementation. Example: you forgot to write body of function defined in your header file. Another situation (but similar conceptually) when you have successfully included headers of some lib but didn't explain linker where find object files (*.o or *.a or *.so), i.e. lib
In your case you have includes for Overlay component of Ogre (used in BetaGUI) but have not lib, that has been detached from OgreMain in 1.9
add Overlay lib to target_link_libraries in Demos CMakeLists.txt. Fix would be in upstream when Ogre 1.9 will be stable.
Edit: My post was delayed because of moderation. Look at later post.
I got it to successfully compile and linked by adding OgreOverlay to the set(LIBS. When I try to run the demo, I can only get as far as the opening menu. After I click Accept, the terminal loads a couple of things and then the Demo just closes.
The last few lines in Ogre.log indicated that it completed loading some items, but I don't see anything there that says why it closed.
14:51:36: Creating resources for group General
14:51:36: All done
14:51:36: Initialising resource group Internal
14:51:36: Parsing scripts for resource group Internal
14:51:36: Finished parsing scripts for resource group Internal
14:51:36: Creating resources for group Internal
14:51:36: All done
14:51:36: Initialising resource group OgreBullet
14:51:36: Parsing scripts for resource group OgreBullet
14:51:36: Finished parsing scripts for resource group OgreBullet
14:51:36: Creating resources for group OgreBullet
14:51:36: All done
I did see some OGRE EXCEPTIONS and fatal errors but those also appeared when I used Ogre 1.8, yet the demo ran fine with that.
Is there some incompatibility with Ogre 1.9?
Edit: I ran gdb on the demo (after disabling mouse and keyboard grab) and the problem is related to the Overlay again:
Program received signal SIGSEGV, Segmentation fault.
Ogre::OverlayManager::getByName (this=0x0, name=...)
113 OverlayMap::iterator i = mOverlayMap.find(name);
Edit 2: Further debugging seems to show that in OgreBulletGuiListener.cpp:27:
mMouseOverlay = (Overlay*)OverlayManager::getSingleton().getByName("GuiOverlay");
getSingleton() is returning a NULL pointer. I set the same breakpoint for Ogre 1.8, and getSingleton returned a non-null pointer. Now my question is, is there something in Ogre 1.9 that has changed for that particular function? Running the exact same code on 1.8 works without any additional setup.
I am new to Ogre and I had one simple suggestion to make, if you edit the CMakeLists.txt and include this parameter
then the make command creates a shared library instead of a static library which is better in my view since all the other libraries of Bullet and Ogre itself are .so files.
It makes it easier for a linux developer since he/she can add this directly via ldconfig and remove a lot of pain while compiling.