[RELEASED] uPhysics & uPhysicsPro

Sounds good, but how has progress been? Over a month later I'm finally at a point where I'm beginning to actually need this

 

Rigidbodies should always be moved on FixedUpdate since thats aswell where they get handled. Therefore it makes little, acctually no sense at all, to use a load balancer on them considering FixedUpdate gets called only 5-10 times a second.
Furthermore, when using kinematic rigidbodies you can simply move them via the respective transform so the load balancer is already capable of handling this.

Though, I can for sure implement some kind of callback to notify when a certain transform is processed by the load balancer. However, you can already fetch this by subscribing to the uPTransform events.

The topic is not forgotten if you mean that. I've been heavily iterating over features making the simulation more stable aswell as bug fixes. I've aswell finished TriMeshes, just the acctual terrains need to be a bit enhanced.
There has been lots of stuff I've been working on lately, for example my batching tool I planned for a long time. However, expect the new version to appear within the next week or two.

 

I've been taking a few steps to clean up the submission pipeline a bit. uPhysics and uPhysicsPro are now effectively the same packages, both include the full source code!
This means that every uPhysics customer will now have free access to uPhysicsPro.

If this cause's inconvenience, im sorry. But hopefully it doesnt!

 

Super efficient physics sounds pretty awesome. How do your joints work? I've been playing around with physics-driven ragdolls following animations but the default Unity joints are too 'floaty' for what I'm trying to do.

 

Thanks for including the source code, I'll definitely buy uPhysics now.

But I still have two questions:

- Will uPhysics work with Unity 5?
- Will uPhysics still outperform the new physics engine from Unity 5?

 

+1

 

Hello there, its been vacation time so I wasnt to active over the last week, sorry for that. Give me the time to get everything sorted at home and I'll be fully up for any question right tomorrow morning.

 

Thats somewhat a vargue question. Technically, constraints/joints always work the same way or at least in a similar way. Tho, unity does not expose to much parameters of PhysX which could be tweaked to setup joints.

1) Yes uPhysics will work with unity 5.x. There might be two or three lines which have to be changed but no worries, I will care for that.

2) Thats a critical question and I dont know how to answer it since there aint a correct answer as of now. For sure the update to PhysX 3.x will bring huge performance increases to unity 5.x. There is aswell a new task scheduler which will enable funky multithreading I guess.
What I can say for sure is that moving objects via uPhysics and using uPhysics triggers/colliders will be faster. If its only slightly faster or if its still faster by an order of magnitude... Well... We gotta see when 5.x arrives. Tho, there will aswell be features included which will benefit uPhysics, im sure of.

 

I anchored a ragdoll (which was mimicking an animation using solely rotational forces) to a plane using fixed joints, so as to keep the ragdoll erect as it couldn't balance by itself. The result was that the ragdoll 'fell off' of it's feet, with the majority of the ragdoll laying half a metre away from it's feet, though the joint was intact.

I was wondering if your joints are better than the default Unity ones at actually keeping things fixed together, regardless of the external forces acting upon them.

 

You mentioned that in a previous update you added manual simulation stepping. I ran into issues when using the "Step" function, and noticed it uses coroutines, which (I assume) would make it not complete till at least a frame later. Is there a way to manually step the physics/collisions (ideally multiple times) in a single frame?

 

Well, that kinda depends and I will only be able to give a vargue answer on this. Technically, unity joints should be able to be setup with a certain treshold of possible distance. At least uPhysics constraints can (joints are not yet implemented). However, uPhysics constraints/joints are currently somewhat a bleeding edge and will most likely deliver somewhat unstable results, to be honest. Tho, this will be fixed in future versions.
Im still iterating on previously mentioned terrain and TriMesh collider stuff. :/

Technically yes and technically no. The physics loop is not run on the mainthread but on multiple other threads. The physics cycle obviously needs time which acctually always exceeds the deltatime one single frame lasts. So expect a physics loop to take several frames, therefore stepping the simulation multiple times per frame makes acctually little sense. Furthermore, as soon as you call Step, the simulation will be run but it wont finish immediately. So there will be lots of code executed in your mainthread before the step acctually finishs. Therefore you might aswell want to use WaitableStep and yield on it in order to continue your game logic on a finished step. (at least code which relies on physics).
As of the coroutine waiting at least to the next frame, I cant remove it since that certain coroutine waits for all physics threads to finish in a decent and clean way. Everything else would start cluttering code.

 

Can you provide any benchmarks to show the performance of this library compared to Unity's PhysX and BEPU?
BEPU is already a lot faster than Unity's PhysX and I'm wondering if it would be worth making the switch from BEPU to your library.


