[RELEASED] uPhysics & uPhysicsPro

I found a really good tutorial for this a while ago, unfortunately the site is down now. Basically what you want to do is take the ball's starting position and velocity, then pass them to a function which iteratively, based on an arbitrary timestep, say 0.1, adds the velocity * timestep to the position and gravity * timestep to the velocity, performing raycasts from position in direction of velocity every step. The collision returned will be where the ball will land. For reference, I found an example on the forums:

Spoiler: UpdateTrajectory

Also, there's an Asset on the Store that does this:

https://www.assetstore.unity3d.com/en/#!/content/12306

 

Dude, if you manage to get a raycast batching and GPU acceleration running, your Physics engine gets upgraded from a "Check it out later" to a "Integrate nao!"

My whole damage system is heavely relying on lots of short raycasts, as I try to simulate true ballistic shell behaviour. If raycast batching works, might make the whole thing faster, as there might be many bullets flying at the same time, not to mention raycasts to prevent camera clipping into the terrain and other stuff.

Sounds really exciting. Will not ask for an ETA as I guess it will be "Soon (TM)" ... you most probably have a lot to do to make this work.

 

Hi there, is uPhysics more performant than box2d?
In my project we are aiming to have at least over 3000 2d objects running around, shooting projectiles, and I'm a bit concerned about performance on mobile.
So if your asset works, even though its made for 3d, I'll be sure to get it in the future.
You should include a webplayer demo, with 5000 units running around, in the asset store.

 

Is the update with Raycasting still scheduled for this time of year?

Thanks.

 

Hello all,

Im finally back from my winter vacation as I call it. Been some busy days, I guess everyone can agree.
The update is scheduled for this month and will include several new systems which were asked for, like TriMesh colliders, raycasting, more and better events, seperated worlds, performance and stability improvements aswell as terrain colliders and most probably (if I can do it in time) a wheel collider. Furthermore, to look into the future, uPhysics will get a native and GPU accelerated backend aswell. Tho, itll be still useable with the free version of unity.


As of 2D support. uPhysics is a pure 3D oriented physics engine for one simple reason: Box2D is great and it would be quiet useless to do a custom implementation seeing as it is integrated into unity quiet well already!

 

I'd like to see a web player performance demo like mentioned a few posts back..

 

This is aswell planned to appear with the next update.

 

Purchased. Looks cool. Thanks for linking the hierarchical hash grid article -- worth the price for a working implementation of that alone.

My initial gut-check for how I would use this:

My game world takes place on a noise-based voxel planet/asteroid using a continually subdividing Octree. I plan on using a GetHeightFromNoise() function for planet interaction with spherical gravity (orbiting moons/asteroid belt).

A planet will have people, animals, plants, asteroids. Does it make sense to use a separate physics grid/instance for plants vs generic animals vs all other mobs? e.g. Plants consider distances to neighbors for growth spacing. Animals will want to eat plants. Each of those instances would run with a much smaller time slice than character-to-character/vehicle interaction. Player to plant interaction could be constrained to LOD. Asteroid/moon physics would be extremely limited while at ground-level LOD. Or is there support for layers/masks that can optimize for something like this within a single instance per planet?

And what about using this for culling/LODs? If this is the most efficient way to store locations for many objects that may need to be interacted with, I may as well query this for e.g. tree billboard/group mesh building/grass splatmapping at the appropriate Octree LODs?

 

Hi, I'm considering purchasing this asset for my lock-step structured game but I have a few questions.
1. Can you run the physics simulation with FixedUpdate (if it is not already).
2. How deterministic is the engine? (Is it not based off of floats??)
If 1 == yes and 2 == very, my 3rd question is this: When will this asset be on sale?

 

