Unfortunately I can't say for sure without investigating exactly how our rigid body library (Bullet) behaves, which would take quite a lot of time.
Most likely this is how it's supposed to work. The reasoning is that the sort of numerical solvers we use are quite sensitive to things like how many objects there are, the order in which objects are added to the simulation, etc.
Determinism is only really guaranteed if you run the exact same simulation multiple times, adding objects changes the simulation.
It's possible to improve this behaviour, but depending on how exactly things are implemented it could be a lot of work.

Thanks for the report, but unfortunately this is expected behaviour.
There's different ways of mixing bounciness (restitution) values of two objects you could use.
The formula we use is: restitution_a * restitution_b, which will give you a value of 0 if any of the two is 0.
It's also common to use the maximum of the two values (which imo behaves better and is also what you expected).
If it were up to me, that's what we wold be using. However, that decision has been made a long time ago and changing it now would mean breaking all simulations.
So this is a limitation.

Yes, this is not a regression, but a quirk of how rigid body cache works.
As noted above you only need to "Delete Bake".
One thing we could do is flag cache as outdated after the the user has pressed "Delete Bake".
The way it is now, you still have to make a change to the simulation before that happens (like modifying or moving objects).

As I mentioned there is a second regression here, in that changes to the force field don't invalidate rigid body cache.
Simple way to reproduce:

1. Add a rigid body.
2. Add a force field.
3. Simulate a few frames.
4. Change force field strength and see that the rigid body cache hasn't been invalidated.

There's been quite a few changes to the way the transformation tools work in 2.8 it seems, so I don't know if it's possible to make it work like before.
I'll try to look into it wen i get some time.

Seems like another depsgraph problem, @Bastien Montagne (mont29) or @Sergey Sharybin (sergey) should look at this.

Ok, I fixed part of this in 5cc015f0ad05.
However there's another regression. Changes to force fields don't mark the rigid body cache as outdated (the PTCACHE_OUTDATED flag needs to be set).
I don't think I have time to figure out how the depsgraph works to add the proper relations for that, so I think either @Sergey Sharybin (sergey) or @Bastien Montagne (mont29) should take a look.

LGTM

@Alexander Gavrilov (angavrilov) Having a drop down menu to select the spring type, like I mentioned above, should be fine.

I find the generic spring constraint to be the most useless of all the constraints, having 2 of them is just silly.
I wouldn't mind too much if the spring constraint had a type field that would be set to the old spring behaviour for old files and default to the new behaviour for new constraints.

The advantage of the new springs is that you can actually create stiff springs.
This is a bug in bullet, so it should also be reported there.
As for how to handle it in blender. I'd really like to avoid having 2 generic spring constraints.
So if the new one doesn't work well and can't be fixed, just revert the change and continue to use the old one.

Regarding bullet update: I've only backported the spring fix as a full update would once again change how all dynamics work.
So it's better to hold of full update until we actually need it.

So I really don't like this.
Setting the origin already has too many options, when is "Origin to Geometry" ever actually useful, especially since we have the "Center of Mass" option.
If anything we should remove the "Geometry" option.
This is not a trivial matter as well, in the past I had several users being confused by this.

This is not really a bug but more of a limitation.
I have a patch that does proper deactivation in the rigid body improvements branch, but it wasn't committed because it wasn't clear how deactivation should be handled in blender in general.
I might dust if off since this really can be preveived as a bug.

This is intentional behaviour. "Final" includes generative modifiers which don't just deform the mesh but generate a new one.
Now we could do shenanigans like rebuilding the collision shapes every frame, but that would be extremely slow and unstable.

Also found another bug unrelated to this which was introduced after 2.78 and is in the RC (baking is broken).
Will look into it later today.

Can someone test this patch to make sure it fixes this and T50230 before I commit?

Probably, but you'd also want to do more significant changes as well.
For the Spring constraint specifically you'd want to do something like this: T39076
More generally there are several big design decisions that I think were wrong. If we could change those for 2.8 that would be even better, but that's a bigger toppic.

I think adding this constraint was a mistake (it's too complicated to use, stiff springs don't really work), but since it's already there adding these settings won't make things worse, so LGTM :)

There shouldn't be any problems with animating these properties in principle.

The flip happens because the object has negative scale on the z axis.

I'm very suspicious about clearing the kinematic flag.
I'm not familiar with how the game engine handles this exactly, but it should be possible to handle these flags when objects are added/modified.
If kinematic objects don't sleep, then there's probably a flag not being set correctly somewhere when it's added.

From a quick glance this patch shouldn't be necessary since the affected classes aren't used by Bullet.

@Lukas Toenne (lukastoenne): I was just about to ask you about this :)
Looks good at first glance.
I'm not quite sure about the ghost object part, will take a closer look over the weekend.

lgtm

Looks fine to me.
You could probably do the refresh collisions part in different ways but it should be ok if it's really needed.

