Real-Time Physics Simulation Forum

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-05-09T13:34:15+00:00

Speaking of DirectPhysics...

http://members.microsoft.com/careers/se ... 3186d96261

Statistics: Posted by Pierre — Tue May 09, 2006 1:34 pm

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-05-09T13:00:21+00:00

I've been a bit delayed in replying to this thread, preferring to work forward than talk too long. Admittedly, at the same time, other projects took priority for a while. The other project member is not so active at this point. I have many ideas to formalize before heating the debate too far.

I'll address a few points though:

There should be a hardware abstraction to allow portable physics programming among physx processors, GPUs, and CPUs (maybe cell processors too?).

The motivating problem is already here. Groups at UNC and elsewhere have been using GPU's for collision detection computations in a language that is entirely not in terms of physics. We aim to alleiviate this and let physics programmers write code in terms of physics, without any graphics knowledge. Havok has also demonstrated collision detection on the GPU, but not on PhysX. Likewise, Novodex demonstrated collision detection on PhysX but not GPU.

The intended goal is as low-level as possible while abstracting away the specific underlying hardware. This should not threaten the existence of any middleware, but instead offer middleware authors further options and portability. We should also skim under the level of proprietary physics algorithms, instead providing the building blocks and primitives that could implement them.

Still, it is worth consideration to optionally expose underlying hardware to allow for specific optimizations. In general, the exposure should be a convenience to users, not a necessity for use.

A programmable pipeline is definitely a requirement, as well as a basic default pipeline implementation for convenience.

We have to be careful not to say this is intended only for game physics. It could also be of interest to the research community and other industry segments that are concerned more with accuracy before speed.

Statistics: Posted by dcoming — Tue May 09, 2006 1:00 pm

Level of abstraction

2006-05-09T01:03:41+00:00

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.

Statistics: Posted by hellcats — Tue May 09, 2006 1:03 am

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-04-20T05:53:58+00:00

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.

Statistics: Posted by ngbinh — Thu Apr 20, 2006 5:53 am

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-04-01T00:22:07+00:00

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.

Statistics: Posted by Erin Catto — Sat Apr 01, 2006 12:22 am

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-03-31T21:33:41+00:00

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

Statistics: Posted by Erwin Coumans — Fri Mar 31, 2006 9:33 pm

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-03-31T21:17:41+00:00

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.

Statistics: Posted by Etherton — Fri Mar 31, 2006 9:17 pm

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-03-31T05:02:37+00:00

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?

Statistics: Posted by John Schultz — Fri Mar 31, 2006 5:02 am

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-03-31T04:42:42+00:00

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𙕮

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

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

Statistics: Posted by dcoming — Fri Mar 31, 2006 4:42 am

"ARB" moderated physics API, OpenPL, DirectPhysics

2006-03-31T04:58:18+00:00

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

Statistics: Posted by John Schultz — Fri Mar 31, 2006 4:42 am