Version Roadmap
Re: Version Roadmap
Right now the largest accuracy improvements will be related to collision detection (particularly with triangles), if that's the kind of accuracy issue you're facing. Constraints will be fairly similar in stability. The engine should be able to handle a 0-length timestep as well to allow for extremely easy 'pausing' by internally turning off components which are meaningless when time isn't moving forward (which happens to be the majority of them).
The looser CCD will feel a lot more robust too due to the lack of jigging during glancing collisions, though it and some other features probably will need to wait for v0.16.0.
The looser CCD will feel a lot more robust too due to the lack of jigging during glancing collisions, though it and some other features probably will need to wait for v0.16.0.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Our main accuracy issues are with the static tri mesh and CCD's jiggling and we also have to run the simulation at all times even within edit mode with a timestep of 0.000001 which the engine doesn't like... So yes all of these improvments would help tremendously expesially the static tri mesh accuracy improvments...
Would it be any better at handleing thin 0.25-0.5 objects? as when one object is on another that is giving us a few issues with lots of jittering.
Would it be any better at handleing thin 0.25-0.5 objects? as when one object is on another that is giving us a few issues with lots of jittering.
Re: Version Roadmap
It depends. The general case robustness will improve, and more special cases will be added over time to deal with specific pairs.Would it be any better at handleing thin 0.25-0.5 objects? as when one object is on another that is giving us a few issues with lots of jittering.
Having dimensions of around 0.25-0.5 shouldn't cause jitter alone in v0.14.2 and before either, unless coupled with some other dimensions that the engine doesn't like. It may also be related to mass- is it some relatively light panel that is being ridden over by something heavy? The solver has a hard time dealing with heavy stuff on light stuff.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Yes when our marble (which has a mass of 65) trys to ride over a 0.25 high plank which has a mass of 20 the marble can fall though and everything jitters alot, would this case be any better in .15?
Will .15 be using the same physics solver as .14 or is that a new/improved part of the engine.
Will .15 be using the same physics solver as .14 or is that a new/improved part of the engine.
Re: Version Roadmap
Is the plank a box (so that the pair is a box-sphere)? That collision should be extremely stable from a collision detection point of view in v0.14.2 and before since it has a very simple special case.
The solver is not changing fundamentally with v0.15.0, though it has been reorganized along with everything else. However, I wouldn't expect a 3-1 mass ratio to cause that severe of issues in a box-sphere pair unless the box was particularly perilously placed. Does increasing the mass of the plank or increasing the number of solver iterations help?
The solver is not changing fundamentally with v0.15.0, though it has been reorganized along with everything else. However, I wouldn't expect a 3-1 mass ratio to cause that severe of issues in a box-sphere pair unless the box was particularly perilously placed. Does increasing the mass of the plank or increasing the number of solver iterations help?
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Yes the plank is a box and the marble is a sphere, we have the solver set to
space.SimulationSettings.CollisionResponse.Iterations = 12;
space.SimulationSettings.TimeStep.TimeStepDuration = 1 / 60f;
However the plank is resting on the edges of two platforms that are part of one static tri mesh.
space.SimulationSettings.CollisionResponse.Iterations = 12;
space.SimulationSettings.TimeStep.TimeStepDuration = 1 / 60f;
However the plank is resting on the edges of two platforms that are part of one static tri mesh.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Here i have a little video of the problem, you might be able to see what i am doing wrong better.
Here is the video http://www.youtube.com/watch?v=T1Jm5VLuIcI
Everything visually matches the physics perfectly that you see here.
The plank is Box(2f,0.25f,16,50)
The 2 boxes are Box(1.95f,1.95f,1.95f,12)
The Player is Sphere(1f, 65f)
All the frictions are around 0.2
And the "Bounce" is set to around 0.1 for everything too
The only exeption to these is the rubber marble which currently this for its settings
Settings.FrictionDynamic = 0.6f;
Settings.FrictionStatic = 0.6f;
Settings.Bounce = 0.1f;
The gravity is set to
space.SimulationSettings.MotionUpdate.Gravity = new Vector3(0, -9.8f, 0);
Here is the video http://www.youtube.com/watch?v=T1Jm5VLuIcI
Everything visually matches the physics perfectly that you see here.
The plank is Box(2f,0.25f,16,50)
The 2 boxes are Box(1.95f,1.95f,1.95f,12)
The Player is Sphere(1f, 65f)
All the frictions are around 0.2
And the "Bounce" is set to around 0.1 for everything too
The only exeption to these is the rubber marble which currently this for its settings
Settings.FrictionDynamic = 0.6f;
Settings.FrictionStatic = 0.6f;
Settings.Bounce = 0.1f;
The gravity is set to
space.SimulationSettings.MotionUpdate.Gravity = new Vector3(0, -9.8f, 0);
Re: Version Roadmap
It looks like a combination of the mass ratio and triangle contacts is causing that. The triangle contacts with that board are not perfect due to numerical issues and some other possibilities, and the mass ratio then pushes the board around while the triangles struggle to cope. v0.15.0 will improve that behavior some through superior triangle collision, but it may still need help in the form of a smaller mass ratio.
The bounciness might contribute a tiny bit to the issue. Under normal circumstances it's not a problem, but once a little jitter gets introduced due to the mass ratios/triangle contacts, the bounciness might exacerbate it. On the other hand, the velocities involved might be below the configurable bounciness velocity threshold and so it doesn't matter at all.
The bounciness might contribute a tiny bit to the issue. Under normal circumstances it's not a problem, but once a little jitter gets introduced due to the mass ratios/triangle contacts, the bounciness might exacerbate it. On the other hand, the velocities involved might be below the configurable bounciness velocity threshold and so it doesn't matter at all.
Re: Version Roadmap
Updated the roadmap to reflect recent v0.15.0 development and added some proto-documentation about the changes.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
Wow looks great.
I like that everything is now more or less a separate part of the engine.
I also like the moving of the buffered property’s away from first glance as even in our big project we rarely use them.
Overall this seems like a very nice design and should make development with the engine (and on the engine) much faster.
Could you tell me more about the InstancedTriangleMeshes? What benefits can they bring (lower memory use?, improved speed?)
Are there any features that are missing from .14, if so will they be returning? (one shot manifolds are obviously gone at the moment)
Any idea yet on the speed of .15 compared to the speed of .14? It seems like lots of improvements have been made to just make the engine smarter and do less work which usually would mean it would be faster.
Obviously there are many breaking changes, do you think upgrading will prove to be a problem or is it mostly strait forward and simple fixes.
I assume we are looking at 2+ weeks for testing, debugging and finishing .15 yes?
Anyway it looks great and i cannot wait to test it.
I like that everything is now more or less a separate part of the engine.
I also like the moving of the buffered property’s away from first glance as even in our big project we rarely use them.
Overall this seems like a very nice design and should make development with the engine (and on the engine) much faster.
Could you tell me more about the InstancedTriangleMeshes? What benefits can they bring (lower memory use?, improved speed?)
Are there any features that are missing from .14, if so will they be returning? (one shot manifolds are obviously gone at the moment)
Any idea yet on the speed of .15 compared to the speed of .14? It seems like lots of improvements have been made to just make the engine smarter and do less work which usually would mean it would be faster.
Obviously there are many breaking changes, do you think upgrading will prove to be a problem or is it mostly strait forward and simple fixes.
I assume we are looking at 2+ weeks for testing, debugging and finishing .15 yes?
Anyway it looks great and i cannot wait to test it.
Re: Version Roadmap
Their primary benefit is memory. An instanced triangle mesh shape contains both its base triangle data and its hierarchy in local space. Each instance can have completely different, non-rigid transforms as well (sheared, scaled, skewed, translated, rotated, etc.).Could you tell me more about the InstancedTriangleMeshes? What benefits can they bring (lower memory use?, improved speed?)
In terms of performance, a convex shape colliding with a InstancedTriangleMesh will be very slightly slower than a non-instanced mesh, since the shape must be transformed into the instance's local space. Relative to the rest of the collision detection process, this is a very small cost.
Colliding a complicated compound body or mesh against an instanced mesh will have an extra cost compared to two objects with world-space hierarchies. However, such collisions are rare and are still not that slow.
A good example of where the InstancedTriangleMesh would be useful is if you have 4-10 unique tree collision models which are repeated in various poses and transformations to form a forest. With normal meshes, the hierarchy (with size proportional to the number of triangles in the mesh) would need to be repeated for every single tree. For instanced meshes, only the original 4-10 hierarchies exist and each instance just has a transform matrix. For a sufficiently large forest and complicated tree mesh, the simulation might be impossible without using instancing due to the memory required.
Other than the manifolds, the compound bodies with non-convex children might be another one. My goal is to support non-convex children, but we'll see how it works out.Are there any features that are missing from .14, if so will they be returning? (one shot manifolds are obviously gone at the moment)
I can't immediately remember anything else. There's probably a few obscure properties that no longer have a meaning due to the new system or got removed, but the major functionality should all still be present.
It should indeed be faster, but I still don't have real benchmark numbers. The biggest sources of speedup will likely be from the redesigned collision systems. MPR received some improvements to how support mappings are managed. GJK was basically rewritten from the ground up. I wouldn't be surprised to see GJK running 2-4x faster now, although what that translates to in end performance gains depends on the simulation. The general convex-convex collision detection case also received some other miscellaneous improvements.Any idea yet on the speed of .15 compared to the speed of .14? It seems like lots of improvements have been made to just make the engine smarter and do less work which usually would mean it would be faster.
Simulations with lots of triangle meshes stand to benefit the most. Triangle-convex collisions should have a special case which, in many cases, will be extremely fast and accurate (5-30x faster than GJK, close to sphere-sphere). In some circumstances, the special case will fall back to the new and improved MPR/GJK. In addition to the per-triangle test improvements, the triangle hierarchies have been rewritten and should play nicer in memory and have a bit of a speed boost too.
Less importantly, I plan to add a few more special cases to things like capsules. These might wait until v0.16.0, but they are pretty simple shapes which can benefit a lot from a little more attention.
What those numbers will actually translate to in 'end performance increase' is unknown. My guess is that the Xbox360 and WP7 will benefit proportionally more due to the various memory-handling changes (reductions in memory usage from instanced meshes, large reductions in heap access in general, more very local stack fiddling).
Given that the box-box special case changes from a couple of versions ago boosted the Xbox360 from 30ms to 15ms on the wall simulation, I would suspect simulations heavily relying on the improved bits would get a similar speedup.
It depends on what a given project is closely integrated with. For example, a simulation relying heavily on certain quirks of StaticTriangleGroup functionality is probably going to have to do a little redesigning. A simulation that simply includes a StaticTriangleGroup, on the other hand, might just have to change a name or two and the parameters to a constructor.Obviously there are many breaking changes, do you think upgrading will prove to be a problem or is it mostly strait forward and simple fixes.
Yes; I really don't want it to take much longer than that. I'm looking at the to-do list for what still needs to be done and, while it's pretty long still, if I can finish one or two of the items each day and push a couple of the less important ones to v0.16.0, it should work out.I assume we are looking at 2+ weeks for testing, debugging and finishing .15 yes?
But then, of course, I'm sure some sort of horrible bug will crop up at the last second
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
The speed stuff sounds amazing!
Are any specific optimizations being done that can help on the phone or does anything that helps the other 2 help the phone as well.
Are there any plans to add in the future more shapes to the core engine like trapezoids, cone, prism or pyramids?
So the engine uses a new and improved version of the MPR/GJK hybrid? With soft interpenetration correction?
Any changes to the way that the ccd/LinearContinuous work?
Our game uses quite a lot of raycasting (both during level building and at runtime) has this been improved in anyway (speed or otherwise)
And one last thing, what is the default broadphase in .15 is it still the DynamicBinaryHierarchy? Have any improvements (speed or otherwise) be made to it?
Anyway sounds great so far, great work with everything and hopefully the inner performance changes result in a nice speed boost overall too.
Are any specific optimizations being done that can help on the phone or does anything that helps the other 2 help the phone as well.
Are there any plans to add in the future more shapes to the core engine like trapezoids, cone, prism or pyramids?
So the engine uses a new and improved version of the MPR/GJK hybrid? With soft interpenetration correction?
Any changes to the way that the ccd/LinearContinuous work?
Our game uses quite a lot of raycasting (both during level building and at runtime) has this been improved in anyway (speed or otherwise)
And one last thing, what is the default broadphase in .15 is it still the DynamicBinaryHierarchy? Have any improvements (speed or otherwise) be made to it?
Anyway sounds great so far, great work with everything and hopefully the inner performance changes result in a nice speed boost overall too.
Re: Version Roadmap
Pretty much everything helps every platform. The phone and Xbox360 may benefit a bit more than the PC, though.Are any specific optimizations being done that can help on the phone or does anything that helps the other 2 help the phone as well.
Cone is already presentAre there any plans to add in the future more shapes to the core engine like trapezoids, cone, prism or pyramids?
![Smile :)](./images/smilies/icon_smile.gif)
The more difficult part is computing an exact inertia tensor/volume for an arbitrary shape. It boils down to doing some form of numerical integration for some shapes. Polytopes like prisms and convex hulls can use a series of tetrahedrons constructed from face triangles. For exceptionally strange shapes, it's simplest to just do a brute force numerical integration using point-in-shape tests or other similar computations. This is pretty expensive, but since you can reuse the inertia tensor and shape for multiple entities, it shouldn't be too bad. There's also the option of completely faking it and just using the inertia tensor of the bounding box- it usually works just fine.
Yes, basically. In addition to the MPR/GJK specific improvements, it's a little smarter about when and how to use each algorithm.So the engine uses a new and improved version of the MPR/GJK hybrid? With soft interpenetration correction?
CCD is handled by using a different kind of integrator in v0.15.0. By default, it's set to the discrete integrator; you can set the Integrator property in the Space to some other continuous version. In v0.15.0, I plan to only have the Linear and Fully continuous paths done (unless I magically finish sooner than I expect). The core-shape based CCD will come in v0.16.0.Any changes to the way that the ccd/LinearContinuous work?
Edit: They did receive a bit of an improvement in how they manage relative motion between objects in a moving frame of reference.
In many cases, raycasting boils down to a call to a GJK variant which was also rewritten. If there's lots of hits or close hits, there should be a speed boost. v0.16.0's broadphase rewrites should improve raycasting performance a little more in the general case.Our game uses quite a lot of raycasting (both during level building and at runtime) has this been improved in anyway (speed or otherwise)
Yes, the dynamic hierarchy is still the default, and it's mostly the same. In v0.16.0, its memory usage and access behavior should be significantly improved. The other broadphase being introduced (a sweep and prune variant) should be pretty speedy too, although it uses an auxiliary system to accelerate raycasting.And one last thing, what is the default broadphase in .15 is it still the DynamicBinaryHierarchy? Have any improvements (speed or otherwise) be made to it?
Re: Version Roadmap
Or even better, my main development computer will get hit by a nasty trojan from a bad ad and I'll have to reformat the drive. How fortunate! That will teach me not to browse even reputable sites without noscript/adblockBut then, of course, I'm sure some sort of horrible bug will crop up at the last second![]()
![Smile :)](./images/smilies/icon_smile.gif)
No data has been lost and everything is secured now, but it will eat up a day or two getting everything up and running again.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: Version Roadmap
May I suggest Microsoft Security Essentials http://www.microsoft.com/security_essen ... fault.aspx, it is actually quite amazing and low impact on your system, also totally free (assumeing you have a real windows copy...)
I managed to get a nasty trojan of an ad when browseing reddit, but but MSE removed it (then the next day everyone on reddit went on about how great MSE was...)
Anyway the fresh install of windows should make your pc feel a bit more snappy on the plus side...
I managed to get a nasty trojan of an ad when browseing reddit, but but MSE removed it (then the next day everyone on reddit went on about how great MSE was...)
Anyway the fresh install of windows should make your pc feel a bit more snappy on the plus side...