xmag and ymag should be clarified to be width/2 and heigth/2

[UX3D-nopper]

Also the tutorial is misleading:
https://github.com/KhronosGroup/glTF-Tutorials/blob/master/gltfTutorial/gltfTutorial_016_Cameras.md

[ardenpm]

This should absolutely be clarified. I just came to implementing orthographic cameras and wasted quite a bit of time due to the imprecise description and misleading tutorial.

[ardenpm]

@UX3D-nopper based on recent discussions I believe we can now confirm here that indeed.

xmag = width/2 and ymag = height/2

With respect to the orthographic view width as has been presented in the glTF Sampe Viewer. I imagine this can now be closed with this confirmed.

[donmccurdy]

I'm afraid we made the opposite assumption in both three.js and in Blender. I would agree that clearer language should be added to the specification. We do not write projection matrices from scratch when loading a model into an existing engine, which I suppose was the source of the mistake. Something to the effect of, "xmag" is half the orthographic width would be useful.

/cc @scurest & KhronosGroup/glTF-Blender-IO#944

[scurest]

You can compare the matrix in the spec against the matrix for glOrtho to get

right = -left
  top = -bottom
 xmag = (right - left)/2 = width/2 = right
 ymag = (top - bottom)/2 = height/2 = top

(I'm not sure if this related to KhronosGroup/glTF-Blender-IO#944 though. The code in Blender only ever looks at a scaling factor, not a concrete width, so it couldn't mistake width for width/2.)

[UX3D-nopper]

Actually, it is already exactly defined:

where

• r equals camera.orthographic.xmag;
• t equals camera.orthographic.ymag;
• f equals camera.orthographic.zfar;
• n equals camera.orthographic.znear.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#projection-matrices

This means that xmag and ymag is width/2 and heigth/2. But agree, this should be better communicated. Actually, I opened this ticket :-)

[donmccurdy]

Sounds good, let's keep this open until the clearer wording is added to the spec.

[ziriax]

I'm trying to implement this feature in Maya2glTF, but every viewer I tried seems to scale the 3D scene non-uniformly when using orthographic cameras when resizing the viewport. Clearly that can't be the desired effect, as an exporter can't know the width and height of the final viewport... With perspective cameras, one can leave the aspectRatio property undefined, so that a viewer uses the aspect ratio of the viewport instead.

So I really don't know what values for xmag and ymag I should export...

[donmccurdy]

@ziriax I think that is the specified result: the exporter should give the xmag/ymag values of the camera it has, without knowing anything about the final viewport. The specification does not say what a client should do when xmag/ymag do not match the viewport's aspect ratio:

(a) display non-uniform scaling
(b) fill only a portion of the viewport
(c) resize the viewport
(d) ignore one of the two values

Most viewers have chosen (a). In many cases (c) is impossible, e.g. a web page cannot resize the browser. Perhaps the spec should be clarified with a convention for how clients should resolve that conflict.

[jbherdman]

@donmccurdy I am running into a similar issue with the xmag + ymag scaling, which makes ortho-cameras almost useless. As you say, the viewer-side behaviour is mostly (a), but that does not really reflect the 'intent' of the source camera data.

Would it be reasonable to change the spec so that xmag could be an optional value? If specified, it should be used as-is, but if left unspecified, the viewer-side code could know to compute it from the aspect-ratio of the canvas. That would make it very similar to leaving the aspectRatio unspecified on a perspective-camera, and neatly solves the "unwanted stretching/scaling" problem.