PDA

View Full Version : New Cellfactor Demo


jAkUp
06-09-06, 10:25 PM
http://www.ageia.com/physx_in_action/cellfactor.html

Also, check out Ageia response to Robert from [H]

http://img68.imageshack.us/img68/811/ageialetterresponse15pq.jpg

faraday
06-09-06, 10:57 PM
I'm still sooooo unconvinced about this PPU thing.

saturnotaku
06-09-06, 11:07 PM
It would be more convincing to me if the hardware were more reasonably priced. $100-150 would put one in my system, but $300+...yeah right.

tacos4me
06-09-06, 11:32 PM
Run on x64 by any chance?

Edge
06-10-06, 02:34 AM
Well, they do have a point about FPS being impacted when there's a large amount of objects being affected. The game literally freezes on my PC for a moment when a gravity grenade goes off, and the FPS stay pretty low when the objects are in the air. Still, I can't think of many games that would have such an excessive amount of objects, or what could possibly justify a $200+ card to speed up only a specific aspect of certain games. And especially when for the price, you could've gotten a dual-core CPU which will allow for greater overall performance AND smoother physics calculation (although not as well as the PPU offers).

But I'll give this new demo a try just for the heck of it, it was mildly fun watching all those boxes explode and fly around. Except why do they say that a PhysX card is required when one of the fixes is to allow the game to have cloth effects in software mode? Why not just let you choose between software and hardware mode to begin with?

