Version Roadmap
Version Roadmap
The roadmap has been moved into the bepuphysics v2 repository: https://github.com/bepu/bepuphysics2/bl ... roadmap.md
You can also keep track of finer grained progress in the issue tracker: https://github.com/bepu/bepuphysics2/issues
Have any input, suggestions, or more ideas? Post them!
You can also keep track of finer grained progress in the issue tracker: https://github.com/bepu/bepuphysics2/issues
Have any input, suggestions, or more ideas? Post them!
Re: Version Roadmap
Updated the version numbers. What was called v0.11.1 is pretty large and adds a few new features, so it is now v0.12.0 to avoid establishing a precedent of massive point releases. What is currently (as of this post) called v0.13.0 will likely be split into multiple versions (v0.13.0, v0.14.0...) to help get each part out faster.
Re: Version Roadmap
Updated the roadmap to reflect v0.12.0's release.
Re: Version Roadmap
During the development of the Ragdoll demo, a couple of issues showed up with RevoluteLimit behavior and possibly TwistLimits. The Ragdoll demo along with v0.12.1 will be released to address these issues. Unfortunately, it may take a couple of extra days. However, the v0.12.1 update will also include the significantly reworked BEPUphysicsDemos project. The roadmap has been updated to reflect these changes.
Re: Version Roadmap
The RevoluteLimit has been improved, but the other noticeable issue was actually triggered by the Box-Box special case collision detection. A complete re-write of this system was planned for v0.13.0, but it's getting pushed up to v0.12.1. The new system should resolve some long-standing box-box behavior issues as well as noticeably improve performance. The new boolean box-box test is up to 12 times faster than the old equivalent test; the full contact manifold computation difference will not be quite as dramatic, but it should still help.
This will cause a little more delay, but it needed to be implemented at some point anyway.
This will cause a little more delay, but it needed to be implemented at some point anyway.
Re: Version Roadmap
Quick update about the Box-box implementation:
It is very nearly done. Its behavior is more stable than the old implementation, and it is substantially speedier. On the Xbox360, the 100 box wall that used to take 30+ milliseconds per frame now takes less than 15 milliseconds. The PC version is also faster, but the effect is less pronounced.
Rewriting the rest of the collision detection system in v0.13.0 should bring similar speedups to other, non-box-box heavy simulations![Very Happy :D](./images/smilies/icon_biggrin.gif)
It is very nearly done. Its behavior is more stable than the old implementation, and it is substantially speedier. On the Xbox360, the 100 box wall that used to take 30+ milliseconds per frame now takes less than 15 milliseconds. The PC version is also faster, but the effect is less pronounced.
Rewriting the rest of the collision detection system in v0.13.0 should bring similar speedups to other, non-box-box heavy simulations
![Very Happy :D](./images/smilies/icon_biggrin.gif)
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Sounds great norbo.
Anything that speeds up the 360 version is awesome![Smile :)](./images/smilies/icon_smile.gif)
Anyway we are having a good time with bepu so far we have gotten the jump and explosion working thanks to your help on Mulet The Great's posts (my teammate) and are also getting our graphics and networking to work quite well too.
Is there anything that can be done for sphere vs sphere and sphere vs mesh collsions on 360 as our game uses 40+ spheres when on the 360.
They are already quite fast but i was just wondering if it would be possible to have a quick look at them for the next release before we finish our game![Smile :)](./images/smilies/icon_smile.gif)
Bepu has been working brillantly so far however.
Keep up the amazing work.
Anything that speeds up the 360 version is awesome
![Smile :)](./images/smilies/icon_smile.gif)
Anyway we are having a good time with bepu so far we have gotten the jump and explosion working thanks to your help on Mulet The Great's posts (my teammate) and are also getting our graphics and networking to work quite well too.
Is there anything that can be done for sphere vs sphere and sphere vs mesh collsions on 360 as our game uses 40+ spheres when on the 360.
They are already quite fast but i was just wondering if it would be possible to have a quick look at them for the next release before we finish our game
![Smile :)](./images/smilies/icon_smile.gif)
Bepu has been working brillantly so far however.
Keep up the amazing work.
Re: Version Roadmap
Both the sphere-sphere and sphere-triangle have pretty simple and fast special cases implemented. I took a quick look and there doesn't appear to be any obvious way to speed them up significantly in the short term. v0.13.0 (unless it gets split into more than one version) should include some significant optimizations to the broadphase and static triangle group amongst other things, which could help (though it will be more than a month or two before v0.13.0 is ready).
Re: Version Roadmap
Updated the roadmap to reflect v0.12.1's completion.
Re: Version Roadmap
Updated the roadmap to reflect the constraint documentation's release.
Re: Version Roadmap
Updated the roadmap to more closely reflect upcoming versions.
Re: Version Roadmap
Updated the roadmap to reflect v0.13.0's release.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Great release norbo ![Smile :)](./images/smilies/icon_smile.gif)
I'm going to be playing around with the path system later this week. The demo looks great.
One thing I was wondering was why the space.getcontacts was removed? is there an equlivilent (I use it for debug)
Also thanks for forceBufferedStateUpdate that should remove our need to update the simulator in edit mode (I think)
Seriously great release thou.
![Smile :)](./images/smilies/icon_smile.gif)
I'm going to be playing around with the path system later this week. The demo looks great.
One thing I was wondering was why the space.getcontacts was removed? is there an equlivilent (I use it for debug)
Also thanks for forceBufferedStateUpdate that should remove our need to update the simulator in edit mode (I think)
Seriously great release thou.
Re: Version Roadmap
Thanks!Great release norbo
I'm making an effort to make the API a little more lightweight by cutting out odd, uncommonly used, redundant, or possibly misleading members. While getContacts wasn't incredibly confusing, it was out of place and implied that the space somehow had direct management of Contact objects.One thing I was wondering was why the space.getcontacts was removed? is there an equlivilent (I use it for debug)
Space.getContacts didn't do anything special internally; the demos replaced it with:
Code: Select all
foreach (CollisionPair pair in currentSimulation.space.collisionPairs)
contacts.AddRange(pair.contacts);
Re: Version Roadmap
Updated the roadmap to reflect the v0.13.0 phone demo release.