Archive for the ‘Articles, Reviews’ Category
Alice: Madness Returns – first game with GPU PhysX support this year and title with most impressive PhysX particle effects.
To determine hardware PhysX performance patterns and GPU requirements we tried to gather all PhysX focused articles and benchmarks, available so far.
[18.06.2011] Alice: Madness Returns GPU test by GameGpu.ru
One of the first articles with proper GPU PhysX benchmarks.
According to their test, only top level NVIDIA GPUs can ensure decent framerate, while used for both graphics and PhysX calculations (however, from our experience, only most intensive PhysX scenes are affecting performance so negative).
Fisrst one, called “Real-Time Eulerian Water Simulation Using a Restricted Tall Cell Grid“, presents further impovements to the real-time hybrid fluid solver, that we were able to see in recent demos like Lighhouse and Raging Rapids Ride.
We present a new Eulerian fluid simulation method, which allows real-time simulations of large scale three dimensional liquids. Such scenarios have hither to been restricted to the domain of off-line computation. To reduce computation time we use a hybrid grid representation composed of regular cubic cells on top of a layer of tall cells. With this layout water above an arbitrary terrain can be represented without consuming an excessive amount of memory and compute power, while focusing effort on the area near the surface where it most matters. Additionally, we optimized the grid representation for a GPU implementation of the fluid solver.
To further accelerate the simulation, we introduce a specialized multigrid algorithm for solving the Poisson equation and propose solver modifications to keep the simulation stable for large time steps. We demonstrate the efficiency of our approach in several real-world scenarios, all running above 30 frames per second on a modern GPU. Some scenes include additional features such as two-way rigid body coupling as well as particle representations of sub-grid detail.
“Game Engine Survey 2011″ article, that can be found in May 2011 Issue of Game Developer Magazine is containing some interesting information about developer’s preferences regarding middleware solutions.
91.4 % of traditional (big-budget) developers prefer to use middleware libraries, and PhysX SDK is holding #4 place – it’s the only one physics engine in this category (we were surprised that Havok was not mentioned).
Far fewer casual developers (48.6 %) are relying on middleware solutions, so unexpensive or free (but good) libraries – FMOD, open-source Bullet engine and PhysX SDK – are the most popular.
Previosly, Game Developer Magazine has performed similar survey in Year 2009.
If you know PhysX only as GPU accelerated physics effects for PC games, lack of news and announcements of new GPU PhysX titles may give you an idea that NVIDIA has decided to drop support for PhysX completely. Forum threads like “Is PhysX Dead?” or “Physx dead?“, popping up from time to time, are indicating – users are worried.
We were able to contact NVIDIA and Mike Skolones, product manager for PhysX, has revealed us the company’s plans regarding PhysX Technology.
PhysXInfo.com: Is PhysX still playing important role for NVIDIA ? Are you planning to use and evolve the PhysX Technology over the years, or thinking about abandoning it in a favor for other solutions ?
Mike Skolones: PhysX has been and continues to play an important role for NVIDIA, as well as for the thousands of game developers who use PhysX for physics simulation across a broad range of platforms, including PC, Xbox360, PLAYSTATION 3, Nintendo Wii , iOS (including iPhone, iPod, and iPad), OSX, Linux, and Android (including NVIDIA Tegra™ devices), MMO servers running Linux and Windows; OSX ports; and Windows games, where GPU-accelerated advanced simulation is poised for continued growth.
More importantly, because PhysX continues to be the choice of developers for integration into world’s leading commercial game engines, including Unreal Engine 3, Trinigy, Unity, Torque, Gamebryo, Lightspeed, Hero, and Dark Basic, not to mention other internal tech engines which also use PhysX, designers and artists know they have compelling development platforms they can immediately take advantage for making their games that much more realistic and interactive.
NVIDIA has uploaded last piece of APEX Framework puzzle – actual APEX SDK component. Now, it is time to take detailed overview on APEX features and structure.
UPDATE: APEX SDK 1.1 is available.
So what is NVIDIA APEX ? APEX is multi-platform scalable developement framework, designed to reduce development time and costs when creating complex physics content.
APEX addresses following typical problems:
- Significant programmer involvement is required to take a relatively abstract PhysX-SDK and create a lot of meaningful content.
APEX provides a high-level interface to artists and content developers. This reduces the need for programmer time, adds automatic physics behavior to familiar objects, and leverages multiple low-level PhysX-SDK features with a single easy-to-use authoring interface.
- Game physics content typically gets designed to the game’s “min-spec” system.
APEX requires each functional module to provide one or more ways to “scale the content” when running on better-than-min-spec systems, and to do this without requiring a lot of extra work from the game developer (artist or programmer, but especially programmer).
- Game engine performance limitations.
APEX avoids many of the game engine bottlenecks by allowing the designer to identify the physics that is important to the game logic, and what can be sent directly to the renderer, bypassing the fully generic path through the game engine.
It also allows the game engine to treat an APEX asset as a single game object, even though it may actually comprise many hundreds or even thousands of low-level physics components.
Authoring tools (DCC plug-ins for 3ds Max/Maya and standalone PhysXLab app) are used create and tune physics assets (for example, destructible wall) while runtime component (APEX SDK) is responsible for deserialization, LOD, data management and interaction with game engine. Accordingly, APEX SDK must be integrated with your engine before you’ll be able to use APEX assets.
Few facts about APEX 1.0 Beta:
- APEX is not the replacement for PhysX SDK, nor the new version of it. It is a layer that sits on top of the PhysX SDK.
- APEX 1.0 public Beta includes Clothing and Destruction modules (and partially – Particles module).
- APEX is free for commercial and non-commercial use.
- All necessary documentation and tutorials are included with APEX 1.0 package.
- APEX supports PC, PS3 and Xbox 360 (with optimizations for consoles), and but only PC version is available for public currently.
- APEX is based on latest PhysX SDK 2.8.4 and does not require PhysX System Software installation.
Go to [Online Support] -> [Download]
- [APEX] -> [APEX PhysX Lab Beta] -> NVIDIA APEX PhysX Lab-22.214.171.124 for PhysXLab (APEX Destruction authoring)
- [APEX] -> [APEX DCC Clothing Plugins] -> [Max 2.60 beta] -> NVIDIA PhysX Plug-in 3dsMax20– x– WithAPEX 2.60.– for 3ds Max PhysX plug-in (APEX Clothing authoring, don’t forget to choose proper 3ds Max version)
- [APEX] -> [APEX DCC Clothing Plugins] -> [Maya 2.6 beta] -> NVIDIA PhysX Plug-in Maya20– x– WithAPEX 2.60.– for Maya PhysX plug-in (APEX Clothing authoring, don’t forget to choose proper Maya version)
- [APEX] -> [APEX SDK Beta] -> APEXSDK-1.0.39 beta-PhysX_126.96.36.199-WIN-VC9 for APEX SDK (game engine integration)
You don't need to download PhysX SDK, or PhysX System Software, or anything else.
Now let’s see what is included in APEX 1.0 public Beta package:
Physical simulation of character clothing is yet inceptive, but very promising trend and a great way to make game characters more believable.
We are giving an overview of most interesting cloth simulation packages in our new article : “Clothing simulation solutions for games“.
We’ve spent some time playing Breach and are presenting our overview, focused on PhysX related components of the game.
Destruction and physics systems.
Destruction in Breach is pretty pervasive – each level contain lot of active physical objects, from fully desctructible (wooden cabins, bridges, barricades, etc) to semi-destructible (structures made of stone and concrete will take damage, but won’t collapse entirely). Rigid body chunks and bricks from explosions will remain active physics objects, reacting to players movement, gunfire and explosions.
Physics calculations quantity can be controlled through special Physics Settings panel, that allows users to tweak amount of rigid bodies present on the scene and time they stay active before disappearing.
These settings are mostly related to secondary rigid bodies (bricks, debris and smaller pieces), while gameplay affecting obejcts (for example, falling wooden planks, that can hurt other players) remain intact.
Update: PhysX and Breach: Final Verdict
We’ve contacted Atomic Games, developers of Breach, to get more background on PhysX implementation and technical aspects of in-game physics. Mark Davidson, director of core technologies, was kind enought to answer some of our questions:
PhysXInfo.com: Destruction system and physics in general – what do they mean for Breach? Are they just a cosmetic features or integral part of the gameplay?
Mark Davidson: Destruction in Breach defines the game. It’s not just a facet of game play; it is the core mechanic, the soul. Everything revolves around it, how to attack, how to defend, where to take cover, these choices are all driven by the destructible nature of the environment.
The fact that almost anything on the battlefield can be destroyed means physics play a pivotal role in how any skirmish plays out. We have gone way beyond swapping models for a destroyed version, In Breach you are physically affecting elements of the world and forcing other players to react to that.
Interesting paper, called “Scalable Fluid Simulation using Anisotropic Turbulence Particles” has appeared at homepage of Dr. Markuss Gross, from ETH Zurich.
As far as we know, same solver is used in APEX Turbulence module.
It is usually difficult to resolve the fine details of turbulent flows, especially when targeting real-time applications. We present a novel, scalable turbulence method that uses a realistic energy model and an efficient particle representation that allows for the accurate and robust simulation of small-scale detail. We compute transport of turbulent energy using a complete two-equation k–e model with accurate production terms that allows us to capture anisotropic turbulence effects, which integrate smoothly into the base flow. We only require a very low grid resolution to resolve the underlying base flow.
As we offload complexity from the fluid solver to the particle system, we can control the detail of the simulation easily by adjusting the number of particles, without changing the large scale behavior. In addition, no computations are wasted on areas that are not visible. We demonstrate that due to the design of our algorithm it is highly suitable for massively parallel architectures, and is able to generate detailed turbulent
In addition, this paper comes with nice video demonstration (92 mb). It is worth to watch.
Thanks to AquaGeneral for the link.
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.
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.