A question along the way: I read some of your blog entries and in one of them you wrote "Expect older platforms like Xbox360 and WP7 to be abandoned.". Now I'm curious if BEPU Physics v2.0 will even work with Unity. Will the compilation of BEPU Physics v2.0 be supported as the compilation of the current version is supported now? As described here: viewtopic.php?f=9&t=2322
It's hard to say exactly.
The rule of thumb would be: if it can handle .NET Core, unsafe code, and the latest version of C#, it should handle v2.0. For reference, I'll probably be targeting the C# 7 preview (ref locals and returns are really nice to have). Unfortunately, it will be far more difficult to 'turn off' some of the incompatible features.
The bad news is older versions of Unity will probably have a lot of problems with it. I don't think webplayer stuff using 2.0 will be feasible due to unsafe code. Note that I'm not very familiar with where Unity stands, so this is partly speculation.
The good news is that Unity has been putting forward effort to escape the legacy issues surrounding the old mono runtimes and platform. I'm pretty hopeful for the future because:
1) .NET Core and the associated technology stack is FOSS,
2) Microsoft bought Xamarin and already had a pretty good relationship with Unity,
3) Unity was already working on IL2CPP as a means of addressing some of the platform problems, and
4)
Unity joined the .NET foundation:Yes we plan to support .NET 4.6 and continue improving support as .NET evolves in the future.
I would be very surprised if Unity has any problem with BEPUphysics v2.0 in the mid-long term. It's just a question of time.
Last but not least, I like to say that I tried to measure the performance of PhysX and BEPU Physics for creating and updating collision data.
By the way, for modifications to a mesh that do not involve topology changes (that is, no added or removed elements, and no element movements such that the form of the tree becomes terrible), you can use Refit instead of Reconstruct. It's way faster. On my computer (3770K@4.5ghz):
Code: Select all
v1.4.0 Reconstruct:
Average: 0.177805882915706
Fastest: 0.156391210178821
Slowest: 0.204268637878478
v1.4.0 Refit:
Average: 0.0266572225445356
Fastest: 0.0260292644907152
Slowest: 0.0273815176657454
Out of curiosity I went ahead and compared this case to the v2.0 tree. (I needed to get away from the mess of driver bugs on the graphics engine for a while anyway!)
Code: Select all
v2 Reconstruct Incremental:
Average: 0.108381626208785
Fastest: 0.105335314609513
Slowest: 0.120236430730378
Cost Metric: 42.10615
v2 Reconstruct Sweep:
Average: 0.258328756093843
Fastest: 0.252644895449062
Slowest: 0.285086683758538
Cost Metric: 25.12667
v2 Refit And Refine:
Average: 0.00335068266550107
Fastest: 0.00323025255419911
Slowest: 0.00376038729092665
Cost Metric: 25.12862
v2 Refit:
Average: 0.000971802507841576
Fastest: 0.000873025416332772
Slowest: 0.00129461711369722
Cost Metric: 25.12862
The first chunk, "Reconstruct Incremental", is doing a construction process very similar to what v1.4.0's Reconstruct did. It just inserts triangles one at a time. You'll also notice a "Cost Metric", which is a rough measure of how expensive a query is. Lower is better. v1.4.0's Reconstruct should have a similar or slightly higher cost- I just didn't bother going back and adding in a measurement for it.
"Reconstruct Sweep" is one of the new tree's features. It is a heavyweight, high quality builder designed mainly for offline or load-time use. It's here as a reference- and to note that it isn't much slower than v1.4.0's much, much lower quality Reconstruct.
"Refit and Refine" is by far the most interesting of the new features. Despite taking only about 3 milliseconds, it gradually improves the tree, both in terms of its Cost Metric (up to a limit- it's based on local sweep rebuilds, so it can't do better than a global sweep build) and in terms of the cache efficiency of its layout in memory. So while the above refinement started from a high quality sweep build, it can also take low quality builds and make them much better over time. This is extremely important for the broad phase use case and in any other dynamic hierarchy where you expect lots of topological changes over time. This system can handle adds and removes of leaves without any problem. Notably, this test was run on one thread, but there's a multithreaded overload that gives near linear speedups (as shown in the blog post).
"Refit" is just the same as v1.4.0's refit, except... >27x faster. Less than a millisecond for all 130,050 triangles. The cost metric turns out pretty good here just because it was initialized with the high quality sweep build and randomizing the y position a little doesn't change much.
I added the benchmark to the scratchpad repo:
https://github.com/RossNordby/scratchpa ... nceTest.cs
PS: I experimentally removed the teleportation code but then I wasn't even able to take the first step of the stair.
The ability for the cylindrical character to walk up steps depends strongly on how 'round' it is. You can think about the character as a 'core' cylinder expanded by a sphere of margin radius across its entire surface, so that edges aren't perfectly sharp. For example:
- cylindercore.jpg (10.71 KiB) Viewed 9030 times
Using 0.1 as the margin means it can only climb stair-like obstacles less than 0.1 units tall, assuming a maximum traction slope of pi/2. With a maximum traction slope of 0.8, it would be closer to a maximum of 0.05 units. If units are meters, that's only about 2 inches. The standard height of a stair in the US is 7 inches, so without increasing the allowed slope of about 0.8, it would require a margin of around 0.35 to 0.4.
Note that the margin can't be bigger than the radius, though- the margin is internal. So the character radius would need to be increased to equal or exceed the margin. If the margin equals the radius, the 'cylinder' is really a capsule.
If the environment is highly realistic with reasonably sized stairs, this can work out okay. Another common option is to design the environment with this kind of character in mind- so 'stairs' would be a detailed graphical model over a physical ramp. Ramps will tend to be faster too- less triangles to collide with.
For my own game, I turn off the stepping queries for performance and networking reasons (stepping is not super slow, but when there are many thousands of characters on a single server, every bit helps). I use a big margin to let them climb stuff as above, but I also increase the maximum traction slope to increase the stair-climbing power even more. This has the effect of also letting characters walk up very steep hills, but I made it slower while climbing steep slopes, and kept the threshold slope required to go from notraction->traction low- so if the character briefly slips on a cliff, they're going to fall. And of course, where I have control over the content, the physics representation tends to be simpler and more ramp-like.
I haven't quite gotten around to testing out the model- I'll probably get to that tomorrow.