v1.3.0 released!

Discuss topics related to BEPUphysics or physics engine development.
Post Reply
Norbo
Site Admin
Posts: 4588
Joined: Tue Jul 04, 2006 4:45 am

v1.3.0 released!

Post by Norbo » Sat Dec 21, 2013 4:23 am


User avatar
Piranha
Posts: 8
Joined: Fri Jun 01, 2012 12:20 am

Re: v1.3.0 released!

Post by Piranha » Sat Jan 04, 2014 6:07 pm

FluidVolume now supports non-Y up vectors and is a little less bad.
Fluids on spherical Shapes (Planet :shock: )?! Awesome!
It's still a little bad.
:lol: :lol: :lol:

Good job man. Can't wait to get out of my finals :twisted:

btw. Seems like everyone else in forum has a hangover from holidays

snoozbuster
Posts: 172
Joined: Sat Sep 24, 2011 7:31 am

Re: v1.3.0 released!

Post by snoozbuster » Wed Feb 19, 2014 1:43 am

FluidVolume now supports non-Y up vectors and is a little less bad.
Oh good! I'll give it another shot in my own project, I suppose!

EDIT: When did you remove ISpace? I thought that was present as late as v1.2.0. Was I dreaming?

Norbo
Site Admin
Posts: 4588
Joined: Tue Jul 04, 2006 4:45 am

Re: v1.3.0 released!

Post by Norbo » Wed Feb 19, 2014 5:46 pm

EDIT: When did you remove ISpace? I thought that was present as late as v1.2.0. Was I dreaming?
I believe that was removed in v1.3.0. The removal is part of an ongoing concretization of the API. Slowly, unnecessary degrees of abstraction are being pruned away to leave a simpler core.

snoozbuster
Posts: 172
Joined: Sat Sep 24, 2011 7:31 am

Re: v1.3.0 released!

Post by snoozbuster » Fri Feb 21, 2014 4:17 am

Norbo wrote: I believe that was removed in v1.3.0. The removal is part of an ongoing concretization of the API. Slowly, unnecessary degrees of abstraction are being pruned away to leave a simpler core.
That's good. I mean, having ISpace was a decent idea, but I doubt anyone is going to implement their own Space replacement. I was just wondering because I didn't see it in the release notes.

diabloqfdb
Posts: 38
Joined: Mon Aug 20, 2012 10:33 am

Re: v1.3.0 released!

Post by diabloqfdb » Tue Mar 18, 2014 4:56 pm

Wow, a new version!

I'll give it a go!

I'm a bit worried about the character controller changes because I had a very high mobility character with skying and superhuman jumps and speed, but I'll see how the new one behaves!

Great to see an update! An with IK too! But what is this about C++? Only the IK part is C++?

Norbo
Site Admin
Posts: 4588
Joined: Tue Jul 04, 2006 4:45 am

Re: v1.3.0 released!

Post by Norbo » Tue Mar 18, 2014 6:03 pm

I'm a bit worried about the character controller changes because I had a very high mobility character with skying and superhuman jumps and speed, but I'll see how the new one behaves!
The handling of the movement direction is a little different, but otherwise it should behave exactly the same. Nothing notable changed in the 'guts' of the character.
Great to see an update! An with IK too! But what is this about C++? Only the IK part is C++?
The BEPUik on codeplex is just a regular C# library. There is a separate C++ port of that for use in the eponymous blender addon.

diabloqfdb
Posts: 38
Joined: Mon Aug 20, 2012 10:33 am

Re: v1.3.0 released!

Post by diabloqfdb » Wed Mar 19, 2014 3:52 pm

Norbo wrote:
I'm a bit worried about the character controller changes because I had a very high mobility character with skying and superhuman jumps and speed, but I'll see how the new one behaves!
The handling of the movement direction is a little different, but otherwise it should behave exactly the same. Nothing notable changed in the 'guts' of the character.
Motivated by that I decided not to update my BEPU project, but instead experiment on another project I have.

This one is SharpDX, so things should be more interesting.

I started with the character controller. One first obstacle that I had was the right-hand/left-hand coordinate system discrepancy. I think I fixed it now, but it is probably way to hacky. And then eliminating the XNA dependencies.

I managed to get the basic space working and now comes the very difficult process of tuning things. I've always had great difficulty with tuning BEPU to behave just right, especially with gravity and object penetration. With my old setting and world scale, tapping jump propels me up at least 100 meters, which is a lot more than expected :). Climbing on top of a small cube with size smaller than StepManager.MaximumStepHeight causes the cube and controller to spaz out in 7 out of 10 cases.

