Softbody motion issues

[SynapticBytes]

Hi All,

I'm updating my Bullet plugin to try and add softbodies, but it's a whole extra world of hurt to rigid bodies.

I was expecting to have to update my 3D model vertices to match the rigid body vertices via a softbody motion state, but from what I can see, soft bodies don't have motion states, is that right?

So does anyone have a pointer in the direction I need to go? Do I just have to iterate all softbodies after a step simulation and try to redraw my 3D models, or what?

I started with a basic patch, but even looking at the triangle layout created from the passed in mesh, the triangles for each quad alternate their layout direction, whereas the 3D mesh always has the triangles in the same orientation. I've tried searching for how others have done it, but not found any suggestions as yet. Any suggestions would be greatly appreciated.

Thanks.

*EDIT* Changed subject to match more relevant discussion later in thread

[Mako_energy02]

It is correct that they lack motionstates, they weren't really built with gaming in mind in my opinion. To a degree a motionstate wouldn't make much sense for a soft body as a soft body doesn't really have a central location. In the few times I have bothered to tinker with soft bodies the transform from the base class doesn't seem to get used. Instead soft bodies are a collection of nodes connected by special constraints.

As for syncing them with a graphics model, you pretty much nailed it. You have to iterate over all the nodes in a soft body, taking the transform and copying them to the vertexes of the mesh. As for the alternating layout, I haven't seen that issue ever come up, but I haven't really looked carefully at soft bodies. Although I have heard of a similar issue being encountered by someone else on these forums when they were trying to synchronize Bullet's heightfield shape class with Ogre's terrain component. I believe it came down to them manually changing the triangle layout of the shape. So I wouldn't be surprised if changing soft bodies is needed.

[SynapticBytes]

Thanks for the reply. I've been doing some reading through the softbody helpers, and I think I see where the patch is alternating the triangle layouts, although I'm not sure why. Maybe an alternative layout will provide more realistic bending than a normal model construction layout.

You may be right about it not being designed for gaming. It's probably more suitable for just animation, but game engines is my domain, so I'm going to try and do my best to get it working. In the end, I think the createfromtrimesh helper is probably the best one to model my code after to get the closest match to the 3D model.

One other issue I've noticed is that as you say, there is no central transform for a soft body, but I think I need to try and virtualise one somehow, both to get some sort of reference frame to be close to the translation of my 3D model, plus the softbody node coordinates are in world space, but the model vertexes are in local space, so you need an offset of some kind to keep the spaces synced between the two objects. I see there are softbody transform and translate methods, and being derived from a collisionobject, softbodies do have a getWorldTransform method, but it seems to be a 0 vector from the initial testing I've done.

Anyway, I'll try and make my own creation and mesh update methods from some other bits and pieces I've found, and see how it goes. Performance in the end will be the deciding factor as to whether they are viable or not, especially since ShiVa, while cross platform on almost all popular platforms, is largely targetted at mobile development, where I think softbodies will struggle.

[Mako_energy02]

While I was doing my test with soft bodies forever ago I did come to the idea that after populating all the nodes from the mesh, adding an additional node that is the intended center of mass for the soft bodies initial shape. Remember to generate (or regenerate) the bodies constraints after adding the node. It should work fine and help give some more structure to the shape (assuming that is your goal). Also this wouldn't work for simulating cloth or paper...at least not as well. But for enclosed shapes, use that extra node as it's central transform.

I have yet to try this myself. If you try that out, let me know how it goes.

[SynapticBytes]

Cool thanks. I'll see how I go. I saw another bit of code which seemed to use vertex 0 as an anchor, but given that vertex 0 could be in a semi-random location, I'm not sure how well this would work, especially since it's likely to be an outlying point in flatish shapes, which is likely to deform more than others.

[Mako_energy02]

Yeah, I think that is how the OgreBullet wrapper does it. I pretty much concluded the same. I actually got the idea to add an additional node for the center of mass as a result of misreading that code.

