I'm using OS X 10.5, I would like to "install" Bullet, ideally as a OS X style framework, but would be happy to settle for a linux style /usr/local/{include,lib} type installation.
Unfortunately, I can't figure out how to do either. If I cmake -G Xcode, I can build and run the demos, but I don't see a way to install onto the system in order to link with my own code. The 2.72 package lacks the 'configure' script, and running automake; autoconf yields complaints about undefined macros AM_INIT_AUTOMAKE and AC_PROG_LIBTOOL, eventually producing a 'configure' script which immediately fails out with "configure: error: cannot run /bin/sh ./config.sub". Using cmake with Makefiles (no -G option) builds successfully, but also seems to lack and "install" target.
Errr, so how is this supposed to work? Ideally I'd like dynamic-link libraries too, instead of static ones which seem to be produced.
thanks!
'install' Bullet'?
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: 'install' Bullet'?
renamed topic to ''install' Bullet'?' to better reflect the issue.
Bullet is not designed to be a system-wide library, so it should not be 'installed'.
Please include the library within your project and use relative paths.
Bullet is not designed to be a system-wide library, so it should not be 'installed'.
Please include the library within your project and use relative paths.
-
- Posts: 96
- Joined: Mon Nov 03, 2008 9:57 pm
Re: 'install' Bullet'?
Hmm, Bullet is kind of large to include in our distribution, although that's certainly possible.
Is there interest in system-wide installation? Some reason to avoid doing this?
Is there interest in system-wide installation? Some reason to avoid doing this?
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: 'install' Bullet'?
Just out of interest, can you give some details about your distribution? You likely only need the Bullet/src folder, which is about 2.5Mb. If that is too big, your project could have have an empty placeholder for Bullet, with a readme.txt that explains which version of Bullet to download from http://code.google.com/p/bullet/downloads/list .Bullet is kind of large to include in our distribution
You need to call ./autogen.sh to create a configure script, and then ./configure and make or jam. Jam has an 'install' option that copies the libbullet*.a into /usr/local/lib and the headers files from src into /use/local/include. If you lack jam, no problem: bullet-2.x/jam-2.5 allows you to create and install it system-wide. Just go to the jam-2.5 folder, type make and then sudo jam0 install.The 2.72 package lacks the 'configure' script
Applications and games using Bullet are usually tuned using a specific version of Bullet. All versions of Bullet have different behaviour, so if games/apps would use a system-wide (dynamic) library, they could become un-usable by an upgrade of Bullet. For graphics and sound and networking this is usually not a big issue, but for physics it is.Is there interest in system-wide installation? Some reason to avoid doing this?
But if you contribute an install for cmake or make, we are happy to include it.
Thanks,
Erwin
-
- Posts: 96
- Joined: Mon Nov 03, 2008 9:57 pm
Re: 'install' Bullet'?
Sure, I'm writing a physics-based simulation for a robotics package: http://www.tekkotsu.orgErwin Coumans wrote: Just out of interest, can you give some details about your distribution
I've actually been trying to use ODE so far, but I'm getting tired of constant denormalization/NaN issues. With ODE this leads to abort()s and the app crashing
Sorry, could you say a bit more about what kind of tuning or behavior might break with new releases? Since I'm coming from ODE because of frustration with simulation fragility, I'm nervous to hear similar issues here. I'm not necessarily concerned with getting the exact same simulation response between different versions, but I wouldn't want it to start abort()ing or otherwise completely blowing up.Applications and games using Bullet are usually tuned using a specific version of Bullet. All versions of Bullet have different behaviour, so if games/apps would use a system-wide (dynamic) library, they could become un-usable by an upgrade of Bullet.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: 'install' Bullet'?
Which constraint solver from ODE are you using? Do you call dWorldStep or dWorldQuickstep?
Bullet currently doesn't have a 'direct' pivoting LCP constraint solver such as Danztig used in dWorldStep. Bullet's btSequentialConstraintSolver has similar quality compared to ODE quickstep (slightly better, due to improved friction model).
In case iterative constraint solver (quickstep/sequential impulse) doesn't provide enough quality: we have plans to add a Featherstone constraint solver. This could be useful for your robotics application.
Thanks,
Erwin
Bullet currently doesn't have a 'direct' pivoting LCP constraint solver such as Danztig used in dWorldStep. Bullet's btSequentialConstraintSolver has similar quality compared to ODE quickstep (slightly better, due to improved friction model).
In case iterative constraint solver (quickstep/sequential impulse) doesn't provide enough quality: we have plans to add a Featherstone constraint solver. This could be useful for your robotics application.
Blowing up or aborting is not so likely, but small differences in behaviour accumulate and lead to totally different results over time.Sorry, could you say a bit more about what kind of tuning or behavior might break with new releases? Since I'm coming from ODE because of frustration with simulation fragility, I'm nervous to hear similar issues here. I'm not necessarily concerned with getting the exact same simulation response between different versions, but I wouldn't want it to start abort()ing or otherwise completely blowing up.
Thanks,
Erwin
-
- Posts: 96
- Joined: Mon Nov 03, 2008 9:57 pm
Re: 'install' Bullet'?
I've tried both... dWorldStep tends to die quicker, dWorldQuickStep survives a bit better but has issues with stuff "vibrating"... I could probably tweak some parameters to fix that, but since it does also die, that's not really motivating.Erwin Coumans wrote:Which constraint solver from ODE are you using? Do you call dWorldStep or dWorldQuickstep?
Meh, I actually tracked my issues back to their LCP solver directly returning NaNs, and it's not like I'm doing anything particularly extreme... masses between 3 and .1, dimensions around .1 to 1. I have a feeling my issues involve needing to filter the collision contact points, but I'd rather not have to write black magic contact-merging code, especially when that still doesn't guarantee that the LCP solver is going to stay healthy.Erwin Coumans wrote:Bullet currently doesn't have a 'direct' pivoting LCP constraint solver such as Danztig used in dWorldStep
I've read bullet likes to have units above .2 so I guess I'll need to try scaling all the dimensions. Is there an upper limit? If I use mm, and my model dimensions are 100 to 1000ish, would that be OK, or do I need to be more flexible? (Although, I'd rather be able to tweak engine parameters and leave the dimensions in SI...)
Oh, to get back on-topic, thanks for pointing out the included autogen.sh and jam method... One more build question: what's the "correct" way to control optimization and/or debugging symbols (e.g. -O2 -g), with either cmake or jam? CXXFLAGS?
If I decide to contribute some build scripts, is cmake the way you're heading? (don't bother with jam contributions?)
Thanks
-
- Posts: 96
- Joined: Mon Nov 03, 2008 9:57 pm
Re: 'install' Bullet'?
I figured this one out btw:ejtttje wrote:One more build question: what's the "correct" way to control optimization and/or debugging symbols (e.g. -O2 -g), with either cmake or jam? CXXFLAGS?
cmake -D CMAKE_BUILD_TYPE=RelWithDebInfo .
(or one of Debug, Release, RelWithDebInfo, or MinSizeRel)
The wiki page could probably use some more details on stuff like this since cmake usage isn't quite as well known I think... looks like there are some cmake options for directly generating OS X frameworks too, so I'll wait until I finish trying to figure that out and maybe do some wiki updates later.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: 'install' Bullet'?
Now the latest trunk has CMake 'install' support (untested).
It was a contribution that wasn't applied yet:
http://code.google.com/p/bullet/issues/ ... d=97&can=1
Thanks,
Erwin
It was a contribution that wasn't applied yet:
http://code.google.com/p/bullet/issues/ ... d=97&can=1
We would appreciate that. Please reply with your wiki username, so we can enable write access (we disabled it, because of previous wiki-spammers).maybe do some wiki updates later.
Thanks,
Erwin
-
- Posts: 96
- Joined: Mon Nov 03, 2008 9:57 pm
Re: 'install' Bullet'?
username: ejtttjeErwin Coumans wrote:Please reply with your wiki username, so we can enable write access (we disabled it, because of previous wiki-spammers).
Thanks — appreciate the responsiveness!
-
- Posts: 96
- Joined: Mon Nov 03, 2008 9:57 pm
Re: 'install' Bullet'?
I submitted a patch for shared library and OS X framework support.
http://code.google.com/p/bullet/issues/detail?id=129
I may followup with another patch to combine the separate frameworks into a single umbrella framework.
Until the wiki gets updated, you can trigger shared libraries by adding:
-D BUILD_SHARED_LIBS=true
to the cmake call.
Under OS X, you can generate frameworks instead of "naked" .dylib's with:
-D BUILD_SHARED_LIBS=true -D FRAMEWORK=true
(need both)
http://code.google.com/p/bullet/issues/detail?id=129
I may followup with another patch to combine the separate frameworks into a single umbrella framework.
Until the wiki gets updated, you can trigger shared libraries by adding:
-D BUILD_SHARED_LIBS=true
to the cmake call.
Under OS X, you can generate frameworks instead of "naked" .dylib's with:
-D BUILD_SHARED_LIBS=true -D FRAMEWORK=true
(need both)
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: 'install' Bullet'?
The CMake patches have all been applied:
How small do your objects need to be?
Thanks for the contribution.
Erwin
- install support has been added. CMake regular build still works with CMake 2.4, but 'install' feature requires 2.6.
- Framework support added
- Lib prefix has been removed, to facilitate Framework support
- App prefix is added to demos, to distinguish them from libs
Support for smaller objects has been improved, by dynamically choosing a contact breaking threshold. It is best to use a smaller internal timestep, when collision shapes are really small. for example:I've read bullet likes to have units above .2 so I guess I'll need to try scaling all the dimensions. Is there an upper limit? If I use mm, and my model dimensions are 100 to 1000ish, would that be OK, or do I need to be more flexible? (Although, I'd rather be able to tweak engine parameters and leave the dimensions in SI...)
Code: Select all
stepSimulation(deltaTime, 4, 1./240.);
Thanks for the contribution.
Erwin