Updates to OgreBullet

Hi Everyone,

Since Tuan was so nice as to give me CVS commit access to OgreBullet, I've made some improvements/fixes that I want to put in the CVS, but before I do, I'm going to post here for comment/objections. So, here is a list of changes I've done to the code (in addition to the previous round of changes which were to just get it to work with the latest Ogre):

1) FIX: Changed references to "OgreBullet???Prerequisites.h" to "OgreBullet???PreRequisites.h" (change in case for the "R" in "PreRequisites"). This is to fix a compile problem in Linux (case sensitivity).

2) Update: Changed default World to use btDiscreteDynamicWorld instead of btSimpleDynamicWorld.

3) Enhancement: Added optional parameter to StepSimulation to be able to specify the maxSubSteps in the simulation step. The parameter is optional, so it doesn't break existing code.

4) Enhancement: Added optional parameters to the OgreBullet RigidBody constructor to allow the user to specify CollisionGroup and CollisionMask bitflags for the rigid body. Again, this is optional and will not break existing code.

5) Update: Removed "OgreBulletCollisionsConvexCast.cpp" since it doesn't appear to be used and it doesn't compile either.

6) Added some missing paths for Ogre Dependencies (headers & libs) to allow compilation using OgreCVS instead of OgreSDK.

7) Various fixes for Linux (as discussed in this thread below).

Added lib folder hierarchy (with dummy files) to the CVS so that post-build events don't fail.
Update: These changes are now in CVS.

Chaster

Don't wait a week -- just do it

You are making improvements and anyone that updates from the CVS should expect changes.

Regards

Andy

I believe in peer review. =)

Chaster

From your list the only 'issue' I see is the switch of DynamicWorlds (#2) as the rest are either fixes or non breaking enhancements.

Are there implications to the change of Dynamic worlds, and is it fairly simple to implement the "old" behaviour ?

Regards
Andy

Chaster, I also agree with Andy that you should just implement the changes, the Linux ones in particular. On Linux I had a few problems out with the ones mentioned above:

1) OgreBulletDemo

undefined symbols with OgreBulletCollisionsRay - getRay(Start/End)Point. This may be an error in the way I'm compiling OgreBullet but I had to move the above to the header file OgreBulletCollisionsRay.h

inline Ogre::Vector3 CollisionRayResultCallback::getRayStartPoint() const
{
return mRay.getOrigin();
}
// -------------------------------------------------------------------------
inline Ogre::Vector3 CollisionRayResultCallback::getRayEndPoint() const
{
return mRay.getPoint(mMaxDistance);
}


2) OgreBulletDemo

a) The window handle code appears to default to a previous version of Ogre:

#if defined OIS_WIN32_PLATFORM
mWindow->getCustomAttribute("WINDOW", &windowHnd);
#elif defined OIS_LINUX_PLATFORM
//mWindow->getCustomAttribute( "GLXWINDOW", &windowHnd );
mWindow->getCustomAttribute( "WINDOW", &windowHnd );
#endif


b) The gui BASIC_HELP_INFO2 codes don't appear to match the OgreBulletListener::dropDynamicObject BULLET_KEY_CODE's (JKUI)

#define BASIC_HELP_INFO2 "K,L,O,I to Drop a Cube, Sphere, Cone, Cylinder"


3) Media/Models:

- plane.mesh should be Plane.mesh
- BulletBox.mesh should be bulletbox.mesh