[SynapticBytes]

OK well I've made some progress and have what visually looks like a working simulation, although my 3D object is not being translated yet.

However, I have some weirdness that I'm not sure where to start looking. I'm dropping a basic 8 sides cylinder onto a rigid body box which is resting on a rigid body plane, also setup as a box. You can see the basic wireframe here



The cylinder falls, hits the edge of the box and bounces sideways to come to rest on the plane. Just before the cylinder comes completely to a stop, it suddenly translates to a random location many units away from where it should be. I've logged the location of node 0 of the cylinder, and you can see in the snippet of the log below, it's suddenly moving millions of units away. The displacement is not constant, sometimes it's only a few hundred units.

[o Message ] {Scripting }Softbody node 0 position transform: 1.82858,0.747861,0.471917
[o Message ] {Scripting }Softbody node 0 position transform: 1.82684,0.746089,0.472665
[o Message ] {Scripting }Softbody node 0 position transform: 1.82586,0.744594,0.472446
[o Message ] {Scripting }Softbody node 0 position transform: 1.82482,0.744718,0.472276
[o Message ] {Scripting }Softbody node 0 position transform: 1.82475,0.747125,0.471398
[o Message ] {Scripting }Softbody node 0 position transform: -2.70127e+008,6.11986e+007,8.24502e+008
[o Message ] {Scripting }Softbody node 0 position transform: -4.68514e+008,2.71059e+008,1.79998e+009
[o Message ] {Scripting }Softbody node 0 position transform: -6.60542e+008,4.41437e+008,2.65385e+009
[o Message ] {Scripting }Softbody node 0 position transform: -8.8426e+008,5.84541e+008,3.53877e+009

What could be causing this? Some kind of penetration issue? I had a basic 5 x 4 "cloth" running earlier and it fell to the plane and settled with none of this teleporting happening.

Any ideas?

Thanks.

*EDIT*

With a bit more testing, it seems to depend on how the cylinder is resting on the plane. If it lands on one of the round end, it doesn't do it's trick.

Also, the cylinder never comes to a stop in any orientation. It continues to slowly turn around the global Y axis.

The body parameters I copied directly out of other code, but are :-

Code: Select all

	btSoftBody::Material* pm=sBody->appendMaterial();
	pm->m_kLST		=	btScalar(0.1);
	pm->m_flags		-=	btSoftBody::fMaterial::DebugDraw;
	sBody->m_cfg.kDF	=	1;
	sBody->m_cfg.kSRHR_CL		=	1;
	sBody->m_cfg.kSR_SPLT_CL	=	0;
	sBody->m_cfg.collisions	=	btSoftBody::fCollision::CL_SS + btSoftBody::fCollision::CL_RS;
	sBody->generateBendingConstraints(2,pm);
		
	sBody->getCollisionShape()->setMargin(btScalar(0.05));
	sBody->setTotalMass(1);
	
	sBody->generateClusters(0);

*EDIT #2*

All of those settings I realised were on a second material, so I just commented them all out, and the teleporting seems to have vanished for now. Object is still rotating. I tried adding this setting in

Code: Select all

sBody->m_cfg.collisions	=	btSoftBody::fCollision::SDF_RS + btSoftBody::fCollision::CL_SS + btSoftBody::fCollision::CL_SELF;

but the rotating seems slightly faster now. I'm yet to figure out exactly what the cluster stuff does, so not sure if that may help, or may have been the cause of the initial problem.

[Mako_energy02]

I'm a bit hazy on this, but I dove into the code for a quick refresher and it provided some clues. Clusters in a soft body are essentially groups of nodes that react to collisions collectively, instead of through the soft body constraints. It makes the math a little simpler and the body overall behave more like a rigid body. When passing in "0" into the method you really aren't doing anything. You are just saying you want no clusters, so it wipes out the existing clusters (if any) and then just returns.

