Okino Website Claims 3DS Exports Cameras

[C3R14L.K1L4]

The information you show is for which camera?

[EgonOlsen]

Camera7 of the second ring example.

[C3R14L.K1L4]

Sorry  but I deleted the file, I thought you would be using the single 3ds I uploaded recently.
If you wouldn't mind to mail or give a link so I can check it...

[EgonOlsen]

I'll just continue working with the latest example, no problem. So i tried to read that one...the results are, as expected, different from the former files. This is what i get for all 5 cameras:

Code Select Expand


----------------------------------
Camera:
x= -103.36
y= -490.54068
z= -17.66559
tx= -790.4902
ty= 93.751114
tz= -85.55919
a= 0.0
f= 51.42857
----------------------------------

----------------------------------
Camera:
x= -103.36
y= -45.35763
z= 7.392467
tx= 587.8376
ty= 533.63574
tz= 79.27386
a= 0.0
f= 51.42857
----------------------------------

----------------------------------
Camera:
x= 225.34636
y= -14.016275
z= 12.724576
tx= -537.1037
ty= -500.6622
tz= 12.724576
a= 0.0
f= 51.42857
----------------------------------

----------------------------------
Camera:
x= -2.0265538E-6
y= -45.35763
z= 153.8393
tx= -720.77325
ty= 501.12222
tz= 153.8393
a= 0.0
f= 51.42857
----------------------------------

----------------------------------
Camera:
x= -25.355688
y= 433.1663
z= 21.352112
tx= -17.98117
ty= -471.32248
tz= 21.352112
a= 0.0
f= 51.42857
----------------------------------


Now, all positions (x,y,z) are correct (when compared to DE). All targets are correct anyway, they always were...
The information tab shows (with (x,y,z) being the camera's position):

(x,y,z) = Org
(x,y,z-1) = Target
(x,y,z+1) = Up

for all cameras but the last two. There, the z-values of the up-vectors are completely off...something like z+10xx. So maybe "Information" is just bogus, who knows.

Anyway, in the two older ring files, f (which is the FOV value) always was correct, i.e. the value in DE was equal to what i got. In this file, this isn't the case. DE tells me, that the FOV is 46.6667° but i'm reading 51.42857° from the file. In addition, the angle is always 0 in this file. It was 1 in the others (which doesn't make more sense, it's just different).
Plus DE gives me a "roll"-value (i don't know where that comes from), which is always 0 in the new file. For ring1 and ring2, it was something like 330-359.999...

To summerize this, we have three different behaviours:

ring1: Position and target were correct, angle was 1, fov was correct, roll was 359.999
ring2: Positions were bogus, targets were correct, angle was 1, fov was correct, roll was 349.999 and 330.999
untitled: Positions are all fine and so are the targets, angle is 0, fov is bogus, roll is 0

For all of them the data in the Information-tab is..whatever...

Does this make any kind of sense? The parsing and reading of the 3ds file is correct btw. It uses the same methods to extract the camera data that are used for the rest of the file, so if that would be wrong, the whole loader wouldn't work. I've re-read the specs, but can't find anything else that is camera related. I've no idea what's going on here and i really start to hate the 3ds format...

Edit: No, i actually hated the 3ds-format before...

[C3R14L.K1L4]

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).

[EgonOlsen]

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.

Which leaves the question why DE says it's 46,6666°!?

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?

Yes, a is bank and f is lens. The formula is fine, but where do i get d from?
Edit: Or is it safe to assume that d is fixed at 36? Seems to be a popular value for cameras according to google...

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

I thought so too, but where does this value come from? The 4700-chunk doesn't have it, does it? At first i thought that it can be calculated from a (bank, angle...), but obviously it can't. And i can't find any other chunk that contains it...

BTW: I'll keep calling it fov. I've never read the term aov in 3d graphics related stuff...
BTW 2: Thank you very much for your efforts. I really appreciate them.

[C3R14L.K1L4]

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:

Code Select Expand

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!

[EgonOlsen]

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...

You've already given that function (it's that arctan-thingy) and it works fine as long as i assume that d is 36 (have to convert it to radians before, but anyway...). The question is, if this is save...(most likely not...)?

[C3R14L.K1L4]

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.

[EgonOlsen]

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.

That's most likely because i spelled safe wrong... what i meant was if it is safe(!) to assume that d is always 36. Because if it is, f can be used to calculate the fov. If it's not, d has to be stored somewhere else in the 3ds and the question is where...

[C3R14L.K1L4]

But as I said before, if I save a 3ds from 3ds max with camera's fov (in the program the parameter is called FOV, not AOV ) set to 30º, you can read from your parser 'f' = 80.0 but if you change this parameter in the same file, for instance to 40.0, and import it to a new scene in 3ds max, you'll get the old 30º fov... and not 60º as you expected (in the table)...

I.e., officially, fov is got from the other chunk, not from the 'camera' / 0x4700 one
To be exact, IMO this is quite stupid... two related parameters for the same thing... (as I can think of).

[AGP]

Thank you, C3R14L.K1L4 and Egon for picking this up without me. I've been spending way too much to buy Okino's exporter! I've got my fingers crossed that Egon will find a way.

[EgonOlsen]

I.e., officially, fov is got from the other chunk, not from the 'camera' / 0x4700 one
To be exact, IMO this is quite stupid... two related parameters for the same thing... (as I can think of).

I got it now, but it doesn't matter to me as long as f in 4700 is valid when saving the file in a normal way, i.e. without using a hex editor to edit it. What does happen to f if you save the edited file again? Does it change?
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!

[C3R14L.K1L4]

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

[C3R14L.K1L4]

I've played with this for a whole day and I couldn't retrieve that chunk's id... Perhaps my brain's low on fuel, but I think we need a real hacker here. I've also checked jme (j monkey engine) and it has some code to process the camera chunk, but does nothing with it. About the unknown chunk, there's no reference to it in jme's source.