"ARB" moderated physics API, OpenPL, DirectPhysics

[dcoming]

http://www.gamedev.net/community/forums ... _id=383736

Ageia, PS3 Cell, and nVidia (GPU) demos discussed (also see links for video demos from Ageia and nVidia+Havok FX). While hardware accelerated physics are early demos, it's a pretty good start. A standardized physics API such as an OpenPL or DirectPhysics would be useful to promote adoption of HW accelerated physics.

OpenPL... a very good point. OK Lets start designing.
OpenPL sourceforge project

Cheers,
Dan

[Erwin Coumans]

It's good to have some discussion about API's. I would recommend to look into the Collada Physics data format too. There is Physics export for Maya, Max, XSI and soon Blender, through Collada 1.4.

http://www.khronos.org/collada/

I've abstracted the basic rigidbody and constraints of around 10 different physics engines, using this interface.
http://projects.blender.org/viewcvs/vie ... bf-blender

However the behaviour is very different (CCD/Discrete and difference in collision representation).

Erwin

[Etherton]

These are some more standards too:
Collada, ODF, PAL, OPAL, and now openPL
These are the more popular but there are about a dozen more that don?t get mention.
Um very soon we will need a super standard to cover all the standards.

[dcoming]

These are some more standards too:
Collada, ODF, PAL, OPAL, and now openPL
These are the more popular but there are about a dozen more that don?t get mention.
Um very soon we will need a super standard to cover all the standards.

I looked at the specific standards you mentioned and I think we are aiming in a new and different direction. OpenPL will abstract out the hardware layer so that you can use OpenPL with either a GPU, PPU, or CPU. OpenPL will provide basic common functionality that physics engines could call upon to get whatever hardware acceleration is available. I could draw the analogy of OpenGL abstracting out whether you are using an NVIDIA or ATI graphics card, but this will be different since GPUs and PPUs are very different beasts.

What we hope to illicit now is what do physics programmers or physics engine developers use/want in terms of base structures, algorithms, and methods that could be hardware accelerated? Then we have to balance this against what can be accelerated efficiently on both GPU and CPU.[/i]

[Etherton]

My impression was that ?standards? like ODF and Collada were made to do that.

Open GL had a very humble origin, it was a simple 2d graphics library made by IRIS.
The design was so good that it became an industry standard not by design but by choice. Now OpenGL have the ?Architecture Revision Board?, for which major players like SGI, Microsoft, IBM, Intel, AMD, Nvidea, ATI, and many others meet periodically to decide what the next direction will be. The board is open to the public, and any nom member company with vested interest in the field can participate in the discussions and even have a vote on the straw pools, as they call it. The only requirement is an application of participation in advance.

With physics now what I see is a proliferation of Wrappers over very specific libraries, and they are called standard but they are nothing but the brainchild of one or two people with and idea of how physics should be programmed.

What we hope to illicit now is what do physics programmers or physics engine developers use/want in terms of base structures, algorithms, and methods that could be hardware accelerated? Then we have to balance this against what can be accelerated efficiently on both GPU and CPU.[/i]

I see your group have a very healthy and ambitious plan.

Are you part of a large committee like opengl ARB? Or is there one in the process of been formed?
Are you working in coordination with Nvidea, ATI, Intel, AMD, and other hardware manufactures, so you can have their recommendation, and you can tell them your recommendations about how to make the hardware?
Are you working with the major physics library makers like Novodex, Havok, meqon, CmLab, Renderware? Have you invited then?
Did you get in contact with the smaller players like ODE, Bullet, Newton, Trueaxis, Tokamaka. I am guessing you have the blessing of ODE, and Bullet, but since this is an industry standard you are talking about, I assume it is for every body?
Have you created a stable physics solution that could be implemented on GPU, and PPU reliable, as fall back?
Have you written at least one commercial of free popular physics library that has been tested and prove be a large group of people other then your group?

I think those are very important factors to be considered for the formulation of a standard. Or I am getting this all-wrong.

My point is that OpenPL is a name with such a distinguish pedigree that it should be left alone, pick a different another name.
If your work is good than it will rise on its own merit.