As for the rolling, I don't think I can help you there. My first thought would be to add some damping, but I don't know how to do that for soft bodies. =\

[SynapticBytes]

Right, so I did a little more research on clusters, and it seems you're right on what clusters do, but using 0 as a parameter creates a cluster for each triangle.

From the api

generateClusters with k=0 will create a convex cluster for each tetrahedron or triangle otherwise an approximation will be used (better performance)

So that should be OK. I've tried variations of configs. The teleporting hasn't happened again since I removed the 2nd material, but still having drift issues. I see there is a drift parameter but I haven't tried it yet.

I dud try the drag parameter, but that looked bad. Even with a 0.1 value, it slowed down the softbody markedly, even while in freefall, and sliding off nother rigid body very jerky.

I guess it's down to playing with the dozens of parameters to see what all changes what.

[Mako_energy02]

I saw that in the api as well. It isn't very clear but a cluster for each triangle is no different than normal operation. A soft body makes faces from triangles anyway which are used for collisions. If you look at the actual source on line 1136 of btSoftBody.cpp you will see it does exactly as I stated. Doing as you have done won't cause issues, it simply won't be different from commenting out the line entirely.

There was a comprehensive list of the soft body parameters posted by Dphil on these forums somewhere, I'll see if I can find it again and post here if I do.

Edit: Found it: http://bulletphysics.org/Bullet/phpBB3/ ... 280#p24280

[SynapticBytes]

Thanks that list will be good.

I didn't realise the triangles were already collision shapes. Other posts I'd read said only the vertices collided, causing penetration when triangles are large. I thought that was what clusters prevented, even on 1 cluster per triangle. But i guess that's why I didn't notice an difference with the cluster ode commented or not.

I also realised by "tranform subtract" solution for the 3d model placement has an issue, as my model vertices are in local space. Made for some interesting results when the object was rotated

So, looks like there will be some matrix algebra needed. I'm still brainstorming ways to defne the transform origin for the softbody and matching it to the rigd body. Instead of adding an additonal node, i was thinking maybe a "sum of all node positions" might be a suitable approximation. Only thing is, I'll have to compute it first as I have to do the 3D object transform before updating the vertices positions, which means two passes through the vertex buffer every frame. This is just an idea yet, I have put virtual pen to paper on it.

[SynapticBytes]

Still no luck removing the jiggles.

I've put a youtube video up showing what's happening, although it's my first Youtube video, and the quality is pretty bad, sorry about that. Debug drawing of wireframe is on. Hopefully you can at least get the idea of what the body is doing.

*EDIT*

slightly improved quality version

http://youtu.be/GqW2tF4SF7A

[Mako_energy02]

That is much more rigid than I had anticipated. Also that looks like normal jitter when there is one minor thing misconfigured. For the sake of thoroughness, lets run down the list.

1. Scale. How large or small are these objects? Depending on their size and the timestep, too much time may be passing on each step for bullet to make it accurate.
2. Timestep. Covered above.
3. Constraints. Are you absolutely sure there are no constraints going on between the object and the ground in way not immediately obvious? This sounds like a dumb question but trust me, it's happened.
4. CCD. Do you in any way have Continuous Collision Detection enabled for your simulation? Last I checked Bullets implementation was unstable. It has gotten improvements since I last tested so it could be better, but something to keep in mind.
5. Collision Shapes. Some collision shape mashups aren't very stable in all situations, in some cases even basic situations. Although the one that seems to get the most complaints is the sphere shape with things like triangle meshes. Obviously the soft body has a btSoftBodyCollisionShape applied to it. What is the ground? You said they were boxes, is it safe to assume they use a btBoxShape? (As opposed to something silly like being boxes visually, but use trimesh collision shapes)

That's all the common stuff I can think of atm.

[SynapticBytes]

That is much more rigid than I had anticipated. Also that looks like normal jitter when there is one minor thing misconfigured. For the sake of thoroughness, lets run down the list.

