[RELEASED] uPhysics & uPhysicsPro

1) I assume you use rigidbodies to archive that behaviour. The answer is rather simple, rigidbodies are moved and must be moved on the physics loop. Depending on how fast/slow this cycle runs, the rigidbodies will look jittery. In future versions I will adresse this by implementing a interpolation feature just like unity does. Aswell consider to subscribe to the uPSimulation event. Itll be called right before the physics cycle and will generate way smoother results.

As of interpenetration, it depends on what you use, continouse or discrete mode. Thought there will always be some small interpenetration since perfect solutions are quiet expensive. Modern solvers always allow some minor penetration since it simply looks smoother. As for oscillating objects, try using physics materials with high friction and it'll be gone. There will always be some numerical error.

Aswell consider to tweak the values of uPSimulation.

2) In the current build, since it was a major update which brought rigidbody dynamics, I disabled the direct positioning of objects. Therefore they currently rely on load balancers. However, I'll Adresse this in the next version.


3)-4) I consider this as a bug report. I'll look into it asap. Consider to report bugs to our support by the way, it'll be handled faster.


Just as a sitenote, remember that this tool is still in it's childhoods and not yet completely fireproofed like stated on the main page of this thread.
Greets

 

How long will it be on offer for? A couple of weeks and I can write it into the next buying spree.

 

Depending on how well the sale goes, it'll be up for that price till the end of the month. Though, the dll version will prolly get a bit higher by about 5 dollars.

 

Hi, I'm currently developing real-time versus battle game with rollback mechanism. I couldn't use Unity built-in physics engine as I need to rollback and re-simulate several frames at once. Does this plugin have the ability to manually simulate physics using adjusted/customized timestep and check for collision at anytime?

Thanks

 

I don't really have time to go through the whole thread, so sorry if this has already been addressed.

1.a) How predictable is this?(Can I have a ball fall on one computer at the same time as the other and have the same simulation occur on both sides as long as I step through the same amount of times?)
1.b) Can I step through the simulation?

2) Are you using high-precision floats?

3) Can I have Unity do a "visual representation" of what the physics simulation is calculating or are you getting the vectors from the transform in Unity for simulating(thus making any attempt at high precision floats void).


Cheers,
Dan.

 

@hitorijanai

1. Yes you can adjust/customize the timestep like in Unity. However, backstepping of time is not possible and you wont find a engine where it is. Most of the time, its just about your code, doing the backstepping yourself. For example, you could cache positions/rotations and scales of objects for several frames and revert them when you need to.

2. Checking collision at any time is currently not supported. Thats somewhat raycasting. But as a heads up, raycasting will be available soon and if you need to be able to check for collisions at any time, I can implement it in the next update. No problem here.


@Dabeh

1.a) Yes and no. There is lots of stuff you can fine tune to get better performance. However, using a simple setup without warmstarting (which will be btw available next update) and without much frame coherence the simulation might lack stability. The question is unfortunatly not easy to answer. It fully depends on what you are doing. For example, a sphere will always collide with a box the same way. However, boxes without frame coherence/warmstarting might carry normals which are slightly off. But in general stuff will always act the same way under the same conditions. Though, remember, there are lots of conditions.

1.b) Currently not available but requested before. Itll be available in the next version.

2) Simple floating points are enough. Doubles do have pro's and con's.

3) Im not quiet sure what you mean by "high precision floats" and why they would be void when fetching from a Transform.
To answer this question, uPhysics implements its own transform component to enable a up-to-date simulation and load balancing. The system does keep any transformation properties internally and just updates unity.
You cant debug draw uPhysics out of the box. That would be way to much and you wouldnt see a single pixel anymore. However, in case you own the source version, feel free to add some debugging gizmos for your need.




As a general sitenote, the next version will be available by the end of this week/beginning of next week. More infos on thís version later.

 

@Sharp Development
Yeah I code my own rollback implementation that saves most of important states, like transforms, booleans, etc, each frame so I can revert to previous state of the game (that is still on buffer) at anytime. If you provide something like

Code (CSharp):

1. Physics.Simulate(deltaTime);

that can be called manually then I think this plugin is suitable for that purpose.

I think it will be like this (semi-pseudocode):

Code (CSharp):

1.  
2.     while (rollbackFrameStates.count > 0) {
3.         rollbackFrameStates.GetOldest().Simulate();
4.     }
5.  

Code (CSharp):

1.  
2.     void FrameState.Simulate() {
3.         switch (StateType) {
4.         case StateType.UPDATE:
5.             world.SendMessage("Update", SendMessageOptions.DontRequireReceiver);
6.             break;
7.         case StateType.LATEUPDATE:
8.             world.SendMessage("LateUpdate", SendMessageOptions.DontRequireReceiver);
9.             break;
10.         case StateType.FIXEDUPDATE:
11.             world.SendMessage("FixedUpdate", SendMessageOptions.DontRequireReceiver);
12.             break;
13.         }
14.     }
15. }
16.  