[dcoming]

My impression was that ?standards? like ODF and Collada were made to do that.

My understanding is that both of these are standards for data exchange formats. They provide a common format for scene descriptions. I don't see any displacement or significant overlap of these by OpenPL.

With physics now what I see is a proliferation of Wrappers over very specific libraries, and they are called standard but they are nothing but the brainchild of one or two people with and idea of how physics should be programmed.

<snip>

Are you part of a large committee like opengl ARB? Or is there one in the process of been formed?
Are you working in coordination with Nvidea, ATI, Intel, AMD, and other hardware manufactures, so you can have their recommendation, and you can tell them your recommendations about how to make the hardware?
Are you working with the major physics library makers like Novodex, Havok, meqon, CmLab, Renderware? Have you invited then?
Did you get in contact with the smaller players like ODE, Bullet, Newton, Trueaxis, Tokamaka. I am guessing you have the blessing of ODE, and Bullet, but since this is an industry standard you are talking about, I assume it is for every body?

There's a lot to address in there, but let me see if I can do so concisely. First a quick correction in case it wasn't clear. We intend OpenPL to be a language in terms of physics, that abstracts the {C|G|P}PU hardware away. That said, the current body is small. We absolutely welcome more partners; as you said it is an ambitious goal and will require many minds and hours. That's why I came here, to invite more involvement. This will not succeed as the "brainchild of one or two people with and idea of how physics should be programmed". You seem passionate about this; if you are also qualified, then why don't you join us?

We are in the process of initial communications. I am part of a large graphics research group. I have some contact at NVIDIA, Intel, and Novodex, but no specific promises for what that can do for us. We'd absolutely welcome the public participation of any parties you mentioned, as well as any who come forth and express interest. Anyone at Sony want to get involved?

One key to this working is not to be significantly tied to one particular group. That is the luxury of being part of a neutral research group. Eventually, (OpenGL took years) it would be nice if this was to the point of the periodic revisions and future-steering meetings. For now, we need to design, test, and get a proof of concept.

My point is that OpenPL is a name with such a distinguish pedigree that it should be left alone, pick a different another name.
If your work is good than it will rise on its own merit.

I think you place a bit too much importance on a name. For other examples of Open* names, see OpenAL, OpenHL, OpenIL, OpenSG... the list goes on. Its simply a descriptive name that was not previously taken (to our knowledge). It means Open Physics Library... It is an open source library for physics computation that will be hardware-independent. Note: Open does not imply "standard". Who called OpenPL a standard? We don't have the authority to make any claim to set the standard. That said, it sure would be a nice bonus at the end of a lot of hard work.

(edit 3/30 8:23pm - reason: clarification of "standard")

[John Schultz]

I think you place a bit too much importance on a name. For other examples of Open* names, see OpenAL, OpenIL, OpenSG... the list is endless. Its simply a descriptive name that was not previously taken (to our knowledge). If not us, someone else would grab it up, especially after the name OpenPL was thrown around without knowing our existence.

I agree that the name is not that important initially, however I have been throwing around "OpenPL" as a suggestion for a physics API for some time:

http://www.gamedev.net/community/forums ... _id=324255
Here's another OpenPL suggestion from 2000:
http://www.gamedev.net/community/forums ... =1&#103790

Thus, "OpenPL" is the obvious name choice for an "ARB" moderated physics API. Someone had to get the ball rolling; if you can get nVidia, ATI, Havok, Aegia, etc., on board, that would be cool (you really only need Shader Model 3.0+ vendors on board in the beginning).

DirectPhysics would also work, and OpenFP might even be a better idea, as a general way to use fast FPU hardware (GPU/PPU/CPU/Cell, etc.).

While I have written a few physics engines, they have been tailored specifically for use in games, as opposed to general purpose engines with fully fleshed API's, documentation, etc. From a game developer perspective, I would like to see a simple and elegant physics API that borrows the best from OpenGL, DX9+, OpenAL, Havok, Novodex/PhysX, ODE, etc. Creating a simple, elegant, generalized, and fast API is not trivial; kudos to those who can create such a system in a timely manner (including in an open committee "ARB" like environment).

