FPSC has simple physics, why can't Torque?

#1 I've got to agree with you that the Physics in Torque could use a lot of work. Though it doesn't seem like something GG would be likely to do soon. I've volunteered to document most of the Rigid's source and methods a lot of which I will be putting into TDN soon, as well as improving much of the physics and writing my own classes. This seems like another thing the community is going to need to do if we want it right now.

As far as the bugs, I only experience the explosive velocities when dealing with RigidShape's with low masses are impulsed, though some sort of limit or damping would be nice (I'll see into implementing that for impulsed velocities). Objects sinking below the terrain is another very annoying issue, though I only experience it with rather boxy shapes, or parts of collision meshes that are boxy. No idea what is causing this as I've yet to go to far into things like collision detection.

#2 So both these bugs are exactly what happens when I implement a crate, low mass and boxy. Would tesselating the box and increasing its mass solve this?

What is an impulse velocity and what is the normal velocity type? Do you mean a velocity that is the result of an impulse along a vector? Like a push?

#3

Quote:So both these bugs are exactly what happens when I implement a crate, low mass and boxy. Would tesselating the box and increasing its mass solve this?

You'll experience bug b) when using shapes that are cubes or have boxy areas, for example a crate. Bug a) can be experienced with low-mass objects

Impulses like ApplyImpulse() apply a certain amount of force to the RigidShape. Based on the object's mass and the location of the impulse, the object is than applied linear velocity (or the direction it is moving in and how fast) and angular velocity (how quickly it is rotating along certain axis) ApplyImpulse() is used for exploding weapons like the default crossbow and also called each time a Rigid Collides with something to prevent penetration. Impulses applied upon collision are no problem, as they are based upon the objects mass and speed of the collision. However other ApplyImpulse() calls (almost always those in script, for example the crossbow) are not scaled depending on what object they hit.

A crossbow explosion applies an impulse of 2000. So a crossbow explosion will push a block with a mass of 300 slightly (roughly 2000/300 = +6.6 velocity), and a can with a mass of 2 almost across the map (roughly 2000/2 = +1000 velocity). This is realistic, but generally not what game's are aiming for. So you could implement some sort of reduction to any ApplyImpulse() coming in through . Probably easiest to do by editing the ConsoleMethod in ShapeBase.cc

#4 Thanks Morrock - I'll give it a go. It's fun messing around with this stuff - it's just frustrating when it all goes wrong.

#5 If you implement the PhysX resource, you'll have a lot of what FPSC has built-in since it makes use of DarkPhysics, which I believe used Aegia physics before it was purchased by NVidia (I think that was the history; I'd have to look back through my DP stuff for more information).

#6 But the PhysX resource is not networkable.

#7 @ Andy

You need to take a look at it again. There has been at least some basic network support added to it.

#8 A full implementation (or even the partial in the resource may not include it...it's been a while since I looked), but then FPSC doesn't implement all of Dark Physics, either. Physics work definitely is a point that needs work in the engine, and now that OpenGL support is in TGEA, hopefully there will be some dev time for physics love.

#9 On an added note, when I integrated PhysX (and partial Havok at one point), I still had issues with explosive velocities and sinking into terrain.

This was usually due to using bad numbers (low mass and friction, uber high impulse) or bad collision masking. The PhysX resource gives you a nice leg-up for sure.

#10 Just to comment, using the rigidbody physics in Torque is rather trivial to implement imo (though it can definitely be buggy, especially at high speeds)-

datablock RigidShapeData( Boulder )
{

category = "RigidShape";

shapeFile = "~/data/shapes/boulder/boulder.dts";
emap = true;

// Rigid Body
mass = 500;
massCenter = "0 0 0"; // Center of mass for rigid body
massBox = "0 0 0"; // Size of box used for moment of inertia,
// if zero it defaults to object bounding box
drag = 0.2; // Drag coefficient
bodyFriction = 0.2;
bodyRestitution = 0.1;
minImpactSpeed = 5; // Impacts over this invoke the script callback
softImpactSpeed = 5; // Play SoftImpact Sound
hardImpactSpeed = 15; // Play HardImpact Sound
integration = 4; // Physics integration: TickSec/Rate
collisionTol = 0.1; // Collision distance tolerance
contactTol = 0.1; // Contact velocity tolerance

minRollSpeed = 10;

maxDrag = 0.5;
minDrag = 0.01;

triggerDustHeight = 1;
dustHeight = 10;

dragForce = 0.05;
vertFactor = 0.05;

normalForce = 0.05;
restorativeForce = 0.05;
rollForce = 0.05;
pitchForce = 0.05;
};


