Assets APE - DeepMotion Avatar Physics Engine for Robust Joints and Powerful Motors

Playing a lot of tank games and always seeing the tracks being animated.. I've always wanted to do that at least once. (and well... There are so many stuffs that I would have to do with APE... ) You'll be the one granting me this opportunity! (which will, I hope, at the same time showcase APE's capabilities ) *Will wait for it even forever if needed!*

 

@ArticulatedPhysics – do the ropes have collision against unity colliders and mesh colliders? Do they exhibit self collision as well? Thanks!

 

YES, YES and YES.
Any collidable bodies/links in APEngine collide with other collidable bodys/links configured with unity colliders or mesh colliders unless you choose NOT to. Links in one articulation/mechanism can optionally turn on/off self collision and optionally turn on/off the collision between immediate parent/child links. They also support the Unity collision mask/groups so you can separate them nicely with collision groups and define the exact inter-group collision matrix from the Unity editor.

Avatar Physics
deepmotion.com/avatar

 

YES, I assure you that tanks with collide-able tracks work well with APEngine because we've done that before. Of course you need to spend a lot of time tuning the shape, mass, friction, joints and motors to make a gorgeous looking tank track

Avatar Physics
deepmotion.com/avatar

 

How useful do you think to support the integration of Unity terrain collider with APEngine ? Working on a basic version of that to read simple height map data under a terrain collider ...

Avatar Physics
deepmotion.com/avatar

 

Going to attend Unity Developer Day tomorrow (Tuesday) at GDC in Room 2014 of West Hall. We will present demos and Q&A at South Hall booth 2242 on March 18th (Friday). Also we will hang out at the EXPO floor most of time Wed and Thursday. Welcome to Tweet us if you are around and would like to meet up. Cheers!

Avatar Physics
deepmotion.com/avatar

 

When is the projected release date? I'm extremely anxious to see if your ropes will work as I would like them to in my current project.

Also wanted to ask – can your joints be used to make cloth like meshes by creating a rope grid of sorts? Assume they can, just wanted to verify.

 

We don't have a definitive release date yet. It's definitely this year. We are going to do a close beta program after GDC. Only a very limited number of users will be selected. Welcome to sign up the mail group at apengine.net if you're interested.

We don't support soft body / cloth physics yet. That can added if the interest level is high. You could build ad-hoc "soft" structures using the spring or rope joints and simple rigid bodies that are supported. The problem of any spring-mass system is that you need spend a lot of time tuning the stiffness/damper parameters to make it right.

Avatar Physics
deepmotion.com/avatar

 

Definitely interested in that as well.
Would be nice to have a great physics AND nice deformations!
(Although, as of now I think that the proper physics is waaay higher in the priority list.)

To be honest, if someday you want to make a tutorial about this ad-hoc "soft" structure system, I would be interested as of how this would work.

 

I am just thinking about it:
Does APE have a way to override the location of objects if it can work with 64bit?
Like, being able to place objects accurately at distances greater than the float precision maximum capabilities?

Let's get a very concrete example. I'd like to place HUGE objects (sphericals) at about 150,000,000... meters. (150k km)
That's an example. Let's say exactly 152,541,563.65 meters.

If I do use the default transform of Unity, everything will end up messed up as Unity will (as far as I remember testing) not be able to place this object this far.
Loss of precision at this distance might seem pointless though. (maybe not if there are things like stellar movements induced xD)
But still. I was just wondering this.
(it would be wonderful that it does although I would not be surprised that not. )

 

Not sure of your exact needs, but usually in cases like that I think games typically use a floating reference frame to keep everything near (0, 0 ,0) and to keep giant velocities manageable. I believe Kerbal Space Program used this kind of approach.

This post has a little information:
http://gamedev.stackexchange.com/qu...ound-limitations-posed-by-float-in-space-game

 

Yeah, Origin shifting, we're already using this and would like to avoid using the frame thing with multi-scale.
That's my main goal, to keep everything as much 1:1 as possible.

 

GDC APEngine Demo #2, crane:
https://drive.google.com/file/d/0BwboCvm6PSvBci1jX1lCZ3JDVUU/view?usp=sharing

Avatar Physics
deepmotion.com/avatar

 

GDC APEngine Demo #3, dragon: not only can APEngine simulates machines, but also a flying and breathing dragon. Even the air lifting force is simulated via air flow bubbles as demonstrated in the collider view of the video:

https://drive.google.com/file/d/0B9D3fcS8XgX0MGttVHJtMnRXWEk/view

Avatar Physics
deepmotion.com/avatar

 

I want it!

 

Some asked for a performance comparison between PhysX and APEngine. In general it is very complex to compare physics engine performance because it heavily depends on the test cases and perspective of quality. Here is a quick comparison of a joint & motor scalability case since joint and motors are what APEngine is designed for.

The PhysX truck and APEngine truck are built of the same tech specs:
-mass ratio between lightest part and heaviest part: 1:320
-number of Hinge joints: 6
-number of Prismatic Joints (modeled as Configurable Joints in case of PhysX): 4
-drive motors:4
-steering motors:2

Both sims run at the same frequency
-fixed step duration: 0.02s (50Hz)
-iteration count: 6

This is how PhysX stacks 10 cars:
https://drive.google.com/file/d/0BwboCvm6PSvBTjFGNW9WMGtIMGM/view?usp=sharing

This is how APEngine stacks 100 cars:
https://drive.google.com/file/d/0BwboCvm6PSvBbVZKSXo2eVlubmM/view?usp=sharing

As shown in the second video APEngine simulates 100 cars (1000 DOF and 600 of which are powered by motors) in realtime with complex geometry collisions while car wheels are spinning. PhysX, to be fair, is not designed to handle this much stress from joints and motors and consequently it can't stack more than 10 cars without explosion.

Avatar Physics
deepmotion.com/avatar

 

The final compilation of APEngine GDC demos

We are still open to requests for participation into our Beta program. Please feel free to subscribe our mailer on the website if you are interested.

Avatar Physics
deepmotion.com/avatar

 

Hi!

Your engine looks very nice. However, as HeartBroken already pointed out here, the comparisons to PhysX are perhaps a bit misleading. I wrote some blog posts about it:

http://www.codercorner.com/blog/?p=1207
http://www.codercorner.com/blog/?p=1217
http://www.codercorner.com/blog/?p=1219

Here are direct links to the videos, some of which recreating your test scenes:

Crane:

5 hinge links:

Rope on a hanger:

And some bonus videos:

As you can see, you can actually get quite decent results with PhysX.

Don't get me wrong: it may very well be true that your engine gives more accurate results and works better "out of the box". In fact, it should not be surprising if this was the goal you had in mind when designing it. But it is not "unprecedented": we all started with exact solvers (Havok, NovodeX, etc) before moving to faster alternatives. This was a conscious choice driven by customer requests. And again, as HeartBroken pointed out, all these engines still offer additional features (like articulations in PhysX) to deal with, well, articulated objects.

Note that as far as I know this feature is currently not exposed to Unity users, so that might explain a few things.

Anyway, good job on your engine so far and no hard feelings. Welcome to the physics family!

- Pierre

 

Hi, can you send the Unity Example of your Crane to me? I would like to try it and, if you prefer, I can buy it from you if it works good with heavy cargos.

 

@Terdiman your recreation of the APE test scenes in a standalone environment using the experimental "articulation" feature looks great. Unfortunately the result won't benefit developers here. Because your scenes were not created in Unity using Unity's physics API. All comparisons in this thread was to compare PhysX and APEngine's joint performance in a common Unity environment. We could have made that more clear. Though it is a Unity forum and it is sort of implied.

PhysX is a great physics engine for massive rigid body simulation. While APEngine is designed from its core to simulate robust joint and strong motors. We were seamlessly integrated with Unity editor and it will enable developers to model and test physics models consisted of robust joints and strong motors without leaving Unity. For a commercial engine to work well it need to provide intuitive and industry standard modeling interface such as the Unity Editor. It also need to work out of box without changing the low level C++ code of the core solvers in order to simulate specific cases. For example all of our test scenes, be it ropes, cars or dragons, were created by artists who don't know C++ programming. They only need use Unity scene editor and inspector to create the APE scenes and models with occasional C# scripting supported by Unity. APE was not designed as a "rope engine". It just happens to simulate rope well as it can simulate many different scenarios not remotely related to ropes. Also we don't have performance problem while simulating high fidelity joints.

The PhysX "articulation" feature is "experimental" under "research" and it only supports spherical joint type according to Nvidia document:

http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Advanced.html:
"Articulations are a somewhat experimental feature of the SDK, under active research"
"The only form of articulation joint currently supported is an anatomical joint, whose properties are similar to D6 joint configured for a typical rag doll. Specifically, the joint is a spherical joint,"

It was hard to find "articulation" demos on the internet until you posted a few just now. Thank you for sharing with us the progress on "articulation". Please keep us in the loop when it becomes an officially "released" feature, ideally with all the mechanical joint types, motor modes, joint limits, joint pos/vel/force sensors, joint springs, implemented and tested, and even better if it's officially ported to Unity. Until then it is impossible for us to leverage it for the games we are developing with Unity.

Avatar Physics
deepmotion.com/avatar

 

Hi,

>Unfortunately the result won't benefit developers here.
>Because your scenes were not created in Unity using Unity's physics API.

Well, it should hopefully benefit them down the road. This story showed that the Unity<->PhysX integration has issues and it looks like steps will be taken to address them. If nothing else the recreated scenes working in PhysX are an incentive for exposing articulations to Unity users. Also, some of the tips I wrote on my blog for creating more solid ropes using the iterative solver might be useful right away.


>All comparisons in this thread was to compare PhysX and APEngine's joint
>performance in a common Unity environment.

Ah, but with all due respect, it went beyond that.

It is one thing to compare them in the context of Unity, especially if you provide a Unity plugin that works better out of the box. That is very fair and it has value. But your GDC demos and what you are writing on your website are another thing entirely.

We are suddenly getting emails and questions about your videos. These questions did not arise because of Unity, they arose because APE apparently got presented as a direct competitor to PhysX during GDC. For example Unity is never mentioned on your website, but the first thing one can see is a direct PhysX-vs-APE comparison video. Unfortunately what PhysX can do in Unity is apparently not the same as what PhysX can do as a standalone middleware. So your video, on your website, in a context unrelated to Unity, is misleading at best because it exposes the limits of the Unity<->PhysX wrapper and sells them as PhysX issues. That's kind of a questionable strategy.

You do have a point though: it is very true, and I am not denying for a second, that iterative solvers are not the best fit for articulated systems. But again, and as people pointed out in this very thread, the physics engines you're now competing against do have dedicated solutions for these. This is unrelated to Unity: if you want to sell your software as a competitor to "industry standard engines" (to quote your website), you should be fair in your evaluations, and compare your articulated solutions to your competitors' articulated solutions. At the end of the day it is in your own best interest to know where you really stand against them. Otherwise you might be providing a solution that does not have as much value as you thought, and the whole thing might end up just a waste of your time and money.


>The PhysX "articulation" feature is "experimental" under "research"

Don't read too much into that doc. I think this paragraph just hasn't been updated since it was first written a while ago. It is not that experimental - we don't actually ship the truly experimental code, it would make no sense to productize it for nothing. And there is no research about articulations being done at the moment.


>Please keep us in the loop when it becomes an officially "released" feature,

It's been released for at least 4 years now (at least since PhysX 3.1). It is available in the PhysX version used by Unity, right now. It is just not exposed by the Unity editor.


>implemented and tested,

We do not ship something without testing it

In any case articulations have already been used in the field, most notably by Natural Motion. They certainly have their limitations, but what is there has been implemented, profiled, optimized, ported to consoles like the Xbox360, we got bug reports or regressions when people upgraded to a new PhysX version (all of which we fixed of course), etc, etc - it should be solid.


>and even better if it's officially ported to Unity.

This part does not depend on us. But we have a constantly open Skype chat with the Unity devs and this story put articulations on their radar, so it might very well happen.


Anyway, I am not a spokesperson for Nvidia, all that stuff above is my own impressions, feel free to ignore all of it

I'd be happy to try APE when it's available and give some fair feedback.

- Pierre

 

@Terdiman
Hi Pierre. I love your blog

 

Nvdia/PhysX document says that PhysX "Articulation" feature is currently "experimental" and "under active research" and you said something different. So one of the two is wrong. If your document is wrong and your feature has matured beyond the point of "experimental" just update the document. No need to blame us developers for "read too much into that doc"

 

Thank you for agreeing with us that "iterative solvers are not the best fit for articulated systems". The "iterative solver" is what is available in PhysX of Unity now for joint simulation and that is what we are comparing APEngine against in our video posts here. Unity is an awesome platform that empowers developers to do free experiment and extend any functions they want that are not fully satisfying. We will continue to leverage this flexibility of Unity and use Unity as a common platform to compare APEngine features with alternatives.

You posted test videos look really nice. They were produced in a standalone simulation lab environment outside the Unity framework. Unfortunately it's irrelevant to the Unity developers here since we can't verify them in Unity. If you would like to discuss general physics simulation topic with us outside the Unity context feel free to message us directly or bring the discussion to more appropriate places. This is a Unity forum and the APE plug-in WIP thread.

At any rate we would be very happy to re-run our comparison between APEngine and PhysX "articulation" feature when the following issues are cleared:

1. Your document says the "articulation" feature is "experimental". Please fix it to avoid the confusion whether it is in production or not.
2. Make the "articulation" feature complete
3. Make the "articulation" feature available to Unity developers

#2 above deserves some elaboration. The PhysX "articulation" feature only supports one joint type, spherical joint, now according to PhysX document which is limited for us to build complex articulated systems. APEngtine supports hinge, universal, spherical, prismatic, plane joints and dedicated position and velocity motors, limits, springs, vel/pos/force reaction sensors on every DOF of every joint type we support. The above we think is the basic feature-set for a mechanical joint simulation package. As what it stands now the "articulation" feature is not qualified to be compared to APEngine yet as a complete mechanical joint package. For example the monster truck model in our video cannot be built out of just spherical joint. If you would like to expand the "articulation" into a more comparable feature set and join us in offering developers more joint simulation solutions, welcome. What's important is to solve the problem of joint simulation for the developers.

Avatar Physics
deepmotion.com/avatar

 

I did not "blame" you This feature is certainly easy to miss (we don't have samples, we don't advertise it much, the doc is not up-to-date, etc). It's entirely our fault if people ignore it.

I'm at the office now and I see that the documentation has in fact already been updated. Since PhysX 3.3.2 articulations have a dedicated page in the manual, and the paragraph you mentioned is gone.

I cannot update the doc on the Nvidia website because it's for version 3.3.1. I cannot change the doc of already shipped versions, so this will have to stay. What I can investigate is why we only put the 3.3.1 doc online.

 

FWIW you can make hinges with the spherical joint, by using appropriate joint limits. But anyway this is irrelevant: you might very well have more features, and you might very well be a better choice in the context of Unity. Nobody is denying this I think.

However, as I already explained - but maybe I did not do that very well - your website is another story. To put it bluntly, it makes incorrect claims about your competitors in general, and PhysX in particular: the failing test scenes can actually work just fine with that engine. We don't need to "complete" the articulations feature for this fact to be true. I would say that the ability to recreate the test scenes makes us "qualified" to be compared to APE. After all, comparing PhysX to APE in these scenes is what you started ...

In any case, it is indeed not the best place to discuss this. So I will shut up now.

- Pierre

 

Wow, I can see a dialogue between PhysX developer (Terdiman, are you from PhysX team?) and APEngine devloper? That's intriguing!

@ArticulatedPhysics Terdiman is right - your video does not say in any way it is Unity-related environment. Even I have strong feeling that you compete with PhysX as a standalone physics engine, not PhysX in Unity out-of-the-box.

 

Hi Pierre, long time no talk. Hope all is well.

I'm one of those people bedevlied by the way PhysX, at least in Unity, handles joints. It's basically an unstable mess, out of the box. For which I am perplexed, actually. Why do you let joints pull away from their anchors? Even in 'impossible' situations, that just seems like a bug. I remember this being the case even as far back as our HeroEngine integration.

Seems like you can postprocess the joint to make sure it is still valid. And/or become kinematic while forced into impossible positions by the constraint. I did a little bit of that on my own, but have not fully nailed it. You, however, should be able to pull this off easily.

You can see some of the issues I deal with here. The toes on t his model use PhysX to find their spot.

APE certainly looks like something that would give me the behavior I'm after out of the box. @ArticulatedPhysics ... would love to test how your stuff works on situations like this.

David

 

Hi David,

FWIW on my side I'm perplexed by your reference to HeroEngine. I thought this worked quite well? I remember John's ragdolls in Rocket and it looked quite nice and solid. It's a bit puzzling to hear years later that it wasn't (?).

Anyway I think we do support the post-process you mention: it is called "joint projection" in the SDK. I think it is exposed in Unity. However quite often it only creates other issues. In your case for example, or typically in the case of a vehicle featuring a heavy chassis supported by light wheels, what happens is that the projection corrects the poses but also makes the bottom of the structure (e.g. the wheels) penetrate the ground more visibly than before. There would be a lot to say here about how one projects things (is A projected on B or the opposite? In which order? etc) and there are even some flags in PhysX to let users control some of it, but it's unlikely to be exposed in Unity, and at the end of the day it's not a magic bullet solving everything. Perhaps not surprisingly, fixing "impossible situations" is in fact not easy

It is worth mentioning that the kind of non-physical fixup you mention is probably best done on the graphics side anyway. You are not forced to use the SDK's poses directly, you can also do corrections between the physical and graphical meshes on the app's side. It is best done there, because these non-physical fixes (like correcting a joint's position by directly setting its pose) adds energy to the system and can create all sorts of other issues on the physics side (breaking friction patches, breaking CCD, etc). So for example if you have a slightly wobbling wheel, you can extract just one angle value from the physics pose, and ignore the two others for the graphics. Visually the wheel then appears to be straight (pretty much in the same way that Featherstone hides errors by working with "reduced coordinates", effectively solving for that single angle and making everything look correct as far as positions are concerned. But the errors are still there, they're just less visible because they appear in velocities rather than positions). For the records I know a bunch of AAA games that do exactly that kind of things to make sure players never see a wheel penetrating the chassis, or bending, etc.

Now, I am not sure what exactly is simulated by PhysX in your (quite nice BTW) video. Is PhysX controlling only the toes? If yes, it seems normal that when pushed into an "impossible position", the engine won't find a proper solution and behave badly. In the real world something would break here

That being said, PhysX with the default values is setup for performance rather than accuracy or stability. Did you try to tweak the parameters already or not? You might get better results with a smaller substep, or a higher number of solver iterations, or more homogeneous mass ratios. I'm afraid that by nature, an iterative solver only converges to the correct solution. But when high mass ratios are involved for example, 4 iterations are not enough. It is not a hack or a shame to increase the number of iterations in these cases. The iterations are relatively cheap in PhysX so people should not be afraid of increasing that number.

Maybe Unity could expose two default settings to their editor, one where PhysX is configured for more performance, one where PhysX is configured for more accuracy. It is not possible to please everybody out-of-the-box. On our side we set it up for performance by default, since historically that's what users have been mostly asking for. Historically there have been engines that worked better out-of-the-box, like Ipion (used in HalfLife2). but it didn't scale well at all, and that's why we all moved to iterative solvers (PhysX, Bullet, Havok, etc).

Finally, at the risk of repeating myself, this case seems like a perfect candidate for articulations. That's pretty much exactly what they're designed for - actuated characters. I think Natural Motion did pretty much the same as what you have in that video, except with humans rather than mechs. I would guess that articulations would give you a better behavior out-of-the-box, although it's hard to tell because I don't know what is simulated and what is kinematic in the video.

Anyway I'll try to install Unity and see what is actually exposed in the editor.

- Pierre

 

Yes.

 

Something like this a bit ?

 

// Off-topic //

All I could say is that, if that's possible to do with PhysX with parameters. Then you'd better talk it through so that it becomes exposed in Unity if you don't want your engine to have a bad reputation (which it already has to me regarding joints/mass-ratios/stability anyway).
That's great to have performance, but if it behaves badly, it's useless I think.

//////////////////

I might permit myself to as well say that, well. This thread is about APE, not PhysX.
This is only my opinion though.

 

Yeah, sort of. But this, again, is not relevant as not integrated with any engine. If you do show me the same thing in UE4 or Unity, this will be something else. I do not plan on writing an engine.

 

@Terdiman Well PhysX worked "well enough" in HeroEngine for what we were concerned with at the time, and Rocket was a synthetic example, not even a game.

And in there lies the rub... games are games, not real life. And they often put things in "impossible" situations because it is an unavoidable consequence of complexity and unpredictability of human input. As a game developer, what I want from the physics simulation is:

A) If nothing is amiss, solve
B) If it is impossible, then at least don't have the joint go bananas, rip away, etc. Just leave it alone until it can be solved.

