VR Physics And Collision Detection In Hardware? 15
Alea asks: "Currently, a big chunk of the graphics pipeline, transform and lighting (T&L), is beginning to show up in graphics hardware. It seems likely that some other capabilities, such as collision detection, will follow. This means the main processor can be used to compute more sophisticated physics models for games and VR systems. However, it seems to me that many physical model computations could also be performed in hardware, freeing the processor for more sophisticated AI and conceptual modeling. Does anyone know if there is any work being done on implementing collision detection and simple physical models (e.g. momentum, gravity, friction) in hardware?"
What's the point? (Score:1)
Don't know, but here is another idea (Score:3)
>~~~~~~~~~~~~~~~~
Flexability vs Efficiency (Score:2)
a. It would require hardware to hold geometric details for the entire level (ie. lots more memory)
b. It would require a lot of data to be sent back and forth across the bus to correctly pass relevant physics and in-game object collision information.
c. Certain objects that are rendered shouldn't be colided with (for example some particles like smoke, semi-transparent polygon's like vines, etc..)
d. Can't be used in all scenarios such as massive worlds as in these cases certain 'quick outs' are used to quickly discard the possiblity of colliding with areas of the scenery that can't possibly be colliding.
Physics lend themselves a little more to hardware acceleration (particularly with mathematical intergration and other cpu intensive operations) but still require close interaction with the collision detection system.
Consider a ball bouncing off the floor. This requires physics to drop the ball, collision detection to detect the collision of the ball with the floor and response by the physics code to handle the resulting bounce back up again. Moving this all to hardware would help a great deal in simple cases as above but due to the independant nature of collision detection/physics and graphics, something like this would likely involve some tradeoff in flexability when moving to more complicated scenarios.
Re:What's the point? (Score:3)
>~~~~~~~~~~~~~~~~
Collision Detection is a Hard Problem (TM) (Score:2)
Just wanted to shed some light on a problem that seems a lot easier than it really is. Perhaps that's why specialized hardware is in order.
Sparta is doing just that... (Score:2)
They seem to be doing just what you are talking about. I have used the demo program, and I must say it is VERY impressive. I haven't seen such realistic physics in a while...
Just a thought...
Ryan
Amiga Forever! (Score:1)
Dedicated game engine cards (Score:2)
Re:Amiga Forever! (Score:1)
Re:Amiga Forever! (Score:1)
Here's a cool Hard-wired-gate idea that uses very little real estate to detect Sprite collisions (used in the C-64 and C-128?)Patent # 4572506 [ibm.com]
Commodore GOT to buy what the genius inventors of the 3 origional custom chips from Hi-Toro(Amiga) Patent # 5103499 [ibm.com]
and The Amiga 1000 Patent # 4874164 [ibm.com] (Sorry if the IBM links are kinda quirky)
Heh, now its fashionable to be "only a game machine", to have stereo sound, NTSC/TV out, 3D shutter glasses, boot fast'er, and have NO user interface slop or latentcy,
as long as you dont pose a threat to the man...
Re:What's the point? (Score:1)
The problem is, 3d graphics engines lend themselves to hardware optimization by virtue of the OpenGL implementation (as of 1.2, at least) focusing more on the use of "popular" hardware acceleration. Unless we see a widely accepted physics modeling API for games, (OpenPL?), most of this will be somewhat pointless.
Raptor
See Robot Motion Planning Literature (Score:2)
A fair amount of work has been done on using graphics accelerators for collision detection in the field of robot motion planning. SIGGRAPH 90, Lengyel et al. describes one such approach. One striking demo of this being used showed motion-planning for moving a piano through a ridiculously complicated maze, with low obstacles and narrow halls. It involves twisting the piano, backing up, etc.
The approach calculates the "Minkowski sum" for a given robot and a given set of obstacles - the Minkowski sum being a stretched-out version of the obstacles that accounts for the closest possible approach of the robot to the obstacle. Then, you repeatedly render the robot into this Minkowski sum rendering (the M. sums are polyhedra) and basically "stumble" around by looking for overlaps between the robot polyhedra and the environment. Dynamic programming is used to prevent repeat checks.
Try searching SIGGRAPH [siggraph.org] articles for more.
How do you handle collisions in software? (Score:2)
Once you introduce physics models, the interface between the software and hardware becomes a lot more complicated--how do you report a collision? Polling or interupt? How do you describe the objects involved?
I really don't know, but I'm quite curious: by the time you introduce all the overhead of extra communication, and drivers, will you save enough clock cycles to make it worth the trouble?
Collision detection = ability to solve many tasks (Score:1)
At least one games console currently available has a 4-way vector processor (everyone probably knows which machine but I'm under NDA...). This can be used for collision detection or anything else you fancy. This is more useful, it seems to me, than a collision detector. The downside is that they can be tricky beasts to program and writing an optimising compiler is hard.
--Re:Amiga Forever! (Score:1)