Reading fov from another chunk than the camera's is really stupid as you have to match it somehow to the corresponding camera...*'"$%!"## 3DS-format!

That's the problem of closed / private file formats... Ahead, this is what I've done:

Exported a 3ds from 3dsm contaning a 'targetable camera' with FOV = 45º.
Read 'f' from the file with 53.3(3) and changed it to 40. Saved the file.
Loaded the scene from the file in a new scene in 3dsm. FOV still is 45º.
No editing, just exported the 3ds and overwrite the file. Read 'f', it got back to 53.3(3).

Now the roll, it's also stored in that strange chunk, which I have not yet discovered it's identifier. The roll specificies this camera rotation (the skillfully drawn arrow ):



This is the actual file structure (another skillfully drawn picture):



This is the same camera like before, I just altered the roll to 45º (0x00003442). I have a feeling that 'camera chunk' is deprecated

Quake 3 Arena based games do like Egon said. Players send events to the server (usually running at 20 events / second, server side cvar sv_fps ) which does all the checking and logic of the game. Then the clients 'pool' the server for world events, and interpolate these. For making shure the game is fluid (like shooting and not waiting to the server's acknowledge), the client may run a kind of event prediction. That's why when someone connected to the server looses communication and walks (fires, etc.), it may happen that the player actually moves or fires for some little time (on the average of miliseconds), but locally!

The question is, if this is save...(most likely not...)?

Sorry, I did not understood. The 3ds I analysed (excluding the ring ones) were all exported from 3ds max.

I've been "playing" with 3ds max for some time and with winhex (nice hex editor) and I came to the conclusion that the FOV (AOV ) is not stored on the camera chunk (0x4700). When I change the FOV on 3ds max, the f value of the camera chunk changes, but another value on another chunk (which I have not discovered yet on the documentation) also changes. Actually, this value is always the fov value, in degrees (and stored as float).

Oh well, in the meanwhile, I've also done a table giving the relation I've found between FOV and the 'f' value:

FOV Focal Length
0,5 4800
2 1200
3 800
10 240
15 160
30 80
45 53,33333333
50 48
60 40
70 34,29
80 30
90 26,66666667
As I said, the f value changes with fov, but not vice-versa, i.e., the fov can't be (or shouldn't be) directly taken from f. Doing some math you can probably get a function giving one value from the other...
Now, I've got to study for an exam The sooner I'm available, I'll give you more about that unknown chunk.
No need to thanks, always ready to help!

Indeed, I don't like 3ds too (both the file and the "proggy"). First of all, it's binary, making me difficult to edit the information by hand (for instance, replacing all vertices with Y of 0.3 to -0.3, mantaining the others). Second, it's documentation is quite complicated (for me), all that stuff of chunks or sections, etc. (like the bsp's lumps). Brrrr.... Wavefront Object rules !!!

Now, about the file. I've installed Cinema4D just to try (don't ask me where I got it  ), and for it, the "f" values (51.42857) is the Focal Length, equal for all the cameras. I also get (for them all), aperture width = 36 and FOV (actually, the correct term is AOV, angle of view) = 38.58º, again equal for all of them.

I checked some one of the 'unofficial' 3ds specifications and as you may now, the camera lump (4700h) only has position, target, 'bank' and 'lens' information, so the aov (fov ) is computed from both bank and lens values. Googling a little (with angle of view), I got this from the wikipedia:
http://en.wikipedia.org/wiki/Angle_of_view

a = 2*arctan(d/(2f)),

where "a" is the aov, in radians, "d" is the 'aperture width' and "f" the focal length, which are the values C4D gives.
The 'code' you show, is it the data acquired by your parser? I.e., "a" is the specification's "bank" parameter and "f" is the "lens" one?

Finally, roll is the rotation on the object's Z axis (planes xOy, what in jPCT appears as rotateZ).

In the api, the sorting algorithm is applied on the object's polygons or on a per-pixel basis (like OpenGL does when using the depth-test)?

Hum, the third tab on my DE is 'atributes' and appears empy for both cameras (Scene_x) and camera targets (Scene_x.target). The 'origin' and 'target' I found (which appear on the object tab, local coordinates) are the same for all the cameras.
For instance, for the 5th camera (scene_5) I get this on the summary page:
World Org : 74.644310,533.166260,21.352112
World Target Point: (-17.981171,-471.322479,21.352112),
Vector: (-0.091822,-0.995775,0.000000)
World Up Point:  (74.644310,533.166260,1030.102417),
Vector: (0.000000,0.000000,1.000000)
View X="95.2684"    Y="180"     Z="-180"
The only item I haven't understood is the 'View X'. It seems to change with rotations on the camera.