After year of silence, OpenC1 project (previously known as OpenCarmageddon) – fan-made remake of classic Carmageddon racing game -  returns in a form of new and stable version 1.4.

OpenC1 utilizes XNA for graphics and PhysX SDK as physics engine. It implements almost all features of the original game (vehicles, tracks, vehicle damage and car deformations, pedestrians, AI and opponents, checkpoints, UI, etc) and can use data files (car models, levels, textures, sounds) from Carmageddon title and Splatpack add-on.

In comparison to 1.3.1 version, usability has been improved greatly – OpenC1 can now automatically download free content from Camageddon and Splatpack demos, it also includes data management functionality and is far more stable.

All you need is to download archive with 1.4 version from OpenC1 project page, extract it, install latest PhysX System Software, XNA Framework 3.0 and run the OpenC1.exe file.

New version of PhysX System Software is available. It contains bug fixes for recently released GPU PhysX games and provides support for 6xx GPUs.

• Includes the latest PhysX runtime builds to support all released PhysX content.
• Changes & fixed issues in this release
  • Fixed a bug that caused cloth (paper) to jitter in Batman Arkham City.
  • Updated SDKs for Alice 2 and other 2.8.4 applications.
• Supports NVIDIA PhysX acceleration on all GeForce 8-series, 9-series, 100-series, 200-series, 300-series, 400-series, 500-series, and 600-series GPUs with a minimum of 256MB dedicated graphics memory.

You can download PhysX System Software 9.11.1111 from NVIDIA website.

Today we have stumbled upon following article (and related post), that is promising huge framerate boost in Batman: Arkham City with GPU PhysX effects enabled by replacing certain APEX .dll file with same .dll, but from Mafia II title (which is also featuring APEX based GPU PhysX effects). We decided to perform a little research on this effect:

Author of this method is suggesting to replace original file APEX_Clothing_x86.dll, located in Batman: AC folder, with renamed APEX Clothing.dll from Mafia II installation. Both those libraries are used by APEX Clothing module (and are responcible for cloth and clothing simulation), but have different version – Batman’s .dll is related to APEX 1.1 and the one from Mafia II – APEX 1.0.

Thus, with APEX 1.0 library cloth assets in Batman are not recognized and not simulated – they are simply appearing on level in frozen state, hovering above the ground (like carpets and posters on a screenshot below).

Disabled cloth simulation is giving you desired fps boost, but you can achieve same effect by setting “Hardware Accelerated PhysX” option to “Normal” – this will switch off all cloth and clothing simulation, leaving only particle PhysX effects, without necessity to mess up the .dlls.

To measure the effect on performance, we have tested the game using various combination of .dlls and PhysX settings (High in-game settings, DX 9).

As we expected, there is almost no difference in framerate between “tweaked” .dlls on “High PhysX” settings and original .dlls on “Normal PhysX” settings, since effect is similar – disabled cloth simulation.

Nothing like “magic tweak that increases fps by using files from older game, because new one is hobbled by purpose” as one may expect.

Sum – Pros:

• Performace boost.
• PhysX cloth objects are not removed completely, as on “Normal” PhysX settings.

Sum – Cons:

• Frozen PhysX cloth objects without proper physical interaction may look out of place.
• Older APEX .dll may decrease game stability and disable cloth simulation, that is not part of GPU PhysX effects.
• Same effect can be achieved by switching PhysX option to “Normal”, without any potential negative backwash.

It is time to summarize what PhysX Technology has achieved in year 2011, recall the most memorable events and releases.

. GAMES

GPU physics acceleration still can not gain enough momentum – only two games with support for GPU PhysX effects were released this year, this is the lowest result since Ageia was aquired.

One may call this an agony, but NVIDIA has told us that it was “conscious decision” – time was taken to develop and improve underlaying technology (PhysX SDK, APEX, DCC tools), thus sacrificing ability to create content and  integrate it into many games.

It was promised that we will see “more GPU PhysX games next year than you did this year” and even “a lot more in 2013″.

Meanwhile, both GPU PhysX titles released this year were pretty interesting by themselves:

• Batman: Arkham City, one of the best games with hardware PhysX support.
• Alice: Madness Returns, which is a decent game too and is certanly worth more than two Darkest of Days.

PhysX SDK as physics engine is still widely adopted by developers – over 45 PC console and games were released this year, according to our database.