From your list the only 'issue' I see is the switch of DynamicWorlds (#2) as the rest are either fixes or non breaking enhancements.

Are there implications to the change of Dynamic worlds, and is it fairly simple to implement the "old" behaviour ?

Regards
Andy

According to my understanding, btSimpleDynamicWorld is a very limited (subset) implementation of btDiscreteDynamicWorld, and changing over to Discrete should not break your code (at least, it hasn't broken the demos and my own code)... Changing back to a SimpleDynamicWorld would be pretty easy though as it's just a simple Search & replace for I think 4 instances where the world is created/accessed..

Chaster

Chaster, I also agree with Andy that you should just implement the changes, the Linux ones in particular. On Linux I had a few problems out with the ones mentioned above:

1) OgreBulletDemo

undefined symbols with OgreBulletCollisionsRay - getRay(Start/End)Point. This may be an error in the way I'm compiling OgreBullet but I had to move the above to the header file OgreBulletCollisionsRay.h

inline Ogre::Vector3 CollisionRayResultCallback::getRayStartPoint() const
{
return mRay.getOrigin();
}
// -------------------------------------------------------------------------
inline Ogre::Vector3 CollisionRayResultCallback::getRayEndPoint() const
{
return mRay.getPoint(mMaxDistance);
}


Hmm, that's a weird error. It seems like perhaps you are not compiling correctly. I am going to hold off on changing that until I get some more verification of the problem (& solution) from other linux users.


2) OgreBulletDemo

a) The window handle code appears to default to a previous version of Ogre:

#if defined OIS_WIN32_PLATFORM
mWindow->getCustomAttribute("WINDOW", &windowHnd);
#elif defined OIS_LINUX_PLATFORM
//mWindow->getCustomAttribute( "GLXWINDOW", &windowHnd );
mWindow->getCustomAttribute( "WINDOW", &windowHnd );
#endif



Okay, I'll put that fix in.


b) The gui BASIC_HELP_INFO2 codes don't appear to match the OgreBulletListener::dropDynamicObject BULLET_KEY_CODE's (JKUI)

#define BASIC_HELP_INFO2 "K,L,O,I to Drop a Cube, Sphere, Cone, Cylinder"



Odd, it is correct in my copy from the CVS. Is your copy old? Did you get from CVS or from the download site? The download site may be out of date.. (tuan?)


3) Media/Models:

- plane.mesh should be Plane.mesh
- BulletBox.mesh should be bulletbox.mesh


Hm... Not sure how to change the filenames through SmartCVS (I'm new to SmartCVS.. I usually use Subversion) but I'll fix this too.

Chaster

1) Fair enough I'll try an alternative build to Code::Blocks.

2b) Yes my copy is from CVS and I've just re-downloaded to double check, it still appears to be as above. In CVS there still appears to be some problems with BulletListener.cpp and BulletInputListener.cpp:

From CVS when attempting to view OgreBulletInputListener.cpp:

��/
An Exception Has Occurred

Error running external program. Command line was: "/usr/bin/highlight --syntax cpp --force --anchors --fragment --xhtml --linenumbers"

Python Traceback

Traceback (most recent call last):
File "/usr/local/viewvc-1.0.3.sf-new/lib/viewvc.py", line 3660, in main
request.run_viewvc()
File "/usr/local/viewvc-1.0.3.sf-new/lib/viewvc.py", line 403, in run_viewvc
self.view_func(self)
File "/usr/local/viewvc-1.0.3.sf-new/lib/viewvc.py", line 1455, in view_markup
generate_page(request, "markup", data)
File "/usr/local/viewvc-1.0.3.sf-new/lib/viewvc.py", line 852, in generate_page
template.generate(request.server.file(), data)
File "/usr/local/viewvc-1.0.3.sf-new/lib/ezt.py", line 326, in generate
self._execute(self.program, ctx)
File "/usr/local/viewvc-1.0.3.sf-new/lib/ezt.py", line 455, in _execute
step[0](step[1], ctx)
File "/usr/local/viewvc-1.0.3.sf-new/lib/ezt.py", line 460, in _cmd_print
_write_value(value, args, ctx)
File "/usr/local/viewvc-1.0.3.sf-new/lib/ezt.py", line 636, in _write_value
apply(value, [ctx] + list(args))
File "/usr/local/viewvc-1.0.3.sf-new/lib/viewvc.py", line 1229, in __call__
' | '))
ViewVCException: ViewVC Unrecoverable Error: Error running external program. Command line was: "/usr/bin/highlight --syntax cpp --force --anchors --fragment --xhtml --linenumbers"


