I'll repeat my sample with video compression. You advice something like "convert bright frame to quantized 256 colors palette". If I send data of hundred objects on every step, I get about 40 kb per second. Yes, if I use your advice, I'll get about 20 kb per seconds, but all of my possible solutions usually use 500 bytes per seconds, with no 8-bit positions, rotations etc.

Anton: If you're saying the client will not run a physics engine, then you will not be able to properly predict the movement of objects that intersect terrain or other objects.

Dead reckoning linear and angular orientation based on snapshots is an old technique. Sending additional snapshots only when there is a given amount of delta between the extrapolated and real positions is also an old technique. This is well defined and well described in available distributed simulation literature -- for example, the DIS protocol (IEEE 1278) defines several modes of dead reckoning and delta compression for snapshots.

Regarding the rotation aliasing problem, there really is no problem. If you send rotational velocity as a denormal quaternion (really, an axis with a length), then the rotation across any particular time period is well defined no matter how long or short the time period is. If you sample it at long enough intervals, you will get sampling aliasing, where the object may appear to rotate in the other direction, or even stand still -- that's a sampling problem, not a representation problem.

So, if you want to keep this thread going, I suggest that you formulate very clearly what the point of your thread is.

1) Are you trying to select between a number of different algorithms? If so, you'll need to show specific numbers that relate to your problem at hand, for anyone to be able to give a good answer.

2) Are you trying to get pointers to mechanisms you can use to solve a particular problem of dead reckoning? If so, I suggest reading the reference linked in this post.

3) Are you trying to have another question answered? If so, you'll need to be more precise and concise in what the question is.

That being said, if the question is "what's the best way of minimizing bandwidth use when getting clients to view some subset of a server-side physical simulation," then the answer really is "also run (parts of) the simulation on the client." If you don't want to do that, then you don't want to use the most bandwidth efficient mechanism, it's as simple as that.

I think you forgot to negate the 0.999 in one of the first case.
The point still holds, though: they are not the same, numerically.

hplus0603, if you can run Havoc engine on j2me device, I'll be very happy. So I need to make something simple to implement it on server and in j2me.

Havok powered games back when a Pentium-120 with 16 MB of RAM was top-of-the-line. It could totally run on modern smart phones (capable of displaying 3D graphics for the moving entities you've been talking about). You'd need to license it appropriately, and probably use a native SDK for the phone, though.

I believe there are also lighter-weight Java physics SDKs, because the basic math of integrating a rigid body, and detecting/responding to collisions, is not that complex. You don't need to run exactly the same simulation on server and client (although it helps); the main point is that forward extrapolating only linear parameters isn't good enough when there are significant non-linear events (intersection with ground or other objects) in the path.

An alternative is that you send every non-linear event visible by the client from the server to the client. That's still less data than sending the full state of each object each frame. If that's what you do, then you send position, linear velocity, orientation and angular velocity per object when that object makes a significant change in those parameters (very similar to DIS/IEEE1278). Forward extrapolating based on those four quantities is a well defined operation, no matter how large the angular velocity is (but there are simulation stability reasons for not wanting it to be too high).

The comparison to video is probably not that useful, because the data entropy and error function of a video data stream is very different from the data entropy and error function of an entity state data stream.

Maybe in your countries touch screens are something popular, but here we just see first affordable touch devices. Some phones are still B/W, not color, about 30% phones have midp 1.0, so most of all have midp 2.0. Smartphones are mostly old Nokias...

But most of MIDP2 devices support 3D, but do not support C++, Symbian, etc. Just j2me. So they are able to calculate easy physics, there's no need to process collision, friction, hard systems. Just move/rotation, synchronized with server. In most cases it's x=x+v*dt, q=0.5*w*q or something like this.