What I never got around to asking: is there a way to heavily bias BEPU against penetration. A way to reduce temporary clipping to a minimum? As an example: when a cube is moving around on a plane and colliding with it while rotating, ofter parts of it will be submerged in the terrain. The good news is that once the motion stabilizes the object is never submerged. Or some settings to minimize spaz out potential?

Norbo
Site Admin
Posts: 4588
Joined: Tue Jul 04, 2006 4:45 am

Re: v1.3.0 released!

Post by Norbo » Wed Mar 19, 2014 6:25 pm

Or some settings to minimize spaz out potential?
It shouldn't spaz out to begin with; could you reproduce the behavior in the BEPUphysicsDemos for me to look at?

My guess is that there are some mass ratio or scale issues, but it's hard to guess the details without more information.
What I never got around to asking: is there a way to heavily bias BEPU against penetration. A way to reduce temporary clipping to a minimum? As an example: when a cube is moving around on a plane and colliding with it while rotating, ofter parts of it will be submerged in the terrain. The good news is that once the motion stabilizes the object is never submerged.
Penetration should be pretty rigidly prevented in most cases as is. Under normal conditions, the only time any significant penetration should be seen is when an object slams into another object at high speeds. Even then, the penetration will only last a fraction of a second.

Two common causes of excessive penetration are 1) incorrect scale tuning, and 2) teleporting objects. Incorrect scale tuning will clamp the penetration speed at an unsuitably low level. Teleporting objects doesn't allow collision response to work properly since the motion no longer depends on velocity, sometimes resulting in very squishy feeling collisions.

A reproduction of the behavior in the BEPUphysicsDemos for me to look at would help with this too.

I would recommend creating another thread for these issues to make it more searchable for others.

diabloqfdb
Posts: 38
Joined: Mon Aug 20, 2012 10:33 am

Re: v1.3.0 released!

Post by diabloqfdb » Wed Mar 19, 2014 7:03 pm

OK, thank you!

I will try to reproduce the penetration issue in the demos, seeing that that is the worse offender.

But first I must clean up my SharpDX port to make sure that it is not my fault. There are still some issues. Even though I'm using the LH version of the matrix creation functions and everything renders correctly, the Forward component of the matrix is (0, 0, -1).

And it has been some time since I last integrated BEPU. What unit does the Update method take? Seconds is too slow, milliseconds is too fast. This probably means my scaling is wrong.

Just an FYI on my scaling: 1 meter is 1 unit, the character's eye level is at around 1.7 and g is -9.8.

And something else strange that I have noticed, but this may be again my fault. Using the new threading class like the demos do seems the raise my Update time, not lower it as in previous versions of BEPU. In those versions, adding a few threads to the thread pool increased performance quite a bit.

And what is the correct order of calling the update methods? There is the space update, the controller update and potentially updates to some objects I manually move.
Norbo wrote:
Great to see an update! An with IK too! But what is this about C++? Only the IK part is C++?
The BEPUik on codeplex is just a regular C# library. There is a separate C++ port of that for use in the eponymous blender addon.
I was hopping for a C++ port of BEPU :)). All my code is in C# and I have no time to port, but fighting C# for the more low level things needed for a high performance engine can be cumbersome. I need a pool for everything.

Norbo
Site Admin
Posts: 4588
Joined: Tue Jul 04, 2006 4:45 am

Re: v1.3.0 released!

Post by Norbo » Thu Mar 20, 2014 1:20 am

And it has been some time since I last integrated BEPU. What unit does the Update method take? Seconds is too slow, milliseconds is too fast. This probably means my scaling is wrong.
The engine itself is unitless. It's up to the user to define what the units are and to choose reasonable values based on that.

As an example, if a character is roughly 2 units tall and the gravity is (0, -9.81, 0) and the simulation is expected to behave in an earthlike manner, the simulation was built expecting meters for length and seconds for time. In such a simulation, seconds should be passed into the Update method.
And something else strange that I have noticed, but this may be again my fault. Using the new threading class like the demos do seems the raise my Update time, not lower it as in previous versions of BEPU. In those versions, adding a few threads to the thread pool increased performance quite a bit.
If anything, threaded performance should have improved over the old versions due to less sequential work. There isn't actually a new threading class; it was just renamed and some of the unused bits were removed.

