btSliderConstraint

Post Reply
Moose
Posts: 31
Joined: Mon Nov 04, 2013 10:58 am

btSliderConstraint

Post by Moose » Mon Jan 13, 2014 2:26 pm

Hello everyone,

I'm trying to include slider constraints into my bullet project after having successfully included 6dof, ball socket and hinge. With sliders however, I have surprisingly bad results.
Basically, each object only ever seems to travel along it's X Axis.
I found an old thread in this forum:
http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=2106

It says there, sliders assume X as their axis and you have to specify a trafo first that will rotate X where you want it. I have tried that in all ways I could see fit to no avail. Like Z for example, currently for one object

btTransform local_trafo = btTransform::getIdentity();
local_trafo.setRotation(btQuaternion(0.0f, 0.0f, 1.0f, 0.0f));
// local_trafo = mytrafo.inverse() * local_trafo;
slider_constraint = new btSliderConstraint(*(a->impl()), local_trafo, true);

Actually, it looks like no matter what I give into that parameter, it only ever travels along X. I even tried random gibberish. To me it looks like the parameters are ignored altogether.

So is btSliderConstraint maintained / useful at all?
Or should I better try to emulate them using generic 6dof?

If anyone has information about them, would be much appreciated.

Thanks,
Moose

Flix
Posts: 456
Joined: Tue Dec 25, 2007 1:06 pm

Re: btSliderConstraint

Post by Flix » Tue Jan 14, 2014 11:25 am

This is very strange... I've used it a few times without big problems (although setting the correct initial transforms is one of the most difficult things to do when using EVERY constraint in general :) ).

It's true that the slider operates on the X axis AFAIR.

You can check some examples in the SliderConstraintDemo if you want.
The constraint is used in the ForkliftDemo too in this way (to slide along the Y axis):

Code: Select all

		localA.setIdentity();
		localB.setIdentity();
		localA.getBasis().setEulerZYX(0, 0, M_PI_2);
		localA.setOrigin(btVector3(0.0f, -1.9f, 0.05f));
		localB.getBasis().setEulerZYX(0, 0, M_PI_2);
		localB.setOrigin(btVector3(0.0, 0.0, -0.1));
		m_forkSlider = new btSliderConstraint(*m_liftBody, *m_forkBody, localA, localB, true);
Maybe you can try changing the value of the useLinearReferenceFrameA flag ?

Hope it can help :)

BTW: What kind of rotation is this:

Code: Select all

local_trafo.setRotation(btQuaternion(0.0f, 0.0f, 1.0f, 0.0f));
?

Moose
Posts: 31
Joined: Mon Nov 04, 2013 10:58 am

Re: btSliderConstraint

Post by Moose » Tue Jan 14, 2014 2:33 pm

Hi Flix,

yeah, I got it to work now. Thanks. The trafo needed to be what I know as a "look at" trafo. With that it works as expected.
What I am unsure of is how to interpret the parameters of the two-body constructor.
Is that sort of a combination of two sliders or how should I read this? Not that important though, just out of curiosity.

Thanks for your help,
Moose

Flix
Posts: 456
Joined: Tue Dec 25, 2007 1:06 pm

Re: btSliderConstraint

Post by Flix » Wed Jan 15, 2014 11:05 am

Moose wrote:What I am unsure of is how to interpret the parameters of the two-body constructor.
Well, for the local transforms, I think the best way we can understand their meaning is to change one of them at a time and see the result.

As for the last argument "useLinearReferenceFrameA", I don't remember exactly its meaning right now... maybe it just "swaps" the constraint effect in some way... :?

Antonz
Posts: 16
Joined: Wed Nov 17, 2010 10:57 am

Re: btSliderConstraint

Post by Antonz » Wed Jan 15, 2014 11:30 am

I'm also wanted to integrate Slider constraint because currently I'm using Generic 6DOF Constraint in a mode with one linear limit constrained and other 5 limits are locked. And it looks that G6DOF constrain has some quirks/bugs that are hard to describe/test : it's like a dead zone where constraint sometimes passes very small impulse to another object when hitting it instead of expected depending on target motor velocity. I played with constraint's ERP value, target velocity, max motor impulse etc - dead zone shifts to another value but I cannot get rid of it completely. G6DOF (and subclassed springed constraint) also has other quirks like going into something like sleep (this happens with angular limits) but it's not the same sleep like with objects, it happens even when attached Rigid Body is set to "Disable deactivation" state. Probably I should setup a demo for this issues and start another topic or post an issue on bug tracker but let's return to slider constraint...

So, I went to look onto more simplier constraints than Generic 6DOF hoping that they are more stable and finished. For angular limits btHingeConstraint is looking good for my needs. But I'm confused with btSliderConstraint:
- It seems that many parameters are described but not used anywhere in calculations. For example: m_restitutionLimAng, m_softnessDirLin, m_dampingDirLin etc ...
- Others are used but only when they are set via generic setParam() function because it sets corresponding flag in m_Flags and only after this it starts to be used as an override in getInfo2NonVirtual() function. When they are set via any other set***() function param is just set but not used. What's the point then? Or I'm missing something?

