I want Physics

#21

Quote:
We just added the Ageis Physics SDK to our engine, and whilst talking to the guy there about indie stuff he said that GG already had a networked physics solution for TSE that was done before IGC last year.

I want to reset expectation here--he was speaking out of turn. There is not currently (even in R&D) a fully networked integration of any physics SDK in any publically available game engine, and certainly not TSE/Torque in general.

As I've mentioned in a couple of other threads, fully networked "real" physics (such as people mostly mean when they talk about SDK's like Novodex, ODE, etc.) is a technical challenge that to my knowledge no one has yet solved with an implementation appropriate for the Internet.

And to clarify terms here: for example, the Aegia Physics SDK allows for a vast number (using their hardware specifically)--in the 4-5 digit range, of physics controlled objects. You certainly can't use ghosting to network those, and client/server desyncrhonization and resynchronization for that many objects is incredibly difficult across the exact same hardware, much less the environment game engines commonly are used to develop for.

#22 Physics can be used over the internet in moderation, not vast numbers but vehicle physics and a limited number of rigid bodies definately can. with vehicles your basicly sending the vehicle transform data over the network. It just gets more difficult the more "stuff" you send. And not very practical unless its over a LAN network or something, in which case things get a lot easier.

#23 Adrian is correct--and that's what I'm getting at--surely, you can have 5-10 "physics" objects and network them using Torque's networking just like you normally would, and run all the physics on your server only.

However, some of the things that physics libraries let you do (such as fluid dynamics, multiple physics scenes with different properties, the list goes on and on) are counting on the fact that you can/will have thousands of these objects--and those aren't going to be networked.

What that means is that your client is going to have to be able to deterministically recreate the exact physics state of the server, or the physics interactions are for "eye candy" only (think a fluidly operating fountain, where the player can put their hand over the water and change the flow of that water)--cool and interesting effects, but not capable of affecting gameplay in any real sense, since there is no way currently to deterministically recreate the effect on all clients.

#24 Hi all,

Please point it out if I was wrong:
-------------------------------------
(1) Half-life2 support network play and have excellent havok physics

(2) As mentioned above, there are difficulties in networked environment.
Would you mean that there will be no problems if we use 'eye candy' physics
in single-user environment? (Torque could be in Server or client mode,
as far as I know)

(3)Are the successfully games: "Marble Blast", "ThinkTanks",
"Rocket Bowl" - network-play or single-play?

Thanks in advance
Sammy

#25 (1) It's supports moderate usage of the physics. The ragdolls in multiplayer are only client side simulations, so everyone see's those differently, as they aren't gameplay relevant. If you try and do a ton of real stuff, it lags to hell. Go screw around with Garry's Mod online and see.

(2) Like the ragdolls in HL2, client side physics are fine, they just can't be things that effect the gameplay. Determinance has a cloth physics simulation, and this is just a client effect.

(3) ThinkTanks doesn't have any advanced physics, Rocket Bowl uses ODE and is singleplayer only, Marble Blast is online only in the X-Box 360 version, and that is just the spherical object physics for the players... not too complex to do for multiplayer.

So yes you can have multiplayer physics within reason, but not having tons of crazy effects all happening in realtime to all the players.

It's amazing the threads that get started from such inchoherent pointless posts (I'm talking about the original post)

#26 Thank you.

Sammy

#27 Look at the "bug" video on this blogpost:www.garagegames.com/blogs/2137/8550 and tell me physics aren't important for good gameplay. The game I talk about in that post was stopped, mainly becuase physics and network problems.

#28 It's good to see that you were trying to make a game where physics were necessary rather than simple eye-candy. That's what I want from developers who clamor for physics. It was the main reason that I was giddy about HL2: physics that had a reason. Racing games cross the spectrum from extremely accurate physics to strange rules as noted above: grass texture = -100 mph; gravel texture = -200mph.

Have you tried talking to some of the people who worked on the ODE, Tokamak, or Newton resources to see what their experiences have been and how they've played with shifting between client and server-side physics?

#29 Originally, I thought here (Official Torque site)
is the right place to ask this.
I am a newbie of Torque only.

Sammy
:)

#30 From www.garagegames.com/mg/forums/result.thread.php?qt=28247

From Akio:

Quote:TGE enhanced collision demo
I have the starter.racing demo so you can see how well it works. The demo has no ODE integrated. It's just based on the TGE release-v1.3, uses TGE's rigid physics, and untouched interior DIF and tree DTS objects. What I did was port my own CD routine, modified a few existing source files, and added a new dynamic class.

What you'll see in the demo:
-all dynamic objects are colored RWG.
-beachball: uses sphere collision
-all others: convex collision (triangle-triangle col.)

Check out how good the TGE physics really is!
I didn't add the box or cylinder collision types yet, but I did have to add sphere and capsule mass inertia configurations in rigid.cc. The demo does not include any large interior buildings because I don't have one to share, but feel free to add your own. I would like to hear your results though.

The demo link leads to a 404 error, but IIRC it showed a variety of shapes bounding around in a fairly realistic manner.

#31 @Sammy
Sorry, I was talking to Ward about asking those who have worked physics engines into TGE to see what their experiences were, what they had to shift from server to client, etc. I didn't mean to go to Aegia or Tokamak and ask about putting it into the engine. That's a good place for optimization, best practices, etc, once you know the particulars of just getting it in the engine.

#32 Oh, I see, David.

Sammy
:)

#33

Quote:
... moment of inertia, and angular momentum. basically these kinds of things also take the shape of the object into consideration.

From what I can tell, the Torque rigid body sollution does exactly this. Have a look at the rigid class, and you'll see that there is full support for mass moment of inertia (otherwise known as the inertial tensor). All of the torque (hah! pardon the pun)/rotational forces act through this.

Quote:
for instance in torque, if you have one box on top of another, if you push the top box off it wouldnt rotate. it would just fall flat to the ground and stop.

in a proclaimed physics engine, the box would tip over a bit before it falls like in real life. it would rotate a bit while falling, hit the ground and rotate a bit to align to the ground plane.

This isn't so much a lack of features in the rigid body simulation of Troque though. This has more to do with a limitation (or rather; an ommision) in the collision response code for rigid body objects. There's also the suitability of the collision detection code when it comes to this sort of thing.

I imagine (I haven't checked) that Torque uses a single point of contact to resolve collision between primitives. You can do okay collision responses for rigid bodies with this sort of thing, but only as long as you can guarantee an update every 16ms or 32ms. Anything below that and you're in jittery collision land.

What Torque doesn't have, is a contraints system and not only is this what Ragdolls use, but also more complex collision response systems use in conjunction with a more complex collision detection system (something like the v-clip algorithm).

Whole businesses have been formed around providing libraries for this sort of thing, such as the guys who do Havok, or the guys who have Aegia. So in my view, it's a bit unfair to expect the GG guys to support this too while also providing a great game engine.

I think we're already getting a LOT of bang for our buck as it is.

#34 James, no one's expecting Havok/ODE whatever-like physics, I don't know what you're trying to respond to. People do however expect that flying a vehicle into the ground doesn't freeze the engine.