When attempting to compile OgreBulletInputListener.cpp, pages of messages such as:

OgreBulletListener.cpp:2435:55: warning: null character(s) ignored


I had to manually recreate the above files, neither dos2unix or fromdos worked for me.

3) You could update the demos code to resolve the case issue for the media files on Linux.

The problem with OgreBulletInputListener.cpp is probably due to the file being unicode encoded instead of ASCII..

I noticed this a couple of times recently (I think it was mainly with Ogrebullet) -- makes things like "grep" etc fail which is ugly.

And you have to have a text editor smart enough to handle the file format.

Cheers

Andy

Yep, your right it is unicode encoded, didn't notice that, Thanks.

Update: I (still) hate CVS.

I am trying to get my changes into CVS and it ain't workin'... When I try to do a checkout, SmartCVS mysteriously just aborts it for no reason during the checkout in random places. AAAaaaaarrrgghh..

Chaster

WHEW. !@#$*&^@$ CVS!!!! I had to redo all the changes (don't ask me why).

Okay, everything should be in CVS except for the "undefined symbols with OgreBulletCollisionsRay - getRay(Start/End)Point" issue. Can someone else verify this problem & solution?

Chaster

One small patch from me (in the Python-Ogre project we use GCCXML to parse the code and it's a tad strict at times)..

In Collisions/include/OgreBulletCollisionsRay.h

replace:
CollisionClosestRayResultCallback(const Ogre::Ray &ray, CollisionsWorld *world, Ogre::Real max_distance = 9999999999);
with:
CollisionClosestRayResultCallback(const Ogre::Ray &ray, CollisionsWorld *world, Ogre::Real max_distance=std::numeric_limits<Ogre::Real>::max() );
Thanks
Andy

That's a good fix. The 9999999 was just something I had originally put in as a temporary thing because I was in too much of a hurry to look up the Ogre define.

I'm test compiling right now... Will add to CVS if the compile is clean.

Chaster

Fix is in CVS. Thanks.

Chaster

There are still appear to be a few issues under Linux:
https://sourceforge.net/tracker/index.p ... tid=302997

There are still appear to be a few issues under Linux:
https://sourceforge.net/tracker/index.p ... tid=302997

I'm testing your patch right now, but encountered an issue with the latest CVS stuff TK added. I get the following compile error:


c:\ogrecvs\ogreaddons\ogrebullet\collisions\src\ogrebulletcollisionsworld.cpp(59) : error C2664: 'btCollisionWorld::btCollisionWorld(btDispatcher *,btBroadphaseInterface *,int)' : cannot convert parameter 3 from 'btDefaultCollisionConfiguration *__w64 ' to 'int'
There is no context in which this conversion is possible


And another (similar) error:


..\..\src\OgreBulletDynamicsWorld.cpp(55) : error C2661: 'btDiscreteDynamicsWorld::btDiscreteDynamicsWorld' : no overloaded function takes 4 arguments



Tuan, can you tell me if these are changes which are for Bullet 2.64? I am using 2.63 still (which is the stable build as of right now..)

Chaster

Sorry, I wrongly updated Ogrebulet to unstable bullet svn.

Please feel free to revert changes to 1.63 an apply patches (make sure you reply to them in sf tracker so that sinbad can mark them as closed.)

Please can you also do something about the (unicode?) encoding for OgreBulletGuiListener.cpp and OgreBulletInputListener.cpp, it really plays havok with gcc / Code::Blocks and submitting patches.

Sorry, I wrongly updated Ogrebulet to unstable bullet svn.

Please feel free to revert changes to 1.63 an apply patches (make sure you reply to them in sf tracker so that sinbad can mark them as closed.)

Hmm, if I revert, I will lose other fixes/updates you made. Also, I'm not sure which files to revert..

Also, apparently, Sinbad has already seen fit to assign the patch to me (Xenopi) which is okay this time, but as I mentioned before I don't want to take on the mantle of OgreBullet maintainer since I'm already overloaded and I can't even keep PCZSM updated (which is my main Ogre-related project)... I'm okay applying the patch this time, but I'm probably going to punt other ones back to you tuan (unless I have extra time somewhere).

Re: Unicode stuff. Hm. Not sure what's going on there. I work purely in Visual C and have almost no knowledge of other OS's (yes, I hang my head in shame) so I don't know how to tackle that particular problem...

*EDIT* Well, I decided to leave the bullet 2.64 stuff in there since 2.64 is supposed to go final "very soon"... Dermont's patch has been applied. All are in CVS now. Sorry, no fix for the "encoding" issue yet.

Chaster

@Chaster: Thanks. Waiting for the 1.64 is indeed wise, knowing great release frequency of erwin.
@Dermont: I committed file reverted to ansi. please tell me if it's ok now.

@Tuan, yes the files you reverted to ansi are OK, BulletListener.cpp still has the same problem ( I should have said above OgreBulletListener.cpp not OgreBulletGuiListener.cpp, sorry.)

Just a couple of minor problems (a) didn't seem to be take from the patch and (b) because of the problem above.

a) OgreBulletCollisionsMeshToShapeConverter.cpp

