Earlier this month, AMD critized Nvidia again, this time on crippling PhysX multi-threaded capabilities.

“When they bought Ageia, they had a fairly respectable multicore implementation of PhysX. If you look at it now it basically runs predominantly on one, or at most, two cores. That’s pretty shabby! I wonder why Nvidia has done that?” said Richard Huddy, AMD worldwide developer relations manager, in an interview with Bit-tech.com

“It’s the same thing as Intel’s old compiler tricks that it used to do; Nvidia simply takes out all the multicore optimisations in PhysX. In fact, if coded well, the CPU can tackle most of the physics situations presented to it.”

Tomshardware asked Nvidia for its responce for such allegations, and here is an answer by Nadeem Mohammad, PhysX director of product management:

I have been a member of the PhysX team, first with AEGIA, and then with NVIDIA, and I can honestly say that since the merger with NVIDIA there have been no changes to the SDK code which purposely reduces the software performance of PhysX or its use of CPU multi-cores.

Our PhysX SDK API is designed such that thread control is done explicitly by the application developer, not by the SDK functions themselves. One of the best examples is 3DMarkVantage which can use 12 threads while running in software-only PhysX. This can easily be tested by anyone with a multi-core CPU system and a PhysX-capable GeForce GPU. This level of multi-core support and programming methodology has not changed since day one. And to anticipate another ridiculous claim, it would be nonsense to say we “tuned” PhysX multi-core support for this case.

PhysX is a cross platform solution. Our SDKs and tools are available for the Wii, PS3, Xbox 360, the PC and even the iPhone through one of our partners. We continue to invest substantial resources into improving PhysX support on ALL platforms–not just for those supporting GPU acceleration.

As is par for the course, this is yet another completely unsubstantiated accusation made by an employee of one of our competitors. I am writing here to address it directly and call it for what it is, completely false. NVIDIA PhysX fully supports multi-core CPUs and multithreaded applications, period. Our developer tools allow developers to design their use of PhysX in PC games to take full advantage of multi-core CPUs and to fully use the multithreaded capabilities.

Source: nTersect Blog

You may be familiar with NxOgre – complex and pervasive PhysX SDK wrapper for Ogre 3D engine, used already is serious commercial games, like Zombie Driver.

User Caphalor, who founds NxOgre “bit too big” for his purposes, decided to create small and simple alternative wrapper, and called it compactly – OgrePhysX

Library is based on PhysX SDK 2.8.3 and supports following features:

- PhysX initialisation
- bind scene nodes or other “PointRenderable” implementations to actors
- mesh cooking
- shape parameter system
- raycasting, sweeps
- contact report

OgrePhysX discussion thread | OgrePhysX Google Code page

PathEngine, pathfinding and agent movement middleware toolkit, was updated to version 5.23.

Apart from other changes, like memory footprint and loading time optimisations, PathEngine 5.23 adds support for automatic ground meshes processing and building from third-party physics provider scene data – PhysX SDK and Havok.

PathEngine middleware was used in certain games, like Titan Quest, Stormrise and Pirates of the Burning Sea, and is going to be implemented into Metro 2033 and Just Cause 2.

Physics simulation component of Esenthel Engine was translated recently to PhysX SDK 2.8.3, which allows developers, among other things, to create 64-bit applications.

In addition, new SDK features, like hierarchical cloth solver or cloth constraints, can help to advance clothing simulation via Esenthel even further (current status is shown on a video below).

Even developed by one man – Grzegorz Slazinski – Esenthel is “complete game development suit“, which includes graphics renderer, physics, GUI, networking, animation system, etc.

User’s opionions on this engine are fairly positive.

Source: Esenthel forums

This week is rich in leaked PhysX tools and software: 9.09.1112 drivers previously, and now – new beta PhysX 2.0 plug-in for 3ds Max. This plug-in was unavailable even on Dev. Support Center, only by personal e-mail request.

New plug-in  supports both 32- and 64-bit versions of 3ds Max 2008, 2009 and 2010. Features overview is located here

Download via Rapidshare (download limit reached)

Update: PhysX plug-in v2.01 for 3ds Max released

Source: sinefx.com

