[RELEASED] uPhysics & uPhysicsPro

It's also not that

Doesn't PhysX 3.xx have like better features? or something

I odn't really understand a physics engine too much (other then, it allows for some effects...I think) it effects water and the sort, correct?

 

Ehm, no. Standart water is just static without any physics applied. Particle systems are what you mean probably. Yes they are aswell driven by a physics engine.

But the real job of such an engine is not to do fancy "effects", but to simulate the whole world environment in a physical correct way. As a few examples, by which you might get what a physics engine is responsible for. Assume two objects, a box and a sphere, moving towards each other. Do they pass throught each other? No they done. Why? Because physics engines calculate collisions/impacts. Now use triggers. Without a physics engine they would never sent an enter/leave/stay event. All this is done by the engine, checking for overlaps. Without the engine, there would be no balls rolling on the ground, no boxes resting on others, no walking on terrain/objects. Infact, your game would look good yes, but would be unplayable because youd just fall throught every stuff in your world.

For sure PhysX 3.xx has better features than 2.xx, but it doesnt matter as long as it aint run multithreaded/GPU threaded.

 

Oooohhhh, okay, thanks for explaining it. I knew it was important, but you know...didn't know why

Does to work with clothing objects? I see the Shroud Cloth Simulation in the asset store, but not sure if that's worth it or not.

 

Im not yet at the point to implement cloth physics nor particle physics. I acctually doubt that Ill ever implement support for clothing physics, since that just makes clothes look physically correct. Like moving in the wind in a fancy way. So Ill leave that to PhysX. However, particle colliders I will add for sure somewhen in the feature. You are, by the way, free to combine PhysX and uPhysics as long as you keep it seperated. If that makes sense.

 

okay, thanks for answering my question

 

Well, never mind

Maybe you know the answer to this too

What effect hair and clothes to get wet? Like if you watch the game The Last of Us by Naughty Dog, every time they got in the water, their clothes and hair got wet

 

Either by mesh animations (I saw some game devs doing that, prolly the worst attempt ever) or simply by particle effects. Thought, youd prolly want to tween the hair/cloth color so it looks more wet-ish.

Thats at least what I could think of now out of the box.

 

And I guess it would be the same with like blood stains (again, like in the Last of Us. they got blood on their hands and it would stain their face when they touches it) or a more extreme would be like...the reboot of Tomb Raider

 

Yes. Thats at least what youd do for 3D stuff on your meshes, using the particle system.

Furthermore, for effects targeting the camera, like rain drops in your field of few, looking like being right on your face youd use a screen overlay.
See this

However, thats a bit unrelated to acctual physics and the topic is drifting apart again.

 

Okay, I think I get it now

thanks for the help

 

Hey Sharp,

I wanted to get your thoughts on if you think your physics system would perform faster than Unity's given a scenario in my game.

I have a model of a tower that is pre-broken up into 40-50 separate objects. On each of these "pieces" of the tower, I have a mesh collider, and essentially break the tower up when it gets "hit" by a projectile. The physics system takes over, and the tower pieces fall to the ground while colliding with one another. It works great, except my games' framerate drops terribly when I collapse the tower AND I have a large battle going on at the same time on-screen. It gets really choppy, and I'm even running the physics solver iteration at a value of "3".

I was wondering if your physics system would help speed things up for my game, and maybe allow me to have a manageable framerate during those large CPU heavy battles. My game is largely CPU bound. What do you think?

 

Well, generally uPhysics performes way faster than Unity itself, given the fact that uPhysics moves every pressure from unity's mainthread to unused threads/cores, granting a nearly stable framerate to all times.

As of optimisations regarding unity's mesh collider system (which is infact slow), there are several options which may speed up unity.
- Most of the time, MORE solver iterations grant better performance since impulses and forces are better "solved" and therefore wont remain to the next frame in which they may cause unwanted behaviour or performance decreases due to additional operations needed.
- Make sure your parts are convex meshes! Solving convex meshes is way faster than using BSPTree's for TriMeshes (concave) objects!
- With so much mesh colliders, try not to use rigidbodies, or at least dont use continous dynamic collision detection.


