Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

Unity Physics Discussion

Discussion in 'Data Oriented Technology Stack' started by smcclelland, Mar 18, 2019.

  1. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    Slightly back on topic, I just turned Unity Physics down to 1 solver iteration... It's still stable. wtf is this solver? seriously. I have a 64 cube long chain and it's still totally stable on one iteration. PhysX isn't stable with a 10 cube chain and 64 iterations. Jeez. Even in worst case it just get's stretchy. It's incredible.

    Once this has better performance and stable stacking i'm switching as soon as I can. It's just so stable. Been trying all kinds of joint setups and stuff just works. Honestly, without the jittering i could just project the renderer back into it's constraint and get visibly perfect joints (minus some penetration from rigidbodies, but it would be subtle). This is going to be awesome for VR when it's performant. Can't wait X3
     
    Arkade, PhilSA, Kender and 3 others like this.
  2. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
    I'd like to request separate overrides for mass distribution:


    It's actually very rare that you want to modify Inertia Tensor when you want to modify COM.

    Current setup forces you to set all these three fields at once. It makes very little sense to bundle there in the editor side script like this IMO (I feel they are bundled just because they are set in same group in code etc, but you should just be able to use the precomputed values for items you don't want to change).
     
    Alverik, steveeHavok and Cynicat like this.
  3. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    854
    Hello,

    Obviously Physic ECS is early stage, but we are already using it for our new prototypes. Currently we have this problem and I am looking for suggestions:

    For our Character controller we want to freeze the rigidbody rotation, this is usually done in Physx by setting rigidbody.contraints = RigidbodyConstraints.FreezeRotation, is There a similar setting in ECS Physics? (we want to disable the rotation part)
     
    steveeHavok and Alverik like this.
  4. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    854
    Today update of the entity package broke the Physic package (no update available so far):

    Library\PackageCache\com.unity.physics@0.0.1-preview.1\Unity.Physics\ECS\Systems\BuildPhysicsWorld.cs(21,16): error CS0619: 'ComponentGroup' is obsolete: 'ComponentGroup has been renamed to EntityQuery. (UnityUpgradable) -> EntityQuery'
     
    steveeHavok likes this.
  5. dartriminis

    dartriminis

    Joined:
    Feb 3, 2017
    Posts:
    154
    That latest version of the Entities packages is not compatible with the current Physics package. However, the Unity team is working on an update for this:

     
  6. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
    I have Unity Physics 0.0.1-preview.1 upgraded to the new Entities package locally, but still waiting for response from Unity here if I can share stuff like this in github:
    https://forum.unity.com/threads/ecs-packages-on-github.656512/

    I'd happily share changes like these but don't want to step over Unity if they don't want these packages on github.

    Unity Physics itself is rather trivial to upgrade to new Entities version, pretty much everything is covered in the release notes upgrade guide.
     
  7. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
    Also, I know joints are still WIP but is there any ETA for breakable joints? What about articulations, are they planned?
     
    Arkade and Brian-FJ like this.
  8. ed-fj

    ed-fj

    Joined:
    Mar 22, 2013
    Posts:
    1
    I have been using the CompoundCollider type to generate collision, set up by code. We have structures that are actually composed of multiple simple shapes, so this seemed the most suitable choice. However CompoundCollider.Create() currently generates quite a noticeable spike.

    Is this a feature where performance will be improved in future releases? Otherwise I might have to do something more specialised when it comes to generating these colliders. Overall though, we have seen ECS Physics working pretty successfully so far - thanks!
     
    Brian-FJ likes this.
  9. WAYN_Group

    WAYN_Group

    Joined:
    Mar 16, 2019
    Posts:
    59
    Hello, I'm starting to play with the unity physics. In my experiments I noticed that having the classic Rigidbody and coliders on a game object and the convert to entity script seem to have the same effect as the new phisycs shape and body components.
    Except losing the ability to choose between unity and Havok, am I correct to assume that or is there any draw backs in keeping the "old" rigidbody and coliders ?
     
  10. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
    Conversion workflow can't convert what is not there: New Physics Body has some settings that don't exist on old Rigidbody component. Same applies to Physics Shape component.

    If you only need to convert the settings that exist on both components, I'd guess it makes no big difference. I dunno if you get PhysX dependency by doing this though? (You probably could remove regular physics module from your project otherwise if needed).
     
  11. PixelizedPlayer

    PixelizedPlayer

    Joined:
    Feb 27, 2013
    Posts:
    358

    Can you please further clarify for Unity Physics:

    Deterministic across all platforms.... do you mean fixed point arithmetic operations? If not - how else is this achieved given the way floats are calculated, if you are using fixed point, how are you optimising this for 3D, can we control precision amount? I couldn't get better than 2D deterministic fixed point arithmetic physics.

    I have desperately needed deterministic 3D physics for networking RTS games, but i couldn't make a good enough physics engine for it with performance. And the arithmetic operations were complicated for 3D.

    Secondly, why is it an either/or between current physics solutions (physX) and unity physics? What does one provide that the other does not, it sounds to me like unity physics will provide what we already have AND more for things like networking, performance and determinism, why would we need the physX solution anymore after that?
     
  12. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    Disclaimer: I don't work for unity and i'm not a primary source, i'm repeating what i've seen in talks and around the forums. There are people here who will know better than me.

    Determinism: From what i've seen they are going to use Burst(which let's them compile their own machine code) to create the same exact operations across all platforms. This would remove all the platform specific optimizations to floats that create different behavior between platforms.

    PhysX difference: It's an either or because Unity physics is missing a bunch of features that you need to ship a game, eg: physics sleeping, dynamic rest (stable stacking of rigidbodies), currently has a bunch of sync points that are tanking performance on even simple scenes, etc... The other thing is that PhysX is for the Gameobject pipeline and Unity Physics is for ECS. Plus stuff like determinism and statelessness can come with a really large performance hit sadly. So it won't be the everything solution for a while yet.

    Hope that helps!
     
    steveeHavok likes this.
  13. PixelizedPlayer

    PixelizedPlayer

    Joined:
    Feb 27, 2013
    Posts:
    358

    Isn't the lack of sleeping and dynamic rest simply because it's still in development ? Or do they not plan to add half the features PhysX has regardless?
     
    Kender likes this.
  14. Opeth001

    Opeth001

    Joined:
    Jan 28, 2017
    Posts:
    228
    My Player Kinematic Physics Body is not colliding with any other Entity :( .
    i tried to change my body to dynamic and im able to collide.
    i didn't get the reason .
     
  15. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    *shrug* No idea. Their design doc makes it sound like they aren't going to implement them but in this thread they've said they're looking for feedback for future releases and made it sound like they where interested in implementing them. It's super weird and unclear. I'd really like a solid answer on whether their planning this to be a full featured solution in the long run but for now it's super ambiguous.
    https://docs.unity3d.com/Packages/com.unity.physics@0.0/manual/design.html
     
    Kender likes this.
  16. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    84
    What exactly is the 3 year plan of unity?o_O
     
  17. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
    Alverik, Antypodish, Ruchir and 3 others like this.
  18. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
  19. davidv_unity

    davidv_unity

    Unity Technologies

    Joined:
    Nov 14, 2018
    Posts:
    14
    Right! And besides many other improvements the new release is of course designed to work with entities preview.30 and we're sticking to our promise: entities preview.31 will e.g. be auto upgradable (even from preview.29) such that this will be a much smoother experience (although still preview). We put a transparent removal date of deprecated API in (currently 3 months while in preview) before we would remove them in the release after that. We will be removing all deprecated API though when we leave preview and go production ready at which point we will provide LTS. Of course a proper announcement of this will follow.

    [edit: auto upgradeable (during preview) means no hard errors]
     
    Alverik, FROS7, Opeth001 and 3 others like this.
  20. Opeth001

    Opeth001

    Joined:
    Jan 28, 2017
    Posts:
    228
    Please provide a clear documentation for the new Unity Physics and restore the ECS documentation.
    ECS does not have a documentation anymore.
     
    Alverik likes this.
  21. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,069
  22. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    357
    So I took preview 2 out for a spin this evening. Out of the box, it still has the same nasty issues as the previous version.

    But I am a little smarter now and turned on Synchronous Compilation in Burst, and all the narrow phase lag spikes completely vanished. It would be nice if Burst cached compilations between entering play mode several times if the C# code was not recompiled.

    The pool table demo is still slow, but that's all render thread issues. Enabling GPU instancing on all the materials helps a bit. I haven't investigated why that's slow. And for everyone struggling to enjoy the interactive demos due to the simulation running outside of fixedUpdate, turning on vsync in the project settings seems to tame that down for me.

    I didn't notice many changes in the code other than a reworking of the collider internal functions and the inclusion of dedicated cylinder colliders.

    So overall, I managed to make nearly all the demos perform well with just a couple of tweaks, and there's some real potential with this Physics Engine! It doesn't meet my needs at all, but my needs are not the normal use case so that is completely understandable.

    I can officially confirm that the broadphase is a very fast BVH-based broadphase from a raw computing perspective. I'm still not convinced it is the best approach, especially if Burst ever supports AVX. And right now it is suffering from some scheduling issues.

    This is with safety checks and leak detection disabled. I know I can expect to see better performance not in the editor, but this is on my workstation and I don't think I would magically get a 4x improvement in a build on something like a Ryzen 3 mobile compared to this setup. I'd test that theory, but it is getting late for me.

    upload_2019-4-11_23-56-11.png
     
    Arkade, steveeHavok and Squize like this.
  23. lijianfeng

    lijianfeng

    Joined:
    Sep 8, 2015
    Posts:
    20
    Will Unity Physics Interoperate Havok AI ,for 2d`3d PathFinding,Character Steering & Collision Avoidance .;)
     
    Last edited: Apr 15, 2019
    Kender likes this.
  24. Opeth001

    Opeth001

    Joined:
    Jan 28, 2017
    Posts:
    228
  25. Seto

    Seto

    Joined:
    Oct 10, 2010
    Posts:
    226
    The character controller scene show us the way to use PhysicsBody and PhysicsShape for character controller. And make Gun as a child with Convert And Inject Game Object for it. It give me the ability to use Animator or other Hybrid feature for it.

    But what about the situation below. I want to add a PhysicsShape with isTrigger checked to the blade.

    Any suggestion for it? Thank you.
     
  26. Henry00IS

    Henry00IS

    Joined:
    May 20, 2015
    Posts:
    11
    As a child I used a physics engine called Newton Game Dynamics, it was the most amazing stable physics experience ever. They never stopped developing it. It's now called Newton Dynamics, open source and highly underrated. If you look at some of their recent work they even incorporated the latest physics findings from the international space station:



    Here is a low quality comparison video of Newton Dynamics VS PhysX VS Bullet and it shines just like it did years ago.



    They are working on a Unity extension over at GitHub.

    Truly a very underrated physics engine that deserves more attention. I wish Unity would reach out to them and give them an opportunity to work together.
     
  27. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    Do you have a source for Chaos being GPU based? I didn't hear that before. FWIW I think you could have "GPU based" rigid bodies right now in Unity by just enabling a couple of flags in the PhysX setup - no need for voxels.
     
    Alverik likes this.
  28. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    But would it be possible? I got the feeling from the MegaCity presentation that the hierarchical culling etc was kind of hardcoded for that specific scene (without using a "complex" data-structure like a BVH). So doesn't that mean you cannot really move all these objects at runtime? Because the culling code wouldn't work anymore.... I probably missed something here.
     
  29. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    That suggests there is a problem in the setup. You can definitely do stable chains with PhysX. Here's an example using the default joints, but it's even better with articulations & the new solver:

     
  30. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    3,891
    I believe Unity Technologies have the people who could make that happen, if they want to.
     
  31. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    Isn't it just the Dzhanibekov Effect ? It's been supported by Bullet for years - they even have a sample for it IIRC.
     
  32. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    That looks like a very biased video, conveniently showing a few cherry-picked tests. The original benchmark suite has hundred more. It's also quite out of date anyway with PhysX 3.4. There's a new version of this tool but it's not released yet. Looks cooler now:

     
    steveeHavok and Antypodish like this.
  33. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    Yeah, I've seen those demos. Never been able to get anywhere close in unity, not sure if that's a unity problem or if those demos are doing fancy stuff under the hood, but it's definitely irritating. It breaks into a jittery mess the moment it hits an impossible situation. I would be very interested how much trickery their doing under the hood to make those demos work. =/

    As for GPU based, it's mostly the scale. They showed in their usage demo they are using voxels instead of convex meshes. Considering these are leagues slower on CPU's and much better fitted to GPU's it would only make sense to be using some kind of GPU acceleration, not to mention the whole demo has too much going on for even a fast CPU physics solver. Plus they mention reading the contacts directly into Niagara on the GPU, considering this would require massive data upload if it was simulated on the CPU i highly doubt their doing that.

    [EDIT] that rope video is from one of the devs of PhysX. He's using a bunch of extra joints (jointed to the root, and every 2-4 elements), COM editing, mass scaling, etc.. to get it to be stable, as well as it's using distance and spheres instead of actual links. Which is fine but it's not stability by default. That's duct tape and hacks.
     
    Alverik likes this.
  34. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    Well it's PhysX, it has always been "performance by default", not "stability by default" :) But the "hacks" like tweaking inertia tensors are the bread and butter of game physics (everyone does that, including Havok) so I'd say that doesn't really matter as long as it works. If you want the "stability by default" I suppose PhysX 4 & the new articulations would give you that anyway.
     
  35. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    One thing I don't understand is why isn't Unity doing the "duct tape and hacks" for users under the hood. Exposing half of the PhysX API as-is isn't helpful, it's like trying to use that lib with one have hand tied in the back. There is no added value in a wrapper if it only exposes the regular API calls but not even all of them etc. I would have expected Unity or Unreal to actually enhance the physics API and provide maybe a higher level rope component making all that stuff work out of the box for their users. Why isn't it the case.
     
  36. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    FWIW there's a "createLongChain" function in this snippet, that doesn't use "hacks" and still works fine. But it's using articulations so I guess not available in Unity:

    https://github.com/NVIDIAGameWorks/...s/snippetarticulation/SnippetArticulation.cpp

    So I think saying "PhysX isn't stable with a 10 cube chain and 64 iterations" is misleading, BUT your point about "impossible situations" is valid: PhysX struggles with "impossible" cases indeed (where things would just break up or explode in real life for example). I suppose it's normal to get numerical explosions in these cases? How is Unity Physics dealing with these? Can you describe your case where you get a "jittery mess"? Would be interesting to test the same case in Bullet or Newton.
     
  37. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    For more context: When i said the 10 cube chain with 64 iterations, I was actually referencing a real test i did the same day. 10 cubes with character joints, with lots of parameter tweaking. Any rapid movement would cause it to explode in a jittery mess (all joints jump around everywhere whenever it stretches) even with 64 iterations. Often knocking into other objects in the scene causing collision cascades.

    Unity Physics I made basically the same setup, just using ball and joint (there's no equivalent in Unity's PhysX, closest is character joint). Totally stable. No parameter tweaks, no extra joints, no COM, tensors, no magic. 1 iteration was a little squishy but still held it's shape, even in impossible situations. Took less than two minutes, mostly just duplicating cubes and assigning targets. even huge chains where stable, if squishy on low iterations.

    I didn't mean PhysX couldn't handle it, but having to add tons of extra non-physical joints, tons of COM and tensor tweaking, just to get basic joint setups to be stable is a terrible workflow. It's also not generally applicable, so it's almost impossible to automate. Meaning every joint setup takes hours. I'm not going to compare setup that takes 2+ hours of tweaking to a setup made in 2 minutes in a dead simple way and pretend their equivalent because it's technically possible with another 3 hours in physX and a bunch of custom code. I'd much rather be doing those tweaks to improve my physics rather than having to do them to make something even remotely usable. On top of this there's the constant knowledge that at any moment during gameplay PhysX could shatter and blow up everything in the whole scene if the player manages to break one of the joints. o_o

    Unity Physics has a long way to go before it's production viable. But i absolutely love the ability to make setups that make sense and they just work. I work on VR stuff, I have wanted reliable joints for ages, the joints in this work way better. I actually feel like they can be relied upon to not break my game. I'm sick of not being able to trust PhysX's joints to not trash everything. I want to spend my time thinking about what i want to make, not fearing when physX is going to explode.

    Anyway, sorry for the long post, just my rambling thoughts. It's really nice being able to just make stuff for a change. Rather than feeling like i'm trying to land on the moon every time i want to make some jointed structure.
     
    Last edited: Apr 13, 2019
  38. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    FWIW there's no "character joint" in PhysX. "Ball and joint" sounds like a "ball and socket" joint, a.k.a. spherical joint in PhysX.

    It doesn't take 3 hours of tweaking to make a 10 cube chain in PhysX. It just works for me, not sure why it doesn't in Unity. Bit of a mystery here. PhysX isn't perfect but it's been used in tons of games that don't randomly explode because of joints, so.... Unity wrapper issues maybe?
     
  39. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    52
    Does PhysicsWorld.CastRay have an error or am I doing it wrong?
    I've tried to cast an ray from the mouse position, but it hits only if the origin(Camera) in a collider.

    The Job:
    Code (CSharp):
    1. [BurstCompile]
    2. public struct RaycastJob : IJobParallelFor
    3. {
    4.     [ReadOnly] public PhysicsWorld world;
    5.     [ReadOnly] public NativeArray<RaycastInput> inputs;
    6.     public NativeArray<RaycastHit> results;
    7.     public NativeArray<bool> isHits;
    8.  
    9.     public void Execute(int index)
    10.     {
    11.         RaycastHit hit;
    12.         isHits[index] = world.CastRay(inputs[index], out hit);
    13.         results[index] = hit;
    14.     }
    15. }
    OnUpdate:
    Code (CSharp):
    1. protected override void OnUpdate()
    2. {
    3.     ref PhysicsWorld world = ref World.Active.GetExistingSystem<BuildPhysicsWorld>().PhysicsWorld;
    4.     var mPos = UnityEngine.Input.mousePosition;
    5.  
    6.     var ray = UnityEngine.Camera.main.ScreenPointToRay(mPos);
    7.  
    8.     uint layerMask = 1 << 0;
    9.     var filter = new CollisionFilter { CategoryBits = layerMask, MaskBits = 0xffffffff };
    10.     //filter = CollisionFilter.Default;
    11.     var input = new RaycastInput
    12.     {
    13.         Ray = new Ray { Origin = ray.origin, Direction = ray.direction},
    14.         Filter = filter
    15.     };
    16.     var rayCommands = new NativeArray<RaycastInput>(1, Allocator.TempJob);
    17.     var rayResults = new NativeArray<RaycastHit>(1, Allocator.TempJob);
    18.     var isHits = new NativeArray<bool>(1, Allocator.TempJob);
    19.     rayCommands[0] = input;
    20.    
    21.     JobHandle handle = new RaycastJob
    22.     {
    23.                 inputs = rayCommands,
    24.                 results = rayResults,
    25.                 world = world,
    26.                 isHits = isHits
    27.  
    28.     }.Schedule(rayCommands.Length, 5);
    29.     handle.Complete();
    30.  
    31.     var result = rayResults[0];
    32.     var isHit = isHits[0];
    33.     if (isHit)
    34.     {
    35.         UnityEngine.Debug.Log("Hit");
    36.     }
    37.  
    38.     rayCommands.Dispose();
    39.     rayResults.Dispose();
    40.     isHits.Dispose();
    41. }
    42.  
     
    siggigg likes this.
  40. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    It does take 3 hours if you want it to be robust for gameplay. There's a big difference between a chain simulating properly and being able to bat it around, stretch it, etc... without it breaking and blowing up everything. Plenty of games don't have everything explode because they take the time to babysit joints, or remove stuff that causes those explosions. It's unshippable. that's kinda my point.
     
    xVergilx and Alverik like this.
  41. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    Pardon me but if we're suddenly talking about shipping an actual game, 3 hours is actually not that much if it's robust in the end. You really should spend more than "2 minutes" on your physics setup & physics fine-tuning before shipping.Otherwise that's exactly how you end up with funny physics bugs in Youtube videos (with any physics engine).

    I suggest we continue this discussion after anything has shipped with Unity Physics. I don't think we can already claim that this one is going to be problem-free (already heard that with Newton, was the exact opposite).
     
  42. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    Okay. Download Unity Physics. Try it. Make a cube chain in PhysX, make one in Unity Physics. Unity physics has taken everything i have thrown at it without breaking once. That's really cool. I praised that and was sharing my experience with Unity Physics. PhysX in my experience takes a long time to get gameplay worthy. Unity Physics is better out of the box than what i get with hours of tweaking and custom scripts in PhysX. Try it for yourself, it's not hard. No unity physics isn't ready to ship yet. I never said it was. I'm not talking about the whole physics engine, just joints. If you don't share my experience, fine i don't need you to. I was just sharing my experience.

    Anyway, let's stop this here. I don't feel it adds anything to repeat myself.
     
    Alverik and Kender like this.
  43. TheoPoilmek

    TheoPoilmek

    Joined:
    Mar 22, 2019
    Posts:
    17
    But I did. Just not through Unity. And my point was that it worked fine.

    Again, I think there's something fishy going on in the Unity wrapper/version. I am not trying to dismiss your experience: I completely believe that Unity Physics works better out of the box (I don't need to try it myself, I believe you).

    But it seems that people using PhysX directly have an easier time than people using PhysX wrappers. It could be useful for Unity users to go to the bottom of why it is the case. Especially with PhysX 4 focused on robotics, joints have to be robust out of the box. They don't randomly explode after an hour training a robot, they're rock solid. And they're not "tweaked" for gameplay either, the params come right out of the robots specs and that's what you use period.

    Anyway this is all off-topic (sorry, I got side-tracked by that Newton video). Should move to a PhysX thread really. Let's stop indeed.
     
  44. Cynicat

    Cynicat

    Joined:
    Jun 12, 2013
    Posts:
    255
    Ok i see your point more now, sorry for being defensive (I need to not reply to threads at 4am). Yes you should start this up on the physX 4.0 thread. This is a totally separate team working on Unity Physics to the PhysX integration. I'd be interested to see what's causing the joint instability if it's coming from unity's integration.
     
  45. nsxdavid

    nsxdavid

    Joined:
    Apr 6, 2009
    Posts:
    291
    So the changelog.md for Unity Physics references this:


    * Physics systems are tied to (variable) rendering frame rate when using automatic world bootstrapping. See `FixedTimestep` examples in ECS Samples project for currently available approaches.


    Does anyone know where these "FixedTimestep' examples are? I can't find them.
     
  46. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    97
    I've found a weird behaviour. I have a very simple scene with a dynamic rigidbody entity. I'm using a system to set the angular velocity. I'm setting
    velocity.Angular.xz = 0;
    and
    velocity.Angular.y = 1;
    This functions exactly as expected (rotating about y) unless the shape type is set to cylinder, in which case it rotates about x.

    I assume that this may relate to the orientation properties on the physics shape. It appears the rotation is relative to those. Is that correct? I find that behaviour unintuitive. When I set
    velocity.Linear
    that appears to be in world space but
    velocity.Angular
    appears to be in some rigidbody space. This is clearly designed behaviour because your examples handle the necessary transforms and you provide extensions, but it caught me out.

    ComponentExtensions.SetAngularVelocity
    looks like the correct API to use here and indeed seems to work. I find it unexpected and clunky that I need to provide a
    PhysicsMass
    and
    Rotation rotData
    to set the world space angular velocity. I did not expect to need access to those components for this simple operation. I find the use and existence of the
    entity.SetAngularVelocity(float3 angularVelocity)
    variant to be distasteful and risky because it lacks type safety. That should not be encouraged behaviour because that way bugs lie.

    As a side note, the source code appears to include basic comments for the API methods but they're not documentation comments, so they don't show in intellisense. That seems like a usability oversight. While this is still in preview, it would be useful to have access to those development comments as a stop gap until you have full documentation comments written.

    Oh. I just thought to check the source for the
    PhysicsVelocity
    type and there's a comment explaining that you already intend to make the change I'm suggesting by moving the angular velocity into world space. That makes this whole comment redundant. I've written it now, so I'll submit it because maybe there's still a little value in it.
     
    steveeHavok likes this.
  47. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    97
    I see that you have a few places in the API where an int is used to denote an axis and an assertion is made to keep that int between 0 and 2 inclusive. I presume that this corresponds to x,y,z. Would it not be nicer to have that as an enum?
     
  48. spakment

    spakment

    Joined:
    Dec 19, 2017
    Posts:
    25
    From a brief spin on 2019.1 this is looking very promising, having source access I hope some of the wider physics community run with this (Obi Physics and the various Vehicle Physics asset creators).

    Is there any roadmap for when UnityPhysics is expected to be production ready?
    The infographic from the DOTs roadmap talk suggests 2022, are you 3 years away from this project being included in a LTS?
     
  49. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    854
    We are betting on it now so I hope it won't be 2022 :D
     
  50. Nyanpas

    Nyanpas

    Joined:
    Dec 29, 2016
    Posts:
    39
    How can I make the Unity Physics Ragdoll Joints in 2019.1 work with an imported FBX with a skinned mesh renderer? I get some rather uncouth results:

    nuhnoh.PNG