jAkUp
06-10-06, 02:50 AM
I am not even using my PPU since I reinstalled x64 and there are absolutely no drivers for it :(

Superfly
06-10-06, 04:01 AM
clutching at straws!!!

as it stands today the PPU is laughable, I really hope game dev's dont go the PPU route.

Gaco
06-10-06, 06:00 AM
This may turn huge in the future, but it's not really convincing right now.. but I DO see potential :)

It's all up to the devs I guess..

muaddib
06-10-06, 10:22 AM
Well, I want to try this out, but the Ageia FTP link is slow as hell (2Kb/s!!!).

BioHazZarD
06-10-06, 11:27 AM
and the game is even more slow lol.

|MaguS|
06-10-06, 11:36 AM
Cellfactor is stupid, the developers should scrap it and make an actual game rather then a stupid demo that has no real gameplay benefit.

Quickstar
06-10-06, 05:53 PM
I think Crysis has really great physics and they won't be using a PPU card. That's good enough for me. Did anyone else see the extended video where he shoots the trees and the shed? Really smooth physics. You'll notice with me that I'm obsessed with Crysis.

Question: In the Crysis videos, you'll notice how all the bushes and trees sway and move about. Everything is active and great. Is that physics code or something else?

Subtestube
06-10-06, 06:41 PM
Question: In the Crysis videos, you'll notice how all the bushes and trees sway and move about. Everything is active and great. Is that physics code or something else?

It won't be "physics" in the sense that you're thinking of (at least, I STRONGLY doubt it). Trees will simply have an animation cycle that will either be in code (more likely as it's cyclic and easy to generate) or just as pre-computed skeletal animations (which I doubt, as it would mean have a LOT of active skeletons at once). When trees respond to moving objects, that's the kind of physics that you're talking about.

reyalP
06-10-06, 09:42 PM
I installed the new demo and it is much improved over the last demo. It now runs very smooth at 1920x1200.

Tuork
06-11-06, 12:42 AM
Pardon my great big laughable ingnorance, but what is this software mode I hear about?

Does it mean that I can run this demo without having a physX card?

MaXThReAT
06-11-06, 01:40 AM
I added "EnablePhysX=false" to the command line for the shotcut llike last time and I don't get any physics at all now. I can see the cloth but nothing moves and the forces don't push or pull. It also started to artifact a bit. 84.56

Edge
06-11-06, 01:46 AM
Pardon my great big laughable ingnorance, but what is this software mode I hear about?

Does it mean that I can run this demo without having a physX card?

Yes, there's a line you can add to the shortcut to have it run without PhysX card acceleration. Can't remember the exact command, it was posted in the other Cellfactor thread.

Edit: bah, beaten to it, try that EnablePhysX=false

Phyxion
06-11-06, 02:35 AM
I installed the new demo and it is much improved over the last demo. It now runs very smooth at 1920x1200.
With PhysX card?

reyalP
06-11-06, 02:58 AM
With PhysX card?

Yes

wrathofgod
06-11-06, 10:48 PM
I added "EnablePhysX=false" to the command line for the shotcut llike last time and I don't get any physics at all now. I can see the cloth but nothing moves and the forces don't push or pull. It also started to artifact a bit. 84.56

They probably did that on purpose to keep you from playing it without the PhysX card. Just to try to get you to buy one, I bet. =/

wrathofgod
06-11-06, 10:49 PM
It would be more convincing to me if the hardware were more reasonably priced. $100-150 would put one in my system, but $300+...yeah right.

AMEN! Same here.

Redeemed
06-12-06, 02:40 PM
Okay, this has been discussed before...

A dual core CPU does not and will not have the power to calculate accurate and realtime physics as well as a dedicated PPU can. Already the PhysX PPU is lightyears faster than any current cpu available. It is up to the devs to make use of that power.

Even quad core or dual quad cores wont be sufficient. The architecture of the PhysX chip and a cpu are completely different- and the processes being executed by both are executed differently when it comes to the "hardware" level (how the actual processing unit handles the current process based upon its hardware capabilities).

When you run something that is DESIGNED to run on the PhysX chip, but you don't have the chip installed or enabled- whay you are seeing is the PhysX API- AGEIA will not make it so that you only get great physics if you have thier card. They not only want their card to be a major success, but thier API to be one as well. As such, if they can get great physics to work smoothly on the software level (meaning, making good use of the processor or extra cores/processors available to calculate physics) the more attractive their API is.

They realise that not everybody can afford the PhysX PPU- but, they want EVERYBODY to be able to ENJOY thier Physics API. Thus, they want it to offer great physics in the software mode while at the same time offering extremely great physics when using their PPU. This way, even those that can't afford hardware accelerated physics can enjoy and improved experience in their gaming thanks to AGEIA's API.

Dr. Morelso (I beleive that is his name) had a good post about this. I'll see if I can dig it up for you guys.

Redeemed
06-12-06, 02:45 PM
Im all for a dedicated physics card that can make a difference the way 3d accelerators did in the late 90s, but really, what exactly is a CPU for if we have specific cards for sound, video and physics?

As far as I know, CPUs are much better at physics than they are at graphics, so the comparison there is a little weak.


This is actually an excellent question that the marketing hype doesn't like to discuss. It's not because the pro-PPU argument is sleight-of-hand, but rather because the explanation of "why you need it" is highly technical and mathematical.

Enter my specialty.

There are a few things a PPU does that trump a CPU when you're talking about acceleration and simulation of a completely destructible environment.

------------------------

The CPU doesn't contain in-built hardware instructions for modeling even a realistic, earth-bound (@ STP), three-dimensional environment over time. The PPU does.

What's it mean?
Every time even two objects interact in your video game, motion over time occurs. I'll give two examples to make sense of it.

First: you're playing with that wonderful Gravity Gun v2.0 and you grab a refrigerator and toss it way up in the sky with velocity v.

How exactly should it fly?

Well, technically it creates a parabola, concave down. So your CPU has to continually solve the equation y = -9.1t^2 + vt (assuming x is already normed to the exact horizontal direction in which you threw it). Computationally, lots of this sort of thing (many different equations needing REALTIME solutions) can add up on a CPU.

The PPU Approach
There are much "computationally smarter" ways to determine where exactly the refrigerator flies, and the PPU will take advantage of this. It's a simple matter of the game telling the PPU exactly three things: the "strength" of gravity, and the exact acceleration (rate and direction) with which you release the refrigerator. The PPU then does the job (smartly, I'd assume) of simply telling the game where the refrigerator is going.

------------------------

Second:When your Gravity Gun v2.0 picked up the refrigerator, you weren't standing at a point perfectly orthogonal to the edge where the refrigerator hits the ground. Thus it should have been slightly "kitty corner" with the ground before lifting off entirely. Because no corner of any reasonable refrigerator is directly under its center of mass (it would be REALLY EASY to topple in real-life if this were true), the center of mass should try to settle to its lowest-kinetic energy point. This means the refrigerator should rotate and continue doing so as you pull it toward yourself.

How quickly and with what "twist" should it rotate?

It is very likely that this kind of pinpoint realism will be left out of your video game by the authors and you'll see one of two "close-to-reasonable" behaviors in software - either it rotates randomly or uniformly the same every time or it just doesn't rotate at all.

The PPU Approach
Because this is very hard to emulate in realtime computational settings, and it's even harder to do in software when you have many things to consider: center of mass, angle of incline, angle of lift, and friction with the ground. If it were a car being picked up diagonally from below and one tire were sticking to the ground, it would want to settle before you picked it up but would be much more limited (because the tire intersects the ground on a line and not on a point, because the car is stiff in certain directions but flexible in others) than our refrigerator.

The PPU needs to be told how it interacts with the ground (point, linear, planar), and where the center of mass is with respect to that interaction. Then when you go to pick up your refrigerator, it will kitty corner exactly as you'd expect if you grabbed it in real life (don't try this at home) and the result will be that it is rotating in a predictable way when you leave it floating with the Gravity Gun v2.0. When you throw it, the rotation should continue, and it should also contribute to how it lands.

