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

Totally agree. Why do we have to sacrifice joint for collision or sacrifice collision for joint ? That is an artificial limit forced upon users by a design choice.

Essentially to a constraint solver collision constraints and joint constraints should be modeled as the same thing and they should be solved together. When they are solved as two separate systems in two separate passes we will be forced onto making this arbitrary choice as to who overrides who. In APE joint constraints and contact constraints are solved together. Consequently:

1) We need NOT ask users to choose the solving order of joints and contacts and sacrifice one for the other.
2) We need NOT ask users to choose "projection" methods or parameters because we consider "projection" a fundamental violation of Newtonian laws and we never need to implement such hacks in the first place.

APE's principle of simulation is very simple: do it right first, then make it fast

Avatar Physics
deepmotion.com/avatar

 

@nsxdavid: ground reaction to a walking mech that forces contacts and joints to be solved together has always been a test to the robustness of physics engines. we did a lot of mech rigging in the past. although we didn't have a mech rig at hand we can show you a T-Rex skeleton rig to get a taste:

https://drive.google.com/file/d/0BwboCvm6PSvBTFVpbW8tVkJRMnM/view?usp=sharing

All mechanical entities in the scene from articulated joints and motors of the Rex to the environment obstacles were simulated by APE. The ground reaction force at the Rex's feet as it is traversing the terrain under constant disturbance is very challenging to simulate right with precision. If you had tried to simulate this level of fidelity of ground reaction to a heavy articulated rig with the off-the-shelf Unity/PhysX combo you would know what I'm talking about.

Cheers,
Avatar Physics
deepmotion.com/avatar

 

@ArticulatedPhysics Oh yes, I do know what you are talking about.

I've managed to get some improvements under Unity PhysX, but I'm limited by the oft-buggy or limited implementation of PhysX itself within Unity. Which makes it hard for me to know even what PhysX might be capable of externally, but since I'm working in Unity it doesn't matter much.

So, now... how do we get APEngine to a beta? Or alpha? For us to have some fun with it and give you back some real-world use-cases?

 