1. Scale. How large or small are these objects? Depending on their size and the timestep, too much time may be passing on each step for bullet to make it accurate.
2. Timestep. Covered above.
3. Constraints. Are you absolutely sure there are no constraints going on between the object and the ground in way not immediately obvious? This sounds like a dumb question but trust me, it's happened.
4. CCD. Do you in any way have Continuous Collision Detection enabled for your simulation? Last I checked Bullets implementation was unstable. It has gotten improvements since I last tested so it could be better, but something to keep in mind.
5. Collision Shapes. Some collision shape mashups aren't very stable in all situations, in some cases even basic situations. Although the one that seems to get the most complaints is the sphere shape with things like triangle meshes. Obviously the soft body has a btSoftBodyCollisionShape applied to it. What is the ground? You said they were boxes, is it safe to assume they use a btBoxShape? (As opposed to something silly like being boxes visually, but use trimesh collision shapes)

That's all the common stuff I can think of atm.

1. The cube and cylinder are 1 unit dimensions, the plane size I set to (10, 0.1, 10) although I tried a Y dimension of 1 as well in case it was a thin object problem, but with no difference. Cube and plane mass set at 0 to make them static.

2. Timestep is bullet default 1/60

3. I created this project from scratch to test the softbodies, and have not entered any constraint code, so if there are any, they coded themselves I went back and checked the code, and can't see anything t do with constraints anywhere.

4. No CCD enabled

5. Both the cube and the plane are btBoxShapes.

I'll try a few other shapes and see what happens.

*EDIT*

Well, after going through most of the easy to setup shapes, I haven't come to any real conclusions except maybe the last point below. I note the following :-

1. If you don't generate bending constraints, your shape will collapse like a dying spider, and I also managed to create another teleport issue with a large plane as a soft body this way.

2. Soft cubes don't react any different to rigid ones?

3. Cones (on the round base) react very badly and bounces away very quickly off the edge of the plane like someone walking over hot coals

4. Turning the planes from a box to a convex hull speeds up the drifting rotation.

5. This is my biggest indicator. Setting my static cube to a rigid body, mass 1, and when the cylinder falls on it, it is rapidly ejected through the bottom of the plane into hyperspace. If I set the cube mass to 20, it doesn't got shot away, but the cylinder still manages to push it towards the outer edge of the plane. At first thought, this could mean for some reason the soft bodies have a large amount of inherent force of some kind, and resting on a static body which can't move, that force is somehow being fed back into the soft body as a reactive force, which is causing the jittering. The question is, if that seems plausible, where is this force coming from, why, and how to stop it?

[Mako_energy02]

5. This is my biggest indicator. Setting my static cube to a rigid body, mass 1, and when the cylinder falls on it, it is rapidly ejected through the bottom of the plane into hyperspace. If I set the cube mass to 20, it doesn't got shot away, but the cylinder still manages to push it towards the outer edge of the plane. At first thought, this could mean for some reason the soft bodies have a large amount of inherent force of some kind, and resting on a static body which can't move, that force is somehow being fed back into the soft body as a reactive force, which is causing the jittering. The question is, if that seems plausible, where is this force coming from, why, and how to stop it?

As far as I know the only way for a soft body to generate force is through it's constraints. I mean the node to node constraints that are generated with the "generateBendingConstraints()" method that you mentioned removing. Without those constraints they are just particles that flop to the ground. There are a few ways you can tinker with the force they produce. The primary one that comes to mind is the pressure coefficient. The pdf from Dphil says that is the "kPR" property. If that is fairly high, you could get getting forces that overcompensate. I think it defaults to a sane value at the intended scales for Bullet, which you have clarified you are using, so I don't think that is very likely.

Two things come to mind for additional tests. Can you add a rigid body to the simulation and drop it to see if it jitters as well? If it does, we may not want to look at soft body specific logic. Also, can you try to up the step "resolution" and change your step time to 1/120 instead of 1/60?