v1.3.0 released!
Posted: Sat Dec 21, 2013 4:23 am
Former forum of queegs; use github discussions now!
https://forum.bepuentertainment.com/
Fluids on spherical Shapes (Planet )?! Awesome!FluidVolume now supports non-Y up vectors and is a little less bad.
It's still a little bad.
Oh good! I'll give it another shot in my own project, I suppose!FluidVolume now supports non-Y up vectors and is a little less bad.
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.EDIT: When did you remove ISpace? I thought that was present as late as v1.2.0. Was I dreaming?
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.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.
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.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 BEPUik on codeplex is just a regular C# library. There is a separate C++ port of that for use in the eponymous blender addon.Great to see an update! An with IK too! But what is this about C++? Only the IK part is C++?
Motivated by that I decided not to update my BEPU project, but instead experiment on another project I have.Norbo wrote: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.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!
It shouldn't spaz out to begin with; could you reproduce the behavior in the BEPUphysicsDemos for me to look at?Or some settings to minimize spaz out potential?
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.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.
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 wrote: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.Great to see an update! An with IK too! But what is this about C++? Only the IK part is C++?
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.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.
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.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.
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.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.
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.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.