http://game-cloud.org/performance.html

Also, what is the difference between uPhysics and uPhysics Pro?

 

Well, there are unique systems implemented into uPhysics which give it the capability to make it even faster than BEPU. Considering BEPU not being integrated fully into unity and ofcourse sacrificing preformance for OOP design. However, to be frankly honest, as of now you will only use functionality when doing the switch to uPhysics. Im currently developing multiple projects and try to push every of those forward. You should definitly keep an eye on uPhyiscs since there is cool stuff coming up, aswell as new features like a native c++ integration and a stripped down version for triggers only.

As of what the acctual difference between uPhysics and uPhysicsPro is? Well, uPhysics was the library version and Pro was including the source code. By now, both are effectively the same, both do include the full source.

 

I bought uPhysics yesterday but I didn't expect that there is no basic functionality like raycasting. I would like to know when uPhysics will support raycasing and functions like OverlapSphere

 

Hello there,

Raycasting is infact not a "basic functionallity". It is not noted on the feature list either. If something isnt written down there, its save to assume it aint implemented at all. This does not only apply to uPhysics but to like all product descriptions. (At least when it comes to major functionalities)

However, the raycasting is already implemented since it does rely on the same systems as normal collision detection does. Therefore it will come with a future version, definitly. However, im currently lacking some time due to university, unfortunately. Thought, it wont be too long untill the next version will arrive so stay tuned!

 

Thank you for the info. I'm looking forward to it

 

As a subnote, I've been notified about unanswered e-mails on the support. It seems the spam filter of my provider has been messed up. So in case you guys sent a mail to our support, dont hesitate to contact us again, it should now work again!

 

Hello!
Can i use this physic's extension for small Physic's Based game for Mobile platforms, such as Android and iOS.
Or this is only for Cuda PC Cards?

And if i can. Do this Asset improve the performance of the project against the Unity Psysic's Engine?

 

Hello there,
Yes the engine works perfectly fine for mobile and it doesnt rely on Nvidias GPU acceleration.
The benefits and drawbacks need to be weighted of course. It will definitly speed up your physics and especially trigger based physics by an orde rof magnitude. On the other hand, rigidbody dynamics is currently a bleeding edge.

 

Does this allow for a custom 'tick()' so that I can rewind a subset of the world and re-sim it myself through scripting (instead of at the next FixedUpdate()). Also is the outcome somewhat deterministic?

If both are true then this will allow me to get it up and running smoothly with networking + client side prediction.

 

Hello there,

Yes you can step the simulation completely manually. However, "rewinding" in terms of turning back time is not supported. You can just step forward. But there is of course the possibility to take a snapshot of a certain area of a certain point in time and afterwards redo everything to that state at a further point in time.

As of deterministic. To be honest, no physics engine out there, and I really mean NO physics engine, is deterministic. To say it with other words, physics engine's simply cant be truly deterministic. This is mostly caused by different hardware and floating point arithmetics. Floating point results vary from machine to machine. Furthermore, its guaranteed that objects do not get processed in the same order again and again due to the highly multithreaded framework. (This will aswell be the case as soon as I implement GPU acceleration)
However, you will never need a completely deterministic physics engine. As long as the outcomes are close to equal in a certain tolerance its more than enough. (We are talking about fraction tolerances here like 20.000001 and 20.000002)
I hope this satisfies you needs.

 

Hello,

I would like to use uPhysics for a procedurally generated large planets environments, does it supports creating mesh colliders on real time without baking and fast enough (or at least on a background thread)?

Also is moving, scaling or rotating mesh colliders is performance hungry in uPhysics?

Any idea about when Joints and Raycasting coming?

 

Hello there,

Pure terrain colliders and concave mesh colliders are currently in the works. Its aswell fully possible to add/remove them on the fly. Rotatingand scaling is of course costy, same as building one. But since uPhysics runs on mutliple threads, there shouldnt be any high noticeable spike/overhead on unity's mainthread. Repositioning and moving in general is fast and does not carry any significant overhead. Afterall movement is a key feature of every collider and should be optimized and fast as much as it gets.

Constraints are already supported. Joints are just the next step. Aswell as the basic backend for raycasting is already available, I just need to implement it. I unfortunately cant give a proper ETA, but expect it to arrive before the end of the year.

 

Sounds exactly like what I'm looking for. So i should be able to reposition an object, apply forces, tick() simulation and query the results directly?
Also how could I go about saying: tick() only this part of the physics world or specific objects?

With tick() I mean directly simulate it.

Also big plus that you're adding the raycast functions! keep up the great work!

 

