Jittery rotation collision

[snoozbuster]

So, I have a row of tube-shapes, and they rotate with AngularVelocity when a box collides with them. The goal is to produce a type of conveyor belt, but the boxes end up jittering and launching randomly, instead of being smooth. What would help increase the smoothness? More/less AngularVelocity? Tubes closer/farther away? More/less mass on the boxes (the tubes are kinetic)? More/less Solver iterations? Bigger/smaller boxes? I tried using a flat plane over the top of the tubes, and setting boxes that collided with it to have LinearVelocity, but that didn't work for some reason. I would like there to be a bit of "jitteryness" to the collision, but not so much that the boxes are rolling all over the place and flying off in random directions.

[Norbo]

If it's just a bunch of kinematic cylinders lined up with a constant angular velocity, there should be no issues with dropping stuff on top of them. If friction is high enough, an object might get pinched, but that shouldn't happen if the rollers all have constant angular velocity (the default friction is quite low).

If you're modifying the angular velocity based on collisions, it's conceivable that the velocities don't match up properly and the objects are more prone to getting pinched. This would manifest as the object falling between two rollers momentarily, possibly getting stuck depending on the spacing, and then launching out one side or the other. Lesser launches could also occur, appearing as 'jitter.' Higher friction would make such launches more likely.

If the cylinders are kinematic, they have effectively infinite mass. Changing the mass of the box will not change the simulation result meaningfully unless you go crazy high or crazy low. Increasing the iteration count increases the simulation quality at a cost, but chances are it would not meaningfully change the result of the simulation you're running. The 'most correct result' based on the information the simulation has may indeed be what you see.

Some pictures, diagrams, videos, and further explanation of what exactly is going wrong and what is desired would help me provide more precise guidance

[snoozbuster]

If friction is high enough, an object might get pinched, but that shouldn't happen if the rollers all have constant angular velocity (the default friction is quite low). If you're modifying the angular velocity based on collisions, it's conceivable that the velocities don't match up properly and the objects are more prone to getting pinched.

When the box hits the roller, it starts rotating. Perhaps this is related, however, I don't want all the rollers rotating at the same time. This leads to an idea; always have the entity rolling but shear off the rotation part of the Matrix if a box isn't touching the tube (that way, I'm visually pleased and the engine is pleased). However, I don't know how to modify a matrix like that; which rows/columns hold the rotation? Or is it more complicated than that?

[Norbo]

This leads to an idea; always have the entity rolling but shear off the rotation part of the Matrix if a box isn't touching the tube (that way, I'm visually pleased and the engine is pleased). However, I don't know how to modify a matrix like that; which rows/columns hold the rotation? Or is it more complicated than that?

It would be easy enough, but still more of a pain than just using the world transform with no extra work. You'd have to handle the rotation component independently. A rigid transform matrix can be composed from a rotation and a translation.

Instead, you could just get all of the rollers moving at once when the box hits a trigger volume (perhaps a NoNarrowPhase rule and hook an event for pair creation).

However, there's most likely more to it than just the rolling velocities starting at different times. I don't have enough information to know what's really going on or what the specific end result needs to be, so any pictures, diagrams and videos would be helpful

[snoozbuster]

This leads to an idea; always have the entity rolling but shear off the rotation part of the Matrix if a box isn't touching the tube (that way, I'm visually pleased and the engine is pleased). However, I don't know how to modify a matrix like that; which rows/columns hold the rotation? Or is it more complicated than that?

It would be easy enough, but still more of a pain than just using the world transform with no extra work. You'd have to handle the rotation component independently. A rigid transform matrix can be composed from a rotation and a translation.

Instead, you could just get all of the rollers moving at once when the box hits a trigger volume (perhaps a NoNarrowPhase rule and hook an event for pair creation).

However, there's most likely more to it than just the rolling velocities starting at different times. I don't have enough information to know what's really going on or what the specific end result needs to be, so any pictures, diagrams and videos would be helpful

I just tried it with all the rollers rotating, and I'm not sure it's any better. Also, pictures and diagrams wouldn't really help. I could do video, but my boss gets a tad grumpy when I "reveal secrets." Plus my screencap isn't all too fantastic. Hmm... I guess I can take the time to make one up.

[Norbo]

Another option would be to make a little runnable simulation in the BEPUphysicsDemos project. That way I could take it and directly fiddle with it. That approach is generally the quickest and most accurate as far as diagnosis goes. If you aren't comfortable making the demo source public, you could private message or e-mail me it.

[snoozbuster]

Another option would be to make a little runnable simulation in the BEPUphysicsDemos project. That way I could take it and directly fiddle with it. That approach is generally the quickest and most accurate as far as diagnosis goes. If you aren't comfortable making the demo source public, you could private message or e-mail me it.

Ooh, good idea. I'll PM it to you once I get it working.

[Norbo]