. PHYSX SDK & TOOLS

Looking on the SDK Development you can say where all resources were spent – brand new PhysX SDK 3.0, rewritten from scratch, optimized and enhanced with new features, was released in Q2 2011, followed by SDK 3.1 and SDK 3.2 Beta. 6-months release schedule was introduced and so far is impeccably fulfilled.

PhysX 3 is a strong technological foundation, that will ensure further expansion, evolution and success of PhysX as physics engine.

NVIDIA APEX 1.0, high-level scalable framework build on top of PhysX SDK, was also revealed for public along with UDK integration, however it can not boast with same release dynamics – new APEX 1.1, promised to be delivered this autumn is now postponed till 2012. APEX 1.2, fully based on PhysX SDK 3, is also supposed to be released next year.

DCC PhysX plug-ins went throught three versions – 2.6, 2.61 and 2.7 – but during this period several compatibility problems and significant delays of releases were faced.

. MISCELLANEOUS

MassFX – new physics simulation solution, using PhysX SDK engine, was introduced in Autodesk 3ds Max 2012, thus replacing Reactor system, which was based on Havok physics. Rigid Body simulation functionality of MassFX was pretty strong along with better performance, however many users were unhappy with reduced functionality set in comparison to Reactor.

According to yearly survey by Game Developer Magazine, PhysX SDK is preferred physics middleware solution for traditional (big-budget) developers.

PhysX Research Team has showcased some new interesting technologies and prototypes. Some of them will appear in future versions of PhysX engine.

After a long break, new 1.05 version of Hybrid PhysX mod was released to support recent drivers and GPU PhysX games in AMD + NVIDIA configurations.

. . .

Well, that is all for now.

Happy New Year to everybody !

NVIDIA has revealed PhysX SDK 3.2 Beta-1, thus providing early public access to next general release of PhysX 3, enhanced with many features and improvements – as a Christmas present, we suppose.

Update [25.01.2012]: PhysX SDK 3.2 Beta-2 is available

Binary SDKs are available for Windows PC, Linux, Mac OSX and Android platforms.

PhysX SDK 3.2 Beta-1/Beta-2 can be downloaded at Developer Support Center.

If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.

PhysX SDK 3.2 Beta-1/Beta-2 Release Notes:

General:

• Three new sample applications: SampleCharacterCloth (character with cloth cape and cloth flags), SampleBridges (character controller walking on dynamic bridges and moving platforms), SampleGravity (character controller with arbitrary up vector).
• On Windows, the PxFoundation instance is now a process wide singleton and part of the new PhysX3Common.dll library.
• PxCreatePhysics() does not create a PxFoundation instance any longer. The PxFoundation instance has to be created in advance through PxCreateFoundation().
• Calls to PxCreatePhysics() are not valid anymore if a PxPhysics instance already exists.
• If profiling information should be sent to the PhysX Visual Debugger, a PxProfileZoneManager instance has to be provided when creating the PxPhysics instance.
• The version number constant PX_PUBLIC_FOUNDATION_VERSION has been replaced with PX_PHYSICS_VERSION. Both PxFoundation and PxPhysics use the same version number now.
• The API now distinguishes between input and output stream types.
• Added mechanism to reduce code size by not linking optional components. See PxCreateBasePhysics() and the PxRegister*() functions.
• Added getConcreteTypeName() to API classes to provide run time type information.
• Added PxScene::getTimestamp() to retrieve the simulation counter.
• PxGetFoundation has been moved to PxGetFoundation.h
• Changed the functions PxPhysics::releaseUserReferences(), releaseCollection(), addCollection() and releaseCollected() to now take a reference rather than a pointer.
• The signature of PxCreatePhysics has changed: The Foundation SDK instance must be passed in explicitly. One can also hook profiling information by passing a PxProfileZoneManager.
• [Beta-2] Platform conversion for serialized data has been moved from the ConvX command line tool to the PxBinaryConverter interface in the cooking library.
• [Beta-2] Documentation has been updated.
• [Beta-2] Samples have been updated.
• [Beta-2] Various bug fixes.

Rigid Bodies

• Introduced a new contact generation mode, see eENABLE_PCM.

Persistent Contact Manifold (PCM) is a fully distance-based collision detection system, which uses the Gilbert-Johnson-Keerthi algorithm (GJK) and the Expanding Polytope Algorithm (EPA) to calculate one contact at the point of deepest penetration. It then uses an incremental method to build up a contact manifold by recycling contacts from past frames, accumulating up to four contacts per frame.