I would agree that those developing and maintaining OpenPL should have written at least one production level physics engine (and perhaps also used commercial-grade engines such as Havok and Novodex/Meqon/PhysX).

A physics testbed was developed over on the Ogre forum that allowed switching between various physics API... Not clear what happened to it.

A first step would be to get simple particles running with interaction primitives (planes, boxes, spheres, cylinders, etc.) on CPUs+GPUs, then rigid bodies with boxes, then spheres, next with convex hulls, then springs+cloth, then constraints, then controllers, and so on.

I'm in the process of finishing a game; I'll comment and provide feedback when I can.

[John Schultz]

Open GL had a very humble origin, it was a simple 2d graphics library made by IRIS.

Are you sure about that? I always thought IRIS was a brand name for Silicon Graphics? IRIX was SGI's *nix, IRIS Workstation series, IRIS GL, etc. Back in the day, we just referred to it as GL.

Since there isn't currently a standard physics library, PL would also be fair game.


(edit)It looks like Kurt Akeley led the development of GL (a 3D API that also supported 2D/4D primitives) at SGI: http://en.wikipedia.org/wiki/Kurt_Akeley Kurt is now a senior researcher at Microsoft.
The history of (Open)GL, PEX, etc., is interesting: perhaps such history should be studied by those creating OpenPL...

[dcoming]

I agree that the name is not that important initially, however I have been throwing around "OpenPL" as a suggestion for a physics API for some time:

http://www.gamedev.net/community/forums ... _id=324255
Here's another OpenPL suggestion from 2000:
http://www.gamedev.net/community/forums ... =1&#103790

I didn't pick the name. It is a pretty obvious one that I'm surprised wasn't taken or registered before, even as a placeholder. Perhaps by taking it, we committed ourself to a daunting task; I'm up for it.

DirectPhysics would also work...
<snip>
...
[developers should have] also used commercial-grade engines such as Havok and Novodex/Meqon/PhysX).

Yes, Microsoft thought so too, on both points.

A first step would be to get simple particles running with interaction primitives (planes, boxes, spheres, cylinders, etc.) on CPUs+GPUs, then rigid bodies with boxes, then spheres, next with convex hulls, then springs+cloth, then constraints, then controllers, and so on.

I'm in the process of finishing a game; I'll comment and provide feedback when I can.

Thanks for the input; its generally the approach we're looking at, and we'll want them to work on PPU's as well.

Physics are already being done on the GPU now. The problem is that everything has to get translated into GPU-specific terms that don't always coincide with the task at hand.

[John Schultz]

Physics are already being done on the GPU now. The problem is that everything has to get translated into GPU-specific terms that don't always coincide with the task at hand.

Has your group written a physics simulator (particles, rigid bodies, springs, cloth, constraints, controllers, etc.)? Link to demos/videos?

[Etherton]

You seem passionate about this; if you are also qualified, then why don't you join us?

I am not as ahead of the time as you are, so perhaps my qualifications are not sufficiently good.
I am still stuck in philosophy ?first you have a problem then you find a solution?.
I always thought that the useful standards were responses to specific and real problems.
It seems things are very different now, now you have the solution then you go out and find the problems.
I did not know there were so many people creating scene with a physics solution and using it with another, and if they were, they were such volumes.
Also I could not image how the standard will cope with the mathematical differences of the various existing algorithms, given that the current trend is to simplicity and incorrectness instead of correctness and complexity.

I have to say you really are a visionary for having this incredible idea Havok just demonstrated at GDC. It takes a man with vision to foresee these future problems in advance, my qualifications are just not good enought for that. And it looks like you have it all figured out, you already have a good name for it, so it cannot be bad.

Good luck with the project, I cannot wait to see it.

[Erwin Coumans]

You seem passionate about this; if you are also qualified, then why don't you join us?

I am not as ahead of the time as you are, so perhaps my qualifications are not sufficiently good.

Are you sure? You made me curious about your qualifications. Are you still student? Are you working in the game industry?