Maybe Erwin can help and tell us what is finished and what's not in a world of Bullet constraints. :roll: It's a common problem when playing with Bullet: it's sometimes very hard to understand which part of engine or variable are in which state and how it works: what can be used, what finished, and what is abandoned and actually should be removed. Sometimes I must read half of engine code, half of forum, half of commit logs and half of issues until I find that some feature is incomplete or unfinished or needs attention. :(

User avatar
Erwin Coumans
Site Admin
Posts: 4184
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: btSliderConstraint

Post by Erwin Coumans » Thu Jan 16, 2014 1:15 am

The developer responsible for the btSliderConstraint is not working on Bullet anymore. I suppose you just need to use the X axis as hinge axis. Several of the constraints have been migrated from one system to the other, hence the unused parameter mess. You will have to look into the source code of the btSliderConstraint to see what parameters are used.

Currently, I am merging Bullet 2 from googlecode into the new Bullet 3 repository at github, and during the merge I'll fix the API/unused parameter issues. http://github.com/erwincoumans/bullet3

The btGeneric6DofConstraint has limitations related to euler angles, so not all axis can be fully 'free'. All this should be documented. There might be other bugs with the btGeneric6DofConstraint. Unfortunately there is no team working on Bullet, so we rely on external contributors to fix things.

Thanks,
Erwin

Antonz
Posts: 16
Joined: Wed Nov 17, 2010 10:57 am

Re: btSliderConstraint

Post by Antonz » Thu Jan 16, 2014 8:28 am

Can you answer a few questions about Bullet 3 plans, please (or maybe better to create separate topic?). I want to contribute from time to time and already submitted few minor patches but don't have much experience in advanced physics simulation topics, but can do some optimizations or fixes. For example, I have some ideas on modularizing Linear Math module and making SSE/Neon usage detection to runtime (and also extending Neon to Android and other ARM platforms) but this is for another topic - I'll write about it a bit later.
  1. When you plan to finish it (make first release)? Just rough estimate.
  2. Bullet 3 will be OpenCL only or it can be compiled with usual compiler as was Bullet 2? One of target platforms for our project is Android and you know the problems of OpenCL on it (moreover, because of middleware that we use we must compile single ARM code for Android and iOS).
  3. Old repository will be for minor fixes to version 2 only and backporting critical fixes from 3? All big patches to do against version 3 repository?
  4. There will be also new Issue/Bug tracker for Bullet 3?

Moose
Posts: 31
Joined: Mon Nov 04, 2013 10:58 am

Re: btSliderConstraint

Post by Moose » Thu Jan 16, 2014 2:49 pm

Antonz wrote: There will be also new Issue/Bug tracker for Bullet 3?
That's an interesting question too.

I had this assertion bug in Gimpact the other day and didn't know what to do with it other than posting it here. Was there a better way?

Cheers,
Moose

User avatar
Erwin Coumans
Site Admin
Posts: 4184
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: btSliderConstraint

Post by Erwin Coumans » Thu Jan 16, 2014 5:06 pm

When you plan to finish it (make first release)? Just rough estimate.
I aim for another release in March 2014, before GDC. It will be combined Bullet 2 + 3.
Bullet 3 will be OpenCL only or it can be compiled with usual compiler as was Bullet 2?
I am merging most parts of Bullet 2 into Bullet 3. OpenCL will be optional.
Old repository will be for minor fixes to version 2 only and backporting critical fixes from 3?
The old googlecode repository is obsolete, and I'm not applying any commits there anymore. I don't have the bandwidth to maintain two repositories, two issue trackers etc, hence the merge.
There will be also new Issue/Bug tracker for Bullet 3?
Yes, there is already a new issue tracker at github, see the Bullet 3 repository:
https://github.com/erwincoumans/bullet3
I'll move over existing Bullet 2 issues, once I am happy with the merging of two repositories. If I close the old googlecode issue, I put a link to the new github issue.
I had this assertion bug in Gimpact [...]
Gimpact, the Bullet 2 softbody, the kinematic character controller are pretty unstable and unmaintained and a support burden. It is not clear what will happen to those parts yet.

Thanks,
Erwin

Moose
Posts: 31
Joined: Mon Nov 04, 2013 10:58 am

Re: btSliderConstraint

Post by Moose » Fri Jan 17, 2014 4:04 pm

Erwin Coumans wrote: Gimpact, the Bullet 2 softbody, the kinematic character controller are pretty unstable and unmaintained and a support burden. It is not clear what will happen to those parts yet.
On the off chance of this getting a bit off topic ;-)

I had the impression Gimpact is not maintained that well. However, if its future is unclear, is there a preferred alternative for concave meshes?
I have substantial use cases for it here and I'd appreciate to know if it's gonna be removed in the future.

Thanks,
Moose

Post Reply