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

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.

Year ago AMD’s opinion on PhysX was clear enough – it will die, if it remains a closed and proprietary standard.

Recently Bit-tech.net has published massive interview with Richard Huddy, AMD’s Worldwide Developer Relations manager, on game development,  competition’s progress, DX11 and other technologies. Of course, few words were said about PhysX – let’s focus on that and see what has changed for the past year.

About Batman Arkham Asylum (Link)

[Nvidia] put PhsyX in there, and that’s the one I’ve got a reasonable amount of respect for. Even though I don’t think PhysX – a proprietary standard – is the right way to go, despite Nvidia touting it as an “open standard” and how it would be “more than happy to license it to AMD“, but [Nvidia] won’t. It’s just not true! You know the way it is, it’s simply something [Nvidia] would not do and they can publically say that as often as it likes and know that it won’t, because we’ve actually had quiet conversations with them and they’ve made it abundantly clear that we can go whistle.

However, PhysX is a piece of technology that changes the gameplay experience and maybe it improves it. What I understand is that they actually invested quite a lot, Nvidia put in a hefty engineering time and they tried to make a difference to the game. So, in that aspect, I have respect for it; it’s a reasonable way to handle the situation given the investment in PhysX. Nvidia wanted a co-marketing deal and put forward PhysX, and Rocksteady and Eidos said, OK, as long as you do it – which they did.

Our commentary: It’s now hard to call PhysX irrelevant, when you have played Batman, isn’t it ? Another interesting part is different look on that ATI-NV PhysX licensing situation.

About ATI+NV PhysX setups ban (Link) | Nvidia’s position

They don’t want to QA it. The PC is an open platform, though – you’re meant to take any two parts and put them together. Intel don’t say “we’re not prepared to QA our CPUs with Nvidia or AMD’s graphics parts” when they obviously spend time QAing them because you want to build a system that works.

Our commentary: Yes, it’s looking, let’s say, not right for us too. That’s why we are doing our best to support PhysX Hybrids idea.

About CPU PhysX (Link)

The other thing is that all these CPU cores we have are underutilised and I’m going to take another pop at Nvidia here. 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? I wonder why Nvidia has failed to do all their QA on stuff they don’t care about – making it run efficiently on CPU cores – because the company doesn’t care about the consumer experience it just cares about selling you more graphics cards by coding it so the GPU appears faster than the CPU.

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. The emphasis we’re seeing on GPU physics is an over-emphasis that comes from one company having GPU physics… promoting PhysX as if it’s Gods answer to all physics problems, when actually it’s more a solution in search of problems.

Our commentary: to get it clear with CPU PhysX – all multicore optimizations haven’t gone, it’s up to developers to use them or not (don’t forget, PhysX is used in majority of games for physics calculation on CPU).

Correct question is - why extra GPU PhysX effects aren’t opmimized enough for CPU execution in certain games ? Because Nvidia is GPU manufacturer, uses GPU PhysX to sell more videocards, and have right not to optimize their content for competition’s products, cause it spends it’s resources and money on that content.

:: As you may see, this time AMD’s statements on PhysX were  more “smooth” and relevant. But what’s you, our readers, are thinking about GPU physics future ? How will PhysX stand against OpenCl/DXCompute physics solution, if they’ll ever emerge any time soon ? (Taking into account that hardware PhysX has 5-years history, and soon will have new specially designed framework, like APEX and SDK 3.0, based on that experience, while competition has showed only some working prototypes).

Use comment’s below to share your thoughts.

End of the year is proper time to gather some statictics and summarize what PhysX SDK has archieved in past 4 years. So, we woud like to present our new article “Popular Physics Engines comparison: PhysX, Havok and ODE“, in which we are trying to compare PhysX SDK with other physics engines presented on the market not in terms of features, quality, performance or something like that – but released game titles.

Article includes basic statistics for Bullet and Newton physics engines, and advanced statictics for PhysX SDK, Havok and ODE – released games quality, platform distribution, and release dynamics for past years.

Expreview asked its readers recently, about which physics acceleration technology looks more promising to them.

Now, after 5 days and 281 votes, Nvidia PhysX is leading, Bullet is going second (probably, thanks to AMD users and all recent hype, as Bullet was listed as “AMD Bullet”, while being independent development),  Intel Havok comes third.

Polling is not over, so you still can lend your vote.

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