This approach is quite efficient in terms of performance and memory. However, it can reduce stacking stability when simulating with large timesteps, tall stacks and small objects. As this approach is distance-based, it will generate the correct contact points for arbitrary contact offsets/rest offsets.

• Introduced two new friction simulation modes, see eENABLE_ONE_DIRECTIONAL_FRICTION and eENABLE_TWO_DIRECTIONAL_FRICTION.

The Coulomb friction model is based on the Coulomb laws of friction. It is less efficient than the default friction model and it can require more solver iterations to achieve stable stacking behavior. However, its friction behaviors are much closer to the analytical results than the default friction model so could be preferable for applications where accurate friction behavior is important.

The Coulomb model comes in two variants, one-directional and two-directional. The one-directional approach is similar in terms of workload to the default friction model and can be stable at similar solver iteration counts. Its behavior is closer to the analytical results but diverges slightly. The one-directional approach is a simplification of the full Coulomb model, in which the friction for a given point of contact is reduced to a one-directional friction model.

• Introduced a new scene query flag PxSceneQueryFlag::eINITIAL_OVERLAP_KEEP to control how initial overhaps are treated in scene queries.
• Per-triangle materials have been implemented.
• Changes to material properties are automatically reflected in contact resolution.
• New helper methods to compute mass properties for a dynamic rigid body taking per shape density/mass values into account (see documentation on PxRigidBodyExt for details).
• A new set of methods for overlap, sweep and raycast tests based on PxGeometry objects has been introduced. See documentation on PxMeshQuery and PxGeometryQuery for details).
• The contact report API has changed (for details see the documentation on PxSimulationEventCallback::onContact()). Among the changes are:
  • Reports only get sent for shape pairs which request them. Previously, reports were sent for an actor pair even if the requested shape pair event was not triggered (for example because other shapes of the same actors started colliding etc.)
  • The following PxPairFlags have been removed eNOTIFY_CONTACT_FORCES, eNOTIFY_CONTACT_FORCE_PER_POINT,  eNOTIFY_CONTACT_FEATURE_INDICES_PER_POINT.
  • Forces and feature indices are now always provided if applicable.
  • It is much easier now to skip shape pairs or contact point information when traversing the contact report data.
  • The memory footprint of contact reports has been reduced.
• The members featureIndex0/1 of PxContactPoint have been renamed to internalFaceIndex0/1 for consistency.
• For trigger reports, the eNOTIFY_TOUCH_PERSISTS event has been deprecated and will be removed in the next release. For performance and flexibility reasons it is recommended to use eNOTIFY_TOUCH_FOUND and eNOTIFY_TOUCH_LOST only and manage the persistent state separately.
• Added PxConstraintVisualizer interface and code to visualize joint frames and limits.
• Improved PxBatchQuery API.
• PxPhysics::getProfileZoneManager() now returns a pointer rather than a reference.
• PxRigidDynamic::moveKinematic() has been renamed to setKinematicTarget() to underline its precise semantics.
• Added new function PxShape::getGeometry and class PxGeometryHolder to improve Geometry APIs.
• Added new actor creation helpers PxCloneStatic, PxCloneDynamic, PxScaleActor.
• Added new functions PxTransformFromSegment, PxTransformFromPlaneEquation to simplify creation of planes and capsules.
• Some methods of PxAggregate have been renamed for consistency or replaced for extended functionality.
• getMaxSize() is now called getMaxNbActors().
• getCurrentSize() is now called getNbActors().
• getActor() has been replaced by getActors() which copies the actor pointers to a user buffer.

Particles:

• Removed descriptors from particle API: The properties maxParticles and PxParticleBaseFlag::ePER_PARTICLE_REST_OFFSET need to be specified when calling PxPhysics::createParticleSystem() and createParticleFluid(). All other properties can be adjusted after creation through set methods.

Cloth:

• Added convex collision shapes, see PxCloth::addCollisionConvex().
• Added friction support, see PxCloth::setFrictionCoefficient()..
• Added angle based bending constraints, see PxClothPhaseSolverConfig::SolverType::eBENDING
• Added separation constraints, a spherical volume that particles should stay outside of, see PxCloth::setSeparationConstraints().
• Added drag, see PxCloth::setDragCoefficient().
• Added inertia scaling, controls how much movement due to PxCloth::setTargetPose() will affect the cloth.
• Added support for setting particle previous positions, see PxCloth::setParticles().
• Added controls for scaling particle mass during collision, this can help reduce edge stretching around joints on characters, see PxCloth::setCollisionMassScale().
• Particle data is now copied asynchronously from the GPU after simulate (rather than on demand).
• Improved fabric layout, you can now share fabric data across multiple phases to reduce memory usage, see PxClothFabric.
• Fixed bug in collision when capsules are tapered at a slope > 1.

Vehicles:

• Added PxVehicleDriveTank, a vehicle class that enables tank behaviors.
• Support for vehicles with more than 4 wheels, see PxVehicleDrive4W, PxVehicleDriveTank.
• Significant refactor of vehicle api to allow further types of vehicle to be added.
• Americal English spelling used in vehicle api.
• PxVehicle4W replaced with PxVehicleDrive4W, PxVehicle4WSimulationData replaced with PxVehicleDriveSimData4W.
• Removal of scene query helper functions and structs: PxVehicle4WSceneQueryData, PxVehicle4WSetUpSceneQuery, PxWheelRaycastPreFilter, PxSetupDrivableShapeQueryFilterData, PxSetupNonDrivableShapeQueryFilterData, PxSetupVehicleShapeQueryFilterData. See SampleVehicle_SceneQuery.h for their implementation in SampleVehicle.
• PxVehicle4WSimpleSetup and PxCreateVehicle4WSimulationData have been removed and replaced with default values in vehicle components, see PxVehicleComponents.h.
• PxVehicle4WTelemetryData has been replaced with PxVehicleTelemetryData, a class that supports vehicles with any number of wheels, see PxVehicleTelemetryData
• PxVehicleDrivableSurfaceType no longer stored in PxMaterial::userData. A hash table of PxMaterial pointers is instead used to associate each PxMaterial with a PxVehicleDrivableSurfaceType, see PxVehicleDrivableSurfaceToTireFrictionPairs.
• PxVehicleTyreData::mLongitudinalStiffness has been replaced with PxVehicleTireData::mLongitudinalStiffnessPerUnitGravity, see PxVehicleTireData.
• Tire forces now computed from a shader to allow user-specified tire force functions, see PxVehicleTireForceCalculator.
• Added helper functions to quickly configure 3-wheeled cars, see PxVehicle4WEnable3WTadpoleMode, PxVehicle4WEnable3WDeltaMode.

What we removed:

• Deformables have been removed. Use the optimized solution for clothing simulation instead (see documentation on PxCloth for details).
• PxSweepCache is deprecated.
• PVD is no longer enabled in the release build.
• Removed anisotropic friction.
• Renamed PxPhysics::getMetaData() to ::PxGetSDKMetaData().
• Removed the CCD mode eSWEPT_CONTACT_PAIRS.
• PxActorDesc has been removed.
• [Beta-2] The ConvX tool has been removed.

We have added a set of comparison PhysX screenshots for Batman: Arkham City, which in pair with previously released comparison video are completing our GPU PhysX Profile for this title.

You can view comparison screenhots, video and additional info at Batman: Arkham City – GPU PhysX Profile page .

NVIDIA has uploaded new portion of video tutorials, covering various aspects of APEX Destruction authoring process using PhysXLab tool.

First set of tutorials is explaining creation and usage of Fracture Maps – simple black-and-white images, that can be used to specify fracturing pattern for cut-out fracturing mode.

APEX Destruction: Fracture Maps (Part 1) – Photoshop

APEX Destruction: Fracture Maps (Part 2) with PhysXLab

Second set of tutorials is showcasing multi-FBX import feature. If multiple parts of one object are imported at once, PhysXLab will recognize them as “depth 1″ chunks – thus, it is possible to pre-fracture asset in whatever manner you need (with Voronoi fracture, for example) before using it in PhysXLab.

APEX Destruction: Multi FBX (Part 1) – Prep in 3dsMax

APEX Destruction: Multi FBX (Part 2) – with PhysXLab

Supplementary files (models, textures, etc) for APEX tutorials can be downloaded here.

Previously released tutorials:

• APEX Destruction authoring with PhysXLab (Slice Fracturing, Cut-out Fracturing)
• New tutorials provide in depth view of APEX Destruction usage in UDK (Fracture Materials, Form Extended Structures, Impact Damage)