As of now, the upcoming version will already advance available physics by a good notch. Most of the stuff unity covers, will aswell be included in that version. Though, to speak clear words, im already developing for like 3 months on this new version and I hate to keep people waiting for so long with existing bugs in recent versions, especially when they bought the product. But yea, im close to the acctual release of that version, thought, im not good at giving proper ETA's since I unfortunatly cant develop fulltime on this project.

However, as soon as the new version arrives, Ill have a proper backend to develop upon. Which means new updates/fixes/contents/additions will come in a weekly/bi-weekly timeframe.


As of your question, does uPhysics performe faster? Yes it does in close to every aspect by an order of magnitude.

 

Thanks for the reply Sharp.

I think I might try your system anyways just to see how it performs in practice. Of course, it depends on my budget though too.

Thank you.

 

Hi.

Can I create separete collision World in your physics and manually add colliders to it and do raycasts.
I want separate Collision World because in PhysX using collision Matrix in the same Collision World is not the case. It is wery slow.

This will be useful for Occlusion Culling solution using collision world.

 

Hi there,

Yes, in uPhysics you will need to set up a simulation area with respective bounds (multiple simulation areas are possible). Any collider/trigger inside the respective simulation will get added to it.

Raycasting is currently not available since the current active version is somewhat basic. Anyways, the upcoming version, to recitate my words, will have lots of new features including raycasting.

Anyways, I dont really get the last part of what you are asking. What do you mean by "PhysX using collision Matrix in the same Collision World is not the case". I dont see where it would be slow, filtering collisions acctually does increase performance.

 

Hi,
so for now not raycasting And about determinism: the math uses fixed point arithmetics? I don't know if this is related to your Physic Engine but it has some kind of feature to get ordered a dictionary (like a dictionary of Physic Objects)?

 

Hi there,

Yes for now raycasting is not available. Like I said before, the current version is rather basic. Thought, the next version will lift this up to a complete physics engine capable of replacing PhysX in close to every aspect.

As for determinism, collision and trigger results are consistent and will always carry as good results as possible. Most of the collisiondetection is done geometrically correct. However, some shapes easily cant be solved geometrically and therefore are approximated iteratively. ( Mesh collisions ) Those techniques are quiet common throught all the available physics engines on the market.

As for your question of an ordered dictionary. I dont quiet know what you mean by that. Do you want to fetch detected objects from triggers?
However, every collision/trigger event will fire a callback to inform your logic about the event. If thats what you are asking about.

 

If I have collision world with say 5000 static and dynamic colliders all of it belongs to "Default" layer and I have "Second" layer with only 5 colliders. In collision matrix I set do not collide between these layers so it behaves as completely separate worlds.

Everything fine but if I want to add new static collider into "Second" layer, in PhysX it will cost around 5ms because Entire Collision World have more than 5000 colliders and it will be rebuild for perfomance reasons.

If I have true separate Collision World for "Second" layer with 5 colliders, than adding additional static object will be cheap! That is what I want.

So the question: Can I create two, true separete CollisionWorld s in one place using your system?

 

Ok heres definitly some missunderstanding on your side of what you are acctually doing and trying to do.

PhysX uses one simulation in which all objects get added, no matter what acctual layermasks those objects use, since in the first stage layers dont have anything to do with collisiondetection at all. What you are doing now is specifing seperate layers to not collide with each other. You are not creating seperated simulations at all, you just specify the filtering to ignore collisions between those two layers.
Furthermore, when adding a new object to PhysX, it doesnt recreate the whole world, it simply adds the object to the current simulation and checks for consistency to fully include that certain object. The overhead you are facing is an O(n log n)/O(n2) (depending on case) behaviour of the broadphase used by PhysX, the sweep and prune algorythm.
Additionally, having seperated simulations will cause more harm than good. Consider layers which both seperated layers can collide with. Objects of that certain layer would need to be inserted into both simulations. Having those objects exists in multiple simulations will cause inconsistency in every single simulation and your physics will simply fail.

Thats a small summary of the technical details behind your problem, targeted at PhysX.


Now to your question, how does uPhysics behave.
First of, uPhysics aswell does only use one simulation at a time in a certain region of spacetime. This, in plain words, means that you can have multiple simulations, yes, but only in different regions of space. Simulation areas must not overlap/cover each other.
Simulation areas in uPhysics will all use the unity given collision matrix and you can therefore archive the same collision filtering as with PhysX, means seperating different layers to not collide at all.