I never understand, for example, why if you create a hinge that there is EVER a rotation on any axis that is not the rotational axis of the hinge. Trying to grok any conceivable code path that would do that which would not be considered a bug. At least in my book.

In the example I showed, yeah, the foot landed where the PhysX on the toes could not solve a way out the situation. But that will happen, sorry.

Oh, and I also did independently come to the same idea that I could have PhysX work on one object and apply it to the graphical representation after some fixup. Though that would solve only a portion of the problem without a lot of filtering.

There is projection exposed on the configurable joint, but not in the hinge joint (for example). So I imagine I'd have to recreate the hinge joint from the configurable joint to test it.


I'm not sure if AEP would handle impossible joints better, but at least the emphasis seems to have been on joint stability out of the box. As this is my #1 issue these days, it certainly has my attention.

 

@nsxdavid: I love your robotic foot, it looks gorgeous ! It is that kind of machine that inspired us to create APE to solve our own joint problems.

In our projects we have an internal policy to NOT use "joint projection" technique that basically post-processes a violated constraint and snap the body positions back into its "allowed" constraint space. A simple kinematic/graphics fix-up like this violates physics laws and injects energy to the system as Terdiman pointed out already. If you seriously want to go this route then you should consider "momentum conservation" based projection to the least. That is simple to do for two bodies and one joint, and quickly becomes more complex when you have multiple bodies connected by multiple joints. Game developers shouldn't be exposed this level of details of the simulation internals. Our modelers for APE for example are artists and designers and they never need to leave Unity editor or look into the C++ implementation of the engine to create something impressive. Such usability factor is as important as the solver underlying of the simulation package. But it was often ignored.