Actual code is not this simple, but I hope it's easy to understand.

Thanks.

 

Ok, thats definitly just a line of code and something I can work with. Itll be included in the next version aswell.

 

Thanks! When will the next version be released? I'll definitely recommend this plugin to my team!

 

look very strong we go video for present this product

 

Yes, Ill do some demo's and videos soon.

 

As of the current pending update:

• Added cylinder collider
• Added constraints (WorldPoint, Grab, Distance)
• Added global forces (custom gravity, Motor (torque), singularity )
• Added manual simulation stepping
• Fixed editor stepping related bugs

The constraints, though, are not yet completly stable and may carry some odd behaviour sometimes.

The price of the DLL version has been increased to 30$. So get it while its still up for 25$.


The next version will include more forces, especially local ones, more constraints, joints, and maybe TriMesh colliders/Terrain colliders and finally a character controller.

Stay tuned!

 

Brilliant, do you have a estimated time when the uPhysics 2D comes out? Also I'm very curious what are the future features that require 2D components? It's much appreciated that we can have a look of the roadmap especially for 2D, as we are comparing different 2d physics solutions, many thanks!

 

Well, 2D components are rather easy to implement. Colliders like circles, planes, polygons, etc. So infact they will be available pretty fast. 2D physics in uPhysics will most likely take a few weeks before implemented, especially since Box2D itself is already a great physics engine. I could aswell just implement Box2D into uPhysics, though, the usecase would be the same as in unity. The nice thing is that there acctually is no need to implement Box2D, its already good enough integrated into unity. In most cases it'd be enough to just supply the unity/box2d components with a load balancer to get the movement performance increase. As of the solution which would come with uPhysics, it'll be most likely 3D oriented, since thats where uPhysics is supposed to deliver major performance increases.

 

Can this be used together with Unity physics ?

Say i have some objects with colliders from your system, will these interact with my terrain and other Unity collisions ?

 

uPhysics is a standalone framework, so no they wont. Though, if you want to keep unity physics, you can simply use unity for collision and gain the performance gain from uPhysics by using uPTriggers and LoadBalancers.

 

The load balancer will apply to the already existing Unity physics as a higher level manager ? Or would i have to apply some script to each object with collider.

Also what is an estimate of the performance boost i would be looking at when using Unity setup with these managers ?

 

The load balancer simply load balances calls made to uPTransforms (which is a custom component reflecting a normal unity transform) over several frames. Just this load balancer component will optimize your generic movement by an order of magnitude. Ex: 1000 objects moved 30 times a second with unity = 20~FPS, with a load balancer 200-700~FPS depending on processor.
Though, this only involves calls to the transform component.
So thats the performance gain for generic movement. When using uPhysics triggers, youll be running at a nearly constant framerate of 200-300~FPS. Though, this does heavily depend on CPU.

 

Nice, buying asap

Is there a manual describing the workflow to integrade this in my current scenes ? Do i have to apply the uPTransforms to each object with a unity collider for example ?

Also is it possible to upgrade to Pro version later ?

 

Unfortunatly its not possible since its two different packages. :/

A manual is delivered with both packages and you can find it on the first post of this thread. Though, it needs some future work since there had been lots of updates in the past weeks. Though, its dead simple to get the load balancer working. Just look at the performanceTest scene.

 

Ok, thanks, just bought and starting the implementation

 

Feel aswell free to message our support if any questions arrise.

 

The new version is now available on the assetstore. Keep in mind, when owning uPhysics or uPhysicsPro you can get instant accses to the package via dropbox by sending your invoice number to our support.

 

It's nice to hear that because I can start to integrate uPhysics in my game without waiting for your 2D colliders, however as far as I remember what you said.

I was actually expecting that you can implement your own 2d collider that benefits from the hierarchical hash grid, anyway as far as I understand the major performance comes from the load balancer which is already there, I'll start to integrate, thank ;D

 

Hi there,

It is infact possible to integrate own colliders, aswell 2D ones. Do you own uPhysics or uPhysicsPro? If Pro you can simply look at the implementation of the already present colliders. Its quiet simply to do so. Just derive your collider from uPCollider and a collider shape from uPCollisionShape. Implement all the necessary methods and you are close to done.

 

Great, I have indie version, I sent u a email to ask if an upgrade to pro is possible. ;D Thanks
and another question is, is it possible to use verlet integration, or other integration method for uPhysics?
and if possible, a better api manual is greatly appreciated;D Thanks

Best regards

Yi Wang

 

Regarding the API, there's lots of documentation I still need to do, the API belongs to it. But uPhysics is a rather large project. But yea, its definitly on my roadmap.