November’s Nvidia Developer Newsletter #49 has brought some very interesting material – 50 min. long video of “Creating Immersive Environments With NVIDIA APEX” session from SIGGRAPH 2009 conference.

It contains in-deph overview of all APEX Modules (FYI, APEX is artist focused framework on top of PhysX SDK), new details and demos, never shown before. Must watch for PhysX developers and people who are simply interested in PhysX future.

Download video (197 mb.)

Browsing certain forums we’ve realised that recent changes in PhysX SDK access procedure weren’t clear enough for some developers, and they now experiencing problems with PhysX dev. account registration.

ATTENTION !

Free binary versions of PhysX SDK, DCC Tools (PhysXLab, PhysX plug-ins) and APEX SDK are now available through Registered Developer Program.

Following guide in only valid for source licensees.

UPDATE: If you have trouble with new account registration or existing account (dissapearing downloads, unable to log-in, etc) you can send your problem description to support@physxinfo.com (with subject – “PhysX account”) – we’ll try to provide a shortcut to PhysX dev. team.

Thus, we’ve decided to put-in small registration guide and contacted Nvidia PhysX team to recieve some commentaries.

STEP 1. Go to PhysX Developer Support Center and click “Sign in” (upper-right corner)

STEP 2. Click “Request a New Account Button”

PhysXInfo.com: What are requirements for participants in general ?

PhysX SDK Manager: Our only requirement is that developers complete the registration form completely and accurately. In general, we reject most accounts because they do not provide a real name but in other cases, developers try to get cute with answers to questions and then we reject them. PhysX has real value in game development or simply studying about game development; therefore, we require that they register with accurate and complete information, they keep the information current, and that they log into their account within any 6 month period. If they provide email address which are not accurate, then we will also delete their account.

Read the rest of this entry »

Accessibility of PhysX SDK binary PC version was changed recently. PhysX SDK is still free but no longer available for public download,  to get access to SDK and tools you must register an account at PhysX Developer Support website and wait until it’ll be approved. As we were told, that will help Nvidia to “have more insight into how it (SDK) is being used.”

Actually, that’s how things were organized in Ageia times. Support forum, as well other PhysX pages will remain on their current places.

Our PhysX Developer account registration guide

32-bit and 64-bit builds of newest PhysX SDK 2.8.3., along with 9.09.30 PhysX System Software are available for download at PhysX Developer Support site, but we think it won’t take long until SDK will appear as public download.

Update: Changes in PhysX SDK access procedure

Meanwhile, some highlights from Release Notes:

General

• This release enables clothing simulation. These new features are required to run the APEX clothing module.
• The release also adds a hierarchical solver for cloth (HPBD Solver).
• Introduction of split pair notification for cloth (existed for soft bodies only in previous versions).
• Improved statistics to track GPU memory utilization.
• Updated with 64Bit Windows support.

Performance

• The hierarchical cloth solver runs before the regular solver at each time step. This does not immediately improve cloth simulation performace. However, running the hierarchical solver achieves the same stiffness of the cloth with fewer solver iterations of the regular solver. Thus, the performance is increased by explicitly reducing the number solver iterations.
• Added support to run force field updates on the scene’s worker threads.

Fixed Bugs

• NxArray::insert() did not work properly if elements were inserted anywhere else than at the end of the array.
• Crash when fluid tries to access invalid convexes. Mirrored convexes can get corrupted when a heap allocation fails.
• GPU fluids: Force and deletion updates are performed on wrong particles in case the updates address particles that have been added since the last execution of NxScene::simulate().
• GPU fluid mesh collision kernel crashes on GT200 cards due to heavily unbalanced workload.
• GPU fluids: Releasing static primitive rigid body shapes has no effect on particle collision.
• Concurrency issues with multi compartment scene configurations.

Ervin Coumans, creator of “Bullet” open-source physics engine, has posted some interesting facts at bulletphysics.com recently. According to article in August 2009 issue of Game Developers Magazine, covering middleware survey results (over 100 senior developers of various development companies surveyed), Physx SDK have the lead with 26.8% in physics libraries rating, next is Havok with 22.7%, third – Bullet at 10.3%, and finally – Open Dynamic Engine at 4.1%.

Source: bulletphysics.com