Answering your question with no, you cant create seperated worlds in the same region of space, you can just filter collisions as you would do with PhysX.

Now coming to the good part, in uPhysics it is not needed at all to seperate simulation areas. Speaking plain words, when inserting objects into a simulation of uPhysics you wont have a 5ms delay, you wont have any delay at all no matter how much objects the simulation already contains. This is due to the multithreading, moving every pressure to seperated threads, making the mainthread have a stable and high FPS, and of course due to the broadphase, the hierarchical hash grid, which inserts objects in close to O(1) and checking them in O(n), instead of O(n log n)/O(n2), time.

As a summary, you just want to get rid of the overhead when inserting objects and you considered seperated simulations for that. Seperated simulations in one region are bad. However, uPhysics doesnt have any increasing overhead when adding objects so your problem is acctually solved at the root.

 

Thanks for quick answer

Second part of my need sid Reycasting. You say uPhysics do not support it now but in future it will.

PhysX have huge overhead when I raycast in this absolutely separate "Second" layer. in my game on iPad2 it is about 10ms.
If I remove all colliders from all layers except "Second" than raycasts become cheap.

I think in next uPhysics I can raycast in separate threadso this will no overhead but. If simulation in separate thread takes 100ms it will hurt too.

If I have simulation with say 100000 colliders and only 50 in separate layer and I do raycast in that separate layer, will I have overhead because of 100050 colliders in simulation instead of only 50 in separate collision world?

 

No, raycasting in uPhysics does aswell exploit the hierarchical hash grid broadphase and will therefore be solved in O(1) time. It just depends on how long the ray is and therefore how much objects it could possibly hit. Furthermore, you can either call the raycast right inside the mainthread or use the multithreaded version which does the job on other threads while letting you wait for it to complete via the coroutine pattern of unity.

Objects are culled if they dont need to be processed so no theres close to no overhead at all.

Furthermore, dont try to think of 100000 colliders not having any overhead at all. Such an amount of colliders will never run on any tablet/phone, no matter what physics engine you use. uPhysics is fast, by an order of magnitude faster than unity, but obviously still limited by hardware. Keep that in mind.

 

OK
Thanks. I have understood

 

Almost ready on the new release? Been keen for a while on this one :/

 

Yes, the new version is finally done. Im currently writing a completly new documentation manual and working on new example scenes plus the promised web player demo.
Depending on how fast I am and unity reviews it, the new version could be up by the beginning of next week.

 

Sounds awesome! cant wait

 

Since the new version will be online by next week, here's some input on what exactly it will bring, aswell as some additional meta data.


Content update's:

=> Colliders/Triggers
Theres now a whole new set of colliders, which include sphere, capsule, box and mesh colliders. Every collider can be centered, rotated and/or scaled depending on need. Additionally, every mesh collider can take three different shapes, which are the normal convex hull, kDOP shape (faster but less accurate convex hull) and so called convex decompositions which will split up the meshs geometry in several convex hulls for better approximation. TriMesh colliders are not yet supported but will be in short. (TriMesh colliders are somewhat costy anyways and I suggest not to use them at all)

Every collider, even mesh colliders, can be set to be a trigger.

Colliders/Triggers are NOT limited to one per object but instead you can have as many of them on one object as you wish. They will effectivly act as one collider/trigger. (Composite collider) Furthermore, every collider in a transform hierarchy will act as a part of a composite collider, just as in unitys physics.

Everything can collide with everything.


=> Simulation area
The simulation area is not longer bound to a power of two in each direction, but just to a multiple of a chosen main axis to preserve a grid of uniform sized cells. It is aswell possible now to allocate cells not only in x-z direction but aswell in x-y-z directions which will make the broadphase for games which use y way faster. Furthermore, some variable have been made public to finetune the performance, like further splitting of the broadphase on multiple threads and starting capacity of grids/cells.


