2 (or 3) Possible Bugs I Found
Posted: Mon Jul 13, 2015 5:45 am
Hello, me again...
So I took your advice and went with a StaticGroup, its working great! After I got over that hurdle I was able to implement many more things and that's how I came across the following:
1. When an instance of CharacterController is standing on top of a StaticGroup that has had it's top extended with .Shaps.Add() the character kind of bounces up and down forever... If you reconstruct the StaticGroup by removing the old from the space and create a new StaticGroup with the exact same set of collidables the problem does not occur. I tried to debug this the best I could to give you as much information as possible and from what I can tell the player is sinking into the top of the StaticGroup and then during collision detection this is realized and an impulse is generated with a positive Y vector and the character is boosted into the air. Then the player is caught by gravity and starts falling again until it sinks far enough into the StaticGroup that the process repeats. Tried to look into how it was constructing the bounding boxes differently for each situation and I quit when the recursion started popping up everywhere... That code is nuts, I didn't understand most of it haha.
2. The second bug I found, or maybe it isn't a bug at all? is related to the CharacterController and its VerticalMotionConstraint not being updated if it doesn't have any external input that results in a net change in goal Y velocity. The easiest way to reproduce is to stand on a floor with gravity set to earths gravity, then on a key press do something like this Space.ForceUpdater.Gravity += new BEPUutilities.Vector3(0, 1, 0); After hitting that key 10 or more times you would think that you should start moving up, even changes to CharacterController.HorizontalMotionConstraint.MovementDirection have no effect. however if you run off an edge, or jump (, or run up a slope I presume) you will be lifted into the air as you should be. I also saw this manifest without changing Space.ForceUpdater.Gravity at all. I just stood on top of a tower of 3 voxels and looked down, clicked the voxel below me to deleted it and at this point I should have fallen to the next voxel but I don't fall until I move, but in this case changes to the HorizontalMotionConstraint will make me fall also, so this may be an entirely separate bug or a known limitation caused by the effort required to make it realistic?
Also with the second part of #2 (deleting box below me and not falling) I tested it with deleting the box both ways, Shapes.Remove and removing the block from the source collidable list and then reconstructing the entire static group and I saw the same thing both ways though it is only reproduceable on about 50% of the times I delete a block below me.
If you would like any more info related to these I'd be happy to provide it, anything in my power I can do to make BEPU better, I'd love to do!
So I took your advice and went with a StaticGroup, its working great! After I got over that hurdle I was able to implement many more things and that's how I came across the following:
1. When an instance of CharacterController is standing on top of a StaticGroup that has had it's top extended with .Shaps.Add() the character kind of bounces up and down forever... If you reconstruct the StaticGroup by removing the old from the space and create a new StaticGroup with the exact same set of collidables the problem does not occur. I tried to debug this the best I could to give you as much information as possible and from what I can tell the player is sinking into the top of the StaticGroup and then during collision detection this is realized and an impulse is generated with a positive Y vector and the character is boosted into the air. Then the player is caught by gravity and starts falling again until it sinks far enough into the StaticGroup that the process repeats. Tried to look into how it was constructing the bounding boxes differently for each situation and I quit when the recursion started popping up everywhere... That code is nuts, I didn't understand most of it haha.
2. The second bug I found, or maybe it isn't a bug at all? is related to the CharacterController and its VerticalMotionConstraint not being updated if it doesn't have any external input that results in a net change in goal Y velocity. The easiest way to reproduce is to stand on a floor with gravity set to earths gravity, then on a key press do something like this Space.ForceUpdater.Gravity += new BEPUutilities.Vector3(0, 1, 0); After hitting that key 10 or more times you would think that you should start moving up, even changes to CharacterController.HorizontalMotionConstraint.MovementDirection have no effect. however if you run off an edge, or jump (, or run up a slope I presume) you will be lifted into the air as you should be. I also saw this manifest without changing Space.ForceUpdater.Gravity at all. I just stood on top of a tower of 3 voxels and looked down, clicked the voxel below me to deleted it and at this point I should have fallen to the next voxel but I don't fall until I move, but in this case changes to the HorizontalMotionConstraint will make me fall also, so this may be an entirely separate bug or a known limitation caused by the effort required to make it realistic?
Also with the second part of #2 (deleting box below me and not falling) I tested it with deleting the box both ways, Shapes.Remove and removing the block from the source collidable list and then reconstructing the entire static group and I saw the same thing both ways though it is only reproduceable on about 50% of the times I delete a block below me.
If you would like any more info related to these I'd be happy to provide it, anything in my power I can do to make BEPU better, I'd love to do!