Hello there,

Yes you are absolutely able to reposition objects. Tho, you have to distinguesh between positioning by forces and direct positioning. Furthermore, the repositioning will still work inside the current simulation. Means "teleporting" two objects into each other will still produce a collision while repositioning which will get solved accordingly. (Even tho that might have been the state of the snapshot youve taken)

As of directly querying the results. As you might have figured already, thats not possible. At least the "direct" part. The physics engine needs time to process the step. Smaller steps will result in less computing time. However, Step() can be used as coroutine so you can yield on it untill the step has finished. The raycasting system will use a similar attempt. Thats needed because of multithreading btw, to keep stuff consistent.
Just as a sitenote, you can fully controll how much time should be stepped.

Coming to multiple worlds. uPhysics runs under one main world in which everything happens. However, seeing that multiple worlds have been requested a few times now, it might be worthwhile for me to implement it. There is lots I plan to do and lots of great stuff to come.


However, on another topic just to point towards a "feedback" I've just received: https://www.assetstore.unity3d.com/en/#!/content/17419
Im fine with constructive criticism, but not with flame posts. Im quiet interested in the overall opinion regarding this topic.

 

About the review: just saw it and was in the same boat as you. It's written in bad english and the feedback is unclear, I was thinking about reporting it myself as well. Reviews like that whether the product is actually any good or not don't do any good to the asset store. Reviews should be fair, but above all clear and constructive.

About the manual stepping: What's the difference between a manual tick() and the normal physics if I would still need to wait for the updated physics over time? Or at least what is the use case?

Basically what I'm looking for is a physics framework that will allow me to deal with client-side predictions & networking. So the client plays as normal but then gets a corrected state from 200 ms ago from the server. I want to go back to that state and re-apply the time-steps between then and now with the recorded user input and re-do each physics step to get the current corrected position. Could I do that with this package?

 

Hello there,

One could say the physics engine automates manual stepping. It effectively uses the Step() method itself to step the world forward, just automatically in a certain timeframe. You can do this all by yourself and fully controll it by disabling automatic stepping which will let you fully step the simulation with the time you specify. The usescase of manual stepping is, that you can a) use your own times which should be stepped and b) to step the simulation when you want it and not when the physics engine wants to.
As of waiting, there unfortunately aint a way around this. The physics engine needs its time to calculate the new state, there is no way it could possibly knew the future just out of the box. That would make a physics engine pointless.
But dont get me wrong, depending on the collision and object count, we are talking about a few milliseconds, if at all.

Coming to your usecase, yes thats definitly possible. Multiple worlds would be a big help here tho. I will definitly look into it. However, unless your user is hacking/exploiting, its save to assume the state of client and server is consistent and close to equal. A simple extra and interpolation should do the trick. Using such a costy attempt to get a consistent state might eventually bite your back. :/

 

Not sure what you mean, but there wouldn't be a way for the client to interpolate to the correct current state, because all states the client will get confirmed from the server will be in the past because of the ping (delay in the messages). This means that the only real way to smooth towards the confirmations from the server is to use the state from the server that is in the past and re-apply our changes (that would be the user inputs and the physics ticks) to update the current state and thus the current output. I think having a small threaded delay wouldn't be that big of an issue though I'll have to see how that could work with networking.

I'm currently prototyping with networking package Bolt which works really nice. I have posted on that support forum to see if they see any issues with combining these two packages based on how you're saying that it works. It'll definitely make things harder if there isn't a way to directly update the sim and instead having it queue up. Especially on how this would respond to the user changes if perform multiple steps (with Step()) after each other and get their individual results.

 

Hello there,

In common game movement, the player character has always the current up-to-date position. The server just does checks on it wether its valid or not. Depending on the result, the client gets corrected up to the time the server could check and validate and user input gets reapplied. The most simple approch therefore is to lineary interpolate the discrepance of server-client over a small timeframe.
For player characters of others, you should use extrapolation which guesses the further movement of an other player which gets afterwards corrected by the server.

To get to the point, there are other, cheaper ways to archive a consistent state. You dont necessarily need a physics engine to do so.

 

Hi I bought this a while ago and just got around to giving it a test. Am I doing something wrong, as I made a simple scene where a large number of spheres drop into a open box like area(basically testing with gravity , uPSphereColliders,uPRigidbodies and uPTransform), and the bouncing that they exhibit seems somewhat unnatural, with a lot of erratic bounces. Should I be configuring some settings somewhere?

 

Hello there,

You can refine behaviour depending on your use case by tweaking the options in the uPSimulation component. That will give the simulation a bit more stability. However, rigidbody dynamics is generally hard to get fully stable. Fortunately, the next version will solve up most of the stability issues.

 

