• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Nvidia PhysX FLEX

Caporegime
Joined
24 Sep 2008
Posts
38,284
Location
Essex innit!
As seen in TWIMTBP in Montreal, Nvidia have released some more info about the upcoming Flex. It is to be a stand alone tech and independent of PhysX. This looks very promising to me and will be working alongside PhysX 3.3.x for early adopters and then included in PhysX 3.4 as a first class feature.


PhysXInfo.com: So what is the NVIDIA FLEX exactly ? What are the main features of FLEX ?

Miles Macklin: FLEX is a multi-physics solver for visual effects.

It grew out of the work I did on Position Based Fluids, which was later extended to support two-way coupling between liquids and different object types such as clothing and rigid bodies.

The feature set is largely inspired by tools like Maya’s nCloth and Softimage’s Lagoa. The goal is to bring the capabilities of these off-line applications to real-time games.


The types of materials that FLEX is designed to simulate are:
  • Liquids (water, goo)
  • Granular materials (sand, dirt)
  • Environmental cloth (flags, newspapers)
  • Rigid bodies (environmental debris)
  • Soft bodies (inflatables / tetrahedral meshes)
  • The solver uses a unified representation for all these material types,
  • which means they can interact with each other in a fully coupled way.
However this unified representation also comes with some limitations. It wouldn’t, for instance, be suitable to use for a character controller, or ray-casts. Those would still be better suited to a traditional rigid body physics engine.

Some key Q&A's :)

PhysXInfo.com: Is collision detection in FLEX re-using some of the PhysX SDK algorithms, or is it completely new pipeline?

Miles Macklin: It is a separate solver and does not share the collision detection pipeline with PhysX.

That means you can use FLEX by itself (independent of PhysX) but need to manually mirror collision objects into FLEX for them to interact. FLEX supports most standard collision primitives to make this easy.

When FLEX is integrated into PhysX 3.4, manual mirroring will not be required.

PhysXInfo.com: Will FLEX support cross-PhysX SDK and/or APEX interactions? For example, can FLEX liquid crush a destructible asset?

Miles Macklin: Two-way coupling between different materials works best when they are all part of the same solver, but in theory you could use a FLEX liquid to affect a traditional destruction asset with some code to arbitrate between the two.

PhysXInfo.com: Are the authoring tools planned for FLEX? Is it going to support LOD and scalability features, similar to APEX?

Miles Macklin: It is likely that we will build authoring tools into at least one major game engine. I expect higher-level features like LOD will be built on-top of the core solver library.

PhysXInfo.com: Is FLEX purely GPU accelerated library, or will it support CPU execution? Is it plausible to see FLEX ported to OpenCL or DirectCompute?

Miles Macklin: Right now we have a CUDA implementation and a DirectCompute implementation is planned. We are considering a CPU implementation.

I have also built FLEX for Linux (Ubuntu 12.04 64bit) and it works great, in some cases it is faster than Windows.

PhysXInfo.com: Are you planning to release FLEX for third-party developers? Is it going to be included in PhysX SDK or APEX package, or available as stand-alone SDK?

Miles Macklin: It will be initially available as a stand-alone SDK that can be used alongside PhysX 3.3.x for a select group of early adopters, and later FLEX will become a first-class feature of PhysX 3.4.

I often say that FLEX is a low-level library because the core solver interface is very minimal (a single C header file). So users who want just the solver can embed that into their applications and build tools on top of it, or they can use the tools we develop inside of PhysX / APEX.

PhysXInfo.com: What future have you prepared for FLEX – computer games or computer graphics?

Miles Macklin: Initially we’ll see FLEX in games, but I am particularly interested to see if we can apply it in offline graphics as well.

To date, NVIDIA FLEX looks like a huge leap for GPU accelerated physics, but will it gain enough momentum to become really popular? Time will tell.

  • a
  • s
 
I agree with a lot of the comments here and would like to see PhysX more in games. One thing people are failing to read or not understanding it, is Directcompute support as well as Cuda support.

This could very well be seen running on AMD GPU's as well As Nvidia in the future. :)
 
If it's independent of PhysX and can run on AMD GPUs without stupid licence terms, then it'd get used and would be good to have.

Is PhysX used to any extent in any games where nvidia hasn't paid them to use it?

It will be independent of PhysX.

As far as I am aware, Nvidia have devs that get involved in implementing PhysX into the games that use it (AAA titles). I have no idea about payments or care in truth.
 
I get the feeling this thread was 50% info and 50% troll, cuz Greg, you know you can't post anything Pro-Nvidia without it being pounced on!

To be fair the same is probably true for any Pro-AMD threads posted, except they seem quicker to shout 'fanboy' at anyone not immediately onboard with it (based on no actual facts, just the impression I get, hence why I said 'seem' and not 'are').

I purposefully left out commenting on the DirectCompute implementation from the OP to see if anybody read it before making daft comments. It seems a few didn't bother reading it and took it as another PhysX locked to Nvidia thread or I am not interested. :D

I was hoping someone would have read it though and pointed it out :(
 
The thing with PhysX that gets me is, if it's so dead and buried why is it every time it gets mentioned, certain people get up in arms about how it's propitiatory. By all means express how irritating it is not to be able to get to try it on AMD hardware, but half the time it feels as though people hate it purely because they cannot use it.

I see what you did there ;)

And I can understand the anger in a way. If TressFX was an AMD exclusive, I would have been disappointed. Such a little thing but I loved how the hair worked and found it made the game that little bit special (sad I know). If more and more games came out with that sort of effect and it was locked to AMD, I would be moaning about it.

To those that keep saying PhysX is dead, I say it isn't and it will be getting better in time ;)

Pay attention Roy!!!
 
It's fairly obvious how gimped Physxs if you look at Kaap's benchmarks he did with Titan's in the latest Batman - I mean come on, taking that kind of hit (20fps@1080p on minimums) on a freaking Titan just for reactive smoke and a swishy cape - get real :rolleyes:

I would like to see Kaaps benches now. Every time I have run a PhysX game, it has had quite a big impact on frame rates when the PhysX is in full flow. Oranges hit it on the nail by picking out 60fps with nothing going on in the background. Do you think that moving a cape or smoke in a real way will not impact performance at all?

I am a manual worker and know a little bit about computers but seems the forum truly has some experts who know better than Nvidia/AMD and all the game devs.

As for the Physics on the CPU in consoles, how you can compare that to GPU PhysX is a joke Humbug.
 
I can see these kind of effects becoming a reality with better optimizations and it is stated that one game is already on board.

Surely this can't be a bad thing?
 
Back
Top Bottom