I've double checked, and based on the capstan's position and dimensions, it shouldn't be embedded in the ship...it should actually be hovering about 0.1 units above the deck
![Confused :?](./images/smilies/icon_confused.gif)
I've double checked, and based on the capstan's position and dimensions, it shouldn't be embedded in the ship...it should actually be hovering about 0.1 units above the deck
Code: Select all
compoundBuilder.BuildDynamicCompound(out Buffer<CompoundChild> _colliderChildren, out BodyInertia _shipInertia);
float _inverseInertiaScale = 1f / (500f * _shipInertia.InverseMass);
_shipInertia.InverseMass *= _inverseInertiaScale;
Symmetric3x3.Scale(_shipInertia.InverseInertiaTensor, _inverseInertiaScale, out _shipInertia.InverseInertiaTensor);
ship.inertia = _shipInertia;
ship.shape = World.physics.Simulation.Shapes.Add(new BigCompound(_colliderChildren, compoundBuilder.Shapes, World.physics.BufferPool));
I haven't changed the weights, so that could be the issue. Just to clarify, do the weights actually affect the final mass of the compound (if I'm scaling the inertia), or do they only make a difference relative to each other? Basically, can I just give each child shape a weight of 1 and then scale the inertia to give the compound a mass of 500, even if the child shape weights don't add up to 500?
Yup, if the final inertia gets scaled to match a target mass, then the weights are only meaningful in a relative sense.Just to clarify, do the weights actually affect the final mass of the compound (if I'm scaling the inertia), or do they only make a difference relative to each other? Basically, can I just give each child shape a weight of 1 and then scale the inertia to give the compound a mass of 500, even if the child shape weights don't add up to 500?
First guess would be some kind of collision filter going haywire.The capstan is now held in place in the desired position, however, I can simply walk through it as if it weren't there. The character controller seems to just not collide with it...any idea what might be causing this?
Naw, it'll be fine- if the constraint wasn't strong to resist gravity, it'd be immediately visible. Constraints don't just force bodies into position, they actually solve for the required impulses necessary to reach the constraint goal and apply those impulses to the connected bodies continuously. In other words, there's no hidden state accumulating in the background.I'm also a little concerned about gravity in this situation—since the constraint is holding the capstan collider in position slightly above the deck, is it possible for the force of gravity to accumulate (because the capstan is technically always falling) to a point where the constraint won't be strong enough anymore—or maybe the ship will start getting pushed around, despite its much larger mass?
I haven't set anything up with collision filtering (besides removing cannonballs from the simulation when they hit another body)—how can I find out if this is the culprit?
It is the demos controller, but I don't think this is the issue because the capstan appears to stay in the correct position. Unless the controller is somehow walking into the capstan body and therefore doesn't collide...Norbo wrote: ↑Wed Jan 15, 2020 10:46 pm If it's the demos dynamic character controller, it may be worth confirming that its mass/maximum horizontal force aren't so huge that it can just shove the capstan around at the hinge's current stiffness settings. I'd be a little surprised if that was it, since it probably would have caused issues with the boat before.
The capstan has a mass of 1 while the player has a mass of 10.
You would have had to implement some form of collision filtering in the INarrowphaseCallbacks by returning false from the relevant callbacks. There's nothing built in.I haven't set anything up with collision filtering (besides removing cannonballs from the simulation when they hit another body)—how can I find out if this is the culprit?
If the capstan is represented by a convex primitive, being inside will still generate contacts.It is the demos controller, but I don't think this is the issue because the capstan appears to stay in the correct position. Unless the controller is somehow walking into the capstan body and therefore doesn't collide...
Depending on the hinge stiffness and the character's movement force, it's conceivable that it could shove the capstan a bit, but this isn't a good explanation if the capstan isn't actually getting shoved.The capstan has a mass of 1 while the player has a mass of 10.
I guess I should clarify: I haven't done anything custom—I simply copied the NarrowphaseCallbacks from one of the demos (can't remember which one though). Considering I haven't added anything, could this still be the issue? It doesn't make sense to me that collisions would work, except for this particular collision...
It's a cylinder.
Some demos callbacks have collision filtering, some don't. If the callbacks all return only true, you can be sure that it's unrelated.Considering I haven't added anything, could this still be the issue? It doesn't make sense to me that collisions would work, except for this particular collision...
I just checked and I'm using the NarrowPhaseCallbacks from the character demo—the only method that doesn't return true is this one:
Code: Select all
[MethodImpl(MethodImplOptions.AggressiveInlining)]
public bool AllowContactGeneration(int workerIndex, CollidableReference a, CollidableReference b)
{
if (b.Mobility != CollidableMobility.Static)
{
return SubgroupCollisionFilter.AllowCollision(properties[a.Handle].filter, properties[b.Handle].filter);
}
return a.Mobility == CollidableMobility.Dynamic || b.Mobility == CollidableMobility.Dynamic;
}
The collision is being filtered out. SubgroupCollisionFilters are being used in AllowContactGeneration, but the filters are never assigned to anything. The value they happen to have causes the callback to return false.Here's the reproduction in a relatively bare bones console app.
I don't see that happening when I increase the mass in the repro, regardless of how much violence I subject it to (I pulled it into the demos for a visual). Even scaling the inertia down by a factor of 100 (inverse up by 100) doesn't cause any tornadoship-like behavior, just the expected wonkiness of a tank with the inertia of a shrew. Even setting the hinge offset such that the capstan is forced inside the box doesn't cause it in this case.I did however notice that if I increase the capstan's mass from 1 to something like 10, the tornadoship makes a reappearance.
The solver tries to conserve momentum; every force has an equal and opposite reaction. Provided the solver has time to find a reasonably good solution, it will not introduce extra momentum. In order to go tornadoship or fly into the sky or anything like that, extra nonphysical momentum is required.I'm picturing a sort of scenario where the player can walk into the capstan and that consequentially pulls the boat around in some way, sort of like making yourself fly/levitate by pulling up on the hem of your own shirt or something, just horizontally. Is this at all a possibility (does what I'm trying to say even make sense)?
Code: Select all
Simulation = Simulation.Create(BufferPool, new ReproNarrowphaseCallbacks() { characters = Characters, properties = BodyProperties }, new PoseIntegratorCallback(gravity), timestepper: new SubsteppingTimestepper(2), solverIterationCount: 4);
So how can I fix this? Is there a demo I can look at to see what I should be assigning the filters to?
That's really strange...so there's no way tornadoship should or could be occurring? I figured it might have something to do with the boat getting pulled into the side of a wave by the constraint—then the buoyancy force increases due to it being further underwater, causing rotational acceleration. Now I'm not so sure about thatNorbo wrote: ↑Wed Jan 22, 2020 11:36 pm I don't see that happening when I increase the mass in the repro, regardless of how much violence I subject it to (I pulled it into the demos for a visual). Even scaling the inertia down by a factor of 100 (inverse up by 100) doesn't cause any tornadoship-like behavior, just the expected wonkiness of a tank with the inertia of a shrew. Even setting the hinge offset such that the capstan is forced inside the box doesn't cause it in this case.
What would be a timestep duration of ideal length? I'm a little hesitant to (at least substantially) increase this as I want to keep it consistent with my server's tickrate, and more importantly, the effect on CPU usage would be a lot bigger than what's initially obvious because my server is constantly rewinding to the oldest unaccounted-for input and resimulating to the present—meaning there'd be more ticks for the server to resimulate each time.
This really concerns me...the only (intentional) physics differences between the main project's and the repro's ships is that the main project's ship isn't a box, isn't affected by gravity, and has my buoyancy code on it (which handles gravity).
The CarDemo (through the SimpleCar), RagdollDemo, and TankDemo (through the Tank) all make use of SubgroupCollisionFilter.So how can I fix this? Is there a demo I can look at to see what I should be assigning the filters to?
Under normal circumstances, it shouldn't happen, right.That's really strange...so there's no way tornadoship should or could be occurring?
Infinitesimal!What would be a timestep duration of ideal length?
Almost no changes- if you wanted to use the brute force 'call timestep more often, with shorter timestep duration', you can just replace the single call with multiple and you're done. Similarly, for substepping, you just call Create with the appropriate parameters and you're done. Don't have to step other game logic more frequently or anything.If I were to use substepping, how would that fit into the whole rewinding part? Would there be extra stuff I'd need to set up & watch out for, or would it work as is?
As always, if you can reproduce the behavior in a minimal repro, I can take a look and probably diagnose it immediately.This really concerns me...the only (intentional) physics differences between the main project's and the repro's ships is that the main project's ship isn't a box, isn't affected by gravity, and has my buoyancy code on it (which handles gravity).