Porting another physics asset, such as Physics Toolbag (https://www.assetstore.unity3d.com/en/#!/content/9785) should be not much more than a matter of updating transforms? Is there a preferred way to apply forces vs running force simulations in a separate thread that update the transform?

 

You'd probably have to put rigidbody.rotation = uRigidbody.rotation, rigidbody.velocity = uRigdibody.velocity, etc. at the end of the uPhysics update loop.

Or, and this is probably better, you can mod the toolkit to be compatible with uPhysics!

 

I was hoping to get a performance increase when you can integrate 2D features in uPhysics; D Now it seems that it wont come, does it?

 

Hey there!

I am scouting for a new physics engine for a multiplayer RTS game. I've understood that the default PhysX engine in Unity produces different results on reruns of the same simulation, and this unfortunately disqualifies it for my purposes. A friend of mine told me to come here and check out uPhysics instead.

I'm hoping you can shed some light on if and how uPhysics can solve my problems. I'd be very thankful for a reply.

My requirements are maybe quite unusual for the genre. The game concept relies heavily on physics, and the multiplayer implementation requires that the lockstep actions sent between peer computers play out exactly the same on every machine.

The requirement on the physics engine is so strict because physics in this game isn't eye candy. The game mechanics heavily rely on the idea that the world interacts with units in somewhat realistic ways. For example, a structure destroyed by an explosion should turn into potentially destructive projectiles. If these projectiles hit a unit they should deal damage according to their velocity, material and size. You might recognise this kind of game mechanics from the Myth game series if you ever played it.

You can see how this would easily spiral out control in a multiplayer game if there is even a slight difference between the simulations run on the different networked computers.

Thus my question is the following: Will uPhysics be sufficient for this task? I've read the other posts in this thread, and I've seen this question pop out a few times before. You keep saying there can be no true determinism in a physics engine, so I won't ask if uPhysics is truly deterministic. But will it keep deterministic enough to repeatedly produce the same outcome in an hour long game replay with multiple players and hundreds, maybe even thousands of colliding and exploding objects? regardless of how many times I run the same replay? And if not, could you be so kind as to point me in the correct direction?

Thanks a lot!
/L

 

I'd like to know more on how to use this package.

(Frankly, reading the pdf manual did not shed any light on this - not any step by step instructions, not even any syntax examples.)

Let's say for example that I have a cube and I want to add gravity to it.

With Unity I would normally do this:

1 - Select cube.

2 - From main menu select "Component > Physics > Rigidbody".

(That's it, now the cube has gravity.)

How would I do the same with this plugin??

And where can I find syntax examples on how to detect collisions etc?

Can you make some Youtube videos (even just one) that show clearly how to use this plugin?

Are there any major limitations compared to "native" Unity physics?

What is the difference between uPhysics and uPhysicsPro (the price seems to be the same)?

 

Hello,

I have a few questions about uPhysics.
Let's say I have some procedurally generated meshes, that can change over time (and new ones can appear).

1. Can I generate respective mesh colliders (with adjustable accuracy) and hold them as an objects (not Unity GameObjects, just objects on a list)?
2. Can I manualy raycast those colliders on demand?
3. How expensive would be recalculation of colliders after mesh change? How does it compare to Unity physics?
4. Would all above work in webplayer and use threads?

Cheers,

Bartosz

 

I don't think this asset is supported anymore, or at least this thread isn't.

 

It's been barely over a month since his last post. More likely, Unity's forums bugged out and stopped sending him notifications (I've seen that happen more than once); try sending him an email.

 

I have around the same time I made my first post on this thread. No reply unfortunately. Also, why would that be likely? Has Unity ever stopped sending you updates on a watched thread before?

 

It hasn't happened to me personally, but I've seen at least one asset author return to a thread after a hiatus claiming he stopped receiving notifications. In fact, it was in response to a PM I sent asking if the asset was still supported .

 

I've PM'd, emailed, and posted on this thread and finally given up on uPhysics to work on my own physics engine.

 

Infact I've gotten the updates for this thread but I frankly didnt receive any emails. Tho, I gotta admit I've not looked into the spam folder yet which seems to go awol lately, even on my personal email account.

Im sorry if I couldnt reply in time over here. As a student you unfortunately aswell have exams which are quiet using up all my time this semester. :/
I'll try to answer everything tomorrow after the next exam. Stuff should be a bit easier for me than, since the last exam im writing is on 23.2 and quiet, well, easy...
I'll aswell look in my spam folder, however, to make sure just resend the email you wrote me!

 

Thanks! Sorry I lost faith in you. Exams are tough.

 

@jason.fisher: You definitely need to summerize the question a bit since I not seem to get what you are asking. :/

1. Physics engines are commonly run on fixed timesteps (or stepped manually) simply because it is a requirement. This is caused by the fact that objects affected by physics need to be processed at the same time for the so called "solver" to solve/calculate the respective forces, general movement and collisions. In other words, uPhysics runs on a fixed timestep and can aswell be stepped manually.
2. As deterministic as it can get to say it the short way. However, no physics engine can be deterministic unfortunately. Not even PhysX and Bullet are. Objects are processed in a threaded environment, there is no fixed order in which they get processed. Furthermore, foalting point imprecision kicks in which aswell does generate some (even tho very small) tolerances. All in all, if you run a simulation twice, itll never be the same, itll always be a bit off from the previous one. You will aswell be able to experience this from unity's internal physics.
And yep, uPhysics is using floats.
3. Thats a good question, its fully up to unity. :/

Porting another physics based asset is just a matter of exchanging the unity components and method calls with the respective uPhysics counterparts.

Its coming, tho in another shape and form. Technically, Box2D is great and the support for it is awesome. What im planning to do is making the load balancing available for 2D and particles which will already push performance by alot. We gotta see if unity5 does run Box2D in a threaded environment. Since if it doesnt, itll be an option I'd definitely look into!

Well, I really really doubt it would. Not in a game which takes over an hour. Just the most tiny imprecision can cause all simulations to move away from each other and if I where you, I would not follow this route any further.
However, the solution is quiet simple, an authorative master server. As it seems you are planning to build a peer-to-peer game. In that case its most probably not a good solution for you to have a server hosted somewhere by you. However, there is another solution: Let a player itself host the multiplayer game. Other players just connect to it and the main player would be aswell be the authorative server. To take this idea another step further, you could split the actual physical world into chunks. Each player client would host a part of the simulation whit which all others synchronize on. (Multiple simulations is a feature of v2.2)
Tho, I've got quiet some requests regarding networked physics. I really should consider implementing a backend which makes synchronizing of networked physics faster/possible/easier.

Im sorry for the manual, its actually... quiet... obsolete and not up to date anymore. I should really remove the link until V2.2 arrives.
1) You would select the cube and add a uPRigidbody.
2) You can acctually find it in the manual. You simply need to add an event handler to the respective collider event and you'll receive it as soon as it is triggered. Tho, with V2.2 this will solve up big time since we now do have simple event/delegate registration via the editor.
3) Sure, im already working on my documentation content for quiet some time already.
4) The current limitations of the existing version are as follows (those I can currently think of!):
-No raycasting
-No trimesh colliders (The normal unity mesh colliders! uPhysics currently only supports convex mesh colliders which are generated automatically)
-No terrain colliders
-Missing some joints
-Stability issues since rigidbody dynamics was a bleeding edge

