Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

[RELEASED] uPhysics & uPhysicsPro

Discussion in 'Assets and Asset Store' started by Sharp-Development, Nov 14, 2013.

  1. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    The Destroy() method of a PhysicsObject aint the destroy method you know from other unity gameobject instances. It doesnt destory the gameobject nor the PhysicsObject, it just removes everything related to it from the simulation area it is currently running on.

    For the exit/enter thing, thats a problem unity got aswell, and its unfortunatly not that easy to archive. For the trigger exit event, im pretty sure I can add that. Though, enter on instantiation is another thing. Im not quiet sure if I can implement that in a decent way.

    But thanks for the suggestions, im definitly looking into it and note it on the list. ;)
     
  2. Ghoetam

    Ghoetam

    Joined:
    May 10, 2013
    Posts:
    6
    Hi Sharp Development,

    I have two problems right now with the library(using the latest version).
    First when trying to build a standalone player for windows I get this error:
    ArgumentException: The Assembly UnityEditor is referenced by EnhancedPhysicsSharp. But the dll is not allowed to be included or could not be found.

    The second problem is with the Mass PhysicsObject example. If I add _obj.InitializeCollider(1,1f,false,true); to PhysicsObjectAdvanced and increase the spawner to 20000 objects.
    It seems like the everything stops moving after some collisions. Unity still works like normals
    but the objects(Enhanced physics) does not move. Without adding collision everything works like expected.
     
  3. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Yes, I forgot that dlls need to be seperated in order to build properly. Unfortunatly the Editor.dll cant be included. This is top priority and will get fixed/updated within the next version. There will be another few nice options and improvements aswell.

    However, I was able to reproduce the collider thingy. Im currently investigating it. It might be that the collision update loop starts taking to long and therefore polls the system. Ill get it sorted out quickly!

    Btw:
    _obj.InitializeCollider(1,1f,false,true);
    -> The last "true" is not needed here, it only specifies if the unity collider should stay active. You arent using a unity collider so you can safely set it to false, it wont take any influence on the internal EnhancedPhysics collider.
     
  4. Ghoetam

    Ghoetam

    Joined:
    May 10, 2013
    Posts:
    6
    Thanks for the quick answer. Also I am wondering is it possible to bake the heightmap at runtime ? I am doing some random terrain so it would be helpfull if it could be generated when a level is loading? It would be even better if its possible to update it with some function like setheights during runtime like the unity terrain have. Do you think that is possible ?
     
  5. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Yes it is! I will aswell include it in the next version, aswell as more stuff to controll the heightfield overall and make colliders more walkable.

    As a sitenote though, baking the complete heightfield on runtime might get pretty performance heavy depending on size.
     
  6. Ghoetam

    Ghoetam

    Joined:
    May 10, 2013
    Posts:
    6
    Hi,

    I am wondering a general thing about how your system works. Using your Mass physicsobject example. Is
    it posible to change the _direction(making it public)(in the PhysicsObjectAdvanced.cs file) variable from another object
    that uses the unity update function ? The variable is used in the Move() function so will it be problems because of the multithreading ?
     
  7. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    No, it aint a problem. Theres literally nothing you could do from your site to break the multithreading so dont worry. ;)
     
  8. KarelA

    KarelA

    Joined:
    Dec 30, 2008
    Posts:
    422
    This plugins sounds wonderful. I am currently working on AI itense project and the calculating collisions are the biggest problem. http://www.youtube.com/watch?v=AwVmLTNwvOg
    I am gonna read through your manual and i will probably buy this plugin for my project. How is the webplayer demo going? Would love to see this thing in action :)
     
  9. Cripplette

    Cripplette

    Joined:
    Sep 18, 2012
    Posts:
    66
    I don't know if you knew it but :

    // It is faster to move the rigidbody directly if we have one.
    if (_rigidbody != null)
    _rigidbody.position = finalPosition;
    else
    _transform.position = finalPosition;

    Did you move the transform directly in your tests or the rigidbody ? (Just asking).

    Otherwise I will keep your asset in my favourite, and If I need to boost the collision/trigger detection, i will take a look at your solution. I only use unity physic engine for this.

    Regards
     
  10. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    I began the webplayer demo but I, for now, put it back on wait. Why? Well, im currently preparing a HUGE update which gives the system the generalization it deserves! The version will be called 1.2, however, contentwise it should acctually be 2.0 (maybe even 3.0, hoho)!

    This update, without telling to much, consists off further huge performance updates, SIMD support, more and generalized collider shapes, additional helper components, editor changes and my full exposed math/collisionmath with respective components! Oh, and due to the fact I dislike the current name (which sounds just eww) a rename will be processed to uPhysics. The update will aswell include the webplayer demo plus additional example content! So yes, stay tuned.


    Is this question directed towards me or Karel? :D
    As of me, I know how stuff works in depth regarding physics. So it doesnt matter if you move via transform.position, rigidbody.position or any other related method simply because they are all to huge considering the overhead it takes for one call. (Due to the c++/c# boundary and partly due to missing inlining caused by to large methods)

    Regarding your question, it depends on what mode you are acctually using. If you use the unity internal physics on a moving object, the rigidbody is moved directly in order for the unity collider to broadcast events. However, if you use the uPhysics internal collision system than just the transform is changed directly and the system takes care of any collision itself. Furthermore, stuff gets cached and reused properly which effectivly reduces the calls to transform.position (set) to one per movement / movement timestep. This ofc only happens if the object acctually moved and is aswell carried out over several frames via load balancing.
     
  11. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    I don't believe, that it could hold 5000 moving objects with 600 FPS. Does anyone have any proof of this (pictures for example) ?
     
  12. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    It moves 10000 objects with 300 FPS on my machine which is a 2.26ghz dual core. You better start believing.
     
  13. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    I may do when I see some screenshots. Well, anyways, if it is made some progress in this area, it is so nice to hear. Do you know if it can work with A* Pathfinder system?
     
  14. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Unfortunatly, I dont. uPhysics, with the new version, is just a wrapper around unity components which implements its own components based on unity. So infact with uPhysics you would have not just one SphereCollider from unity on your object but a SphereCollider and a uPSphereCollider. Depending on what you chose to get processed (unity collider or uP collider) the respective framework will be invoked. So infact you can either let unity process the collision or uPhysics (which will be way faster). In the end you call the same methods just on uPhysics components to let uPhysics process all your physics related stuff.

    Now it depends, is A* wrapped into a dll? If it isnt than you can simply exchange every call to a transform with a call to uPTransform and the uPhysics framework will effectivly do the work !
     
  15. primus88

    primus88

    Joined:
    May 14, 2013
    Posts:
    611
    Is there a webplayer for this?
    Anyone bought it and could offer some feedback here?

    I'm not ready to spend 61 euros on a plugin that offers me no way to test it.
     
  16. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Its 65 dollar which is equal to about 45 euros.

    The webplayer demo will be available as soon as I finish version 1.2. That will be in few days, prolly after christmas, and will put this framework on a whole new level. :)
     
  17. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    That's so great to hear that there is coming webplayer. I still do not understand fully how you achieve so great FPS. I tried with empty objects, containing just mesh (for example cubes) and which just move at constant speed. When I am generating them, my FPS is going down and at around 2000 objects it drops near 30 FPS (which is in my case several times greater as it would be with colliders attached. When colliders are attached I get like 4-5 FPS on 2000 objects). What is your FPS on empty objects (without any colliders, lets say containing just cube mesh)?
     
  18. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Here's a brief explanation of what the framework effectivly does and how the optimization works.

    -> What most people dont understand is that the UnityEngine.dll and UnityEditor.dll are just wrappers around the basic unity engine which is coded in c++. Any call to the UnityEngine API will result in the framework PInvoking the counter method on c++ side. This makes sense as long as methods are acctually doing calculations or performance heavy stuff BUT thats not the case for many of the methods. For example, transform.position (get/set) calls the c# getter/setter of the wrapper, which in turn PInvokes the getter/setter on the c++ side just to process one op instruction which in turn is setting the position or returning the position. Now you have to understand that c++ is fast, I mean very fast and c#, when properly done, can only archive down to twice of the speed. BUT this performance benefit is effectivly reduced to negative (which means c# is faster than c++) as soon as you perform a PInvoke on a method which does nothing more than to return or set one value which transform.position effectivly is. The PInvoke will cause way more overhead than it is acctually worth. Therefore, the system ports the position controll over to itself. That means my system fully controlls the position and just notifies Unity of the new position with transform.position. This reduces the costy call to transform.position to one per move request, instead of at least two in common cases. (get position, calculate stuff, set position) This is aswell increased by proper caching ofc.

    -> Update is called once per frame, we all know. Consider your game runs on 200 FPS, you really want to set the position of 5k objects 200 times a second? Doesnt make sense. The system moves objects only in given, updateunrelevant, timesteps which you can adjust. That means, setting the systems movement timestep to 0.05s will move objects 20 times a second which is enough to appear smooth. So infact, you could request a movement every frame (lets say 200), the acctual calculations and update for unity will only be done 20 times a second.

    -> Continueing from the point above, each timestep of the movement isnt carried out in one frame. That means, the system doesnt set the position of all objects in one frame. No. It load balances any position update. That means, it does the calculations and instead of updating the position directly, it splits the calls to transform.position in several chunks and updates the respective objects within the frames inbetween two timesteps. This still features accurate movement but increases the performance by a few notches. For example, your timestep is 0.05s -> 20 times a second, your FPS is 200. So inbetween 2 timesteps there are 10 frames. Instead of setting the position of 2000 objects in one frame, it sets the positions within those 10 frames. Which reduces the problem to 200 object position sets per single frame but still having all objects updated when the next frame kicks in!

    -> Additionally, method calls cause OVERHEAD! uPhysics implements the methods in a way to make sure they are inlined by the JIT which, again effectivly increases performance.

    -> Vector3 operations are slow! I dont know why, but yea, they are slow as ****. Therefore, the system unrolles them for its calculations, that means it used x, y, z components directly. Furthermore, the new version will do its calculations with SIMD!

    -> PhysX is a singlethreaded framework. Singlethreaded in terms of CPU. It is acctually meant to be run on the GPU to run fast. However, unity doesnt do that and therefore PhysX gets pretty slow. My system, infact, does every calculations right in place, with the optimizations mentioned above.

    -> Last but not least, the system is absolutly multithreaded. That means, any performance heavy task is pulled from unitys mainthread to another thread which effectivly increases performance and speed of the mainthread. Additionaly, it doesnt use one extra thread but multiple threads to process stuff in parallel as much as its possible on the target machine.
     
  19. MikaelTroc

    MikaelTroc

    Joined:
    Nov 2, 2012
    Posts:
    33

    I bought it. It basicly does everything "Sharp Development" says it does.
     
  20. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    Ok, I managed to get good results without any physics at all by using my own translate frequency (not based on Update or FixedUpdate). With 0.2s refresh I am getting around 60 FPS for 8000 and 47 FPS for 10000 units.

    If I include acceleration, I am getting 60 FPS on 4800 units and only 40 FPS on 8000. This does not include any other physics, just kinematic calculations, which I described for linear and rotational constant movements and accelerations. I am attaching script here how I implemented movement equations. I mentioned that FPS drops based on how much calculations I am including.
     

    Attached Files:

  21. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    After a small test, the question arises of what do you acctually want to do with this script?

    But from a first look, here's some stuff to consider regarding performance (you need to consider them when moving 10k objects):

    -> Update is a dynamic invoke, not a direct method call. Even if you are just carring out stuff every 0.2s, update will still get invoked every frame. Use co-routines instead. Start the routine in your Start() method and let it yield for the given timestep.

    -> The calculations you do are... heavy.

    -> Cache stuff, every instruction causes overhead you dont need:
    - (Time.deltaTime) cache it, its a property -> unneeded overhead due to method call.
    - (updatetime/Time.deltaTime) -> calculate it once every timestep, maybe even only once statically!
    - Mathf.Pow((0.5),powran) -> powran is never changed, 0.5f is static... calculate it once.
    - Mathf.Pow((updatetime/Time.deltaTime),1) -> why? Itll return (updatetime/Time.deltaTime) anyways.
    - .... more.

    -> You are calling Mathf.Pow !!!!!!46!!!!!! (if i havnt miscounted) times for each object... This should be considered a bottleneck. Let alone the call itself which will add up to huge costs. Not only that but Mathf.Pow is a wrapper around Math.Pow that means additional 46 calls -> 92 method calls. Now consider the work Math.Pow does... Consider this on 10k objects. This is leaking performance like a whirlpool blown up with a bomb.
     
  22. AndroidBebop

    AndroidBebop

    Joined:
    Dec 19, 2013
    Posts:
    7
    I am very interested in this, I'll be keeping an eye on its progress.
     
  23. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    You mean, that it could be better to put all this code which is inside Update() info Start() and loop it into infinite loop with my defined time step?

    Thanks a lot about these tips, that I can calculate constants only once.

    So you mean, that it would be better to call Math.Pow instead of Mathf.Pow ?

    By the way, I got interested, from previous message - you mentioned about c++ and dll files. I am actually working on Mac OS, so would this technique work on Macs?
     
  24. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    Well, I just fixed my script. Actually now the most complex model (5, which includes translation, rotation, vibration in constant velocity and acceleration) hold
    3000 units visible in scene, 6000 units invisible in scene for 0.2 s refresh at 60 FPS; and
    1800 units visible in scene, 2800 units invisible in scene for 0.05 s refresh at 60 FPS.

    I used infinite for() loop in Start() function, but not sure if it is the best way to do that. Let me know if it is good way, or there is another?

    This model (6) allows to construct any kind of motion available in nature. My equations reduced dramatically, but I still do not understand how you are able to get tens of thousands units running at acceptable FPS?
     

    Attached Files:

  25. KarelA

    KarelA

    Joined:
    Dec 30, 2008
    Posts:
    422
    Actually your framework costs 61 euros for me also. I think that Unity adds some kind of a tax for certain regions.
     
  26. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    @chanfort:

    Im not very good at JS since I really never used it. Im an old fart c/c++/c#/Java developer and therefore never felt the need of JS. Anyways, I dont know what JS implements but I know for sure that there is huge stuff missing right there. JS should be considered a prototyping language like python so I'd suggest you take a look at c# cause thats what you need to really code something, lets call it huge.

    You dont need infinitive forloops. What you do is technically just this:
    You could aswell do it right in your strat method by letting it return a IEnumerator.

    Your first "model"/type is equal to transform.position = newPosition;
    Acctually with proper vector arithmetic you dont need all the stuff you are doing there. The only real calculation you need to do consists of the respective vectors and set the position accordingly. Sth like newPos = _forward * _distance * timestep. Apply forces in the same way. Like newPos += _gravity * timestep. So I really dont get why you want to do such huge operations cause you can discribe pretty much everything in a way easier way.

    Furthermore, my system aswell archives such great performance since I just do the minimum and optimized calculations needed. And all this in a multithreaded fashion. While setting the positions for unity overtime and not all in one frame.


    For the others, the new version 1.2 will aswell has its price reduced while featuring a huge amount of new stuff. Its christmas! :D
     
  27. runonthespot

    runonthespot

    Joined:
    Sep 29, 2010
    Posts:
    305
    Hi there- is there any way to ask you some questions on this privately?

    Thanks!
    Mike
     
  28. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
  29. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    I am translating my code into C#. However I am dealing with problems, that I can't find any documentation about System.Math. There is plenty of documentation about this Mathf, but not System.Math. Where I can find it?
     
  30. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    MSDN is the complete doc for any .net class. However, you dont need that doc since Mathf is just a wrapper around Math. Mathf's methods do exactly the same as Math just with the easy difference of using floats instead of doubles. So looking up Mathf docs will essentially tell you what you need.
     
  31. chanfort

    chanfort

    Joined:
    Dec 15, 2013
    Posts:
    641
    so at which standard I can get best performance by using doubles (as from system.math) or floats?
    If doubles, how do you deal with vector3 as it allows to use floats?
     
  32. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Nowadays, especially on 64 bit systems, double is nearly as fast as float. So its up to you. Though, when you are doing extensive calculations, try to do them yourself. Thats at least what im doing. In terms of vector arithmetic it doesnt really make sense to use doubles since the typecast would add to much unneeded overhead. Oh and converting a double to a float and vice versa is called typecast. By default you can use floats as doubles but when using a double as float you have to do (float)yourDoubleVar;

    Oh and please, this thread is about uPhysics and respective questions and not a help thread for abitary performance issues. So id like to step away from this kind of "offtopic". If you like to continue this kind of conversation, please open a seperated thread or mail me. :)
     
  33. paraself

    paraself

    Joined:
    Jun 30, 2012
    Posts:
    139
    I am greatly interested in how efficiently your plugin works. Do you have any plans to fully extend it as a physics engine. Given that you have already implemented triggers, movements, it'll be good that if you add constraints.

    I was previously planning to replace PhyX with my own verlet integration system after having enough with PhyX performance issue. But I never realised what you mentioned above. I guess I could build my verlet system on your plugin if it's easily extensible.

    Anyway your solution is brilliant.! Keep it up. Do you have a roadmap?

    Best Regards
    Yves
     
  34. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Thanks for the kind reply!

    Yes, the upcoming version will target a full replacement of PhysX in a way faster implementation! Furthermore, the release after the upcoming one (so version 1.3) will feature "constraints". So infact every "joint" unity implements so far plus additional ones and bonus content to tweek the behaviour even further. :)
     
  35. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    This all reads great. Subscribing, wishlisted for now, planning to buy when that upcoming version comes out. =)
     
  36. thoorne

    thoorne

    Joined:
    Jul 22, 2012
    Posts:
    64
    I'm really interested in buying this. Also, as mentioned some other people i really would like to see some comparison tests.

    Currently i'm testing some large scale battles and i'm wondering if that script would improve performance in my project. I wanted to achieve wandering-like movement with a bit of randomness around the target.
    This is script i wrote in couple of minutes and i see some fundamental problems with 1k units onscreen.
    Script: View attachment $boidChild.cs

    Also there is web demo of how it looks in action: Click!
    Around 45 FPS with 3k boids on Macbook Air 2013 (i5, 1.3ghz)

    And there is pic of profiler window:
    $Zrzut ekranu 2013-12-30 o 13.43.43.png

    As you can see there are spikes when instructions like "myTransform.Translate" and "Quaternion.LookRotation" are executed, there is also a lot of overhead.

    And there is my question. Do you see a possibility to improve this script using your extension? I mean, if your movement instructions are better than transform.translate or rigidbody.velocity. I would like to see also some Quaternion calculations because as you can see they are not so fast.
     
  37. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Well, right here there is a bit of knowledge needed of how uPhysics and how unity itself work.

    I already mentioned and explained it in an earlier post, due to unity being written in c++ and us only being able to use the wrapper around this engine (namely UnityEngine.dll and UnityEditor.dll which are just c# wrappers around the c++ core) adds overhead, no matter what you do. You cant change that the PInvoke between c#->c++ does cause heavy overhead, thats a problem of .net. However, the acctual bad thing is not that the engine is a wrapper around a c++ core but infact that for ex UnityEngine is a PURE wrapper. Theres no logic at the .net side which kind of sucks since every simple getter which just fetches and returns a value (which could effectivly be cached on c# site) will cause a PInvoke.

    Another problem is that unity is a pure single threaded engine. I mean, thats good for thread safety but when it comes to performance heavy operations itll get slow. The best rule of thumb one can follow is that doing nothing is always better than doing something. However, how does this help to speed up things? Of course, you cant simply port everything to c# site, that wouldnt work because unity simply needs to know the meta data, for ex object positions/rotations/etc. But what you can do is reducing calls to unity to a minimum needed. For example, using only transform.position (set) and transform.rotation (set) while doing all calculations yourself plus keeping track of those meta will greatly increase performance. Effectivly only one call to transform.position_set is needed with this layout.

    Coming to your question, is uPhysics better in moving objects? It depends, but yes it is. The huge benefit you effectivly get is that uPhysics completly runs on its own threads, not the unity mainthread at all which greatly moves most of the pressure to other threads and therefore increases performance of the mainthread. Furthermore calls to the unity API are kept to a minimum and load balanced over several frames in order to get rid of those nasty spikes. All this is currently done by uPhysics itself when it comes to positions, rotations however, are currently not included and still have to be set by your own since most of the time, rotations are simply not needed for the calculations.

    But yea, one thing to keep in mind is that uPhysics, as the name suggests, is a physics engine to increase performance of physics and not a movement/pathfinding script. Therefore movement only plays a secondary role, thought, without doubt, theres no physics without movement.
     
  38. Lotho

    Lotho

    Joined:
    Feb 19, 2012
    Posts:
    9
    Waiting for the new version to be released before buying!! c'mon unity! also you did mention it was deterministic in a reply correct? :)
     
  39. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Correct, it is. :)

    Now that christmas and new year is over, I gonna have some more time to get the new version finally done. And by the way, merry christmas and a happy new year to everyone. :)
     
  40. Lotho

    Lotho

    Joined:
    Feb 19, 2012
    Posts:
    9
    Cant wait it sounds awesome! is the new version getting close to release?
     
  41. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Working hard on it and its getting pretty big! ;)

    Though, I hate it to let you people wait so long. Unfortunatly I cant update it in minor versions but have to do this major update to get the backend capable of the upcoming features after the new version. But yea, its definitly worth the wait so stay tuned!
     
  42. madrobotMK

    madrobotMK

    Joined:
    Nov 19, 2013
    Posts:
    17
    Bought! Sorry for the delay!

    Grüße aus Hamburg!
     
  43. KarelA

    KarelA

    Joined:
    Dec 30, 2008
    Posts:
    422
    How are things going? Do you have any updates about the progress?
     
  44. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Things are going well, the progress so far is huge. Im currently debugging and checking for robustness. Initially I wanted to post the changelog when the update is done, but it is taking way longer than expected. So for now here's what I got so far:


    Collider/Trigger shapes:
    - Mesh colliders are now available, 4 types are choseable
    1. Convex hull
    2. Composite convex hull (several convex hulls combined )
    3. kDOP hull ( more performance friendly )
    4. Composite kDOP hull
    - Box collider (AABB)
    - Box collider (OBB)
    - Capsule (oriented in any direction, any main axis)
    - Composite colliders (made from abitary primitives )
    (- Sphere colliders are were already available )

    - Triggers and colliders can have any supported shape

    Triggers:
    - Two modes:
    1. Other.Origin -> Perimeter
    2. Other.Perimeter -> Perimeter
    - Mainthread events now execute directly instead of in a given loop timestep
    - Execute Enter events when instantiated inside another trigger
    - Excute Leave events when destroyed while registered by another trigger
    - Every shape can trigger with every other shape


    Colliders:
    - Three different modes depending on collider type
    1. static - static
    2. static - dynamic
    3. dynamic - dynamic
    - Every shape can collide with every other shape
    - Proper collision data gets passed when collided
    -> Interpenetration
    -> Collision normal
    -> Collision points
    -> Collision time
    -> Cached references and position/rotation/size/velocity data of objects


    Components:
    - uPMonoBehaviour: Implements methods to directly interact with any given collider and uPhysics
    - uPCache: Holds loads of cached references (Requiered by default)

    - Colliders/Triggers now follow unity's collider style
    -> Colliders can be toggled to triggers
    -> Custom center offsets can be chosen
    -> Collider specific data can be adjusted ( Just as we know it from unity )


    Simulation(Area):
    - Axis dont need to be at a power of two anymore, main axis is freely choseable and others get refactor to any multiple
    - Fine grained controll over physics cycle
    1. List initiall allocations (objects in cells, objects in grid, occupied cells, ... )
    2. Load balancer for movement can be de/actived
    3. Grids can be further split onto more threads
    4. Local area gravity
    - Grid can be allocated in X_Z or X_Y_Z directions ( X_Y will follow for 2D based projects )


    Physics cycle:
    - Physics cycle now follows its timestep more accurate
    - Collisions now get resolved more realistic (depending on setting)


    MATH:
    - The whole math is exposed and useable from outside

    - Math primitives and components have been created
    - Common unity components (Vector3, Vector4, Quaternion) have been replaced with !SIMD! counterparts ( Yes the system DOES USE SIMD now )

    - Huge raycasting math class has been implemented
    - Any shape is raycastable with segments/rays

    - Huge common math class has been implemented ( Closest points/ distances from any shape to any other )
    - Huge collision math class has been implemented ( Collision of any shape with any other )

    - Collider types/shapes are now represented by mathematical shapes

    - GJK is useable from outside


    General:
    - Just to say it again, the system uses SIMD now (Mono.SIMD)
    - Unity collider support has been dropped
    - PhysicsObjects are deprecated
    - Heightfields are obsolete and dont need to be baked anymore. They are now created at runtime from heightmaps and updateable!
    - CollisionMatrix is obsolete, matrix gets created at runtime from unity's Physics settings

    - Way more detail stuff which would exceed the post limit



    I guess I missed some points and theres ofc much more to it in terms of details and stuff. But I guess for now this does create a good picture of what has been done so far!

    :D
     
  45. KarelA

    KarelA

    Joined:
    Dec 30, 2008
    Posts:
    422
    I am very exited about this and it looks like its going to be a "must-have" plugin for my library :)
     
  46. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Well this sounds all very promising but look forward to a clarification regarding:

    you know I think I'd only really buy-in to EnhancedPhysics if it could become/remain a "transparent, in-place PhysX drop-in replacement" such that I could toggle between "out-of-box physics" and "EnhancedPhysics" with all my other custom code remaining mostly unchanged or easily adaptable.. is that still part of the philosophy?

    I'm kinda trying to think "long term" here.. otherwise I'm always jumping back and forth every half-year -- "oh look a smart kid has a faster physics lib while Unity's has been outdated for a while now" -- "oh look, new Unity version has a faster built-in physics now" -- "oh look, a smart kid has an even faster physics lib again now" :D
     
  47. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    With all the new content coming in the new update, stuff will greatly improve. Since I changed the system over to go along unity's component style, code refactoring is nearly unneeded since uPColliders share the same properties. I would have liked to override unity's colliders to be serious, since that would have been the most awesome implementation but unfortunatly they are all sealed. But yea, code becomes even easier to adapt.
    Transparency is aswell given and increased since most methods and goodies the system offers are now properly exposed and documented.

    However, in the previous version uPColliders were able to recognise unity colliders and execute collision events on them. I tried to keep it and I was halfway done but stuff cluttered up and ended in a huge code mess. Overall, not clean. So I decided to drop the unity collider support to make our lives easier. But yea, unity collider support will aswell get obsolete since the system now implements everything unity does so far.

    Switching between unity and uPhysics is aswell easy and fast by the way, dont get me wrong. ;)


    Well, I of course cant say what unity does/implements in upcoming updates but I can for sure say that Ill keep up with it. As long as unity uses PhysX (singlethreaded and even multithreaded, doesnt matter) uPhysics will always be faster and the better approach. As soon as I get everything implemented and all the updates done which I plan, there wont be much consideration needed if to use uPhysics or not! :)

    And I hate it to be called kid!!! :evil:
     
  48. metaleap

    metaleap

    Joined:
    Oct 3, 2012
    Posts:
    589
    Hahaha sorry; well awesome, that all sounds reassuring, will keep this on my to-buy list ;)
     
  49. VataRaven

    VataRaven

    Joined:
    May 24, 2013
    Posts:
    180
    Will this cover Unity's slack with them refusing to update PhysX (from what I read we still use PhysX 2.xx, while 3.3 came out last year)?
     
  50. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Simple answer, yes. Unity would implement it single threaded again, which infact means no multithreading and no GPU threading. (And GPU threading is what makes PhysX fast) Other than that, PhysX is just some common physics engine, nothing special compared to bullet or solid, or w/e. ;)