Our goal is to focus on robust joint and strong motors and solve these pain points from both the solver perspective and the usability perspective.

 

@ArticulatedPhysics Would you like to collaborate a bit and use this mech foot as a use case?

 

I switched the join from Hinge to Configurable Joint, but it was no better. Projection didn't seem to help much and setting angular distance anything lower than 180 caused it to just flip the heck out.

But here it is with the PhysX configurable joint. I simplified the obstacles so as not to exagurate the behavior, but it is still very unimpressive.

 

>And in there lies the rub... games are games, not real life. And they often put things
>in "impossible" situations because it is an unavoidable consequence of complexity
>and unpredictability of human input.

Which is also why games switched to iterative solvers. With old-school matrix solvers you would end up with a system that cannot be solved and the physics engine would blow up, faced for example with a matrix that cannot be inverted - and then it would just stop without a possibility to continue. An iterative solver on the other hand, won't care, it will still give you a result when faced with an impossible situation. That's their strength. On the other hand...


>Just leave it alone until it can be solved.

...that's also their weakness: the system does not know anymore if things can be solved or not. It just iterates and converges to some new state.


>I never understand, for example, why if you create a hinge that there is EVER
>a rotation on any axis that is not the rotational axis of the hinge. Trying
>to grok any conceivable code path that would do that which would not be
>considered a bug. At least in my book.

