Newest PhysX SDK 2.8.4.2 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 2.8.4.3 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

RELEASE NOTES:

General

• 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.

Read the rest of this entry »

According to NVIDIA, new 2.8.3.3 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 PhysXDevSupport@nvidia.com

(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.

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.

Abstract:

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.

Abstract:

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.

Read the rest of this entry »

GDC 2010 (Game Developer Conference) is just about to start, and is going to be rich on PhysX related content this year. Apart from session on APEX Clothing integration with EvE Incarna we mentined previously, featured talks will include “Authoring Physically Simulated Destruction with NVIDIA APEX” and “Taking Fluid Simulation Out of the Box: Particle Effects in Dark Void“.

You can read session descriptions via provided links, but actually not only this has catched my eye. Nvidia GDC 2010 page was updated with schedule of presentations, that are going to be demonstrated at Nvidia booth #1702 at March 12-13

Those include such intriguing topics like:

Unity for Engineers – are they planning to demonstrate update physics system in Unity 3.0 ?

Authoring Runtime Animation with NaturalMotion Morpheme 2.3 – I’ve heard that Morpheme is going to be integrated with APEX Clothing, is that it ?

Softimage 2011 Enhanced with PhysX – next version of Softimage will include updated PhysX SDK integration ?

Streamlining PhysX Content in Max – is it related to rumored new physics system in XBR ?

Sadly I can’t visit GDC myself, but I’ll try to provide you with any open or insider information I’ll be able to gather

And yet another PhysX SDK textbook from Yoshikuni Okawa – PhysX & DirectX10. It’s like he got a cycle already, three months per new book.

Textbook is available for pushase at Amazon.co.jp

PhysX developers may be familiar with John Ratcliff – author of NxuStream (XML file format which is used to capture state of a PhysX SDK scene), Novodex/PhysX Rocket (physics demo application and editor) and other physics related researches.

In recent days John has updated his blog, known as John Ratcliff’s Code Suppository, with new usefull PhysX tools and code snippets:

PhysX2Obj – library that allows one to export a PhysX SDK scene as either a single Wavefront OBJ file in world space or a series of OBJ files in object space. Code has been compiled and tested with PhysX SDK 2.8.3 but should work with earlier versions of the SDK with little or no modification.

Library is available for download via Google Code page.

Tool with reverse purpose – Obj2PhysX - is going to be released shortly.

NvCoreDump is a windows 32 bit DLL which allows any PhysX 2.8.3 based project to perform an NxuStream XML compatible core dump in a single function call.

Rather than including all of the NxuStream source code in your application, instead you can simply demand load this tiny DLL and save it out.  The value, purpose, and benefit is to take simply add the ability to export the contents of the current PhysX SDK in any application by simply adding this tiny code snippet and the DLL.

Project is available for download via Google Code page.

Read the rest of this entry »