function RigidShapeData::create(%data)
{
// The mission editor invokes this method when it wants to create
// an object of the given datablock type.
%obj = new RigidShape() {
dataBlock = %data;
};
return %obj;
}


function RigidShapeData::onCollision(%data, %obj, %col, %vec, %speed)
{
//if it is colliding with it's self or the terrain, ignore it
if(%obj == %col || %col.getType() & $terrainObjectType)
return;

error("RigidShapeData::onCollision %col:" SPC %col.getDataBlock().getName());
error("RigidShapeData::onCollision %obj:" SPC %obj.getDataBlock().getName());

%normal = vectorDot(%speed, vectorNormalize(%speed));
if(%normal > 58)
%scale = %normal / 2;

%objMass = %obj.getDataBlock().mass;
%colVel = vectorLen(%col.getVelocity());

//add some random boost to the Z
%objVec = getWord(%vec, 0) SPC getWord(%vec, 1) SPC mFloor(getRandom(2, 5));

%objImpulse = %objMass * ((%speed / 100) + (%colVel / 15));

//the case is, we don't want to apply an impulse greater then X times the objects mass, so
//clamp it down, otherwise it might visit the moon
%objImpulse = %objImpulse / 8 > %objMass ? %objMass * 8 : %objImpulse;

error("objImpulse:" SPC %objImpulse);

%obj.applyImpulse(%obj.getWorldBoxCenter(), VectorScale(%objVec, %objImpulse));
}

Rather simple scripting imho.

ODE works pretty well though.

#11

Quote:A crossbow explosion applies an impulse of 2000. So a crossbow explosion will push a block with a mass of 300 slightly (roughly 2000/300 = +6.6 velocity), and a can with a mass of 2 almost across the map (roughly 2000/2 = +1000 velocity). This is realistic, but generally not what game's are aiming for. So you could implement some sort of reduction to any ApplyImpulse() coming in through . Probably easiest to do by editing the ConsoleMethod in ShapeBase.cc

IMO, that's a problem with the scripting, not with Torqu. If you want the crossbow to apply so much impulse, you've sort of got to accept that it will fling things about. Just scale down the impulse, or make everything heavier.
If the impulse is so high because you want a disproportionate force applied to players, then maybe just put an if case in the function that applies the impulse - if it's a player, apply more, otherwise apply a sane amount.

#12 Ok, I am reading between the lines here.

http://www.garagegames.com/blogs/83134/15693

I assume the "New Torque" with 3rd party Physics means they are integrating ODE or hopefully Physics. I vote for PhysX :)

Micheal is right. After adding the PhysX model I still had explosive objects at times.

#13

Quote:IMO, that's a problem with the scripting, not with Torqu.

Well you are right that this is not a result of any math or physics code error. I wasn't saying it was an error, just something that could result in unwanted game play results. I guess I didn't explain my last sentence much. By editting the consoleMethod I was kind of thinking of adding a damping field to the ShapeBaseData, like maxImpulse or something. And in the applyImpulse consoleMethod reducing the applied impulse to this amount. I guess my thinking just spilled over into my post a bit, but you are right, it is more of a scripting than simulation-side error.

#14 Yes, it's not an error with the coding. My point is that if you're getting explosive velocities with an impulse of 2000... well, nothing is wrong at all. I guess a maxImpulse would be useful if you want to be able to have your cake and eat it too - apply whatever impulse you like, but not get crazy results.

#15 PhysX is a good SDK but it requires a big runtime (and doesn't support all platforms). 80mb added to your downloadable title that might be 20mb is a lot to swallow. Bullet is the best thing going right now IMHO.

#16 For me I am only concerned about Windows platforms, and downloading games is not the only way to distribute them:) Besides the last game I bought and downloaded (just this week) was about 3GB. I am not to worried about the Xbox 360 Creators Club or other areas where download size is an issue.

That is why I was saying hooks for implementing the Physics engine of your choice would be better than GG releasing a specific integration.

But what platform does PhysX not support? It supports most, but may require a hefty lic for the Xbox360 or PS3.