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
    -uPhysics-


    uPhysics is a custom, selfmade, integrated and dedicated game physics engine for Unity3D. It's intend is to speed up the internal physics by replacing it completly. It archives its task by using extensive multithreading, moving any pressure from unity's mainthread to remaining cores/threads. This will ensure a stable and high framerate on the mainthread while still having proper physics. It archives speedups by an order of magnitude and is capable of moving thousands of objects at once.

    uPhysics will get alot of new features in the near future. See the "In the works" list for more details.



    Features
    • Highly multithreaded
    • Load balancing of transform components over several frames, increasing performance by alot
    • Rich set of collider shapes
      • Sphere collider
      • Box collider
      • Capsule collider
      • Cylinder collider
      • ConvexHull collider (Mesh)
      • kDOP collider (Mesh)
      • Convex decomposition collider (Mesh)
      • Automatic compound collider
    • Any shape can move freely
    • Any collider can be used as trigger
    • Rich math
    • GC friendly (Allocators)
    • Rigidbodies
    • Rigidbody dynamics
    • Constraints
    • Global forces
    • Many little snippets to be discovered
    • Fast!


    In the works
    • Joints/More constraints
    • Local and single/two body forces
    • TriMesh collider (Standard unity mesh collider)
    • Terrain collider
    • Bug fixes and tweaks
    • Raycasting
    • Multi simulation in one scene, not just one
    • Further stability, performance and memory improvements
    • Network syncronized/optimized physics
    • Decoupling of code, virtualization of objects so objects can be created/hosted from script without the need of an actual GameObject as host, dramatically increasing performance for server's and alike
    • 2D and particle load balancing
    • Native and GPU acceleration
    • Rich wheel collider and Vehicle API
    • Controller's (Character, Vehicle, ... )
    • Simulation rewinding/replaying/recording
    • Better event integration using unity's serializable events
    • Better convex decomposition for uPhysics AND Unity mesh colliders (Concave colliders)
    • Rope physics for uPhysics AND Unity
    • Destruction/Deformation for uPhysics AND Unity
    • Soft body physics (Cloth)
    • Inverse kinematic (Ragdolls and alike)
    • Raycasting/Physics in editor while not in playmode
    • uPhysics -> Unity collider interaction (Lets uPhysics colliders interact with Unity ones)
    • Demos/Videos/More documentation


    Changelog:

    2.1.1
    • Added cylinder collider
    • Added constraints (WorldPoint, Grab, Distance)
    • Added global forces (custom gravity, Motor (torque), singularity )
    • Added manual simulation stepping
    • Fixed editor stepping related bugs
    2.1.0
    • 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
    2.0.0
    • Reviewed full system
    • Added full set of colliders
    • Various mesh colliders
    1.0.0
    • Initial release



    Asset store packages:
    uPhysics / uPhysicsPro
    (Packages were previously seperated into library and source version. Both versions now include the full source code!)


    Manual (Deprecated)

    Support: Sharp.Development@web.de

    NOTES

    • Anyone owning a uPhysics/uPhysicsPro copy can receive access 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.
     
    Last edited: Apr 22, 2015
  2. Casto

    Casto

    Joined:
    Aug 14, 2013
    Posts:
    44
    Interesting. I'm a bit surprised that you can get such performance. A webplayer demo would be awesome to check that! Do you use PhysX like Unity does?

    How difficult/long would it be to integrate your solution in a project and make everything use your engine instead of Unity's one? For example, would it be easy to make a Character Controller using your physic system?

    What about mesh colliders? Is there any method to create them on the fly?
     
  3. Sharp-Development

    Sharp-Development

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

    As soon as I get the final touch done, I'll write a manual aswell as including example projects demonstrating every aspect of the framework.
    A webplayer demo sounds like a perfect addition, I havent thought of yet!

    No, im not using PhysX. Integrating it in a custom framework would carry the need of users having unity pro since PhysX comes in shape of c++ dll's. However, PhysX is not the ultimate physics library anyways. Its dedicated for extensive GPU multithreading to utilise its whole power, so it aint really suited for our single threaded unity. However, my system, like stated above, does make extensive use of CPU multithreading to get the pressure from unitys mainthread, in order to let it run more smooth.

    How easy it is to integrate this framework? Good question!
    Short answer: Very easy.

    Long answer:
    This framework implements own custom components, that means for characters and interacting objects (static environment colliders excluded). So, yes, theres no need for any unity internal component like character controllers. The system implements all of a character controllers functions by default in its own components.

    Implementing the system means several steps:
    1. Create a simulation area (or multiple) where your objects interact in. Those can be as big or small as desired. Specify the physics and movement timesteps of that certain area and, if you want to use gravity, bake a heightfield. That setup is done within a few clicks. ;)
    2. Every interacting object (for example your character controllers and trigger colliders/colliders, excluding static environment colliders) should be replaced with the internal component called "PhysicsObject". On this component you can then specify how the object behaves, either in the editor or by script. However, I will aswell implement a few minor functions to convert character controllers and trigger colliders/colliders to the system components.

    Technically, thats all. However, theres way more options to finetune the performance. For instance, the movement timestep of an area. That timesteps will move every registered PhysicsObject with load balancing each interval when that certain object has requested a movement.
    Requesting a movement, for example, means calling the "MoveInDirection"/"MoveTowardsPoint" method of that object.
    And for even further optimization, instead of requesting the movement in the update method, you can define MovementExecutors which will let you implement the systems custom update method which will be called with the movement timestep of the area. This happens on another thread all at once so you wont have the overhead of unity calling 5k monobehaviour - Update methods each frame.

    For environment colliders, they can stay as they are. The system will recognize any static environment collider on startup and execute collision events on them. However, for static environment colliders, only primitives are supported, that means box, capsule and sphere colliders.

    PhysicsObjects can use sphere or capsule colliders. Depending on need, you can let the EnhancedPhysics framework do the whole collision detection, or when needed otherwise, let the system use unity internal colliders. That means, when a collider comes in range, the unity collider will get enabled. However, by default, the system will do every range or collision detection related stuff itself when not specified otherwise.

    Coming to your last point, MeshColliders. Unity itself struggles with multiple MeshColliders, they arent really performance friendly at all. In most cases they can easily be replaced with primitives. So yes, the system doesnt support them and I unfortunatly doubt it will ever. :/
     
  4. Vincenzo

    Vincenzo

    Joined:
    Feb 29, 2012
    Posts:
    146
    First of all, WOW. You ran into it too.

    We ran into the same problem with our current development project, where first of all Character controllers are CPU killing if you have more than one, so we switched to rigidbodies with capsule colliders...
    This introduced a lot of problems to make everything look right and perform well..

    Then we ran into issues with general physics performance (which person at unity decided to run everything on the main thread?).

    I am quite excited to check out your work.

    A few questions.

    You said you don't support mesh colliders, none at all? Imagine a house, made out of destructable parts, and we destroy certain parts of the house on explosion for instance, these parts have (simple) meshcolliders, and we would def need to keep these so you can for instance fire through gaps in the building.

    these houses have no rigidbodies and are static colliders, we simply remove the house part on hit, and have client side effects to make this look nice.

    What is your ideas for this?
     
    Last edited: Nov 14, 2013
  5. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    I see the need in this case for a meshcollider. As long as they stay static it might not be a problem but let me go a bit indepth first.

    Without changing the system at this point I could definitly think of multiple ways to realize this.

    1. As long as you want pure collision detection, the mesh collider can be roughly rebuild with box or sphere colliders around the gap. So you still would be able to fire throught the gaps. However, this requires way to much setup.

    2. Objects like projectiles shouldnt be PhysicsObjects at all, only character, monsters, players, objects which move or interact like items on the floor, w/e. Projectiles are most of the time to fast to be actively handled by my system. So infact, I would let unity handle the projectile and keep the meshcollider on the house. That means those can pass throught the gaps. However, there would be no way a PhysicsObject could collide with the MeshCollider. So, my idea would be to implement EnhancedPhysics ONLY primitive colliders which would behave like unity colliders but only collide with acctual PhysicsObjects. So you could keep your MeshCollider, fire projectiles throught it but let PhysicsObjects collide with an internal collider by overlaying, lets say an internal box collider, over the MeshCollider. I assume that only projectiles should pass throught the gaps but a character shouldnt. Doors could be rebuild with method 1 above. Those enhanced physics collider could ofc be removed to any time. (Which would fullfill your need of removing parts of the house).

    Though, the idea of the internal enhanced physics colliders just for PhysicsObjects could aswell be done via internal unity colliders by specifing collision layers.

    MeshCollider and Projectile = Layer - Projectile
    Overlay box collider and PhysicsObject = Layer - World

    However, if the second solution aint sufficient, I might end up coding a meshcollider to primitive collider converter. ;)
     
  6. MikaelTroc

    MikaelTroc

    Joined:
    Nov 2, 2012
    Posts:
    33
    Seems very useful. Does it work with the Unity terrain ?
     
  7. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Yes it does.

    Though, you have to bake a so called "heightfield" for it. Its technically just an array of heights produced by raycasting from a certain y-position. So this heightfield technically represents the moveable height aka terrain heightmap.
    The nice addition with this technique is that stuff like ramps or bridges will be automatically included, no need to walk over those via "collided below" events but rather by default.
    The downside, though, is that, under circumstances, youll have to disable colliders like houses while baking. Though, theres alot of customizeable options how the heightfield should be baked to get around it. For example, layerbased or terrain collider only.
     
  8. MikaelTroc

    MikaelTroc

    Joined:
    Nov 2, 2012
    Posts:
    33
    Nice. Have you decided on price yet ?
     
  9. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Not yet, but I guess inbetween 40-70$.

    I am acctually hoping for some serious suggestions from the community. ;)
     
  10. smb02dunnal

    smb02dunnal

    Joined:
    May 5, 2012
    Posts:
    439
    This sounds pretty cool, but how optimized can you really make a physics engine in managed C#? Even unmanaged C# is no match for C++, and especially no match for assembly, which is what a lot of physics engines are made from.

    What do you plan to do that makes this work and different from the rest?
     
  11. RandAlThor

    RandAlThor

    Joined:
    Dec 2, 2007
    Posts:
    1,293
    Will this also work on mobiles now that they not only have one but two or quad cores?
     
  12. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Its not about what im planning to make this "work" since its already working like a charm for both, collision and range detection with the performance I stated in my first post.

    What makes it different from all the others? Its fully implemented into Unity, not to replace unity physics (which it btw can) but aswell to go along it so you can use both engines simultanous depending on need. Though, you would want to use EnhancedPhysics most of the time since its absolutly more performant then unitys PhysX implementation. However, from what I saw so far, not even Bullet wrappers can archive the performance of this system. Thats aswell due how most modern physics engines work, they use world lists of objects and compare all their AABB's for intersection. However, thats not really performance friendly at all. This system implements one of the newest strategies called the hierarchical hash grid. I implemented it dedicated for unity and pure collision/trigger detection with detector based triggers etc etc to enable highend culling and reduce acctual needed processing to a minimum.
    Furthermore, the bottleneck is NOT the physics itself. A proper system like this can speed it up a few notches, thats for sure. But the real bottleneck is the unity internal movement processing which will drastically reduce your FPS. So this system aswell implements methods to fully batch and load balance movement calls to unity, getting rid of update loops and so on.
    Anyways, the power aswell comes from extensive multithreading which moves all the real costy physics operations to other threads/cores and therefore gives the mainthread more air to breath.

    I was aswell kinda surprised when I first benchmarked the system but yes, its true, even c# can get as fast as stated above. You just have to push the right buttons.

    However, its already fast as a breeze. Though, I aswell already planned on providing a c++ dll in further releases to target pro users. This is of course currently not a priority since I want to provide this system to everyone.

    Sure, I dont see a reason why it shouldnt. ;)
     
  13. DigitalGlass

    DigitalGlass

    Joined:
    May 12, 2009
    Posts:
    88
    Woah! Question, can I use this for my own standalone mono c# server or must it be used with Unity? I current have BEPUPhysics running on my game servers, and integrated it into Unity for CSP, but what you have sounds more promising. This is a must have for me if I can integrate it with my server engine.
     
  14. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Just a question, did you ever considered using unity for your game servers? Theres alot of nice frameworks out there to realize proper and especially fast network communication and overall server/db handling. I can only suggest using uLink from MuchDifferent, im using it myself. The benefit is definitly the ability to use all the awesome stuff that comes with unity. ;)

    Now to your question.
    My framework will be provided in a dll. Easy reason, most fields are internally exposed via the internal keyword. In simple code I would have to make them public and possibly having users mess up their version with it. Btw, why making them "internal", easily to avoid costy getter/setter and methods. You unfortunatly cant always rely on inlining. :/
    Integrating it in a standalone version shouldnt be as hard. Though, I myself would need to rewrite parts of the framework and decouple it from unitys classes for you. This acctually only means replacing stuff like Vector3, coroutines, position-handling, start and awake. But yea, you unfortunatly wont be able to do it yourself. :/
     
  15. DigitalGlass

    DigitalGlass

    Joined:
    May 12, 2009
    Posts:
    88
    I have, and Unity is nicer for mmos, but not for instance based games such as MOBAs or FPS where you need a lot of separate game server instances. Each Unity game server instance has a lot of overhead, even when running without graphics. There may be clever things that can be done by using the same game server, and split network groups into virtual game server instances, but I'd imagine the management of doing it that way would be a nightmare.

    That's too bad that your plugin doesn't work out of the box standalone, if you ever decide to get it working for standalone game servers, I'll give it a whirl in a heartbeat(or if I work on an mmo that uses physics)
     
  16. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,437
    That sounds awesome :) The performance sounds superb.

    Can I use your physics system for say units, and then use Unity's mesh colliders on a couple buildings? So use both in the same scene?

    Secondly, is your physics/math deterministic?

    Thank you.
     
  17. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    You could do that but this physics system is currently not supporting mesh collider collision. See my post above for further reference.
    Though, this framework lets you chose between internal collision (for primitves which it will calculate itself) or on the other side with unity colliders which get turned on when a collider comes in range. With the later method, you would be able to use mesh colliders, though this could possibly get a bottleneck for you if done on to many objects. In most cases you can replace stuff with primitives and that should always be the goal to get rid of meshcolliders which are rather costy.

    Deterministic? Yes it will and should always behave the same. ;)
     
  18. Olafson

    Olafson

    Joined:
    Aug 7, 2012
    Posts:
    255
    Yeah. It sounds pretty great, the only problem I see for our game, as Vincenzo already explained above, is that we can not use any mesh colliders.
    Usually not a problem, we are not using mesh colliders anywhere unless really needed, but setting up our destructible Buildings with primitives is going to be a pain.

    I guess you know what we mean, but for better visualization, I made a quick drawing in Paint.
    Red is the primitive collider that would fit the most, black is the actual model of the destroyed brick wall piece.




    Now, that is obviously not feasible, at all. So one could set them up like the yellow colliders.
    But that would be a pain. Some of our larger buildings consist out of hundreds of those pieces, and setting them up by hand would not be feasible.

    Then again, We would only need mesh colliders for bullet hit calculations, which we are currently doing with raycasting, so we could maybe make that independent from your System? As you said before, using mesh colliders for bullet stuff, and using your primitive colliders for player - building collision.
     
  19. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    That would be the way to go since you can fully combine unity physics and EnhancedPhysics physics at once. That infact means you could set up your meshcollider on collision layer A, so only bullets can hit it while PhysicsObjects driven by EnhancedPhysics react to a primitive collider of layer B. The static primitive collider could be a unity Box, Sphere or Capsule collider.

    Just as a little note, EnhancedPhysics uses the unity collider primitives for static object collisions.
    As another thing to note is, that you can aswell set up a EnhancedPhysics driven PhysicsObject to respond to MeshColliders. This works by specifing that object to use a unity internal collider. This means unity will do every collision detection again instead of EnhancedPhysics. Furthermore, that unity collider wouldnt be always active, but gets enabled/disabled by EnhancedPhysics to increase performance.
    You can aswell fully change the behaviour on runtime on your needs. Its as simple as calling a method to switch from unity collision to EnhancedPhysics collision and vice versa. ;)
     
  20. MikaelTroc

    MikaelTroc

    Joined:
    Nov 2, 2012
    Posts:
    33
    Any news about when it will be released?
     
  21. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    I still have to stick with the sentence "within the next few days". Unfortunatly writing a manual takes longer then I initially expected. Though, I aswell was a bit busy the last days, implementing a few requested features. Theres not much more left to be done for the release.
     
  22. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    The package is, by the way, currently pending on the assetstore!

    The manual can already be read under: Manual!
     
  23. madrobotMK

    madrobotMK

    Joined:
    Nov 19, 2013
    Posts:
    17
    Gratz! Waiting for it!
     
  24. TriplePAF

    TriplePAF

    Joined:
    Aug 19, 2009
    Posts:
    246

    Is this asset already released? It was this morning inside the Unity Asset store RSS feed but got later removed somehow.


    Kind regards,


    Peter.
     
  25. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
  26. TriplePAF

    TriplePAF

    Joined:
    Aug 19, 2009
    Posts:
    246
    Purchased!
     
  27. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Thanks!

    On a sitenote, please keep in mind this is the first release. So if there is any idea for improvements, questions, errors/bugs aswell as additional content you wish to see, let me know! :)

    Theres already a todo list for the next version which will mainly include documentation additions, further options to seperate how physics cycles should behave (in terms of threading) and aswell some more meta data properties on PhysicsObjects to pull some more (maybe usefull) data.
     
  28. MikaelTroc

    MikaelTroc

    Joined:
    Nov 2, 2012
    Posts:
    33
    Hi,

    I get this error when testing out sample 5. Mass PhysicsObject test

    ArgumentException: Destination array was not long enough. Check destIndex and length, and the array's lower bounds
    System.Array.Copy (System.Array sourceArray, Int32 sourceIndex, System.Array destinationArray, Int32 destinationIndex, Int32 length) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System/Array.cs:977)
    System.Array.Copy (System.Array sourceArray, System.Array destinationArray, Int32 length) (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System/Array.cs:936)
    System.Collections.Generic.List`1[EnhancedPhysicsSharp.PhysicsObject].ToArray () (at /Users/builduser/buildslave/monoAndRuntimeClassLibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:593)
    EnhancedPhysicsSharp.PhysicsSimulationArea+<ProcessObjects>d__5.MoveNext ()
     
  29. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    I investigated the error. Its a typical multithreading error. I unfortunatly missed a lock. Depending on how fast unity processes version updates of assets in the assetstore, the hotfix might already be up today. Ill aswell include some in-editor help documentation updates.

    Sorry for the inconvenience.

    //E: The hotfix is by the way pending.
     
    Last edited: Dec 6, 2013
  30. MikaelTroc

    MikaelTroc

    Joined:
    Nov 2, 2012
    Posts:
    33
  31. TriplePAF

    TriplePAF

    Joined:
    Aug 19, 2009
    Posts:
    246
    If it is as good as other German Quality Equipment than I don't worry!

    Oh and please consider to sell Source Code Licenses on Request. I personal will be more then happy to share all my improvements with you. :)

    Peter.
     
  32. silentneedle

    silentneedle

    Joined:
    Mar 14, 2013
    Posts:
    280
    Could you please release a pro version without a DLL or including all source code? I would definitely buy your script then as we're already using uLink (we love muchdiffernt too :D).
     
  33. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Its currently not a priority for me to upload a Pro-Package of this asset, im afraid.

    There are valid reasons it is packed into a dll. And yes, not the common abuse/steal reasons but infact performance and code security points! The framework massivly relies on fast variable accses without getters/setters or additional methods which will ALL add major overhead. When building for a dll, you can expose all the needed variables as internal, accses them fast in your framework code but still have the ability to secure them from being messed with from the outside. Which infact is whats needed for this framework since its sensible when it comes to users messing with internal variables from the outside.

    Im using this framework aswell in my MMO, I power my server with it and do first pass collision detection on my client with it. Therefore, this framework is constantly developed and any feature you might want to see can be implemented. It would just take a mail.
     
  34. silentneedle

    silentneedle

    Joined:
    Mar 14, 2013
    Posts:
    280
    Could you tell me more about the workflow of moving - as example - an npc?

    When reading the documentation it looks like I've to set the IsMoving Flag to true and calling one of the two Move functions. But how can we control the speed?

    You've also wrote that Y is being used for gravity and only X and Z are moveable. Whats about letting an npc run up or down a hill?
     
  35. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Sure. The IsMoving flag just determines if an object can move at all. It doesnt take any further influence. You would, for example, want to mark dropped items or something like area/region triggers as not moveable.

    Speed can be fully controlled when using one of the three collision processing move methods. The Position property can aswell be used to set the position but no collision will get processed, its considered a teleport. Therefore the following three methods are "collision processing move methods".

    Vector3 MoveInDirection( Vector3 direction, float distance, bool processInstantly )
    Vector3 MoveTowardsPoint( Vector3 directionPoint, float distance, bool processInstantly )
    Vector3 MoveToPoint( Vector3 point, bool processInstantly )

    For example, when using the MoveInDirection or MoveTowardsPoint method, the distance itself is the speed.
    distance = UnitSpeed * Time.DeltaTime or movementTimestep;

    MoveInDirection uses a normalized unit vector (direction) whereas MoveTowardsPoint takes a point in worldspace towards which the object should move. With MoveToPoint you can directly specify the point a object should move to. This can come in handy if you want to process stuff yourself.
    Every of those three methods can be forced to be processed instantly, that infact means they will instantly calculate the new position and aswell return it. Collision detection will take place aswell. Otherwise the movement will be calculated in the next movement timestep of the respective area. However, you would only want to use this for objects which need more moves within a second, for example the player character itself to make it appear more smooth.


    The sentence "only x-z axis are moveable" is a bit missleading in this case. It doesnt mean that only on those axis can be moved, it rather means that an object should only be able to move on the x-z axis on player input. That means forward/backwards/left/right. The player shouldnt have a button or choice to move in the y direction. However, it is still supported and if needed you could aswell let the player move on the y axis. Its meant as a suggestion/good practice.
    You can fully specifiy if an object should use gravity or be forced to a heightfield. (A heightfield in this case represents your terrain, so your hill) The object would always walk on this heightfield, either be forced to it or use smooth gravity to accelerate towards the heightfield untill it is reached. When using internal y handling by gravity or heightfield forcing any y input you give will be ignored. When not specifying one of those two (or both) options, you can move an object on the y axis completly free.

    I hope this makes stuff a bit more clear. :)
     
  36. ZJP

    ZJP

    Joined:
    Jan 22, 2010
    Posts:
    2,649
    Last edited: Dec 7, 2013
  37. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Yes it does. Though, the system uses multiple uniform grids to determine which objects are near. It might cause a bit more of overhead on the sites of a planet since multiple objects (even though they are spatially subdivided by the y coordiante) would get processed in the same cell. The acctual collision and trigger detection wouldnt be effected, infact the broadphase would just have a bit more work. Shouldnt be a problem though since the boradphase itself is highly performant.

    Other than that, the gravity and heightfield ability would clearly break, since it is 2D oriented. (Just like unitys heightmaps) You would need to solve gravity via colliders.

    I know about the native dll "bug" with unity indie. But I prefer not to "abuse" it in an asset of the asset store as long as unity doesnt clearly state it is allowed.
     
  38. ZJP

    ZJP

    Joined:
    Jan 22, 2010
    Posts:
    2,649
    Thanks for the reply. ;)

    This is not a bug, it's Mono. :D
     
  39. Toad

    Toad

    Joined:
    Aug 14, 2010
    Posts:
    298
    This looks cool. Could you do a web player demo showing a comparison between your physics and PhysX? (e.g. stress test results)
     
    Last edited: Dec 7, 2013
  40. silentneedle

    silentneedle

    Joined:
    Mar 14, 2013
    Posts:
    280
    Ah now I understand, thanks for clearing those things up. So with your hash grid solution we don't have to use unity's navmesh at all? At this point I usually would ask if you've done performance tests vs. unity's navmesh or other solutions like A*. But I'm sure it's not possible with those two systems to move 5000 units without killing the client.

    How big was the terrain in your test?

    Will your move script avoid dynamic (at runtime) placed obstacles?
     
  41. david55527

    david55527

    Joined:
    Mar 24, 2013
    Posts:
    58
    Would like to see this as well :)

    This looks very promising, will almost definitely purchase sometime in the future.
     
  42. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353

    Just to clear things up, this framework is a Physics system like PhysX is one and !NOT! a pathfinding solution!
    I might know why you got on the wrong track.

    So its like this. EnhancedPhysics is a pure physics solution which does range and collision detection. It implements it via the hierarchical hash grid method and has multiple multithreaded cycles on which it processes its calculations in parallel. Additionally, it features "movement methods" which will register the object as moved in the system and will set its position in a more performant fassion.

    So why does it need movement methods? Easily because the system always needs to know the position of every single object to any time of the game. Those are methods like the Move or SimpleMove methods from a character controller, nothing more.

    You will have to implement your own pathfinding solution or integrate one of the asset store which uses the movemethods on the PhysicsObject instead of a character controller.


    Ill see that I port the mass physicsobject example scene to a webplayer demo btw. ;)
     
  43. stawberry

    stawberry

    Joined:
    Nov 12, 2012
    Posts:
    13
    Mobile friendly?
     
  44. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    Depending on the size of the area in which objects should experience physics. (It would be limited on ram) But yes, in common cases it is perfectly for mobile, even more than unity's internal PhysX implementation. As long as you dont go into sizes like 10k x 10k its fine.
     
  45. stawberry

    stawberry

    Joined:
    Nov 12, 2012
    Posts:
    13
    Can I place MoveInDirection or MoveToPoint method inside Update? Say I am implementing a steering system. I want to move the character right after the desired position is calculated during Update. I first tried:

    void Update () {
    ....
    .....
    .......
    thisPhysicsObj.MoveInDirection (desiredDirection, 0.04f, false);
    }

    The movement is jittery. Then I tried:

    thisPhysicsObj.MoveInDirection (desiredDirection, 0.04f, true);

    The movement is good but I get the following error:

    NullReferenceException: Object reference not set to an instance of an object
    EnhancedPhysicsSharp.PhysicsObject.Move ()
    EnhancedPhysicsSharp.PhysicsObject.ProcessInstantly ()
    EnhancedPhysicsSharp.PhysicsObject.MoveTowardsPoint (Vector3 directionPoint, Single distance, Boolean processInstantly)
    MovementTest.Move () (at Assets/Scripts/MovementTest.cs:29)
    EnhancedPhysicsSharp.MovementExecutor.Process ()
    EnhancedPhysicsSharp.MovementExecutor+<ProcessMovements>d__0.MoveNext ()

    What would be the best way to implement your system in this case?

    I don't exactly understand how the movement system works. Do I have to add a MovementExecutor? Do I have to use the Move method?
     
    Last edited: Dec 10, 2013
  46. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    I guess I should rewrite the docu for the movement matter.

    Your basic approach is already fine. When requesting a movement via MoveInDirection, MoveToPoint or MoveTorwardsPoint, the movement will get calculated and evaluated on the NEXT movement timestep of the area your object is registered in. So to avoid the stutter you need to lower the movement timestep of the area, eg to 0.02f instead of 0.1f! This will make the system calculate and evaluate the movement 50 times a second and should be enough for a smooth look.

    The MovementExecutor itself is just a multithreaded replacement and therefore an optimization of the Update() loop which lets you run your own movement loop on timesteps equal to the one of the PhysicsSimulationArea. But first off, dont bother with a MovementExecutor untill your final movement is done.

    Regarding the error. This happens when you try to move an object which hasnt been added to the simulation area yet. Object always get added to it in the next Physics cycle. Its already handled more gracefully in the newest version.
    For now, if you want to use the processInstantly function, heres the workaround:
    -> create a private bool
    -> make your start method an IEnumerator
    -> when you did your setup in start, yield return for about 0.2s (a bit higher than your physics timestep)
    -> set your bool to true

    -> in your update loop, check if your bool is true, otherwise quit
     
    Last edited: Dec 10, 2013
  47. stawberry

    stawberry

    Joined:
    Nov 12, 2012
    Posts:
    13
    Now It works exactly the way I wanted. :)
     
  48. stawberry

    stawberry

    Joined:
    Nov 12, 2012
    Posts:
    13
    Is it discouraged to change trigger radius during runtime? For example, setting TriggerRadius directly in Start().
     
  49. Sharp-Development

    Sharp-Development

    Joined:
    Nov 14, 2013
    Posts:
    353
    You wouldnt want to set the TriggerRadius right within the start method because it wouldnt make any sense. You could aswell set the objects radius right in the editor (or Initialize method) to that new radius. However, you are free in doing it, so yes you could set it in the start method. You can aswell change it to any other time of the game, theres not a single problem with it. ;)

    Though, to note is that permanently changing the radius, eg on multiple objects every frame, will be costy. So limit the TriggerRadius adjustments to a minimum to save performance.
     
  50. stawberry

    stawberry

    Joined:
    Nov 12, 2012
    Posts:
    13
    Some new feature request. When destroying a PhysicsObject, it would be nice to send exit event to triggers detecting it. Also sending enter event when instantiating a PhysicsObject inside triggers. Maybe some sort of pool manager friendly feature? You suggest to remove PhysicsObject using Destory function, which may not be good on mobile.
     
    Last edited: Dec 11, 2013