some suggestions

[Reno]

As previously stated, there\'s a large possiblity that we will write our own(which ultimately would be better overall anyways because TTR is online focused, so network friendly physics is a must)

As Joe stated, Havok is *far* out of our price range. I\'ve looked around alot at different physics engine solutions, and ODE while good overall, obliterates network performance without heavy tweaking on both ends of things. Novodex would be a good solution, except that we would need to support the physX chip, which no one on our team currently knows how to code for, let alone has the extra cash to get the dev kit i\'m sure would be required to use it.
I\'ve also looked at Tokomak, which suffers most of the same problems as ODE, and Newton physics, which while slighting more effecient on the networking, doesnt have as near robust a feature set as of yet as the other physics solutions.
And all of these(with the possible exception of novodex)are not geared towards networked physics.

If we coded our own, however, we could make that a top priority, and everything would be better in the long run of things.

As for your question on things like slings and the like, yes, we can implement that, and there\'s the probability that we might, be because we dont have a physics engine just yet, it\'s lower on our priority list

[SgtH3nry3]

Why should physics data go through internet?

Most physics can be calculated on your own computer.

Why would you send rag-doll and rigid body data over internet?
This is completly useless.

UT2004 doesn\'t send it\'s Karma data over the internet, neither does Half-Life 2 or Max Payne 2 or any other game (well maybe a few like Vietcong 2).

Maybe in the far future games will have basic network physics.

[tomcat ha]

Sorry but the mg34 and 42 can be fired from the hip. You cant shoot with using the sites however when carrying it. So i suggest that you can only fire from the hip like in ro. They should also be slower to move around.

[The_Punisher]

Well, the physics of a rag doll body could be calculated on your computer. But stuff like real Objects that could affect movement paths, positions, cover...

That will have to be calculated Server Side.

[SgtH3nry3]

Or client-sided and the 4/8/16 (depends on internet connection) most important bone-position data can be send to the server.

Which takes less work for both your pc and the server.

Open Dynamics Engine is actually even more versatile compared to Havoc.
Mainly because it was built on the Open Dynamics Framework...

But in the FAQ you mention vehicles, will these vehicles have a suspension and inertia system like in BF2 and HL2?

[SgtH3nry3]

SgtH3nry3 Wrote:Or client-sided and the 4/8/16 (depends on internet connection) most important bone-position data can be send to the server.

Which takes less work for both your pc and the server.

Open Dynamics Engine is actually even more versatile compared to Havok.
Mainly because it was built on the Open Dynamics Framework...

But in the FAQ you mention vehicles, will these vehicles have a suspension and inertia system like in BF2 and HL2?

Bump for attention.

[Reno]

We havent decided what we\'ll be doing with ragdolls just yet, but as for the vehicles, yes they\'ll contain suspention, inertia, and all the other stuff that goes into good vehicle physics

[Big-Al]

cool

[SgtH3nry3]

Hmmm, you could take a complicated physics engine and only send the bone/joint-position data of a soft-body.

You send out 9 main bone/joint-positions over the internet from server to client (or when the client interacts with the body vice versa).
- 2x hands
- 2x elbows
- 1x head
- 2x knees
- 2x feet

This should be enough data, and shouldn\'t cause any lag, unless you would be playing on a 28.8k modem.

If you have like 32 dead bodies it shouldn\'t be more than 64kb of data, which is more than enough.

Then of course you\'ll have to count the other physics data too, but most of that can be done client-sided.
Except for street junk/props, like boxes, cartons, dragonteeth, hedgehogs, etc.

[delerium10101]

SgtH3nry3 Wrote:Hmmm, you could take a complicated physics engine and only send the bone/joint-position data of a soft-body.

You send out 9 main bone/joint-positions over the internet from server to client (or when the client interacts with the body vice versa).
- 2x hands
- 2x elbows
- 1x head
- 2x knees
- 2x feet

This should be enough data, and shouldn\'t cause any lag, unless you would be playing on a 28.8k modem.

If you have like 32 dead bodies it shouldn\'t be more than 64kb of data, which is more than enough.

Then of course you\'ll have to count the other physics data too, but most of that can be done client-sided.
Except for street junk/props, like boxes, cartons, dragonteeth, hedgehogs, etc.

Everything sounds like it wouldn\'t be much. It always sounds like it wouldn\'t be much. Imagine a single object that needs a whopping 64 *bytes* per second to keep the client completely up to date. Doesn\'t sound like much, does it? Let\'s drop this into the worst case scenario. We have 128 clients connected to the server, and this object must update on all of them. We just hit 8 kilobytes per second to handle that. For that one measly object. But oh you say, that isn\'t much, cable can still handle that. Righto, continuing with this example (I actually coded this object, but pulled networking support for this reason, makes life fun, but it still works) we have not one, but three hundred of these updating at once. Minimal estimate really. Now, we have a problem. 2.3 MB per second, just for that object type. Out of the question.

It takes far more than 64 bytes/sec to transmit the correct position of an object over the network. It actually takes 896 bytes/sec, per client. Networked ragdoll is out of the question. Networked rigid body is bad enough, and this is exactly why. But yes, it is absolutely necessary that rigid body calculations be sent over the network. It\'s amazing just how quickly client and server can start to disagree.

Moving on, vehicles: Yes, there is a suspension and inertial system going on here. It sucks, but it works, and doesn\'t kill network performance (as much as previous examples). There\'s even a traction system which lets you pull slides under certain conditions.

Rigid body physics: Torque has its own rigid body solver. Again, it sucks, but it works, and doesn\'t kill network performance as much as ODE does. ODE has been successfully integrated into Torque, so long as its a single player game. There have been no playable networked ODE tests with Torque. Once you hit over ten moving objects, even if there\'s just one client, heavy lag kicks in and the whole thing goes to hell.

As a side note, if we do go with a 3rd party physics engine, it would be Novodex. Just wanted to make that clear.

Searching bodies: I don\'t see any reason why not. Certainly a better way to get ammo than running into the spinny shiny clip with sparkles flying around it. It\'s not like TTR was kid friendly to begin with anyways.

Lens flare: No. Just no. End of story.

Blood splat in face: Again no, as stated before. It\'s just worth reiterating.

HDR: Well, ya. I just hope you have a card that can handle it. If not, we do have fallbacks that work pretty well, even on my lowly Rage 128 (Note: My computer(s) will not be supported by TTR, so my saying something works on my computer should not be taken as an indication that I meet minimum system requirements).

Interaction with stuff: Um, ya. Sure, if you absolutely insist.

Keep the questions coming! Ideas from the community fuel development, unless we\'re in a bad mood and just say you\'re wrong.