There would be a lot to say here but it's off topic I suppose. I can only guarantee that things are not that simple. We can start a new thread to discuss this or maybe google things like "impulse based solvers" - which compute new velocities, from which new poses are derived for the bodies. The velocities have errors that lead to positional errors. "Fixing" the positional errors by just ignoring the undesired rotations just adds energy to the system and leads to other issues.

The Featherstone algorithm does what you describe for articulated systems (I suppose that's what APE is using, correct me if I'm wrong). If there's a hinge, it only updates one of the rotation angle, period. But it has its own set of issues. Again, that's what we started from (we had Featherstone in NovodeX, before PhysX was even born) and it's certainly still useful (as pointed out before, Havok / Bullet / etc still support it as an alternative solver for articulated structures).

Anyway there's too much to explain here but the short story is that it's not that simple.


>There is projection exposed on the configurable joint, but not in the hinge joint (for example).

Yeah I downloaded Unity today, started looking at the editor.... and I feel your pain. There's a lot of stuff that isn't exposed properly there. I talked to Anthony (Unity) and I will try to make him change a few things. Exposing articulations was apparently already on his roadmap anyway, but there's much more basic stuff that needs fixing.


>Projection didn't seem to help much and setting angular distance anything lower than 180 caused it to just flip the heck out.

Errrr... as far as I can tell 180 is the default and it means "don't project anything". So it didn't help much because it was not active And if it doesn't work when decreasing that value, then it sounds like a bug to me.

Anyway guys, to be a bit more productive and to avoid the wrath of the off-topic police: I just started looking at a rope project that Anthony sent me, and my goal is now to make it work better in Unity. I can also look at that articulated mech if you want. If nothing else, I can always show it to our joint guys (I'm only the collision/optimization guy) and investigate why projection fails. It really should not fail on such a simple case.

 

Sure if you can share with us your mech model (feel free to simplify it and send us in a PM if there are IP concerns), we can see if we can help.

 

Well what I meant was, I'd use your stuff to wire it up. It's a bit of a unique technical rig.

 

Well that's embarrassing. There is a bug. Turns out that projection does not take joint limits into account.

I reproduced your scene & issues here so I can confirm that:

- without projection it does behaves like in your video. That's just the solver failing to find a proper solution when faced with an impossible situation. The contact constraints are solved after the joint constraints by design, to make sure that ragdolls don't end up penetrating the static world or tunneling. The side effect is that jointed systems jitter like crazy when penetrating the static world. Solving the joints after the contacts helps a lot here, but it makes it possible for a user to slowly drag a ragdoll through a wall for example. There might be something to expose to users here, to let them decide which is most important for them.

- with projection (using 0 / 0 tolerances) the side motions are perfectly fixed, but the hinge still jitters around the hinge axis because the limits are ignored by the projection code. That's a bug - or rather something we completely overlooked.

- with a fixed joint you can see the same jittering without projection, but behavior is perfect (no jittering at all) with projection. So I would expect that a projection code taking limits into account would fix the problem for the hinge.

So, well, it's on our radar now and we'll fix it. Thank you for that one, it was a genuine surprise to me that the projection code ignored the limits.

- Pierre

 

@Terdiman Glad you found that. It does bring up an issue though:

When you say you'll fix something, do you mean in the PhysX SDK, or in the Unity implementation of it? That is to say, if you fix it just in the PhysX SDK, but Unity doesn't update the SDK (which I take it they do rarely), it'll still be broken for some unknowable amount of time?

Also note that a hinge joint, for example, exposes no projection options. You have to use a customizable joint, which I think would be something worth fixing too.

 

Also, I think your presumption that avoiding penetrating the world is more important than a joint constraint is fairly arbitrary. In my case, I want the exact opposite. I know that many times the toes are going to penetrate the world, and there's not squat all I can do about it... so in such cases, I would rather the joint behave as properly as possible and allow itself to tunnel. So yeah, I think you are right, this should be something you configure on a joint-by-joint basis to swap the order of solving between constraint and contact.

 

I'm afraid we can only fix it in PhysX. We are not doing the Unity wrapper, and we have no control over it. We do send patches to the Unity devs, that they integrate into their branch of PhysX (i.e. they don't need to wait for an official PhysX release). But they're the ones doing the integration of PhysX into Unity. So for example they would have to expose projection for the hinge joint, it's not something we can do.