What you mean exactly by verlet integration thought?

 

Just wondering, as this project seems interesting, I'm pretty new so maybe this is a dumb question but do you have One-Way colliders implemented in this physics plug-in?

It would definitely save me a load of headache than trying to do it a round about way either through:

• Ignoring collisions
• Mesh collision (making sure I have only 1 normal face to collide with)

I guess what I'm asking is if there is a Plane collider.

Anyway, props to this, I love the idea of a cone collider, makes a lot of things much easier for me!

 

Not quiet sure what you are asking but yea you can ignore collisions just like in unity via layers.
Plane colliders are on my list and not a big deal, prolly arriving soon. Mesh colliders are aswell available.

 

Yea this was what I was most interested in, it saves a huge amount of time in my mind to have this in advance and less code. Was pretty disappointing to see Unity doesn't have cone/plane colliders, figured that'd be in there.

Again thanks!

 

How was your vacation last month

Not needed for me as I'm not using Unity's terrain system and cannot.

Yeah this thinking concerns me! For example, you recently said "Plane collider is no big deal", and it's true because as we know only a single y-coordinate needs to be compared. Would you implement this as a mesh-collider with a tesselated plane mesh? Of course not, that would just be wasteful. Too much work that does not actually need to be performed for the purpose of plane-collision-testing. Sure, our hardware can deal with it but who knows what crazy other stuff needs to be done. Physics is only a tiny fraction of a complex multi-faceted gameloop, ideally.

Likewise, a heightmap collider only needs to compare a single y-coordinate against a 2-dimensional "heightfield" array. Yes, some minor interpolation is needed but still MUCH better than doing a full-on per-triangle mesh-collision, especially when there is no equivalent mesh being rendered in the scene anyway.

As I said.. maybe I'm targeting mobile, or maybe I'm doing other crazy crowd simulations or planetary crazy whatevers.. if only a heightfield collision is needed, no cycle should be wasted on a full-blown per-triangle mesh-collision testing, amirite

As I said, the collider would have to check a y-coordinate against a 2-dimensional "heightfield" array of floats with some basic interpolation within a quadrant of the 4 surrounding height values, quintic perhaps.

Btw. does the asset have to require 4.5 in Unity's built-in Asset Store? I was considering grabbing the source version but U won't let me until l upgrade which I cannot do for another 1-3 weeks..

 

No plane colliders wont be integrated as TriMeshes, that would just be wastefull. Tho, neither is it about checking of a single value, its done by the plane equation. Furthermore, a normal plane can aswell be plugged into GJK/MPR. No worries, planes will come in an optimized form!

Sure, I had this method implemented at some point but it carried more than unsatisfying results. Generally, movement and big objects arent gracefully handled. As of mesh colliders for heightmaps, you might now think thats overkill. Infact it isnt since the triangles are evenly distributed on a 2D area and can therefore be looked up with an indexing system. No need to build up a octtree like for other mesh colliders. Heightmap collisions just need to check two or three triangles, looking them up is fast and testing them is fast aswell.So infact there wont be any significant performance lose/overhead, just way more accuracy.

Just to say it again, heightmap mesh collisions arent "full-blown per-triangle". Its a matter of checking a couple of triangles which one cant compare to a normal mesh collision.

No, uPhysics was coded on 4.3 so I aswell guess its backwards compatible to 3.5. I've just recently upgraded from 4.3 to 4.5 and uploaded the new version from there. But yea, I intentionally left out stuff requiring 4.5. No worries.

 

Good stuff, that's what I love to hear -- just would be neat to be able to construct this sanely when a Unity terrain object isn't present (worst case I can accept having a terrainData asset and instance around, but no Terrain gameobject/component) -- so are they coming up any time soon?

Yeah I'm not worried except it's nonetheless now somehow classified in Asset Store as "requires 4.5" and I can't buy it by default when you export a package Unity (stupidly) takes your Editor version as the min-version-requirement but IIRC asset authors can overwrite this somewhere, somehow

 

I've gotta look into that, maybe I'm able to override it. ;o If not i'll just upload the next version from 4.3 again, still got it somewhere on my machine anyways.

As of when the next version will appear. I'm not having an ETA yet, theres currently much stuff I need to do for university and I've been coding a small tool lately in my spare time which I had planned for quiet some time. However, I assume it'll be on within the next one or two weeks maximum but dont quote me on that.

 

Imagine someone using a 4096x4096 heightmap. Unity can't do this but I can.

What I *think* Unity cannot do is have a triangle mesh of that same resolution at full detail. 16 million unique vertices if we only take positions. I can easily script mesh generation, that's simple stuff. But even without colors and normals and texcoords, I think Unity's 65530-vertices limit kills this.