Note that if multithreading is used on a near-empty simulation, it will likely be slower than running on a single thread. There is a fixed overhead associated with dispatching and rejoining the threads repeatedly during engine execution. This should be only fractions of a millisecond, but it can still dominate execution time in extremely small/empty simulations. There may also exist other pathological cases which could harm multithreaded scaling in small simulations.

If you have a simulation of reasonable size (meaning it takes at least a couple of milliseconds when single threaded, and is composed of at least a few hundred dynamic objects) and multithreading is actually slowing the simulation down, I'd like to take a look. That's an area of optimization that's very important to our project. I know of the big areas that need improvement, but additional data is always nice.
And what is the correct order of calling the update methods? There is the space update, the controller update and potentially updates to some objects I manually move.
As far as the actual simulation managed by BEPUphysics goes, the only thing that needs to be updated is the Space itself. Anything added to the Space (e.g. the CharacterController or Vehicle) should not be updated directly.

Any external input- changing character controller or vehicle movement direction, forcefully teleporting objects around, and so on- can be performed at any time so long as the Space.Update isn't currently executing. There are sometimes reasons to order things one way or another, but those reasons are not defined by the physical simulation. For example, you'll usually want to update the character's movement direction before a Space.Update rather than after just so that the character has the latest possible movement direction. Doing it the other way won't break anything, though.
I was hopping for a C++ port of BEPU :)). All my code is in C# and I have no time to port, but fighting C# for the more low level things needed for a high performance engine can be cumbersome. I need a pool for everything.
Every once in a while, I'm tempted by such gross ideas as a C++ rewrite :) The reality of language-restricted tooling quality and general productivity always quickly nips any such urges in the bud, though. The fact that C# can approach C++ performance closely enough as-is (especially if you're willing to sometimes write code that looks like C) helps too.

(With regard to memory management, there are some tricky things you can do which can go a long way in improving usability, lowering memory usage, and lowering heap complexity. One implementation of these ideas can be found in the "Quick" collections in the currently under development v1.4.0. The collections themselves are value types and all of them rely on reusable arrays of predictable sizes. Even though it's only been used so far in one area in BEPUphysics, it's produced significant savings.

That is also just one potential approach. If the target platforms all allowed unsafe code, I could do even more stuff. For example, there's nothing stopping tight C-style unmanaged memory usage in C#. The GC could be left completely idle. It just goes against common C# idioms and tends to look ugly. I've done this in some other internal projects.

This won't protect you from needing to worry about memory one way or another, but it can close the gap when it's really helpful and when you still really don't want to/aren't allowed to deal with C/C++.

Also, if you'd like to see C# move towards offering higher performance, there are some exciting things going on and don't forget to tell Microsoft what you want. :))

diabloqfdb
Posts: 38
Joined: Mon Aug 20, 2012 10:33 am

Re: v1.3.0 released!

Post by diabloqfdb » Fri Mar 28, 2014 4:14 pm

Thanks for the info!

I managed to fine tune the physics and now everything is mostly working just right. Jumping is no longer super human which for my needs is bad but I think I can fix it though code that adjust jump speed based on movement speed. And maybe my G could be increased by 10-20%. I will probably need to bring out the formulas, compute real Earth physics drop times and add a time tracker to reproduce in engine the time for drop to clear 100% my paranoia that g is not right.

So I'm going to go forward and use BEPU extensively as an experiment in an very stressful scenario and if I find anything or have questions I'll start a new thread. I expect small things on large objects to misbehave a bit, but maybe you fixed that since 1.2 :).

As for C#, I do agree that for general use it is more than fast enough and as an average it has roughly the same performance as C++ (average C++, not highly optimized one :) )

Problems arise when creating heavy duty 3D engines. GC is out and you need to pool, cache and avoid new as the plague, because random GC collection cycles will mess with the requirement of extremely smooth and predictable frame times.

In C++ with the libraries I'm using I have automatic deterministic management of 99% of all resources without any smart pointers or hacks. No code or worries. In C# engine programming, I need to write a ton of of Buffer and Pool classes and worry about the GC and what generation the objects will wind up in. I remember back in the day when I added the first pool and was pleasantly surprised to get rid of a bunch of spikes.

Stream support is also abysmally poor in C#, especially when using floats.

And there is the added cost of marshaling things from the managed world to unmanaged and back.

So if I had a choice I would go C# for general purpose programming, C++ for engine writing.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest