Small bugs and lots of questions...

Discuss topics related to BEPUphysics or physics engine development.
Post Reply
Danthekilla
Posts: 136
Joined: Sun Jan 17, 2010 11:35 am

Small bugs and lots of questions...

Post by Danthekilla »

Hey Norbo, I have a few issues that have cropped up lately.

We upgraded to 14.3 and now around 30% of our static tri meshes return mesh verts that are in the wrong location...
So we tried to build a content processor to extract the vertices and also tried the one on the xna website in the picking sample, but both make our rendering engine crash (Have no idea why as we don't have the source) even thou we don't ever try to render those meshes...

So basically i have 6 questions...

1. Do you have or know of a good content processor that could help this?

2. We were wondering if there is a way of updating one object more than others, like the player marble in our game, for improved stability.

3. When the entire physics simulation slows down (when you touch a slow time pickup) we want the player marble to be unaffected and move and normal (or some other speed) how can we achieve this?

4. When our game runs on the phone the collision events only fire about 10% of the time, any idea why this could be?

5. Is there anyway to make an object unraycastable but still have normal physics responses and be in the physics system that is being raycasted?

6. Also how is .15 going any chance of an early test version so we can get a build of our game converted over to use it?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Small bugs and lots of questions...

Post by Norbo »

1. Do you have or know of a good content processor that could help this?
The one I'd recommend is something like the XNA picking sample, and I'm not sure a different content processor would address the crashes you were experiencing. I think those problems might have to be dealt with directly.
2. We were wondering if there is a way of updating one object more than others, like the player marble in our game, for improved stability.
Simply updating the marble more probably won't help that much, and it wouldn't be easy to do. It would basically be a hacky equivalent of increasing the update rate for the entire simulation, but ensuring that things not interacting with the player are deactivated or in low-expense states.
3. When the entire physics simulation slows down (when you touch a slow time pickup) we want the player marble to be unaffected and move and normal (or some other speed) how can we achieve this?
The simplest way would probably be just to change the update rate such that the simulation runs half as fast (or however fast) overall, and increase the speed of the marble appropriately. If internal time stepping is on and you cut the TimeStepDuration, you should also cut the time passed into Space.Update so that the simulation slower overall.
4. When our game runs on the phone the collision events only fire about 10% of the time, any idea why this could be?
Nope, that system should behave exactly the same. I'd assume the culprit is elsewhere. Hopefully, the behavior you are seeing is consistent between the emulator and device. If it isn't consistent, check for known issues like the GetData overload.
5. Is there anyway to make an object unraycastable but still have normal physics responses and be in the physics system that is being raycasted?
Raycast results can be arbitrarily filtered by using the multi-hit version of the raycast method. v0.15.0 will have a convenience function that lets you supply a delegate to do the filtering, but it's the same idea.

v0.16.0 is planned to have a raycasting-centric structure to assist a new broadphase that doesn't accelerate raycasts alone. In the future, you could create your own instance of that and only add the objects that you want raycasted into it.
6. Also how is .15 going any chance of an early test version so we can get a build of our game converted over to use it?
Unfortunately most of the work remaining is connecting still-disconnected parts of the engine together. It's not usable yet, and probably won't be until a few days before its release (the debugging phase). While there may be an 'early' version, it won't be very early :)
Danthekilla
Posts: 136
Joined: Sun Jan 17, 2010 11:35 am

Re: Small bugs and lots of questions...

Post by Danthekilla »

Norbo wrote: The one I'd recommend is something like the XNA picking sample, and I'm not sure a different content processor would address the crashes you were experiencing. I think those problems might have to be dealt with directly.
This processor seems to give us some broken data when we use it, and we had to modify it to return indices as it doesn't return them by default eather, could we get a copyu of your one if you managed to get one working?
Norbo wrote: Simply updating the marble more probably won't help that much, and it wouldn't be easy to do. It would basically be a hacky equivalent of increasing the update rate for the entire simulation, but ensuring that things not interacting with the player are deactivated or in low-expense states.
That is what i expected.
Norbo wrote: The simplest way would probably be just to change the update rate such that the simulation runs half as fast (or however fast) overall, and increase the speed of the marble appropriately. If internal time stepping is on and you cut the TimeStepDuration, you should also cut the time passed into Space.Update so that the simulation slower overall.
I don't see how we could do that in a way that looks correct as when you hit the slow time orb time slows for around 10 seconds and it lerps to 0.01 speed and then back up to 1.0 speed again over those 10 seconds.

We need a way for the player to remain unaffected by this, in regards to fresh input and the velocity/movement that it already has.
Norbo wrote: Nope, that system should behave exactly the same. I'd assume the culprit is elsewhere. Hopefully, the behavior you are seeing is consistent between the emulator and device. If it isn't consistent, check for known issues like the GetData overload.
I think it is consistent i'm hoping that it just happens to go away... :)
Norbo wrote: Raycast results can be arbitrarily filtered by using the multi-hit version of the raycast method. v0.15.0 will have a convenience function that lets you supply a delegate to do the filtering, but it's the same idea.
Yer thats fine, I noticed that if you set an object to NoPair then raycasts dont hit it. Would it be possible in a future version for there to be a NoRay CollisionRule in addition to the others which would be normal responce but with no raycasting? Or should i just use the multi-hit cast? I'm just worryed about phone performance thats all.
Norbo wrote: Unfortunately most of the work remaining is connecting still-disconnected parts of the engine together. It's not usable yet, and probably won't be until a few days before its release (the debugging phase). While there may be an 'early' version, it won't be very early :)
Cool good to hear.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Small bugs and lots of questions...

Post by Norbo »

This processor seems to give us some broken data when we use it, and we had to modify it to return indices as it doesn't return them by default eather, could we get a copyu of your one if you managed to get one working?
I don't have one lying around at the moment, but if I make one it'll get stuck in the demos somewhere.
time slows for around 10 seconds and it lerps to 0.01 speed and then back up to 1.0 speed again over those 10 seconds.
It won't be 100% perfect, but you can get pretty close. Each frame, you look at the ratio of the current timestep to the previous frame's timestep. The inverse of that is the factor that multiplies your marble's current speed. Any fresh inputs would be multiplied by the inverse timescale. The main source of inaccuracy in this would be the incremental nature of the process, but there are presumably other controls which bound and control the character's movement and the error wouldn't be all that big anyway.

In other words:

Code: Select all

//Scale the marble's current velocity by the inverse of the ratio of the current timestep to the previous timestep.
marble.CurrentVelocities *= previousTimeStep / currentTimeStep;
//Scale the input's velocity changes by the inverse of the ratio of the current timestep to the NORMAL timestep.
//Since inputVelocityChanges is an acceleration, it's multiplied by the currentTimeStep to get the per-frame change in velocity.
//The usual currentTimeStep term cancels with the new scaling denominator. 
marble.CurrentVelocities +=  inputVelocityChanges * normalTimeStep;
So, consider what happens when you go from 1/60 timestep to 1/6000 timestep. The simulation is moving 1/100th as fast. If that change occurred over one frame, you'd need the next frame to multiply the marble's velocity by 100. (1/60) / (1/6000) = 100. As the simulation started to speed up, the velocity of the marble is scaled down each frame. By the time normal simulation speed resumes, the marble is moving at a normal speed. Throughout the process, given no external input, the marble appears to move at a constant speed while everything else slows down.

Now let's say external input accelerates with X units per second of velocity. Under regular circumstances, this would be a change of X * currentTimeStep. In the slowed version, currentTimeStep is modified, but we still want to accelerate each frame as if time was normal, so we use the normalTimeStep instead: X * normalTimeStep.
I noticed that if you set an object to NoPair then raycasts dont hit it.
That shouldn't actually happen. The raycast shouldn't care about collision rules. If you saw otherwise, it might have been a bug.
Would it be possible in a future version for there to be a NoRay CollisionRule in addition to the others which would be normal responce but with no raycasting? Or should i just use the multi-hit cast? I'm just worryed about phone performance thats all.
There probably won't be raycast-specific rules built in, though using the usual filtering approach (now or with the delegate convenience methods in v0.15.0) would let you do it externally with relative ease.

As far as performance goes, the system would be doing something pretty similar to what you would do externally. There is some pre-filtering that could be done to avoid some shape tests internally that could help some, but a few raycasts a frame isn't going to slow things down much.
Post Reply