I would personally expose a lot more to the "Inspector" window. I found the way it's currently done confusing. There are things that are exposed in the UI correctly. Then things that are exposed in the UI incorrectly (for example only one solver iteration count is exposed while PhysX uses two different values, and it's exposed as a per-scene param while it's per-object in PhysX). Then things that are apparently only exposed in the scripts (e.g. the max angular velocity). And then things that are not exposed at all (e.g. inertia tensor scales for joints). It can make it challenging for Unity users to get the best results, since they're artificially limited to just a subset of PhysX.

- Pierre

 

It's not entirely arbitrary: all these things are usually done in response to customer requests. People did complain about ragdolls being dragged out of the world, this was part of the solution.

But it's fair to say that we should have expected or seen the negative side effects, and exposed some way for users to control this. It's a difficult balance though because people also complain when there are too many exposed parameters and / or when it doesn't do what they want out of the box. Even if we would have this option for swapping the order, "out of the box" the SDK would only please either you or the other customers who asked for the opposite. Not both.

 

Well, I sure hope some Unity folks are monitoring this thread and taking notes! My confidence in the Unity/PhysX implementation is not great at the moment.

-Jeff

 

I would say: make complex controls with presets for "people that do not care that it does S***".

I mean, It's great to have presets, but most of the time, they do work in a case that's so specific that it's just annoying...
I think that flexibility should be something important. Especially for engines like PhysX or APE which have very general purposes and no specifically designed use-cases. (or if they do, please let everybody know black on white which are the limitations).

