PEEL 1.1

PEEL 1.1 has been released. You can grab it here:

https://github.com/Pierre-Terdiman/PEEL

Here’s a copy of the release notes:

* January 2017: v1.1 - the PhysX 3.4 issue.

This new version celebrates the official release of PhysX 3.4 and its built-in support for GPU rigid bodies. There is now a “Use GPU” checkbox in the PhysX 3.4’s options panel. Just check that box to run the scenes on the GPU. It uses CUDA, so you need an Nvidia graphics card for this to work - and a recent one for good performance. Otherwise the regular CPU version is of course still the default, and it runs everywhere.

Many changes have been made over the last two years. Some of them are listed below:

PEEL app:

  • implemented smoother camera motion (when using cursor keys).
  • added support for prismatic joint limits.
  • added support for distance joints (only exposed in PhysX so far).
  • added support for cylinder shapes.
  • added support for articulations (PhysX).
  • added support for aggregates (PhysX). This improves performance of ragdoll scenes quite a bit.
  • added initial/experimental support for vehicles.
  • various test scenes have been added or revisited.
  • introduced support for configurable tests (per-test UI dialog). As a result, some similar-looking tests have been merged together.
  • added tool-specific UI to edit tool-specific parameters. For example the picking force can now be modified in the main UI.
  • added camera tracking tool.
  • added support for per-test keyboard controls etc.
  • improved wireframe overlay rendering (’X’ key). Now enabled by default.
  • new Pint caps have been added, as well as comments explaining their role better.
  • new test categories have been added.
  • tests can now access the font renderer to draw some debug text on screen. See for example the “AngularVelocity” test in the API category.
  • tests can now access the debug renderer to draw some debug data on screen. See for example the “COMLocalOffset” test in the API category.
  • replaced “ComputeWorldRay” with its ICE counterpart to fix some accuracy & performance issues in the raytracing test. The raytracing test became an order of magnitude faster after that.

Stats plugin:

  • now displays gravity vector.
  • added support for articulations & aggregates.

Bullet:

  • added new PINT plugin for “Bullet3-2.85.1″ (from Oct 15, 2016).
  • Bullet3-2.85.1: exposed more solver settings to the UI for this version. I also set the default “erp” value to 0.8 for this plugin, which improves the behavior a lot in jointed scenes like for example FixedJointsTorusStressTest. In previous Bullet plugins however I kept Bullet’s own default value (0.2) because increasing it to 0.8 creates “dancing stacks” (see e.g. LargeBoxStack30).
  • Bullet3-2.85.1: for this version I used 4 solver iterations by default, since this is what PEEL also uses for other physics engines. It should then be a little bit faster than before, since we used 5 iterations by default in the previous Bullet plugins (2.79 to 2.82). However I noticed that Bullet’s own default value is now 10 iterations. Not sure if this is really necessary. Play with the settings until you find a good compromise.
  • constraints are now properly released.
  • collision margin has been reduced. That way the ConvexStack2 test doesn’t explode anymore.
  • support for cylinders has been added.

Newton:

  • Newton’s PINT plugin has been revisited by Julio Jerez.
  • sleeping can now be deactivated (except in 3.14).
  • the per-test gravity vector is now taken into account (it was previously ignored).
  • we can now use Newton 3.9 and 3.13 at the same time: I just switched to static libs for 3.13.
  • the 3.13 libraries have been updated. It is now using the stable version from Jun 17, 2015.
  • added new PINT plugin for Newton 3.12 (from May 24, 2015).
  • added new PINT plugin for Newton 3.14 (trunk from Jan 3, 2017).