All of this issues have been addressed in V2.2.

5) There is no difference, at least not anymore. Previously uPhysics was a compiled version, means no source code but it was cheaper. Now, both versions are absolutely the same and both do carry the source code.

1) Colliders in uPhysics are aswell derived from MonoBehaviour, means youll need a GameObject. Tho, it is definitely possible to implement this via uPhysics primitive shapes which the respective collider components are just wrappers for.
2) Raycasting is currently not supported but in V2.2
3) uPhysics does automatically recalculate the collider for you. Of course it does it in a threaded way so you will not experience any overhead.
4) This, I will have to test but I doubt it wouldnt work!

 

Thank you for your reply and your advice! I am thinking of how to solve this, but there is still much I can do on the game without touching the subject of multiplayer. I'll lay in wait and see if an answer pops out. If it doesn't, I'll have to rethink a lot of stuff.

However, if you manage to make it easy to sync uPhysics over a network, or if you decide to somehow make it deterministic enough, I'll buy it the same day. I'll keep close track of the progress of this plugin.

 

Syncing over network should not be the real problem. Most networking solutions such as Bolt and uLink do this already by default. You just have to pick a place where the master simulation is run on which everyone is syncing.

In the end uPhysics (aswell as any other physics engine) just applies some physical behaviour to objects which, at the last stage, get fed back into the objects transform. Syncing does require nothing more than the actual transformes being updated via the network.

 

