Minor suggestion: PositionUpdateMode.Calculated

Post and discuss features you'd like to see in the BEPUphysics library.
Post Reply
mcmonkey
Posts: 92
Joined: Fri Apr 17, 2015 11:42 pm

Minor suggestion: PositionUpdateMode.Calculated

Post by mcmonkey »

So currently there are 3 position update modes:
Discrete,
Passive,
Continuous

I am suggesting one to go between Passive and Continuous.

Discrete and Continuous are the two logical options, and passive is a 'middle ground', but I want a slightly different middle ground:

Discrete 90% of the time, except when velocities are high relative to the size of the object (probably around the point where a frame of movement is one or two times a body's radius)
Basically: all the speed of discrete, all the extreme-situation handling of continuous!


I could probably add this manually by swapping position mode every frame based on my own calculations, but it seems like it'd be good to have this option more generally available.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Minor suggestion: PositionUpdateMode.Calculated

Post by Norbo »

That happens to be how Continuous works already :D
https://github.com/bepu/bepuphysics1/bl ... ler.cs#L84

The threshold for when to actually perform a cast is based on the shape's minimum radius. For some shapes that are very thin along one axis, this can result in a pretty low threshold, but it would otherwise potentially miss collisions.

For reference, since v1 is not too far away from being obsolete now:
CCD is changing quite a bit in v2- these motion clamping based approaches are going away completely. The most expensive replacement will still use a similar 'only do the work if the objects are moving fast' configuration, but the user can specify exactly how large of a step is okay, as well as an upper limit on how much work to do, on a per collidable basis. You can sacrifice a bit of accuracy for higher performance, and if the objects aren't moving quickly at all, it'll be basically free just like the current approach. Also that mode actually supports angular motion, unlike anything in v1 :)
mcmonkey
Posts: 92
Joined: Fri Apr 17, 2015 11:42 pm

Re: Minor suggestion: PositionUpdateMode.Calculated

Post by mcmonkey »

Norbo wrote: Sun Jun 25, 2017 7:29 pm That happens to be how Continuous works already :D
https://github.com/bepu/bepuphysics1/bl ... ler.cs#L84