Updated PhysX 3.1.1, which adresses many issues found in SDK 3.1.0, is now available for download.

Update [11.01.2012]: PhysX SDK 3.1.2 available

• Fixed wrong write/read clash checks.
• Removed some compiler warnings from public header files.
• Fixed PxScene::getActors() returning wrong actors when a start index is specified.
• Fixed broken joint projection in connection with kinematics.
• Fixed inaccurate normals returned from height field scene queries.
• Fixed a crash when the geometry of a shape changes and then the actor gets removed from the scene while the simulation is running.
• Fixed a crash when re-adding scene-query shape actors to scene.
• Fixed crash bug in particle simulation code on GPU.
• Fixed a crash when GPU fabrics are shared between cloths.
• Fixed a hang in cloth fiber cooker when handed non-manifold geometry.
• Fixed SampleVehicle doing an invalid write.
• Fixed SampleVehicle jitter in profile build.

PhysX SDK 3.1.1 Release Notes:

General

• Ported samples to Linux.
• Fixed crash bug in ConvX.
• Fixed crash bug in the allocator code of PXC_NP_MEM_BLOCK_EXTENSIBLE.
• Fixed crash bug when connected to PVD on various platforms.
• Fixed bogus asserts due to overly strict validation of quaternions.
• Fixed one frame lag in PVD scene statistics.
• Fixed a number of OSX PVD sockets issues.
• Fixed SampleSubmarine code that violated concurrent read/writes restriction.
• Added warnings about read/write hazards to the checked build.
• Fixed RepX not reading joint properties.
• Fixed support for concurrent scene queries.
• Fixed PhysX GPU Visual Indicator support.
• Made it more clear in documentation that simulate(0) is not allowed.

Rigid Bodies

• eNOTIFY_TOUCH_LOST trigger events do now get reported if one of the objects in contact gets deleted (see documentation of PxTriggerPair for details).
• Dynamic rigid bodies with trigger shapes only do not wake up other touching bodies anymore.
• Added lost touch events for trigger reports when objects get deleted.
• Fixed dynamic triggers waking up actors they are triggered by.
• Removed an inapropriate assert from articulation code.
• Fixed problem with the angular momentum conservation of articulations.
• Fixed articulation sleep problems.
• Fixed a linear velocity related bug in CCD.
• Fixed crash bug CCD.
• Optimized performance of joint information being sent to PVD.

PhysX SDK 3.1.1/3.1.2 can be downloaded at Developer Support Center.

If you are experiencing trouble with registration of PhysX Developer account, please refer to our registration guide.

Time to update PhysX performance metrics of NVIDIA GPUs with newest title with Hardware PhysX support – Batman: Arkham City.

In following article we’ve tried to gather all the benchmarks and tests, published on the web.

[25.11.2011] Batman Arkham City im Technik-Test: Grafikkarten-, DirectX-11- und Physx-Benchmarks by PCGamesHardware.de

German article with graphics benchmarks, overview of DX 11 and PhysX features, and a superficial PhysX tests.

[25.11.2011] Batman Arkham City GPU Test by GameGPU.ru

Includes PhysX benchmarks with over 20 GPUs tested, however, only on “High” PhysX settings without Hybrid PhysX or dedicated GPU tests.

[27.11.2011] Preview: Batman Arkham City – výkon grafik pod DX11/DX9 a PhysX by DDWorld.cz

Czech preview article with very basic PhysX benchmarking part (only one GPU tested).

[28.11.2011] Want to play Batman: Arkham City with PhysX enabled? Get ready for some abysmal framerates by DSOGaming.com

Despite of provoking title, measured performance is not that bad. Also, this is the first article with benchmarks of dedicated PhysX GPUs.

[30.11.2011] Waiting for the patch: Batman: Arkham Asylum in DX9 mode by 3DNews.ru

Russian article with some PhysX/DX11 effects overview and decent PhysX testing.

[02.12.2011] Technik-Check: Batman: Arkham City im Benchmark-Test by GameStar.de

Includes some benchmarks with different PhysX settings. Results are interesting – GPU PhysX effects on CPU (AMD card) are faster that GPU PhysX on middle-end NVIDIA cards (in this case, minimum fps would be more meaning than average).