Thanks, Im looking forward to it.

 

Your asset sound very interesting to me....

I am working on a prototype that makes heavy use of physX, and I see that PhysX is a notable performance hog in these situation. I would love to replace it at one point with a more performant physics engine.

Now, I do heavely rely on Wheel colliders (which are so limited that I am not sure they are worth the hassle, but anyway), as well as on raycasts.

Does your physics engine as of now support these two features? If not, are there ways / tutorials that show how to get similar functionality out of it? Is it a good idea to mix your engine with PhysX? If these features are not supported yet, any ETA?


Thanks

Gian-Reto

 

Hello there,

Wheel colliders are not supported by uPhysics, unfortunately. They are quiet some PhysX special type of collider which not many physics engines implement at all. It might somewhen arrive but dont quote me on that since as of now I've not looked into it.
Raycasting is currently in the works and should arrive somewhen next month along with alot of other new features and fixes. This includes better interoperation of PhysX and uPhysics aswell. However, stuff is seperated and will stay seperated. uPhysics cant collide with PhysX colliders and vice versa. (Tho you always have the possibility to attack both a uPhysics and a PhysX collider on an object!)

 

I guess it wouldn't be to hard to implement wheel colliders myself as soon as raycasts are available in uPhysics, right? After all wheel colliders are not much more than glorified raycasts... and seeing all the shortcomings of the PhysX Wheel colliders, I might need to code my own version anyway.

Any ETA for raycasts in uPhysics? Can you already make an educated guess how the performance of raycast in uPhysics will compare to the physX version?

 

Hello there,

Raycasts are currently in the works and planned to be included in the next major update. The update is planned to be released around christmas/new year. Either a few days before or a few days after. Thats as close of an ETA as I can give, unfortunately.

I've been lately looking into wheel colliders aswell. I've been finding open source solutions especially for unity so I guess itll be simple to migrate such one. Tho, I will rewrite it to be extendable since yea, its always great to be able to integrate own logic on top of something like that.

Performance is always a topic which is hard to break down. uPhysics in general already delivers a performance way better than the integrated PhysX solution due to shifting work to other threads and general load balancing. This will aswell be the case for raycasting and as a result raycasts will be way faster and less polling than the current system in unity.
Generally speaking, there will be no load on unity's mainthread when executing a raycast since it is handled externally. You will just execute the raycast and wait for it to finish via a coroutine/callback.

 

if you plan to integrate wheel colliders, maybe just some input... what I find really lacking in the current PhysX ones:

1) The known problem: no interaction with the normal friction model. While the fact that the normal friction model is assigning a single friction "value" to the whole object is a problem with terrain, this is easy to fix just for the terrain by replacing it on the fly with other value depending on the splatmap.
With the current PhysX solution, you have to build a second system of friction "values", for ALL objects in the scene.

2) The not so well known problem of the wheel colliders not really reacting to slopes! This was driving me mad at the beginning, I had to build a complex system that lowers friction, reduces torque, and in the end also introduces additional drag based on speed and height differences between the wheels.
The wheel colliders themselves will more or less ignore slopes and never lose grip because of it. So you get completly unrealistic behaviour as soon as you try to create an off road style game.

3) The general friction curve model is not so ideal. Somehow you never quite get the behaviour out of it you are looking for. An easier to understand model with more finegranular control would be cool, even though I am not sure how to create that at the moment.


About the raycasts: is there any additional cost in your system when creating lots of short ranged casts vs less, but longer ranged ones? Or is it too early to tell?

 

This sounds great, definitly, and I will make sure to tackle those problems as soon as I implement it. Thanks for the feedback!

As of Raycasts. Yes, starting lots of raycasts has the overhead of triggering multiple raycasts, of course. But to tackle this problem Im implementing a kind of "batch raycasting" with which you can effecitvely start multiple raycasts at once and yield on them. The real problem is more the coroutine pattern used. Coroutines by default wait at least one frame. Waiting on multiple raycasts sequentially in one method will consume several frames, doing it parallel in decoupled code not so much. However, tackling this, a batch raycast does the job aswell as internal logical batching.

Whether to chose long or short raycasts does not matter as much for you as an end user. Itll work and you wont experience any performance different on your site. However, work is shifted on worker threads external to unity's mainthread and those will experience a greater load when executing long raycasts since more objects need to be checked for intersection. But really, it aint much of a problem and performance penalty.

Tho, just as a sitenote, there are already plans ongoing to GPU accelerate the system where possible which will give another huge performance benefit.

 