The threshold for when to actually perform a cast is based on the shape's minimum radius. For some shapes that are very thin along one axis, this can result in a pretty low threshold, but it would otherwise potentially miss collisions.
That's beautiful! I guess my problem was I had my objects with too-small minimum radiuses going quite fast, and I wondered why it lagged with continuous on... heh. Didn't properly think about, just remembered I got lag and switched to discrete some months back. Then recently I had an object fly through a wall and thought 'surely there's a good middle ground'...
That's what I get for not testing more closely! :P
For reference, since v1 is not too far away from being obsolete now:
CCD is changing quite a bit in v2- these motion clamping based approaches are going away completely. The most expensive replacement will still use a similar 'only do the work if the objects are moving fast' configuration, but the user can specify exactly how large of a step is okay, as well as an upper limit on how much work to do, on a per collidable basis. You can sacrifice a bit of accuracy for higher performance, and if the objects aren't moving quickly at all, it'll be basically free just like the current approach. Also that mode actually supports angular motion, unlike anything in v1 :)
Woo! Eagerly waiting for v2 functionality! The performance timings you mentioned in the past sounded really nice... could definitely stand some performance upgrades! (Though BEPU takes only a few ms frame time for the most part under normal environments!)
(That's with a /massive/ world of voxels using code styled off what you made a while back - still cannot thank you enough for that!)
(I do hope you'll eventually have time to add a new voxel demo to V2 when the rest of the system is complete enough that you can fit that - if/when you do that, I'm immediately making the upgrade (also, of course, adding some donation money for you as my budget grows slowly with time - still can't afford the price it would cost to direct pay you for devving something like that, but hopefully a bit of donation money makes it feel worthwhile))

I am so far beyond in love with BEPU physics, and the idea that you're making it faster and stronger is just amazing.

While I'm here making a long post, I should in passing note something:
I have a side project in Unity, and myself and my dev partner discovered something annoying: Multi-Threaded BEPU physics will freeze the Unity editor. Single-threaded is fine, and multi-threaded works on release builds, so this isn't really an issue. Just thought I'd note it both for future travellers and in case you ever want to improve Unity support.
(If unclear: The workaround is to just have single-threaded while debugging and multi-threaded in release configuration, which is perfectly reasonable)
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Minor suggestion: PositionUpdateMode.Calculated

Post by Norbo »

A little demo of a custom voxelstuff shape type and pair handler for v2 would be nice to have. The design around narrow phase pair handlers is significantly less.... OOP-octopus this time around, so it might not actually be too time consuming. (Small chance I might do it within the next few weeks since I'm currently working on the collision detection pipeline- though even if I happen to get it done that soon, be warned that the rest of the engine will still be a ways off of usably feature complete :P)
Multi-Threaded BEPU physics will freeze the Unity editor.
I wonder if that's the same as this old report:
https://forum.bepuentertainment.com/vie ... php?t=2129
Unfortunately, I don't think the exact cause was determined.

With any luck, v2 just won't suffer the same issue. If the default thread dispatcher still has the same behavior, it's still possible to swap out the implementation. v2 handles load balancing internally, so custom thread dispatchers don't have to worry about it- you can get basically-optimal performance out of something as simple as Parallel.For(0, threadCount, action).

Hopefully none of the internal load balancing runs afoul of... whatever it is. Might have to poke some people at unity :)
mcmonkey
Posts: 92
Joined: Fri Apr 17, 2015 11:42 pm

Re: Minor suggestion: PositionUpdateMode.Calculated

Post by mcmonkey »

Norbo wrote: Mon Jun 26, 2017 4:55 am
Multi-Threaded BEPU physics will freeze the Unity editor.
I wonder if that's the same as this old report:
https://forum.bepuentertainment.com/vie ... php?t=2129
Unfortunately, I don't think the exact cause was determined.
It is indeed most likely the same as that report - that's what I was looking at that more or less matched my inspections that tempted me to test the threading modes.


Also RE: Voxels, just in case you're not already thinking along this specific line:
it would be very beneficial to keep the voxel handler part of the demos and not in any way built in to the engine itself.
For general public purposes: It serves as a golden example of how to implement a complex custom collider.
For my own purposes: I don't have cube-shaped voxels, so I would have to adapt the logic a bit either way, and that's easier if reference code is separated. (My voxels are on a cubic grid, but take unique non-cuboid shapes fairly often in an attempt to smooth the terrain a bit... EG they might be sloped to allow walking up the side of a voxel as opposed to having to jump up it).

A really cool thing I'm hoping to do when v2 is available is off-grid voxel chunks. Meaning free moving physics objects shaped like voxel areas.
Currently I just convex hull them as a fair-enough approximation, but it'd be interesting to see how well small sets work out with the v2 engine.
(In v1, there's **just** enough lag (and confusion in my dev work, heh) to make it not really worthwhile for chunks above a certain size).
Though realistically I could probably get away (with small sets) by just making the outtermost voxels become shapes in a compound... but still, would work far better with some safe accelerations provide by v2!

I did have it working as a general system before when I had chunks convert to meshes, though that had general delays with regular chunks, and rapidly noticeable size limits on off-grid chunks.

I could go ahead and take a fresh crack at those at any time and try to improve it, but I'm too hopeful for v2 to want to bother with something I know will be slow and rewritten before the release date (unknown time a year or two away minimum... big project, small team, heh)
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Minor suggestion: PositionUpdateMode.Calculated

Post by Norbo »

A voxel type demonstration would definitely be in the demos, and would be pretty minimalist. I try to keep everything in the engine at a pretty high quality bar in terms of feature completeness and performance, and getting a voxel shape and its collision pairs up to that bar would be a great deal of effort. (So, like the example in v1, probably no dynamically evaluated isosurfaces with compressed deltas and voxel-voxel boundary smoothing :P)

As for mobile blobs of voxels, I suspect they will indeed work better in v2. There's actually no more distinction between entity and static collidables at the level of collision detection, so there should be more code sharing opportunities. And the extra performance will be handy too, of course :)
Post Reply