Which is annoying, they should let us create meshes of arbitrary vertices if RAM permits and simply prevent uploading to the GPU instead, which wouldn't be needed here anyway. Think you can work with a verts+tris array outside Unity's Mesh class?

 

As of custom terrain generation. I Will most likely optimize it. Means linear height increase's will not produce several verts/tris but only one. That might end up making 4096x4096 perfectly possible depending on detail.

 

I was trying to do what you said, but unfortunately particle's position is accessed by ParticleSystem.Particle.position , instead of transform. I supposed what you meant is to replace all the transform calls by uTransform calls, however when it's a particle system, is there a way to integrate the load balancer with particle system? Thanks a lot!

Best regards

 

Well, it seems we talked about different things right there. :/

It is possible to rewrite the load balancer to apply aswell on particles. If you dont mind I will do that and include it in the next version.

 

Fantastic! It's better that you can upgrade it, because I am an artist that just pick up programming....Anyway thanks a lot.

I mean the 2d particle physics like this: http://subprotocol.com/verlet-js/examples/tree.html
It's powered by Verlet integration to have a soft body effect. Previously I tried to use box2d's hinge joint, dist joint, to reproduce the same effect, but its performance is too low to use. My question is, can I have these particle-physics effect using uPhysics? Or it's better that I have my own verlet particle physics system and integrate only with load balancer?

Best regards

 

Hm thats quiet interesting! Im quiet sure you can modell such behaviour with uPhysics constraints. But to note is that at the current date of time, the constraints in uPhysics lack some stability.
Tho, you have always the option to implement own colliders/constraints on top of the given uPhysics base classes aswell as the load balancer.

Ill definitly look into this!

 

Hi,
I am eager to give your physics engine a try. I am currently struggling with unity physics due to it's unpredictability. I am making a game where you need to throw a dice and get its value. The dice value is determined on the server and I have precalculated the force, torque to get the value I want on the dice. But due to floating point calculation variation the dice doesn't always land on the desired side on every pc. This is very frustrating. If your uPhysics can be predictable, where I am sure that giving x amount of force, x amount of torque will land the dice in the desired side up on every pc, mobile no matter what, then I will definitely buy it. Otherwise, i think I need to manually calculate the physics part for dice rolling, which I am finding to be very hard.

 

Unfortunatly, thats not a problem with the physics engine itself but platform/hardware specific. There's nothing you can do against it, so no uPhysics will most probably behave in a similar way.

Furthermore, why do you use physics for a diceroll at all? Thats a bit over the top to rely on a physics engine for such a thing. I'd recommend to use animations instead to simulate the dice rolls.

 

I just thought of this but maybe it's a bit too complicated.

I was looking at the physic materials, trying to mess around with them, and while there are options to change the friction and bounciness I noticed there isn't an option to change the "hardness" or more accurately the "elasticity" of an object.

I wouldn't mind coding the physics myself to account for Hooke's Law on objects that need it (say if I were to create a wall made of rubber that the character can run into and bounce off of after sinking into it. Having this increase with velocity of course).

I'm sure that it would be a lot of work to get it working for things other than a box/plane collider but it might be something pretty neat to have with your Physics engine. I haven't really seen anything done in the nature of physic materials.

 

Are you speaking of uPhysics?
uPhysics does infact implement PhysicsMaterials with fully working friction and bounciness (which is infact elasticity).

 

Ah, I see. Too bad for me.

I did think of that, unfortunately my dice will roll in hundreds different ways to make it all look unique. Those animation becomes around 20MB. My game will run on a web player. So 20MB is out of question. Looks like I am stuck with writing my own physics for it

 

Sorry should have been more specific.

By including Hooke's Law I also was wondering of having a breaking point in which the object looses elasticity if the force is too much or can loose some of it's elasticity.

I also was wondering if it's technically possibly to deform the mesh based on the physics added to it but I suspect that's a job better done with animation. (Rather than have a "stiff" bounce. More like a trampoline effect).

 

Implementing a breakpoint or a point where the object begins to lose elasticity is somewhat hard. Though, you can implement that by using triggers and changing the physics materials of surrounding objects depending on velocity of your main rigidbody.

As of deforming meshes, uPhysics delivers collision data which include points and normals. You can deform your meshes with that data and force uPhysics to update the respective collisions shape.

After all, uPhysics is a physics engine just like unity's PhysX so absolutly dedicated stuff will not be implemented out of the box. (Such as changing elastisity, thats up to your logic)
Tho, for mesh deformation, I will add that to my todo's since thats something which fits right in.

 

Sounds awesome man.

I figured as much on breakpoint, it should be a good project for me to do.

Thanks!

 

Is there a way to make use of uPhysics' great looking Load Balancer with Unity PhysX rigbodies instead of uTransforms?

It would be great if it could handle callbacks to inform which rigibody should be moved during this frame.