Also, thank you for the insight of the bug on the projection. Seems like thanks to that I've been able to make a somewhat working tank suspension (although in UE4).

Now let's hope that Unity devs will hear us out and realize that they need to expose a lot more if not everything and use PhysX names.. I mean, they've been named

This could be something interesting as well for APE.
If APE's team is doing the engine integration/plugin, this allow to expose everything that's needed/wanted although much more tedious I would say.

@ArticulatedPhysics How are things going?

 

I don't know if we list all limitations in the manual (it's hard to make an exhaustive list of what you do not support, it's easier to list what you do support ) but one of the first paragraphs is called "Physics vs PhysX" and it does say, black on white indeed, that:

"Because of such approximations a PhysX simulation is subject to limitations that are not seen in ordinary physics, and later sections in this Guide will highlight these limitations wherever they are likely to concern the user. PhysX is best suited for quasi-real time interactive 3D applications where performance and scalability are more important than precision. Here "quasi-real time" means that advancing a PhysX simulation by a given time step, say 1/60 second, will take less than that amount of time on an observer's clock if the performance of the hardware platform is sufficient for the complexity of the simulation. That the PhysX SDK is more widely used in computer and video games than in scientific or engineering applications is both a cause and an effect of these design choices."

So I'm not sure we explicitly write that collision constraints will have "the last word" against joint constraints but there is a big warning about performance vs precision right in the introduction. There are various ways to work around the limitations (using smaller timesteps, tweaking inertia tensors, adding extra constraints here and there, joint projection, you name it) but the focus was on games, the use cases were typical AAA game scenarios, and all the design choices and compromises have always been dictated by these use-cases (and actual customer requests, rather than our own preferences).