I am still stuck in philosophy ?first you have a problem then you find a solution?. I always thought that the useful standards were responses to specific and real problems.
It seems things are very different now, now you have the solution then you go out and find the problems.
I did not know there were so many people creating scene with a physics solution and using it with another, and if they were, they were such volumes.
Also I could not image how the standard will cope with the mathematical differences of the various existing algorithms, given that the current trend is to simplicity and incorrectness instead of correctness and complexity.

I have to say you really are a visionary for having this incredible idea Havok just demonstrated at GDC. It takes a man with vision to foresee these future problems in advance, my qualifications are just not good enought for that. And it looks like you have it all figured out, you already have a good name for it, so it cannot be bad.

I agree that there is a lot of variety amongst algorithms and implementations in physics engines. Also there are a lot of customizations and programmability necessary, so a fixed pipeline like the old OpenGL will not work I think. It will have to be very programmable, even more then the vertex and pixel shaders.

So the language of programmability and integration of callbacks will become very interesting area. Compare HLSL, GLSL and Cg to some 'physics language' for callback code and customization. Perhaps that can be part of OpenPL?

Another challenge is the fact that small behavious difference make the swapping of physics engines algorithms difficult in practice. For games, the content is usually tuned around the strengths and weaknesses of the physics engine.

So I'm curious to hear from Daniel Coming what problems OpenPL wants to solve, and who benefits from OpenPL. Physics technology is still under development in several areas, and so are the physics API's and data structures.

However I do like standards so I'm curious about more details what Daniel Coming has in mind. If necessary, I can help bringing in some contacts in the industry.

Erwin

[Erin Catto]

For me, physics algorithms seem to be too secretive and receive little serious interest from academia. For example, how much funding is available for research in game physics? As far as I can tell it is close to zero.

Computer graphics has a long history of academic research and open sharing of information and algorithms. Game physics has a long history of being proprietary middle-ware.

I don't know how you can hope to have anything "open" about commercial physics engines. It's sort of like asking Microsoft to adopt your GUI API. Physics middle-ware companies want to be entrenched, not swappable.

[ngbinh]

For me, physics algorithms seem to be too secretive and receive little serious interest from academia. For example, how much funding is available for research in game physics? As far as I can tell it is close to zero.

Well, not quite! time stepping method, velocity based constraints, GJK,.. are originated from academia. Also, Erleben PhD thesis, Michael Cline Master thesis,... are kind of helpful to game physics developers.

See this group:
http://www.cis.upenn.edu/davinci/index.html

It's just one physics simulation group in academia, there are more. Ofcoure they don't really doing research on game engine, what they are after is simulation/control but maybe 3,4 years later you will see gaming industry start to use their current theories.

[hellcats]

One thing to be careful about when designing an API for game physics is having a certain set of capabiilties in mind while coming up with the API. For instance, if you have implemented an LCP-based solver then you will probably come up with an abstraction for complementary problems. If you have implemeted "freezing" then you will want to be sure the API supports that feature. The problem is that the space covered by game physics is huge and rapidly evolving.

If we look at the evolution of graphics APIs, we see a trend towards generalization. The Xbox 360 for instance doesn't even support a fixed pipeline: you must write a shader before you can even draw a simple wire-frame box! To me, the value in a physics API would be as an abstraction for hardware acceleration that is common to many physics and colliision detection tasks. Hardware acceleration is key because that is where a common API can deliver real value. If you make the level of abstraction too high then you risk turning away new innovations because they don't fit the model you have created. The world of game physics is just changing too fast. Here is a short list (IMHO) of the advantages of a low-level API:

* Small developers spend less time and money bringing a product to market, but can still compete with the "big boys" because they have equal access to hardware acceleration.

* Users get more control over physics effects much as they can control FSAA and other graphics features today using the graphics card driver.

* Adoption of "physics hardware" is accelerated because the physics API enables many different algorithmic solutions across multiple hardware platforms.

And even if you still want to develop a higher-level API, it should at least be built on top of a lower-level hardware API that is also available to developers.