=> Load Balancer
The load balancer has been fully removed from the physics cycle/simulation area and will now work as globally standalone. A custom transform hierarchy is build up, in which you can assign every transform to a different load balancer to ensure customizability. You will effectivly only operate on those custom transforms to move/translate/rotate/scale your objects. The load balancer will take care of splitting the move/rotate/scale over several frames and keeps your simulation up to date.
You can aswell chose not to use a load balancer at all.
The load balancer now integrates the functionallity of the previously called "MovementExecutor". Means you can register custom methods which will get executed right before any update of the load balancer happens. (To implement updatelike move methods) Those methods can be executed either on the main or on another thread. (Usefull since not every unity API call is threadsafe)


=> General General Physics
The former collisionmatrix is now entirly removed. The system uses the unity internal collision matrix now (The one you setup in the preferences) aswell as the internal gravity force. Objects are no longer restricted to move inside a certain simulation area, the can freely move around but will lose the effects of physics as soon as they leave their current area. (and dont enter a new one)
There are now three different collisionmodes. Discrete, Continuous and Continuous Dynamic. The standart colliders without rigidbodies will always use the normal discrete method which simply consists of checking the position at discrete timesteps (the physics cycle) and repositioning depending on collision.
The other two methods are only available for rigidbodies. They consist of counting in the current velocity, removing close to any interpenetration and tunneling, which results in more accurate physics.

Heightfields no longer need to be baked, they are created at runtime and can aswell be updated. Furthermore, gravity, collision below, slopes, etc are handled more gracefully.

Every event can either be executed on the current worker thread or on the mainthread. Collision events will now carry alot more information to the event delegate, like object data (transform, gameobject, position, rotation, scale) and collisiondata like contactpoints, contactnormal, interpenetration, etc.
You can register as much event methods to a certain collider event (OnCollision, OnTrigger, OnCollisionBelow) as you wish.
The system now aswell uses a solver which enables effects like sliding, bouncing, limits. (Joints will be included soon)

Theres lots of math, general methods, math components and snippets made available.

And of course alot more, considering the system has been flipped upside down.



=> Meta
- The framework is now called uPhysics (offically ;o )
- There will be a source code version on the asset store. Any pricing wishes?
- Webplayer demo will be up soon.
- The math namespace will aswell be uploaded as a standalone asset, for those who are just interested in it.
- Because of the namechange i will most likely create a new thread!


Greets

 

I vote100$ for the source code, or better the same price as it is ?

 

That somewhat is what I thought aswell. ;o The 100$, I mean!

 

Well done, sounds very impressive, cant wait to try it. 100$ sounds fair for the source.

 

How do you think this would work for an online multiplayer game involving buoyant ships that are carrying a number of people?

My requirements are:

• Deterministic movement for client-side prediction (feeding 20 forward inputs to different machines should result with the same output position).
• Moving platform support (to allow people to stand and walk on moving ships)
• A way how to get apply input and move your version of the Character Controller in the same frame PLUS get the exact transform.position after the input is fully processed by the 'character controller' (like Unity's CharacterController.Move()). This is so that I can replay previously inputted inputs in the same frame to apply server-sent corrections on the client.
• A nice method to have is one which teleports a physics object to a position in world-space but doesn't intersect with physics colliders to allow easy snapping on the clients when applying a server correction. Think something like CharacterController.Move().

Thanks a lot for your time and this plugin!

Btw, the link to the Manual is currently dead.

 

As of now, the tool is under constant and heavy development to get the most out of it. To be serious, this tool is still in its childhoods but im doing my best to deliver the best, to say it like that. Now that I uploaded the offical new version, 2.0.0, (which is btw still pending in the unity submission process, sorry for that guys!) I do have a proper backend to expand on. Thought, Im currently developing alone on this tool since I need my guys working on our acctual game. But yea, the next weeks will be awesome and im pretty excited since im planning some huge content updates. (Prolly coming in a week or two, at maximum)

Regarding your questions:

1) I may not get this straight but adding up two vectors produces the same output, no matter on which machine.
2) Like in any physics simulation, this wont work by default. (Objects are likely to roll off) But you can do it the common way, either set the players transform parent to the platform transform or use a joint. (Joints are near to come)
3) Updating the position happens directly as long as you dont use a LoadBalancer, which I highly recommend to use otherwise youll face a huge bottleneck. However, like in any other physics engine, physics gets processed lateron and depending on collisionmode and occuring collisions, the acctual position might change. However, fetching the event does the job. As of caching the positions for inter/extrapolation, thats not part of a physics engine and you have to do it yourself.
4) As of the next update, the behaviours will be split a bit in order to grant a better seperation between methods. This includes normal colliders being nearly unmoveable (but updateable) and rigidbodies being the main moving objects, simulation any aspect from normal moving colliders to acctual bodies with physics. (depending on your setup) When moving a rigidbody via transform.position or rigidbody.position, this is considered a port and wont intersect anything in line. ( !Disclaimer!: (Yes i have to write this) This is part and content of the next update! )