hi, will this work in unity 5?

 

Hello there,

As of now I cant tell if it will work or not. This can be only accurately answered as soon as 5.0 is publically available. There might be some internal code breaks due to code refactoring in the unity API but those will be addressed in a hotfix as soon as 5.0 arrives.

Long story short, any appearing code error will be addressed directly and uPhysics will therefore work with unity 5.

 

Hello,
is it possible to test your engine in a webplayer or at least watch a video?
Its a bit difficult to believe that a c# code (implicitly slower than c++ based Physx) can have so great performances..

 

I wonder how my scene would perform if it used uPhysics: https://www.dropbox.com/s/alce6pj6o4ps0l5/demoKIDpediaShapes.mov?dl=0

In my scene each shape has a script (https://www.assetstore.unity3d.com/en/#!/content/17528) that handles the 50 collisions when these numbers of shapes are spawned.

I really want to optimize my game and if uPhysics would reduce memory I'll buy it.

Does it work on windows phone?

Thanks

 

There currently is no video and/or webplayer demo, unfortunately. We are currently working on a major version update with which there will be a webplayer demo, API help files and a new manual. Hopefully, that will satisfy your needs.

As of performance, there are several limits supplied by PhysX. The old version used by unity is not optimized as much to run on the CPU, it does not get multithreaded and it aswell isnt GPU accelerated.
uPhysics on the other hand is written in optimized C# code (about 10%-20% slower than optimized C++ code), heavily multithreaded and aswell planned to be GPU accelerated in the future. Another factor is unity's transform and movement system which is greatly optimized in uPhysics by implementing an own multithreaded transform hierarchy which gets around costy matrix calculations in unity's core. Furthermore, uPhysics uses a so called "LoadBalancer" to move objects a fixed number of times a second, while balancing those movements over several frames. All this does deliver the performance benefit.

Hello there,

uPhysics is a replacement of the internal physics engine of unity. Im not quiet sure how the asset of yours work. Does it detect collisions itself or does it really on the 2D physics of unity?
Either way, uPhysics is a pure 3D physics engine. It does not make to much sense to run 2D scenes with a 3D physics engine, especially since Box2D is great and very performant.
As of windows phone, I cant say it for sure but there is no reason why it shouldnt work. Maybe someone around here who uses uPhysics might give a feedback regarding this topic.

 

Hi. Apologies if this has been asked before, but do you imagine there would be any problem with using uPhysics alongside another multithreading solution? Specifically, I'm looking at using something like Loom to offload work of creating procedural geometry at runtime and I'm wondering how much control over threading I'd have if using this with uPhysics.

 

Technically your OS makes sure for scheduling threads respectively. So, after all there is no problem in using other threaded solutions alongside uPhysics, especially on quad cores.
uPhysics only runs a fixed amount of times per second, doing some work and waiting for the next physics frame. So, unless you run it on a really really low end machine, theres plenty of time for other work to be done on the remaining cores.

 

Thanks! Just picked this up, looking forward to putting it to good use.

 

Hi,
Just bought this...got the following warning (Unity 4.6pro)
Script 'Joint' has the same name as built-in Unity component.
AddComponent and GetComponent will not work with this script. (Will the error effect anything?)

Also I've added a uprigidbody to a projectile, however it's not being recognized when i drag the gameobject to be placed on another script requiring rigidbody gameobject that I'm using.

 

Is this physics is deterministic.

Pls reply fast

 

Hello there,

I guess I've just answered your mail.
As of the problem regarding the name clash of the "Joint" component, this acctually shouldnt happen since uPhysics is using its own namespace. Did you change the namespace or something similar?

Im not quiet sure if I understand your second question correctly. So, you have a custom script which has a public field requiring a Rigidbody (a unity rigidbody to be clear)? Now you are asking why the script does not recognize the uPhysics uPRigidbody as valid input?
Well, the answer is simple, uPRigidbody is not derived from Rigidbody and is therefore not in any way connected to this type. Both are seperated components. If you'd change the type of the respective field to "uPRigidbody" it would work.

I've been answering your mail aswell, PhysX is already very deterministic. Due to the nature of physics engines, its impossible to create a truly deterministic one. But either way, the results delivered by PhysX and uPhysics are close enough. Under normal circumstances you shouldnt worry to much about it being fully deterministic or not.

 

Hi,
Is it possible to pre-calculate several seconds of physics? In my case I have a baseball game, at the time the ball is launched the fielders should start running to where they would be in position to intercept the ball, runners need to know how many bases to run, etc. So basically I need to know the entire trajectory of the ball at the moment it is launched. Is that possible?
Thanks!