------------------------

Third:Your refrigerator v2.0 has to come down eventually (as long as gravity is on), right?

Many, many factors change exactly what happens at this, the most important, stage in the refrigerator-toss (you were throwing it to hit something or someone, right?). Measurements necessary for the refrigerator include its velocity at impact (linear and rotational), its momenta (linear and rotational) and how rigid it is in every respect. Measurements necessary for the surface it hits include its density and malleability, its friction (both surface and composite), and the smoothness of its surface (is it covered with bolders?).

Your PC game will very most likely include a canned "damaged refrigerator" texture and maybe a "damaged ground" texture. You'll be lucky if you get a "damaged ground" and some variation in how the refrigerator actually moves. This way, the game needn't know anything about what I said above. It's computationally cheap and easy to recreate.

The PPU Approach
Here is where the PPU allegedly shines. Apparently it will know whether the refrigerator tumbles, rolls or slides and exactly how much of each. It will also know how to dent the refrigerator and exactly how the ground should be reshaped as a result of this whole exatravaganza. If the fridge is very stiff and lands flat on a big rock, it should probably crack or shear or even disintegrate the rock. And it should bounce or collapse on itself in a reasonable way. These are a bunch of calculations using a bunch of interrelated measurements that have to be handled at >30fps continually.

If I throw a fridge almost perfectly straight up and it lands in very soft sand, it should probably send up a cloud of sand and bury itself. If i throw it at a low angle, but really quickly, it could probably shear a guy's arm off on its way down if it hit him just right. The PPU should show you this correctly.

------------------------

These are just a few simple things I can think of to discuss the benefits of using a PPU. Other necessary things will be the interaction of MANY objects similar to the refrigerator (an avalanche, a bunch of rocks falling off a cliff, the L-train collapsing, grenade fallout blah blah blah). Currently, either the detailed particles don't interact, they don't exist (common), or they interact in a pre-planned way that's identical every time regardless of changes in the trigger (at what speed and angle did that car hit that ramp and come off of it?)

It's also necessary to understand that the PPU enables whole destructible environments, which means that instead of just seeing the same bullethole textured over that fence over and over again, and then along the concrete wall, and then the paper house in Japan, and finally on that depleted-uranium tank armor you'll see specific differences in interaction. The little impact crater from the bullet should appear more clearly in concrete, whereas the bullet should ricochet or flatten on the heavy metal, and should cut right through the paper and probably through the fence (although the wood may want to splinter depending on the weapon).

Considering the complete variability of the whole playing arena that a PPU provides, it's absolutely sensible to understand what the CPU will be doing: keeping track of every part of the arena you're NOT currently changing (after i blew up the building it burned a little, and a half-empty fuel tank exploded sending burning liquid all over, and some other stuff got melted, but then it remained static).

So now the game needs to remember the relationships between a WHOLE BUNCH of changed states instead of just the map and the location of a few of the bulletholes (as is currently done to "preserve realism").

a PPU will bring an exciting realistic edge to games of all genres once authors learn to fully harness and focus its potential. It will also create exactly what they describe: a fully immersive environment. And with this extra realism comes extra computing cost.

Your system will strain just as hard to keep the game up, but everything will have that "interactive edge" we all drooled about when 3Dfx started this.

Then you also have to consider the increasing complexity of effective AI. If you are a rogue secret agent being pursued by thirty members of a SWAT team while carrying information that will incriminate the President, you at least want to be chased by people whose movements are dictated by self-aware intelligence (so the game can't cheat) and whatever their weapon specialty tells them they should do (a machine-gunner should run after you while a sniper should climb something; the other way around would be pretty stupid).

I hope that helps with some of the ambiguity. Sorry it's such a long read.

~ dan ~


From:

http://www.nvnews.net/vbulletin/showthread.php?t=71213&page=2

Pretty dang good explanation. That was in a topic about the GPU accelerating physics in place of the PPU.