If the goal is to make something like a roller slide (like these old spectacularly dangerous finger-pinchers: http://www.youtube.com/watch?v=XTaqi4yXTMU), then the rollers need to be oriented such that the rotation is around the long axis.

Here's a quick modification of the WallDemo, showing a bunch of cylinders rolling a wall away:

Code: Select all

            for (int i = 0; i < 20; i++)
            {
                var roller = new Cylinder(new Vector3(-10 + i, -.5f, 0), 3, .5f);
                roller.Orientation = Quaternion.CreateFromAxisAngle(Vector3.Right, MathHelper.PiOver2);
                roller.AngularVelocity = new Vector3(0, 0, 1);
                Space.Add(roller);

            }
            
            int width = 10;
            int height = 10;
            float blockWidth = 2f;
            float blockHeight = 1f;
            float blockLength = 1f;

            for (int i = 0; i < width; i++)
            {
                for (int j = 0; j < height; j++)
                {
                    var toAdd =
                        new Box(
                            new Vector3(
                                i * blockWidth + .5f * blockWidth * (j % 2) - width * blockWidth * .5f,
                                blockHeight * .5f + j * (blockHeight),
                                0),
                            blockWidth, blockHeight, blockLength, 10);
                    Space.Add(toAdd);
                }
            }

            game.Camera.Position = new Vector3(0, 6, 15);

I would also again recommend the use of primitives over meshes for this type of thing. It isn't the cause of the problem nor will it fix it, but this is a perfect place to use them. Keep in mind, if you intend to target the Xbox360 things take around 10x as long, and even longer on the phone. The speed of primitives becomes very valuable on those platforms.

[snoozbuster]

Did you use the .sln I included? Or maybe the things are stored someplace else, I had properties set in the importer to rotate the models so that they would appear with Y as up instead of Z. Set all the models in my folder to -90 degrees rotation on X in the Properties, and also 90 degrees on Y for both the tube models (normally it would just be one of them, but I'm not using one of the tube models and I don't want to guess).

EDIT: I'm not sure how the Xbox could really be slower than my laptop with Celeron 900. Dualcore (or is it quad?) at 1.9GHz is better than 2.2GHz single-core. =p

[Norbo]

Without doing any reconstruction and testing using the intended rotations, I can say that the rollers have few sharp edges and flat faces. It's likely that you will get a lot of pinching going on due to the fact that the rollers are hexagonal prisms, not cylinders.

Have you tried out adapting the sample code above using cylinders? The primitive cylinders are perfectly smooth, so there's no way for them to pinch in the way that a prism does.

EDIT: I'm not sure how the Xbox could really be slower than my laptop with Celeron 900. Dualcore (or is it quad?) at 1.9GHz is better than 2.2GHz single-core. =p

Prepare to be horribly surprised

Not only is it slow, but it's slow in different ways due to the different platforms and architectures involved. The Xbox360 Xenon is tri-core 3.2ghz (six logical cores), but it's a completely different hardware architecture so frequency comparisons don't work so well. For example, it's an in-order processor and stall-prone code suffers hugely if the hyperthreaded workload can't fill the gap well. Unfortunately, a lot code not specifically designed with this in mind will end up with branchy, cache-thrashing results. Desktop processors handle this pretty well with all sorts of tricks and brute power. Xenon does not. In addition, a lot of its floating point power is tied up in the AltiVec SIMD instructions which cannot be accessed from XNA.

Another way to look at the hardware: the Celeron 900 was released in 2009 and has 410 million transistors. The Xenon was first released in 2005 and had 165 million transistors. There's a big gap in time, complexity, and architecture. The gap won't be as large as from the Xenon to an i7 3960X, but be prepared for the worst.

Also, XNA runs under the compact framework as opposed to the desktop framework on the Xbox360 which means many JIT optimizations just won't happen. The compact framework garbage collector isn't generational and you pretty much have to eliminate all runtime garbage for consistent behavior. Its GPU is still quite a beast, but the CPU performance is going to be really, really bad.

If you're targeting the Xbox360 or phone, it's best to test early and often.

[Norbo]

I went ahead and fiddled some things so that the orientations were correct. It appears the mesh may not have consistent winding. When solidity is enabled, it chooses a winding which represents the outer hull. If it's wrong, colliding objects might fall or get sucked in and then immediately get pushed out by the 'inner contacts' generated by solidity. It's also possible that something about the mesh is confusing the solidity sidedness computation. (Edit: I didn't look too closely, but assuming the graphical mesh is the same mesh as the physics, then the winding appears to be okay; something else must be confusing the computation.)

For example, try using Counterclockwise instead of Solid. It works quite well.

Incidentally, non-Solid meshes are a good bit faster than Solid meshes due to all the extra required tests. Still a lot slower than a simple primitive, though, and the faceted nature of meshes still poses a pinching risk.

[snoozbuster]

I went ahead and fiddled some things so that the orientations were correct. It appears the mesh may not have consistent winding. When solidity is enabled, it chooses a winding which represents the outer hull. If it's wrong, colliding objects might fall or get sucked in and then immediately get pushed out by the 'inner contacts' generated by solidity. It's also possible that something about the mesh is confusing the solidity sidedness computation.

For example, try using Counterclockwise instead of Solid. It works quite well.

Incidentally, non-Solid meshes are a good bit faster than Solid meshes due to all the extra required tests. Still a lot slower than a simple primitive, though, and the faceted nature of meshes still poses a pinching risk.

Oh wow, that does work amazingly. Perfect, in fact.

I tried Cylinders, but anything I dropped on them just stopped halfway inside the cylinder and just sat there shaking. They didn't appear to be rotating, either. Uncomment the line in ADTestDemo.Tube.ctor() where it makes the internal entity a cylinder and you might see my problem.

[Norbo]

I tried Cylinders, but anything I dropped on them just stopped halfway inside the cylinder and just sat there shaking. They didn't appear to be rotating, either. Uncomment the line in ADTestDemo.Tube.ctor() where it makes the internal entity a cylinder and you might see my problem.

It appears at that point that the cylinder does not get added to the space. The mesh is still in the space, but lacks collision events, so it does not rotate. The shaking was just the mesh solidity sidedness inversion problem.

[snoozbuster]

I tried Cylinders, but anything I dropped on them just stopped halfway inside the cylinder and just sat there shaking. They didn't appear to be rotating, either. Uncomment the line in ADTestDemo.Tube.ctor() where it makes the internal entity a cylinder and you might see my problem.

It appears at that point that the cylinder does not get added to the space. The mesh is still in the space, but lacks collision events, so it does not rotate. The shaking was just the mesh solidity sidedness inversion problem.

Gotcha. I'll play with it a tad more. Thanks! =p