Now, more recently various companies did ask for more accuracy and support for larger mass ratios, etc. That's when we added articulations. Again, as a result from a customer request. And again, with limitations: they solved the customer's problem perfectly, but we didn't try to extend them beyond that - simply because there isn't enough time in the day and we don't have enough resources to work on things that people didn't actually ask for.

As far as I can see so far, the most urgent thing to do in Unity would be to expose more of PhysX. It would already solve a lot of the issues I read about. Then we could start from there and work towards improving accuracy even more, if needed. In any case we are in contact with Unity so they know all about it already. (We have a constant Skype chat with them. I fixed a PhysX bug reported by Unity just this week again). But I suppose they also don't have a lot of time / resources to devote just to physics, so, yeah, things may appear to move slowly for an external viewer.

- Pierre

 

@Terdiman I was one of the people who made a big deal about the ragdoll. But, in my opinion, it's not okay to sacrifice one important thing for another and then say "There, fixed!" When those tradeoffs are unavoidable, as it may be here, then that requires the option to be exposed.

When Unity went to integrate that latest PhysX with Unity 5, it was a pretty big mess especially for ragdolls. But I got John Ratcliff in touch with the Unity dudes doing that integration and they closed a lot of loops. Obviously not everything got done right, and I'm pretty sure they are not monitoring this particular thread since it is not a PhysX thread, but an APE thread.

As for the fix you just did, you have a guy who talks to Unity there, might be good for him to emphasize the bug fix with them.

 

I actually posted about this thread in the physics forum to hopefully bring it to their attention.

http://forum.unity3d.com/threads/unity-and-physx-worries.400973/

Maybe this convo should be continued there...

-Jeff