Hello,

I like your package so far but I am still trying to figure out how it works. I looked at the Movement script in the examples, and would like to Vector3Lerp the transform.position. Unfortunately, Unity tells me that I can only call the Time.deltaTime from the main thread. Is there an equivalent to Time.fixedDeltaTime for uPhysics?
Is this recommended at all?

 

Well, this is not simple to answer since your setup is not entirely clear.
Do you use a loadbalancer? If so, do you use the "OnLoadBalance" or "OnMainthreadLoadBalance" events to move your objects?

Either way, you can move uPTransforms like you'd move normal transforms. They will be updated directly or by a loadbalancer depending on your settings. You are aswell able to use unity's delta and fixed delta time depending on the method you use to move them. Either in each frame (deltaTime) or on fixed Update (fixedDeltaTime).

 

Say I have client side prediction for a networked game, would I be able to make multiple move positions, and collision checks for an object in a single frame?

For example:
My player starts at position A:
- moves forward
- bumps into wall
- turns around

and is now at position B

My game rolls the player back to position A and replays all the inputs in a single frame. Will the player end up back in position B?

 

So you are asking if the simulation does always carry the same results, so if its deterministic? No it isnt and it will never produce the exactly same results, there will always be a small tolerance and offset in which two simulations differ.

As of rolling back and replaying:
You can for sure roll back everything yourself by taking a "screenshot" of the state you want to go to. However, there is no possibility to calculate physics for just one object. You will always have to step the full simulation.

 

It didn't have to be fully deterministic, but for csp to work, I would need to calculate for one object. Would it be possible to freeze the calculation on all objects but that one object, and then step the full simulation? And can I step the full simulation multiple times per frame?

 

Well, there is no limit to stepping a simulation other than the time needed to compute the "step". Effectively you dont call "step" multiple times, instead you give it a fixed delta time with which the simulation should be stepped forward.
As of stepping just one object, its simply not possible since thats not how physics engines work. All objects get processed together and get their respective forces and movements solved at the same time in order for the simulation to stay consistent. If you wish to only step one object, you will have no other choice but to only move that certain object and leave all others static.

 

I'm not sure if I've been making myself very clear. I get that the physics simulation needs to process all the objects together, so I'm wondering if there is a workaround where I can freeze all objects in place while making the physics engine simulate just my one object that needs prediction. I'm thinking that's a yes by your last answer? If so, how difficult would that be?

The only part still not clear to me is if I can step the simulation forward manually. Say I need to step the simulation forward x number of times, I can call something that would look like Physics.Simulate(FixedDeltaTime) in a for loop?

Edit: I meant to tell you this sooner. I'm getting a 404 error when I'm trying to look at your manual.

 

A workaround would be to just move one object at a time, computing a step afterwards. However, thats only a feasible solution if there is just a limited amount of objects having to be moved this way.

Code (CSharp):

1. public void Step( float deltaTime )
2. public IEnumerator WaitableStep( float deltaTime )

Thanks for the report regarding the manual, I'll see whats the problem.

 

Sweet thanks for the quick response. One last question. I can't figure out the difference between normal version and pro version. They're priced the same, and it looks like they have the same assets listed on the asset store?

 

Thats correct, they are fully equal.
Previously uPhysicsPro was the source code version, uPhysics was a compiled version. However, that setup didnt make any sense therefore both version do now offer the equally same content.

 

What's the current status of version 2.12?

 

Its already quiet late on its schedule due to unity5 coming out earlier than expected. (Publishers had U5 Pro access for about a month already)
Currently we are getting uPhysics U5 ready and doing further optimizations which are now possible due to thread profiling.

 

Hi since U5 Pro has come out, do you have any conclusion for 2d improvement? or any specific plans ?

 

Yes, infact the load balancer is equally usefull on U5 as it been before. You might not have catched it but uPhysics 2.2.0 does implement the load balancer aswell for particles and 2D physics objects which should deliver a noticeable performance increase.

 

Oh..Sorry I though that it is still 2.1.1 b as it's what I found in the asset store, btw, where do I get the latest 2.2.0 ;D Thanks a lot ;D

 

Thanks for the update.