-#include "Shapes/OgreBulletCollisionsTriMeshShape.h"
+#include "Shapes/OgreBulletCollisionsTrimeshShape.h"


b) OgreBulletListener.cpp

-#include "Constraints/OgreBulletDynamicsPoint2PointConstraint.h"
+#include "Constraints/OgreBulletDynamicsPoint2pointConstraint.h"

- Entity *entity = mSceneMgr->createEntity(
- instanceName + StringConverter::toString(mNumEntitiesInstanced),
- "BulletBox.mesh");

+ Entity *entity = mSceneMgr->createEntity(
+ instanceName + StringConverter::toString(mNumEntitiesInstanced),
+ "Bulletbox.mesh");



The demo runs OK, but the left mouse drag doesn't appear to work. There are still may be some issues with texture names/ material names on linux:

chassis.material

//texture CB_SKIN.png
texture CB_Skin.png


and the following (?):


17:11:59: Can't assign material Ac3d/Plane/Mat001_Tex00 to SubEntity of Plane_13 because this Material does not exist. Have you forgotten to define it in a .material script?

17:11:59: OGRE EXCEPTION(5:ItemIdentityException): OverlayElement with name OgreBulletGui.w1 not found. in OverlayManager::getOverlayElementImpl at OgreOverlayManager.cpp (line 588)

17:12:09: Can't assign material default to SubEntity of cone2 because this Material does not exist. Have you forgotten to define it in a .material script?



Thanks.

@Dermont: Done. In CVS. Others warning are just warnings (betaGUI "betaness", and from plane mesh looking for material before we apply ours on it.)

I'll try to make a Bullet 2.64 release soon. It might not have all planned features, but let's move them to 2.65. The open source motto: release early and release often.

Could you make sure to use the btDiscreteDynamicsWorld instead of btSimpleDynamicsWorld? And btAxisSweep3 (or bt32BitAxisSweep3) broadphase instead of btSimpleBroadphase (I haven't check OgreBullet internals, but just to make sure).

Thanks,
Erwin

Could you make sure to use the btDiscreteDynamicsWorld instead of btSimpleDynamicsWorld? And btAxisSweep3 (or bt32BitAxisSweep3) broadphase instead of btSimpleBroadphase (I haven't check OgreBullet internals, but just to make sure).

Thanks,
Erwin

I already changed from btSimpleDynamicsWorld to btDiscreteDynamicsWorld. I will check the broadphase sweeps and update if necessary. Thanks Erwin!

*EDIT* OgreBullet is currently using btAxisSweep3. Should we change to bt32BitAxisSweep3?

Chaster