[02.12.2011] Batman Arkham City, DirectX 9 e DirectX 11 a confronto by HardwareUpgrade.it

Technology overview and minor PhysX testing.

[05.12.2011] Batman: Arkham City Gameplay Performance and IQ Review by HardOCP

Once again, disputable benchmarking methodology from HardOCP – NVIDIA cards are tested with GPU PhysX effects enabled and compared to AMD cards with PhysX disabled. Thus, it is shown what GPU PhysX takes – performance, but it is not revealed what it brings – additional effects.

[17.12.2011] Batman: Arkham City Performance Review by Playwares.com

Detailed article from a Korean website, however, PhysX part is most interesting for us.

[17.12.2011] Batman: Arkham City Graphics Breakdown & Performance Guide by GeForce.com

Performance and features overview from NVIDIA itself. Graphs are interesting, for example this one shows ineffectiveness of dedicated PhysX card usage in pair with GTX 560 Ti GPU.

[10.01.2012] Batman: Arkham City — podívejte se na PhysX a DX11 v akci by PCTuning.cz

Good technical review (in Czech) with strong benchmarking part (includes CPU tests, for example). For some reason, PhysX effects were tested only on “Medium” settings though.

– We’ll update this post as more articles emerge –

Batman: Arkham City, sequel to award winning Arkham Asylum title and second GPU PhysX game this year, has finally hit the shelves worldwide.

Update: Batman: Arkham City – GPU PhysX Profile

As usually, we are proud to present you our PhysX review and comparison video, showcasing extra physical effects that can be found in PC version of the game.

Can't view the video ? Watch alternative variant on Vimeo

Some technical details, like difference between PhysX settings, were already revealed in our preview article, so let’s give a score to different aspects of GPU PhysX implementation and compare them to previous Batman: Arkham Asulum title:

All effects are done accurately, with diligence – you will not see jerky or buggy behaviour (within physics engine limitations, of course), art is fine, almost everything is configured correctly. However, some particle effects could be done better – for example, it is not appealing to see when glass shards are jumping all over the place like they were made out of rubber.

PhysX effects are scattered all over the game and accumulated in a places you will visit during main storyline (for example, you won’t see dynamic paper sheets on a random street).

Overall amount of extra physics content is similar to Arkham Asylum, but the components differ: you won’t see many “environmental” cloth objects, like all those banners and flags that can be teared appart with batarang, but in return APEX Clothing module is used extensively to simulate dynamic clothing on characters, including hoodies and coats on thugs, pants on russian twin-clowns, costume of Bruce Wayne, etc.

SPH smoke, steam and fog are rare in this game, but other particles (physical debris, shards, splinters, sparks) can be encountered much more frequently. All boss battles are enhanced with unique particle effects, for example.

As a good tradition, there is psychedelic level with lots of GPU Rigid Bodies. Looks gorgeous, actually, without PhysX effects this scene feels not nearly as vivid and spectacular.

GPU PhysX effects are certanly enhancing gameplay experience, giving it a little more depth, color and vibrance, either by providing  momentum to the battles through particle debris or making the environment more believable with interactive objects.

If you are not expecting from PhysX content something it is not supposed to be (game changing or gameplay affecting feature), you will be satisfied.

At the same time, GPU PhysX support is showing a little progress in this title. Particles, cloth and stuff – we have already saw it in a games before. While PhysX effects in original Batman have received the top score, today we are forced to deduct a few points (back in 2009 most of the effects were fresh and innovative, but now “more of the same” content did not impressed us that much).

As always, hardware accelerated PhysX effects are requiring a powerfull NVIDIA GPU, however this time framerate with PhysX enabled is unusally stable (without infamous issues like spontaneous slowdowns in Alice: Madness Returns or half-GPU physics in Mafia II). On our single GTX 580, framerate was holding on 50-60 fps even in extensive PhysX scenes and never dropped below 30 frames per second.

Nevertheless, we are thinking that GPU PhysX requirements are over demanding, giving the level of physical effects found in the game.

Also, additional PhysX effects are slightly more friendly to CPU calculation this time (in case if you don’t have NVIDIA GPU), you even will be able to play certain parts of the game normally, but smooth gameplay is still a dream.

Hybrid PhysX owners will be pleased to hear that new Batman is compatible with such systems.

Update: PhysX benchmarks roundup

Great game with a good level of GPU PhysX support. Once again, main reason to choose PC version over the console ones.