Am I missing something? You cannot have both here and you have to make a choice. We are talking about a case where the jointed pieces are pushed into an impossible situation by a kinematic object. There is no way to solve it correctly - in the real world something would break here. So you can either sacrifice joints (what PhysX does) and let them bend past their limits, or sacrifice collision (what APE does I assume, if it's using Featherstone) and let the joints go through geometry. One way or another you have to make a design choice here.

FWIW collision & joint constraints are modeled as the same thing, and they are solved together. There is only one system and each of the "passes" (i.e. solver iterations) goes over both collision & joint constraints the same way. But the order in which you iterate over constraints has an impact on the final result. You can iterate over the contact constraints first, or the joint constraints first, or randomize the order, etc. When the system has a solution, the ordering doesn't matter much. However when the system has no solution, as in David's case, it makes a difference.

With all due respect, if you don't let users choose then you are making the decision for them. It is also an "an artificial limit forced upon users by a design choice".......... David's case is interesting because he's also the one who came up with the ragdoll issue that led us to this design decision. So the same customer has two different articulated systems, but one of them (the ragdoll) needs contacts to have precedence over joints, and one of them (the mech) needs the opposite. How do you please everybody if you don't let users choose? Remember: these are non-natural cases that cannot be solved "properly"... The mech foot is already in the ground. You cannot move away the kinematic leg. What do you do? Your video looks very nice but it doesn't show that case.

As for projection, it is certainly a "hack" but... isn't Featherstone using exactly the same under the hood? It's a more noble, glorified hack because it's part of the solver now, but in essence doesn't it do the same kind of things? Correcting the poses by moving the objects or ignoring the undesired motions in the first place isn't that different. You still end up with a mismatch/error between poses and velocities, as far as I can tell.

Anyway I think PhysX has the right idea: it doesn't choose for you. If you want performance, you can use the default solver. If you want Featherstone, you can use articulations. It's up to you, we do both.

Yes, that's exactly what we did People all started with exact solvers. And then tried to make things fast, and realized that they had to cut corners to meet the performance goals.

There is a reason why Havok, Bullet, PhysX, all switched to iterative solvers. That's not because we like hacks or we cannot do "real" physics or something. That's because iterative solvers offer the best middleground / compromise between quality & performance. And one great feature is that users can tweak the compromise themselves by using more or less solver iterations. They have a physics CPU time budget, and they can tweak the engine accordingly.

With exact solvers, you do get the "artificial limit forced upon users by a design choice" that you criticized. You chose accuracy over performance. And then if things are not fast enough, users are stuck. So the fact that things work "out of the box" is a double-edged sword if there's no way to make it run quickly on a PS3 SPU, or a WiiU, or a mobile platform without a strong CPU, etc.

Last week again I suggested to halve the timestep for improving a joint behavior problem in PhysX, and I was told that this wouldn't fly on a mobile, where physics was already too slow. In other words, even the performance-oriented PhysX is still too slow for a lot of people. Most of the support I do is about this - performance & memory usage.

So your principles are sound. But I suspect you will have to bend them a bit if you want to please all your customers. After all you're not the first one going down that road: Dynamechs, Newton, Algoryx, etc, all said the same thing in their time. Then Dynamechs died. Newton gave up and switched to iterative solvers as well. Algoryx is used in simulators and serious apps, but nowhere in games. Etc. I think it would be a mistake to ignore this and dismiss performance as an afterthought that one can fix later. For better or worse, it's very important to customers. Most of them have a tight CPU budget and they cannot afford more than a couple of ms per frame for physics - and that's the whole physics, not just one mech running around. That's pretty much the only reason why Havok / PhysX / etc all focus so much on performance.

- Pierre

 

Count me in as well. I'd like to add APE to PEEL (a tool used to compare physics engines, it can run the same scenes in Bullet / Havok / etc). If it wouldn't be such a maintenance nightmare for Unity, I would suggest that they could switch their physics to PEEL's "physics interface" and then use separate plugins for each of these physics engines. They wouldn't be tied to PhysX anymore, they could use any physics engine they want. And most importantly, users could choose (a bit like what happens with renderers: AFAIK you can use either D3D or OpenGL in Unity, it's the same principle).

- Pierre

 

Hmmm I might have been wrong here. I didn't know but they even have a Unity plugin! http://www.algoryx.se/products/agx-dynamics/#tab-6

So they might be the real competition for APE, more than PhysX.

 

that algoryx seems like the thing I need, I am currently making a firefighter simulation game and I just noticed how useless regular joints are when trying to make something as complex as a hose, the simulation is ok if you have to drag it around, but try to wrap it around a collider and it just won't work (or even simpler, just try to pull it around a corner)

There are other ways of "simulating" a hose (which aren't physical simulations) but I really would like to behave it as in real life or close to.

I feel depressed once again, can someone remember me why we decided to become programmers?

 

I can only show once again that PhysX can do that with articulations.

With regular joints you could try to add extra distance constraints between the elements of the hose (e.g. between object i and i+2 in the chain). I suggested to the Unity devs that they could expose a Rope object, which would do all the necessary tricks under the hood without the need to actually expose everything to users. It could even silently use articulations underneath. I think it could be quite useful as a temporary solution.

 

Thank you for showing me that,
I'll add it to my list of "why unity could be a great engine but never will"

I don't think we'll see that implemented in any short period of time, release is a couple of months away and I don't see any mention of articulations in the upcoming unity 5.4 version.

I would implement it myself, but of course you can't do that either.

I am doomed

 

@nsxdavid: Feel free to sign up our Beta online. It will take us sometime to get it ready.

 

"projection" is a kinematic hack and it has all sort of problems. we shouldn't kinematically pop the feet of a ragdoll into the ground in the first place.

Thank you for the history information. It's irrelevant to APE. We don't bend our principles. And we never said our goal was to "please all your customers". As a matter of fact we set out solving our own real pain during joint & motor simulation and then we thought the solution may help others.

 

@Terdiman With due respect, this thread is not for posting PhysX/PEEL demos since it is an external research environment and not relevant to Unity developers. Feel free to start your own thread if you want to share with us what could be possible in the future PhysX/Unity endeavor.

Avatar Physics
deepmotion.com/avatar

 

Love to sign up for the beta.... but um... could you point me to where said sign up is? I did sign up on your web site for updates, etc. but I don't think that's the same thing is it?

Also, sorry for perpetuating the PhysX discussion here.

So far APEngine looks amazing! It certainly seems to understand the way in which real-time physics needs to work for games.

David

 

That's all you need, David. We will send out Beta forms in batches to selected participants.

For everyone who is interested in helping us testing APE please register in our update form on the website.

Avatar Physics
deepmotion.com/avatar

 

Thanks. Done!

 

I think that would be the best plugin for Unity

 

I now have a question, since I found the Bullet physics engine on the Asset Store entirely free. What can APE do that Bullet cannot?
https://www.assetstore.unity3d.com/en/#!/content/62991

--IronDuke

 

We are adding the exciting "breakable articulation" support to APE so that a prebuilt articulation can be broken into pieces at runtime. The following are two prototype demos utilizing this new breakable articulation feature:

https://drive.google.com/open?id=0BwboCvm6PSvBV1d4QXJOX3h2NG8
https://drive.google.com/open?id=0BwboCvm6PSvBdjNfUkpqWDIwS1U

So no need to resort to the old soft joints in order to do destructible mechanisms. You will be able to build complex machines/creatures with robust joints and strong motors and at the same time enjoy online destruction capability !

Also we want to thank you all beta testers for the great feedback. We are recruiting more Beta testers right now. So if you are interested please go to our website (http://www.apengine.net/) to sign up !

Cheers
APE

 

It looks like the "Bullet physics engine" asset is a C# wrapper for the Bullet C++ native library. The code looks automatically generated from a class to class basis. It can be very useful for porting physics based games developed with Bullet into C#. However for production games you will have to bear the performance hit: the per API pInvoke marshaling cost and the memory overhead of the C# class wrappers for every Bullet class. I wouldn't adopt this approach for a production project myself.

 

Thanks.

--IronDuke

 

Quick question for developers: in 2017, which platforms are going to be focusing most of your development on?

 

For me, just desktop. (PC, Mac, and Linux.)

--IronDuke

 

same

 

Can't say for sure, but it should be PC or Android (or both).

 

We are getting very close to launching the full release of APEngine, so if you're a beta tester, it would be a great time to provide us with feedback!

 

Hi ArticulatedPhysics!
We're currently working on a vehicle-creator based game
called Homebrew Vehicle Sandbox (http://steamcommunity.com/app/325420/) and we'd love to do some testing with APEngine, more specifically the hinges (which is what we're implementing currently.)

Is there any way we'd might get a beta somehow? I've already signed up through the beta page a while ago, but haven't had any reply yet.
We also have a pretty big group of beta-testers who'd love to get their hands on hinges, so there will be plenty of feedback!
We think Homebrew Vehicle Sandbox would be a perfect testing environment for the physics implementation

 

This is incredible. I've spent a few hours a night for almost an entire month building a rope in unity, but its main purpose is to be very light but drag something very heavy, and I'm having the exact problems highlighted in this thread.

Had tried every permutation of settings, types of joints, scripting, etc. and have come pretty close to getting what I want, but could never fully get it to work... and now I've learned why!

I am extremely interested in using APE, as it's literally exactly the solution I didn't know I needed. Visited the site and the forum there seems pretty dead, but then again the most recent posts in this thread are from just a week or two ago, so is APE actually nearing release? Also any indication of rough price ballpark? Finally, will it run acceptably on mobile devices?

 

What platforms are you going to support initially? (it's written in c++ and access through a DLL right?)

 

Hello,
some days ago i wrote a bug report and a feature request on the APE forum, but I didnt receive any feedback.
Is it better to write our feedback here? Btw, now the APE forum seems down.

 

Hi Igniuss,

Your project looks awesome! And it seems a great fit for APE's design. We will take a look at your Beta request as soon. Also welcome to bring your group to our Beta program and ask them to sign up on our webpage. Sorry for the delay in processing the Beta requests. We were overwhelmed recently due to the holiday season.

AP

 

Thank you for your interest. Please sign up the Beta on the website http://www.apengine.net/ to request for a Beta build. The tentative release date of APE is January 2017. It runs on iOS just fine. Android support is on our roadmap too. The initial release may only include x86 platform. We will see.

 

x86 (Windows and MacOS) initially. iOS, PS4, Android in the future.

 

We'll check the forum. Thank you for reporting the problem.

 

The very first physics based giant robot VR combat game powered by APE will hit Steam on 12/15 !

https://vr.reddit.com/r/Vive/comments/5fmyxm/

 

Great, thanks. Do you know when iOS support would be added? And also a rough ballpark cost? I'm trying to decide whether to wait and include this in my project or just work around Unity's physics shortcomings, and those two answers would let me make that decision.

 

Hah, that actually looks really fun! (And exhausting.) And the robots shown there moved in a very realistic manner. I'm impressed.

--IronDuke

 

iOS version was already working, at least a few months before. we just need find some time to QA it and fix possible bugs/regressions. Price will be in par with other high-end Unity asset store engine/tool products. We will hopefully release the initial version (PC only) Jan/Feb next year.

 

Hello,
is it possible to add the monster truck example? I think that this is one of the most interesting use cases of Apengine.

 

Sure, just queued a ticket for it.

 

New PhysX vs APE demo for a piston crawler:

https://drive.google.com/file/d/0BwboCvm6PSvBcjhGUDR3c0k5SEU/view?usp=sharing

 

Demo: Crawler Vehicle (simulated by APE) + Humanoid Driver (simulated by ACE)

https://drive.google.com/file/d/0BwboCvm6PSvBYmZqWTBTLVBWZEk/view?usp=sharing

Avatar Physics
deepmotion.com/avatar

 

Ok great, thanks for the reply. Apologies for asking again, but I still don't really have an answer on either question...

So for the iOS build, do you think it would be soon after the initial release, or more like 6-12 months after or more?

And for price, unity asset store tools range wildly. I appreciate you not wanting to nail down a price at this time, but can you at least tell me if it would be closer to 100 or 1000?

Just hard for me to justify waiting if the time and price are both essentially unknown.

 

Also I signed up for a beta build, is there something else I need to do to receive it?

 

Has everyone checked out Fist of Physics on HTC Vive yet? It's the first commercially available game to use APEngine. We just received a great review on YouTube for the game from PhilantrhoPwn!

 

We are only one month away from launching APEngine. What incredible creations will you build with the most powerful joint physics tool on the planet?

 

Want to create a Crane Simulator

 

Oh, APEngine can totally help with that!

 

This weekend, the Midas Touch team will have a booth at PAX South in San Antonio. If you're attending the event, please drop by and say hi!

 

Ok, GDC attendees! We're going to be on-hand March 1-3 to show off APEngine - the first step in next-generation character physics! We will be on-hand to answer questions, and help you figure out how to make your awesome project even better with APEngine! On top of that, we will be showing off adorable VR puppies... and who doesn't love that? Come on by and say hello!

 

Hello ArticulatedPhysics,

Your system looks great! We'd like to try using it for our pretty complex quadruped ragdoll. A couple of questions, though:

1) Do you think your product is appropriate for ragdolls?

2) What kind of interactions with the regular Unity PhysX physics are possible? Can you collide with PhysX colliders? How about connecting joints to PhysX rigidbodies? I'm asking because we currently use PuppetMaster for characters that are animated (with regular animations) while respecting physics, and PuppetMaster uses PhysX of course.

3) It seems your system is very focused on simulating physics in a correct way. How does your system behave if I create an illegal situation? I need to create and destroy joints on the fly and it's very difficult to make sure they're always 100% legal. Does your system explode in that situation or does it find the least disastrous way to break the rules?