Hope that helps, Greets!

 

+1 for source code!

 

Source code package is aswell pending. ;o

 

Can you update the link to the manual please? Because I'd love to go through it before purchasing.

 

Yes, of course. It seems I've broken the link somewhen last week when I updated the manual.

The new version plus source code version is now available in the assetstore. Links and description will be updated in a couple of minutes on the startpage of this thread.

 

Hey, Sharp Development, looks like a job for you

 

Wow, I should really apply for that! Thought, my c++/c skills are only decent, not excellent. :/

 

I've just purchased the uPhysics Pro package but encountered some trouble when trying out the provided Performance example scene.

It seems there are two missing scripts which should be attached to the uPhysics object?

 

Wow this is funny... Was acctually fine when I uploaded it.
The two missing components are simply the uPSimulation and uPLoadBalancer components. Drag and drop them on that gameobject and itll work.

Feel free to message our support if there's anything more you want to ask/report.

 

Just to give you guys a few infos about the next update arriving next week. (Hopefully I'll do it till than)

The next version, 2.1.0, will have another few major updates:

• Full rigidbody dynamics
  • Mass
  • Inertia
  • Velocity handling with abitary forces/acceleration/impulses
  • Constraint backend
  • Global/local/single body force generator backend
  • Proper solving of islands
  • etc
• Rigid-Rigid, Rigid-Collider, Collider-Collider collision
• Fixes regarding hierarchy updating for uPTransforms
• SweepAndPrune broadphase, you can now chose between SweepAndPrune or HierarchicalHashGrid
• Better narrowphase dispatching for collisions and triggers
• Major rework of classes, especially shapes and physics loop to a more OOP layout
• MPR collision detection for better collision results regarding overlapping convex hulls
• Moved uPVector3/uPQuaternion to unity's internal types in form of extension classes
• Threading improvements
• Improvements to garbage collection via allocators and recycling of objects

As of 2.1.1, the version after the next update:

• Constraints
• Force generators
• TriMesh shape/collision
• Improved terrain collision via trimeshes
• Character controller

As a few sitenotes:

• In advance to the future update, I'll greatly enhance the manual
• More and proper example scenes / webplayer demo will come after this.
• After I completed the code commenting, Ill build up an API help tool (via Sandcastle)
• Anyone who bought uPhysics (the DLL version, former "EnhancedPhysics" ) until the 1. of Mai 2014 can receive a copy of uPhysicsPro (source code) for free. Just message our support with your invoice number.
• Anyone owning a uPhysics/uPhysicsPro copy can receive accses to the private dropbox project and therefore to the newest version without the need to wait for the asset store submission. Just message our support with your invoice number. (Takes effect after 2.1.0 releases)
• uPhysics and uPhysicsPro are both registered for 50% sales so watch out.

 

What's the status of the next 2.1.0 uPhysics update?

 

Pending on the asset store.

 

The new versions of uPhysics and uPhysicsPro are both now available.
Furthermore, they are both reduced by 50% for a limited time only!


Changelog:
.) Added dynamics
.) Added rigidbodies
.) Added constraints backend
.) Added force backend
.) Reviewed/Optimized colliders, added cached ones
.) Disabled terrain collision, due to major update (coming back next version with TriMesh collision)
.) Reviewed/Optimized uPTransforms
.) Greatly optimized LoadBalancer and PhysicsLoop performance
.) Optimized garbage production with allocators
.) Optimized multithreading
.) Added sweep and prune broadphase (now default one)
.) Optimized convex object collision (implemented MPR)
.) Added recognition mode for triggers
.) Rigid-Rigid, Rigid-Collider, Collider-Collider collisions
.) Source is now more OOP
.) Much more little details