Havok:

  • better tracking of memory usage.
  • started to share code between all Havok plugins.
  • exposed more parameters to UI.
  • initial (incomplete) support for “articulations”. Currently disabled because it crashes in some scenes.
  • support for cylinders has been added.
  • support for kinematics has been enabled in old versions of Havok.
  • free versions of Havok are not available anymore (see https://www.havok.com/pcxs_redirect/) so I will not be able to add and test newer versions in PEEL.

PhysX 3.x:

  • the UI has been unified for all 3.x PINT plugins except 3.1.
  • new parameters have been exposed to the UI.
  • default contact offset value has been increased (decreasing performance here and there but otherwise increasing stability).
  • max angular velocity has been properly setup to a higher value in all PhysX plugins. The default value in PhysX is quite small, which makes some tests fail and perhaps give the wrong impressions.
  • added some quick preconfigured settings to tweak PhysX for either performance or accuracy.
  • the PhysX allocator (on the PINT side) is now thread-safe.

PhysX 3.4:

  • the PCM regression (in PEEL 1.01) has been fixed.
  • the overlap/sweep performance regressions (in PEEL 1.01) have been fixed.
  • the 3.4 architecture has changed significantly since the PEEL 1.01 version, to make the code compatible with GPU rigid bodies.

9 Responses to “PEEL 1.1”



  1. oscar Says:

    You say “It uses CUDA, so you need an Nvidia graphics card for this to work - and a recent one for good performance”..
    a two years old GTX 970 is expected to be running GRB faster than a fast CPU (Skylake 6600K)?

  2. oscar Says:

    Second comment is seems GRB is currently binary libary so no source code for it.. anyway as CUDA is supported on MacOS and Linux plans to distibrute GRB precompiled binary libraries for this two platforms..
    thanks..

  3. oscar Says:

    Sorry forget third question:
    is realtime GPU fracture (no precomputed) in 3.4?
    as shown on YouTube “NVIDIA GDC 2012 GPU Fracture Demo” or “Real-Time Dynamic Fracture Demo - GDC2013″ showing “Real Time Dynamic Fracture with Volumetric Approximate Convex.. ” Siggraph paper?
    hope if not, to hear some kind of early access to it @GDC 2017 similar to GRB was in early access since last year..
    also now with 3.4 with GRB seems the next big thing to have in say Physx 3.5..
    makes sense?
    thanks..

  4. admin Says:

    “a two years old GTX 970 is expected to be running GRB faster than a fast CPU” => honestly I don’t know. The GPU version has a high overhead (launching CUDA kernels isn’t cheap, etc) so even with a super recent graphics card, simple scenes will still run faster on the CPU. So it also depends on the complexity of the scene, not just on the type of graphics card or CPU you have. I am not one of the GRB devs so I only tried it myself with whatever I have in this machine (GTX 680). I think you should simply try a complex scene with and without ticking the “use GPU” checkbox, and see what you get…

  5. admin Says:

    “anyway as CUDA is supported on MacOS and Linux plans to distibrute GRB precompiled binary libraries for this two platforms..” => I don’t know, I will have to ask the right people. I suspect you would get better or faster answers to these questions on the PhysX 3.4 GitHub repository. I don’t actually know a lot about GRB myself (and even less about the plans to port it to X or Y).

  6. admin Says:

    “is realtime GPU fracture (no precomputed) in 3.4?” => there is no code to do the fracture itself inside PhysX 3.4. PhysX only simulates the fractured parts after the fracture happened, but the code generating the fragments is not “PhysX”. It was just some research code from Matthias Müller I guess. I don’t know if we have plans to release that but I can ask.

  7. admin Says:

    “a two years old GTX 970 is expected to be running GRB faster than a fast CPU” => I am told the answer to that one is “definitely” :)

  8. admin Says:

    I hear that “Linux support exists and should be released. It only supports linux64 due to the CUDA team dropping linux32 support. MacOS is technically possible but it’s not a platform we’ve supported before for GPU accelerated PhysX because there isn’t that much demand AFAIK.”

  9. oscar Says:

    Many thanks for all responses..
    Good news GRB is fast in GTX970 and Linux GRB is coming too..
    I would be interested (and more people I asume) in hearing about fracture code and if also supports well using both either CPU Physx or GRB.. Nvidia could release as additional Physx “plugin” either in source code or binary form..
    Will ask in Github site also to see response I get..

shopfr.org cialis