You are describing effect physics and that's not what Ageia is, what has ever been from the start. Ageia has always been about physically correct simulations and that's what they are showing there. Every particle has its own calculations and interacts with each other based on its geometry and surrounding geometry and forces. In that situation the particles being the same is irrelevant, it's not a pre-baked simulation like the one in the Toyshop demo so how a "particle" will interact is not known beforehand and has to be calculated. You accuse them of faking that so it's clear that once again it's just a matter of believing Nvidia is lying or not, and I have seen enough PhysX demos running perfectly even in my uncle's 8400 GS (with like 1/100th GPGPU performance) to believe it's true.
You are correct in the sense of pure geometry and rendering workload, but if you are just talking about the rendering part of the ecuation, then you are missing the point by far.
It's not different from AMD promoting DX11 or DX10.1 or Nvidia promoting DX10 or DX9.0C before that or Ati promoting DX9 before that and so on.
Nvidia is not forcing you to buy any of their cards to enjoy the improved physics. You can always turn GPU PhysX off and enjoy the same physics that you find in any other game, be it Havok, Bullet or developer's own engine. That you'd have enjoyed forever if PhysX had never existed. What every PhysX hater always forgets is that without PhysX there would have never been better physics in games. Physics have been almost stagnated since the first games using them in the 90's and it didn't start to trully change until Ageia demostrated there was something more out there. Now you want those extra physics, but you want them for free, don't worry, human nature, wrong nature though. (I'm not saying wanting something for free is wrong, mind you, but enervating and hating because you want something for free is)
Like kid said you can play every game and that's the exception rather than the norm in todays industry.
Perhaps you need to read up on Physx?
You may not add angular torque, you specify the time each interaction has, and limit the number of iterations a interaction has to limit your processing workload, you may predefine each interaction beforehand, mass/velocity is calculated and then stored to be accesed later or can be predefined.
From the Nvidia developer site for PhysX.
#1 If you do not need to manually generate the mass of your object, I suggest you guys uses NxActor::updateMassFromShapes( density, totalMass ) which take in EITHER density OR totalMass and recompute mass properties like inertia tensor, mass frame and center of mass based on your input.
Fromthe way it looks, there are rigid and soft joint, cloth, fluid, and particle interactions, and at the most basic real time game level most of your interactions are predefined to eleminate the rendering workload. The true real time interaction on all three axis of more than one flat planar surface causes current generation cards, and even the high end cards to crawl.
Sorry to say, Physx in form today is compiled of alot of predefined rules, datasets, and calculations and predefined mass objects interacting in a limited number of functions.
So that cloth, single layer object you are "interacting" with is just alot of crap. it is mostly predefined, prerendred, and limited. PhysX is still FAIL.
It does however allow people who want to run things through many interations for more accuracy run them at crawling speed.
"I'm unclear from the docs whether it is possible to have a triangle mesh that is dynamic (i.e. not static and does not have to be dynamically created) interact with fluids. I can get static triangle meshes to do so, but need dynamic ones working as well.
From the docs (Fluids Interaction with Rigid Bodies) it mentions pre-cooking, but is this required or optional, ie can the SDK handle dynamic TM's (albiet slower than pre-processed)?
The following is from the PhysX dSDK documentation.
QUOTE
Fluids contacting meshes (i.e. triangle meshes, heightfields or convexes) require special processing of the triangles for fluid collision. Instead of relying on the SDK performing these calculations automatically, you can pre-cook areas you know will contact fluids using the NxScene::cookFluidMeshHotspot method. This way you can avoid performance spikes."
"I want to know , how to do physx particle fusion together , I can't to do for UDK , anyway , the particle can't fusion together , UDK maybe can't to do this , I mean is UDK can't create dynamic fluid particle (the point to point fusion together effect ) .
Hmm, you can probably get quite good effects with sprites or a screen space effect(eg similar to the blobs dx sdk sample). I dont think the fluid surface stuff is available for PhysX anymore, ie marching cubes like mesh generation (plus udk wouldnt have it integrated even if it was).
David"
A code showing predetermined gravity interaction
"struct ParticleUpdateSDK
{
NxVec3 force;
NxU32 flags;
};
////////////////////////////////////////////////////////////////////
std::vector<ParticleUpdateSDK> gUpdates;
////////////////////////////////////////////////////////////////////
void SampleCollision::update()
{
NxVec3 defaultGravity(0,-9.8,0);
if (!gMyFluids.size())
return;
//Get particles from MyFluid and compute forces.
MyFluid* fluid = gMyFluids[0];
const ParticleSDK* particles = fluid->getParticles();
unsigned particlesNum = fluid->getParticlesNum();
gUpdates.resize(particlesNum);
for (unsigned i=0; i<particlesNum; i++)
{
gUpdates
.force= -defaultGravity;
gUpdates.flags=0;
}
NxParticleUpdateData updateData;
updateData.forceMode = NX_FORCE;
updateData.bufferForce = &gUpdates[0].force.x;
updateData.bufferForceByteStride = sizeof(ParticleUpdateSDK);
updateData.bufferFlag = &gUpdates[0].flags;
updateData.bufferFlagByteStride = sizeof(ParticleUpdateSDK);
fluid->getNxFluid()->updateParticles(updateData);
"
This is a snippet of code to generate a set of particles to enter into a game interaction.
.
), where the hell is it?
keep at it boys