There are two things here:
If you want the rigid body to deform, you have to check the "Deforming" checkbox.
The second problem is that you actually move the deforming rigid body, so even if it looks like it's standing still to the simulation the object is moving in the direction it's animated (I understand that that's what you need to do for the curve deformation to work). So the second file will work, but the circle will still fail.

Linking with rigid bodies is tricky, afair we decided that you counldn't link individual rigid body objects but could link entire scenes containing rigid bodies.
The problem is that the rigid body world belongs to the scene which causes all sorts of trouble for linking.
If you need individual objects you have to bake. Otherwise keep all objects that belong to one simulation in one scene.
Not sure if the unlinking in this case is a bug though, I don't really have this stuff in my head anymore and can't tell what is good behaviour for linked objects in blender.

I'm not familiar with this code so I'm not sure why we get a hit reported without having a mesh, I guess this is intentional?
Doing the check to prevent the crash should be fine then, but maybe it's better to test for m_hitMesh?

@Julian Eisel (Severin), actually I wanted to look into this again soon, maybe in the next few weeks when I can find some time.
Unfortunately it's not so simple to track down.

Should be fixed by rBf7dedbc

Ok, can reproduce now.

Hmm, I can't reproduce the problem, seems to work fine.

Just a heads up, upstream bullet has a new spring constraint that might work better if someone is interested in playing with it.

Ok, I think messing with bullet's main loop is not a good idea after all.
Closing this, as a limitation.

Can't reproduce issues with baked sim with either 2.71 or master. Are there specific steps I can follow?

@Inês Almeida (brita_)
Look in intern/rigidbody/rb_bullet_api.cpp, also the convex hull mesh operator in edit mode uses it.
As for whether the GE should use it or not, I didn't make quality comparisons but the new hull computer should be much faster with bigger meshes.
So for games this shouldn't be that important since you generally don't use big meshes and we didn't get any complaints about convex hull generation afaik.

No, it does lower stacking stability. If you use it you'll need more solver iterations/simulation steps.
The thing is that in this case split impulse might only marginally help and only sometimes.

Looking further into it, culprit seems to be rBdf1a199, settings in blenderobject->bsoft are now completely ignored.
Here is a quick patch:

This is a regression, it's been broken somewhere after 2.70.
My guess would be that the way softbodies are constructed by blender has changed.

Afaik this is a AI feature, not really physics related.
If moving obstacles are supported, it could probably be done for the character controller as well.

@Inês Almeida (brita_) that depends on whether walk direction is allowed to be 0 or not. If it can be zero just check for that and don't call normalize.
I'm not sure what's intendet here, maybe ask @Mitchell Stokes (moguri)?

@Inês Almeida (brita_) the problem with the cast is that the shape can be non-convex, as a trimesh is. So we have to at least make sure that the shape is in fact convex before casting.

@Inês Almeida (brita_) moguri's suggestion is just a style nitpick :)

Usually character controllers use shapes like sphere and capsules. Maybe there is a problem when doing a convex cast with other shapes? I'm just guessing though.

Hmm, the character controller actually rotates the object. I guess there's a problem there or maybe the walk direction is not calculated correctly. I'd start by looking at KX_ObjectActuator.cpp, lines 223-255.

From a quick glance, the character controller needs a convex shape. This is either the main shape assigned, or a separate convex shape.
For the latter m_useGhostObjectSweepTest needs to be set to false.

I'd rather not do that.
Since this is only a problem with compounds, not all static objects, having 0.04 as default seems still sensible.
Bblender first makes all objects static and you can switch to dynamic afterwards.
There is no way of setting different default margins for dynamics and staric objects, otherwise we could make static objects have 0 margins by default.

Thanks for the report, but this is not a bug.
You're assigning convex hull shapes to non-convex objects (pretty much all objects in the files are concave).
What you need to do is either split the objects into convex parts, or use mesh shapes. Mesh shapes are not very stable of course to it'll be hit or miss.
In general, if you want to do things like having objects rotate about a specific axis, it's much better to use constraints.

Using the old raycast method should be fine, we did that for T37673 as well.

Sorry for responding so late.
In general this is a good idea.
However, I have some reservations.
In hindsight we shouldn't have added the generic spring constraint either.
The main problem is that bullet's builtin springs don't behave very well and make it pretty much impossible to create stiff springs which is the main use case as far as I can see.
So I think we need a better spring implementation before adding it to the UI.

Closed by commit rB258e30f2c7d2.

Closed by commit rB6ffabfae852f.

Hmm, I'll have to think about this. Not quite sure if we can make this work.

@Garrett (Garrett):
I agree, I'm not a fan of the use of groups here either. But it was decided to use them here and it's hard to change it now.

@Garrett (Garrett):
It seems thst your rigid body world doesn't have a group assigned.
Try selecting "RigidBodyWorld" as the simulation group and things should work.

@jens verwiebe (jensverwiebe): I think you should take a look at this.

Since the problem isn't present in the buildbot builds the bug is either fixed or it's a problem with the way the testbuild was made on OSX.
Please Test the release candidate when it comes out to make sure it's not the latter.

◀ Merged tasks: T38940.

✘ Merged into T38746.

@jesus lamas (jesus650rwc) @Rob Waite (vectorspace)
Could you test the latest buildbot and see whether the problem still exists?

Can't reproduce here on arch linux 64 bit.
Would be good if someone could try to reproduce this on a mac.

it's actually a general problem with simulations, changes to force fields don't always invalidate the cache.

@Ellwood Zwovic (gandalf3) it's not just a problem with constraints, if you change the speed of the simulation or the steps per second during collisions you'll have the same problem. So be careful.