How likely could you back port some of the features into the current version? I am interesting in implementing a wheel collider, but I figured it would need certain features available only in the update.

 

Oh im sorry, thats not what I meant. 2.2.0 is the upcoming version and not yet live. :/

We are keeping unity 4.x support, the main release version will be 4.6 tho and thats acctually the recommended unity version due to nice updates like serializable delegates and respective editors.
So yes, uPhysics 2.2.0 will perfectly work with 4.x, 4.6.x and 5.0.0.

 

Note: I sent an email about my questions, in case you don't check here.

Hey there!

I'm currently making a Voxel Engine and using Unity's Mesh Colliders to fit each chunk. I want collision data to be handled entirely in the background, but I have to send the vertices/triangles to Unity on the main thread in order to create the collision data. When I do on large view ranges (10), I end up with this awful problem:



So I've been looking into rolling my own physics. I discovered I don't wish to take the time to have to code and maintain it, and instead looked for open source engines I could integrate and extend to fit better with my own game.

And then I found uPhysics here. I noticed that you don't provide the source code for it.

However, I'm wondering if you think that I could use this system for my game instead of Unity's. In other words, does it have features I could use to get better performance that Unity's engine lacks?

Essentially, I need:

1. Each chunk of blocks needs to register collisions with the player, AI, or other things that could run into it. Chunks are generated procedurally during runtime, and the collider must be able to match its shape. I need all chunks to register collisions, because events requiring collision detection could happen anywhere in the active world (chunks currently visible).
2. Collider has to change when modifications to the chunk are made, to match the modifications.
3. Preferably multithreaded entirely.
4. The only collisions that will happen are player/enemies against chunks. That is, chunks won't ever be able to collide with each other. I'd assume the engine would account for this, right?

If you think your engine will work for this type of use case better than Unity's does, I'll purchase it.

Thanks,
Jason

Edit: Took the time to read some more of the thread (didn't get a chance to read a lot of it before), and a few things to add:

-Is the code actually provided? I was a bit confused on that.
-Do you have a comparison of performance vs the updated physics in Unity 5?

Edit 2: There was actually a bug in my code, causing the performance shown in the picture up there to be so awful. I've brought it down to around 100-130 ms now, but it's still too slow for my liking.

 

Alright, given the clear lack of support here, I am going to move on. Thanks anyway.

 

Hello there,

Seems I've not catched this reply at all. In any case, the following might be helpfull.

uPhysics infact ships with the full source code included!

Collider interaction can be fully controlled by using unity's collision matrix. About fitting the shape's, this requires mesh colliders (TriMesh colliders) which are currently not supported but which will arrive within v2.2 of uPhysics.
In any way, I'd still recommend you to implement a special collider ontop of a standard mesh collider coming with uPhysics. This is due to the fact of chunks having quiet a huge count (I guess) and therefore having the demand of highly optimized collisions. I doubt chunks will move, they will just change shapes.
Furthermore, you should think about disabling and enabling chunk colliders depending on players and AI position which will save you critical performance cost.

Check.

This can acctually be archived in several way. Either use the collision matrix or treat the voxel terrain as a composite collider of chunk colliders. Parts will not collide but events will be triggered.

The definitely big advantage of uPhysics is its multithreading and load balancing capabilities. Not to mention that the full source is shipped and you therefore always have the choice to extend and expand any component or system you wish.

We've unfortunately not yet have proper performance comparisions towards 5.0, but the tests we did so far do still show performance benefits.

Since you've been bringing down your processing time quiet alot, there might be further space to decrease it. You should consider updating the acctual unity mesh collider only when a player/AI is up to collide with it.


Sorry again for the late reply and greets.

 

Sorry if that was rude. My intent was to help a community user to a relevant possible solution to his question, without having a look at the thread owner. Comment removed.

 

I've just seen your solution is open source and free. Seems I've been shooting to fast.

 

Hi, just want to ask if this version works in Unity5, or will it be compatible with the next update, thanks!!

 

Hallo there, it is compatible and we've been working the past couple weeks on increasing performance and systems especially for unity 5. Tho, those improvements will aswell reflect back on unity 4.x versions.

 

Thats great! any rough time frame on the new update release.