As some performance sitenotes, the general physics cycle has greatly been reviewed and now runs on a way smaller timestep. Its approximatly 80% faster than before. Furthermore, the load balancing of uPTransforms has aswell been reviewed which now aswell runs on a fraction of what it used to run before!

Stay tuned!

 

Hey, loving your work! I have a simple little question Not today, not tomorrow, but pretty soon I'm gonna need a "heightmap collider" without the need for a Unity terrain in the scene (because there won't be any), and of course without generating a uselessly expensive (for heightmap collision) mesh collider.

Not sure if this is already in your package. Alternatively, perhaps the possibility via some uPhysics-defined C#/Mono interface (ICollider or something) to write custom colliders that only return a numeric or boolean collision info after they do their checks. Do you expose something like this? Advantage would be seamless plugging-in of custom/obscure collision-testing needs (such as a heightmap lookup with some interpolation algo of my choosing) with the rest of the system, all the other stuff like physics-materials etc. could still work and one wouldn't have to worry about this and simply write whatever crazy custom collider one needs. Of course I can code up my own "dumb" heightmap checker temporarily but much better to have a "real collider" that integrates with the rest of the physics, whether PhysX or uPhysics. And of course uPhysics would be the preferred choice then

 

So if I have other physics based assets, they will NOT work with this?

 

Brilliant works. But I am making 2D games, do 2D games benefit from uPhysics? As far as went through this thread, uPhysics seems to be powerful solution to replace physx. However if uPhysics also provide native 2d support, that will be very helpful.
Thanks.

 

@metaleap
As of heightmap colliders via terrains, those will be supported with the next version. Heightmap colliders depend on so called TriMesh colliders, which simply are the normal mesh colliders in unity. However, when done correctly and aswell in the multithreaded environment of uPhysics, there wont be much of a performance overhead and itll be still fast. Though, I dont quiet get what you mean by "a heightmap collider without unity terrain" since the collider needs to depend on some abitary geometric shape.

Writing your own collider is pretty easy. Its as simple as deriving your own collider from "uPCollider", implementing all the methods and giving back an abitary shape which derives from "CollisionShape" or "Composition". Thought, every part of the shape needs to be convex. Everything else the system will handle. Incase you own the source, simply look at the implemented colliders/shapes and youll pretty fast get the hang of it.

Theres of course way more to say but im currently on vacation.


@vidjo
As of any other assets, uPhysics does implement lots of stuff given by unity. Therefore, it should be rather simple to port any other existing packages to uPhysics as long as you own the source of those. Of course this is aswell some kind of situation depending.


@paraself
The system is layed out for 3D environments and gets its power from massive 3D simulations which it can properly speed up. In most cases you wont have a bottleneck in 2D games/simulations therefore there aint any 2D support currently. Thought, im planning to implement 2D components in order to support some future features.


Back to vacation.

 

Good to hear that you have plans to support 2D. Because basically what I am trying to make is a fluid-driven particle system. There are around 2 thousands of particles on the screen. In the current build it's very consuming to move thousands of particles in each frame. Is this possible to have some speed-up with uPhysics regarding this particular need?

Anyway yes or not, I'll purchase it ;D

Thanks for your prompt reply.

 

This case can be especially well optimized with the load balancer delievered with uPhysics. The load balancer effectively optimizes any transform calls by balancing the calls over several frames giving huge performance increases.

 

Hi, I've just purchased uPhysics and encountered some issues:

1. The dynamics simulation lacks stability and kinda jittery, even when load balancer and simulation time steps are at their minimum. Objects penetrate each other and slightly oscillate when standing on a perfectly flat surface

2. It's impossible for some reason to disable the load balancer - should I remove it from the scene and tell every transform NOT to use the load balancer, I get lots of exceptions for trying to modify localPosition from thread other than main.

3. In the sample scene modifying properties of flying spheres can eventually lead to GC crashing Unity, stating that too many threads are created.

4. Pausing Unity editor and using Step button causes simulation to perform HUGE steps, like advancing forward by several seconds.

My setup is quite simple - static box collider as a ground and two boxes.