Archive for the ‘PhysX SDK’ Category
NVIDIA PhysX SDK was updated to version 22.214.171.124
Since no updated release notes are avaialble, we assume that only minor bug fixes differs this release from previous one – 126.96.36.199
As always, you can download PhysX SDK 188.8.131.52 via Developer Support Center.
If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.
NVIDIA has released a first public version of PhysX SDK for Mac OS X.
Feature set is almost the same as for PhysX SDK 2.8.4 for PC, but unfortunately, Mac version is missing GPU PhysX support.
You can download PhysX SDK 2.8.4 for Mac OS X via Developer Support Center.
If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.
Interesting technical article, called “PhysX: An easy target?“, was posted by user Bohemiq Scali at Window Live blogs.
First part of the entry is dedicated to brief overview of PhysX vs AMD’s physics solutions topic, similar to our “AMD and PhysX: History of the Problem” article, and can be read briefly.
But second part is focused on recent PhysX and x87 theme, and original “PhysX87: Software Deficiency” article by David Kanter. Original statement of mr. Kanter sounds like “SSE can easily run 1.3-2X faster than similar x87 code“, and that’s where Scali gives him a full pack of criticism:
Kanter then makes claims about the gains that can be had from converting the code to SSE. He claims that SSE could quadruple performance in theory, and in reality a boost of more than 2x would be possible. Kanter claims that a modern optimizing compiler can easily vectorize the code for SSE automatically, and such gains could be had from just a recompile.
So nVidia is just leaving all this performance on the table. What’s more, if PhysX would indeed be 2-4 times faster on CPU, it would actually be a threat to GPU-accelerated physics. Kanter claims that PhysX is hobbled on the CPU, and that nVidia is deliberately doing this to make GPU physics look good.
while, actually, “magic” SSE powers were a little exaggerated, since recent tests (#1; #2) with no-doubt SSE optimized Bullet physics engine have shown that
In synthetic tests, there is about 8% to be gained from recompiling. This is nowhere near the 2-4x figure that Kanter was using. In fact, 8% faster PhysX processing would mean even less than 8% higher framerates in games, since PhysX is not the only CPU-intensive task in a game.
Perhaps the net gain in framerate would be closer to 3-4%, depending on the game. In other words, recompiling PhysX with SSE would not make CPUs threaten GPU physics. Not even close. The difference would be lost in the margin of error, most likely.
but in spite of this
Kanter’s article, wrong as it may be, is linked on many news sites and forums all over the web, and many discussions ensue. Most people buy into Kanter’s article, and some sites make even more bold claims than Kanter himself, referring to Kanter’s article as ‘absolute proof’ of nVidia’s evil actions. This is exactly what AMD needs.
You may found Scali’s article biased (AMD conspiracy theory and stuff), but it is worth a read as it has common sense. Give it a glimpse, and share your thoughts.
Also, don’t forget that PhysX SDK 2.8.4 already includes SSE2 compiler option, and should be included into next release of FluidMark, so we’re hoping to perform some tests soon.
Newest PhysX SDK 184.108.40.206 is ready for public beta testing – this is last and most stable current generation SDK, next one is going to be 3.0.
In addition, SDK 2.8.4. will be used as basis for upcoming APEX 1.0 toolset.
[18.08.10] Update: Release notes were supplemented with “driverless” mode description.
[19.08.10] Update #2: bug in the PhysXLoader code, that was preventing it from loading the local DLLs in 2.8.4, is now fixed. Replace the PhysXLoader.dll and PhysXLoader64.dll in your SDK installation with the new files from the archive “2.8.4_Loader_patch.rar“, found in the 2.8.4 folder on the developer download site.
[20.08.10] Update #3: PhysX SDK 220.127.116.11 with fixed PhysXLoader .dlls and included (previously missing) PhysXDevice.dll – is ready.
Currently, binary builds are available for 32- and 64-bit PC Windows, and Xbox 360
- Removed PhysX Loader source code from source distribution. THIS WILL BE REVERTED FOR RELEASE. PhysXLoader code will be supplied to source licensees.
- Discontinued the Training Programs.
- Added source code of NxTetra (tet-maker) utility to source distribution.
- Removed spin waits from sample code.
- Added API to permit the user to specify the order in which compartments are simulated.
- Added compression limits to cloth.
- Cloth simulation no longer performs prediction for kinematic rigid bodies for improved interaction behavior.
- New driverless loader option for PC CPU distribution. In 2.8.4, application developers must ship PhysXCore.dll, PhysXCooking.dll, the cudarXX_XX_X.dll and physxdevice.dll with the application ‘locally’, in the directory where the .exe is located:
1. The application requests PhysXCore or PhysXCooking (v 2.8.4) from the PhysXLoader.
2. PhysXLoader searches for another DLL called ‘PhysXUpdateLoader’.
3. If PhysXUpdateLoader is not found, PhysXLoader will load the local PhysXCore or PhysXCooking.
4. If PhysXUpdateLoader is found, it looks for an updated replacement for the PhysXCore or PhysXCooking dlls.
5. If PhysXUpdateLoader cannot find the specified replacement DLL, PhysXLoader will load the local PhysXCore or PhysXCooking dlls.
6. If PhysXUpdateLoader can find the replacement DLLs, these will be loaded in place of the local PhysCore or PhysXCooking dlls.
7. The net result is that the developer has more control over the game installation process, doesn't have to worry about shipping a large System Software with the game, doesn't have to worry that the player will break his System Software somehow, etc.
According to NVIDIA, new 18.104.22.168 PhysX SDK for Linux (both 32- and 64-bit versions) has passed QA process and is available for beta testing.
If you want to participate in beta program, you need to send your request to
(Provide a description on how are you planning to use the Linux SDK - number of beta testers is limited)
Long awaited event actually, cause after old 2.8.1. SDK many developers have thought that PhysX SDK for Linux was completely abandoned. From now on Linux SDK will be updated accordingly with PC versions.
As everyone else, we have very little information about next major release of PhysX SDK – 3.0, which was rumored as complete rewrite of current SDK, full of new features and extended capabilities, currently kept under straight NDA.
UPDATE: PhysX SDK 3.0 has been released
However, few pieces of information are beginning to leak:
Today, as answer to all the hype about PhysX and SSE instructions, Nvidia’s senior PR manager Bryan Del Rizzo has stated in interview to THINQ.co.uk website, that new SDK 3.0 will feature “a task-based approach that was developed in conjunction with [Nvidia] Apex product to add in more automatic support for multi-threading“.
In generally, SDK 3.0 will automatically take advantage of however many cores are available, or the number of cores set by the developer, and will also provide the option of a “thread pool” from which “the physics simulation can draw resources that run across all cores“. – adds THINKQ.co.uk
We will keep an eye on all SDK 3.0 traces and post new info as we’ll find it.
Another paper called “Real-Time Simulation of Large Bodies of Water with Small Scale Details” (you can find previous one, Wrinkle Meshes, here) has arrived from Dr. Matthias Müller-Fischer, PhysX SDK research lead at Nvidia Switzerland.
Paper is decribing hybrid grid- and – particle based fluid solver used in latest, and technically most impressive, demo from Nvidia – Raging Rapids Ride.
We present a hybrid water simulation method that combines grid based and particles based approaches. Our specialized shallow water solver can handle arbitrary underlying terrain slopes, arbitrary water depth and supports wet-dry regions tracking. To treat open water scenes we introduce a method for handling non-reflecting boundary conditions. Regions of liquid that cannot be represented by the height field including breaking waves, water falls and splashing due to rigid and soft bodies interaction are automatically turned into spray, splash and foam particles.
The particles are treated as simple non-interacting point masses and they exchange mass and momentum with the height field fluid. We also present a method for procedurally adding small scale waves that are advected with the water flow. We demonstrate the effectiveness of our method in various test scene including a large flowing river along a valley with beaches, big rocks, steep cliffs and waterfalls.
We still hope that this solver will make it into next, 3.x release of PhysX SDK.
In addition, demonstrational video is available (61 mb)
David Kanter from RealWorldTech.com in his “PhysX87: Software Deficiency” article has hypothesized that origin of slow execution of PhysX content on CPU is fact that PhysX SDK is mostly based on x87 rather than faster SSE instruction set.
“On modern CPUs, SSE can easily run 1.3-2X faster than similar x87 code” – stated Kanter.
However, TGDaily has managed to recieve commentaries from Bryan Del Rizzo, Nvidia spokesperson
[And although] our SDK does [include] some SSE code, we found [that] non-SSE code can result in higher performance than SSE in many situations. [Nevertheless], we will continue to use SSE and plan to enable it by default in future releases. That being said, not all developers want SSE enabled by default, because they still want support for older CPUs for their SW versions.
Update: official responce from Nvidia – We’re not hobbling CPU PhysX
Update #2: some more Nvidia statements at this ars technica article
Update #3: and more at Hothardware.com article “NVIDIA Sheds Light On Lack Of PhysX CPU Optimizations”
But lets get back to original article. According to David, sole reason for PhysX SDK to rely on outdated x87 instruction is to make “Nvidia GPUs looks a lot better than the CPU“. This idea was inherited other websites, like TechReport.com
The PhysX logo is intended as a selling point for games taking full advantage of Nvidia hardware, but it now may take on a stronger meaning: intentionally slow on everything else.
and Semi Accurate
In the end, there is one thing that is unquestionably clear, if you remove the de-optimizations that Nvidia inflicts only on the PC CPU version of PhysX, the GPU version would unquestionably be slower than a modern CPU.
Unfortunately, previous authors are missing few vital points: PhysX SDK is used in many games running on CPU, and physics level in those titles can be easily compared to physics content in games based on other “non crippled” physics engines, like Havok; nor there are any games, that can offer content, similar to GPU PhysX effects, but running on CPU with stable framerate.
And, most important, GPU can accelerate only few parts of PhysX code – rigid bodies, joints, raycasts, forcefields, broadphase, etc – rely purely on CPU, so what is the reason not to optimize those at the full potential, to make PhysX SDK more attractive for developers (and thus increase number of games with GPU PhysX support) ?! Something is telling us that reason “just to make GPUs look better over CPU” is not so obvious.
And what do you think ? Tell us in comments.
Dr. Matthias Müller-Fischer, PhysX SDK research lead at Nvidia Switzerland, Novodex founder and man behind many core PhysX algorithms, like Position Based Dynamics solver for cloth and soft-bodies, has published another interesting paper – Wrinkle Meshes.
We present a simple and fast method to add wrinkles to dynamic meshes such as simulated cloth or the skin of an animated character. To get the desired surface details, we attach a higher resolution wrinkle mesh to the coarse base mesh allowing the wrinkle vertices to deviate from their attachment positions within a limited range. The shape of the wrinkle mesh is determined by a static solver which runs in parallel to the motion of the base mesh. Our method can be used to automatically enhance a purely animated skin mesh with wrinkles which would be atedious task to do by hand.
The fact that the tessellation of the wrinkle mesh can be chosen independently of the structure of the base mesh can be used to control the look of the wrinkles. The locations of wrinkle formation can be defined by painting the maximum distance the wrinkle mesh is allowed to deviate from the base mesh. The second important application of wrinkle meshes is to add detail to simulated meshes such as cloth. Our method allows one to reduce the resolution of the simulation mesh without losing interesting surface detail. This speeds up the simulation, collision detection and handling and it reduces stretchiness. We show the efficiency and visual quality of the approach in a real-time setting.
In generally, that means more detailed cloth simulation with less resourse consumption. Previous research – Hierarchical Position Based Dynamics – was already added in PhysX SDK 2.8.3 so we believe that Wrinkle Meshes will appear in PhysX SDK or APEX Clothing module soon enough.
Also, you can download demonstrational video (63 mb)
Presentations from “Nvidia Game Technology Theater“, which were demonstrated at Nvidia booth on GDC 2010, are now live – slides and following sound accompaniment. Let’s take a look at those related to PhysX SDK and APEX toolset.
Update: main PhysX and APEX session are now available as slide decks and video records
APEX Clothing with 3ds Max by Gavin Kistner, Product Designer, NVIDIA
Gavin gives a quick overview of 2.0 PhysX plug-in for 3ds Max, and uses superhero character with cape to explaing full clothing authoring process. Personal love Gavin’s manner of talking.. funny guy
Physically Simulated Clothing By CCP (EVE Online) Using NVIDIA APEX by Vigfus Omarsson, Lead Technical Artist, CCP; Snorri Sturluson, Senior Software Engineer, CCP; Monier Maher, APEX Product Manager, NVIDIA
Include overall cloth sim benefits overview from CCP, clothing tools pipeline features demonstration with Maya, and, of course, authoring process with pretty female character. While authoring was done in Maya, actual simulation was running in “CCP engine” window, as stated by Vigfus.