How to retrieve aperture from FBX Camera

Questions
1

I can’t seem to find any aperture info from my exported cameras within the camera objected imported into Three.js. Is this not supported?

Also, what about fisheye cameras?

2

The features supported by THREE.PerspectiveCamera are:

https://threejs.org/docs/?q=perspectiveca#api/en/cameras/PerspectiveCamera

FBX is not known for being well-documented as a format, but you can see what has been implemented by reverse-engineering in FBXLoader here:

3

Alright. So I see there is the following in the attr

ApertureMode: Object { type: "enum", type2: "", value: 3, … }
  flag: ""
  type: "enum"
  type2: ""
  value: 3

I’m not positive how to decipher this. The FBX SDK docs aren’t much help either. Is 3 the aperture diameter or something?

It seems to relate to a type of aperture “mode”. But what does that even mean to the end-programs? lol

Update: So I found this page: KFbxCamera

When the aperture mode is eHORIZONTAL_AND_VERTICAL , eHORIZONTAL or eVERTICAL , the field of view is used. When the aperture mode is eFOCAL_LENGTH , the focal length is used.

It has a method to compute either modes, but I’m not sure what they’re doing for “eHORIZONTAL_AND_VERTICAL” to get their value. Focal length is obvious no issue. Though It’s confusing the mode is “3”, when it only mentions two modes. Oh, no scratch that. There is three modes. I just don’t know what it is doing with horizontal and vertical. I assume FOV. But are they divided, multiplied, added? lol Frustrating.

1 Like
4

How can I access these attribute values while loading a FBX? Is that possible?

5

I think this would require local modifications to THREE.FBXLoader, but I’m not familiar enough with the FBX parsers to say how difficult or easy that would be.

6

I just created a global array before the functional encapsulating the classes, then I just pushed the attributes to it

cameraAttributesArray[ attr.propertyList[1] ] = attr;

I figure it’s good enough as anyone running this, is running it locally and so not a security issue (with any of the data being stored or used server side).

Then just access the array after the FBX is loaded.

I tried to do it internally with a variable to access from FBXLoader() but I was having issues getting the functions to pass the array data without extensive modification to constructors and stuff, which would make updating the whole thing a pain if that were to be needed.

It turns out all this may have been for not though, even though it is using aperture mode 3, the focal length set as aperture doesn’t work, and the exported camera is not what the source is. I need to figure out the math side of things, calculate f-stop, etc and derive aperture in mm in X and Y. Still not sure. I’m terrible with math and not finding the info I need.

7

Turns out I hit another road block. The issue is, at the camera creation level, I only have access to the true cameras name (naming the camera and not the camera node in something like Blender). I also have access to an ID. The problem occurs in the actual created camera. It has a different ID, and a different name (the node name). So I have no way to access the array by key to get the attributes I need for each camera.

Where is the name for the actual camera object being set? Also wondering why it wouldn’t follow the cameras actual name instead of using the node name. The node name could be just referring to the same camera, and thus wouldn’t even need to be a new camera.

For example, if I just duplicated the default camera a bunch and move it around, i’ll end up with camers named as so:

[Node]       [Camera]
Camera      -> Camera
Camera001   -> Camera.001
Camera002   -> Camera.002

And so on.

8

I solved this by pushing the attributes ID as a variable in the camera model object, and using that ID to retrieve the relevant info from my attributes array.

For some reason if you use the ID raw, or even as text without actual text, ie “ID1234567” it will create a infinite array of random digits until it breaks. Not sure what that is about.

1 Like
9

The FBXLoader is split into Parser and Loader (roughly). The Parser reads the file (either ASCII or binary) and returns an object called fbxTree with the data in a format that can be read by the Loader. The Loader is then responsible for converting this data to three.js objects.

I am fairly sure that the Parser now returns all data from the FBX file (although not 100% sure, it’s a while since I worked on this and it hasn’t been tested with newest FBX releases). However, the Loader ignores quite a bit of it, mostly because it can’t be implemented in three.js. There’s also still some stuff like handling camera attributes that can probably be improved (cameras in particular I didn’t spend a long time on).

You can view the fbxTree by uncommenting this line:

To figure out what the FBX data means I have found a couple of useful places. First is the FBX SDK docs which @WASasquatch already linked to. Then there’s docs for Autodesk products. This one seems to have a good list of camera properties (don’t consider it exhaustive though, it’s just what the Smoke app supports)

http://docs.autodesk.com/smoke2013/index.html?url=files/GUID-E5D48282-76C5-4123-A6BC-89DA5AAD277E.htm,topicNumber=d30e49728

If you do need to hack into the Parser then this post is useful for an idea of how the binary format works, although it’s easier to start by exporting your file as ASCII.

You could also try searching through the source code of tools like Assimp, FBX2GLTF, or Blender to see how they handle FBX cameras. Maybe Godot too, not sure if they do FBX.

1 Like
10

Thanks for that information. Yeah, at least I think I found all the information I need relevant to cameras in Terragen, to import. The only real issue now though is that darn rotation issue I’m having. I’ve tried every combination in export, but I think it’s more down to not understanding Three.JS rotation radians and how to properly convert them for X +Y +Z space.

I do think the parser could be improved to offer the real gauge from the FBX file that I’ve discovered in the other topic that you referred me here with. It does seem to relate pretty much exactly to the blender camera at 36mm, and it also matches the vertical gauge that TG also wants at 24mm. So these must be correct values. They’re just oddly in inches. So they need conversion.

Additionally, my tool in it’s current state is online here: FBXCam2Terragen - NWDA - New Worlds Await if anyone is curious. Definitely open to improvements. Not used to working in Javascript.