Relation between orthogonal view width and focal distance

Comments

• TheMysteryIsThePoint Posts: 3,216

  March 12

  Orthgonal view doesn't have a focal distance since its parallel lines never meet.
• Omniflux Posts: 427

  March 12

  I specified focal distance control as that is how DS is exposing zoom for orthogonal cameras, but then I neglected to specify that is what I am trying to do :(
• algovincian Posts: 2,664

  March 12

  I'm reading the forums on my phone atm, but just from looking at your test cases, it seems that the Focal Distance and the View Width are proportional, no?

  So, for this particular orthogonal camera:

  Focal Distance = View Width * ( 432.8629150390625 / 421.6197204589844 )

  Please post back if I'm missing something. I'm not sure exactly what oCamera.currentViewWidth actually means in this case lol

  - Greg

   
• Omniflux Posts: 427

  March 13

  No, but I only gave two example points to show what I was looking for, so you couldn't know that from just the data in the post

   

  Focal Distance: 474
  View Width: 444.1061096191406
  

   

  444.1061096191406 * (432.8629150390625 / 421.6197204589844) = 455.948941352 != 474
  

   

  There are other factors that affect it as well, such as aspect ratio and focal length (so probably just field of view), but I don't know if that is all of them, and if it is, I don't know how they all relate.

   

  Focal Length: 65
  Aspect Ratio: 16:9
  Focal Distance: 462
  View Width: 432.8629150390625
  
  Focal Length: 65
  Aspect Ratio: 1:1
  Focal Distance: 462
  View Width: 396.00238037109375
  
  Focal Length: 50
  Aspect Ratio: 16:9
  Focal Distance: 462
  View Width: 562.7218017578125
  
  Focal Length: 50
  Aspect Ratio: 1:1
  Focal Distance: 462
  View Width: 514.8030395507812
  

   

  I thought it would be

   

  distance = targetViewWidth / (2 * Math.tan(oCamera.getFieldOfView() / 2))
  

   

  but it's not...
• Omniflux Posts: 427

  March 13

  oCamera.currentViewWidth is shown here

  

  

  Untitled.png

  1280 x 696 - 48K
• algovincian Posts: 2,664

  March 13

  Omniflux said:

  There are other factors that affect it as well, such as aspect ratio and focal length (so probably just field of view), but I don't know if that is all of them, and if it is, I don't know how they all relate.

  After testing some when I got home, I'm confused by the fact that I can vary the focal length of a cam when the perspective is off since focal length is infinite for ortho cams as @TheMysteryIsThePoint said. Also, talking about the FOV for an ortho cam makes no sense to me intuitively, or in the calculation for FOV.

  Then again, it's after midnight here and it was literally another century when I actually studied optics, so maybe I'll try again tomorrow. Or maybe I'll just try plotting it to help back into the math DS is using. If I'm reading you right, you don't care about the optics equations - you just want to predict how DS is calculating?

  I have an old project that automatically adjusts an object so it fills a cam's frame exactly, which seems related. It's working for cams with perspective on but I never got it working for ortho cams.

  - Greg
• Omniflux Posts: 427

  March 13

  algovincian said:

  If I'm reading you right, you don't care about the optics equations - you just want to predict how DS is calculating?

   

  If by predict you mean reproduce, then yes.

  In a script I want to adjust an orthographic cameras zoom such that the currentViewWidth is a specified value by only changing the focalDistance control value like DS does when using the mouse scroll wheel in a viewport.
• algovincian Posts: 2,664

  March 13

  After not being able to match your results using an actual camera instead of the view, I tried to recreate your setup. I ran the script you posted, zoomed out with the mouse wheel one click and ran it again. Zoomed out another click and ran it again. Here are the results:

  FD  /   VW

  450 / 474

  462 / 441

  474 / 453

  I then Reset the view and changed the position of the dividing bar. When repeating the procedure, looks like I got different results only for FD = 450?

  450 / 553

  462 / 441

  474 / 453

  Then my phone rang - doh! I've got to deal with other things so I have to stop now, but I did upload a video of what I described:

  

  I'm probably not going to be able to mess with this any more today because I have to leave.

  - Greg
• Omniflux Posts: 427

  March 13 edited March 13

  I have noticed this issue too. It appears sometimes the currentViewWidth and height are not updated when they should be, and you have to cause something else to trigger the fields to update before they are correct.

  I have noticed it when changing the viewport camera to a camera not set to use local settings (so it updates to the render view settings) for the first time in a session, and when calling the reset method.

  I have not filed a ticket for the issue at this time.

   

  Moving the dividing bar does not change the view width, the viewport adjusts to keep the aspect ratio the same. view width != pixel width, it is more like...a world view width?

  Post edited by Omniflux on March 13
• Omniflux Posts: 427

  March 16

  Off topic for what I'm looking for, but here's another case where currentViewWidth and height do not update as I would expect...and then they do. Maybe need to wait for a signal before proceeding in this type of use case.

   

  var oCamera = MainWindow.getViewportMgr().getViewCamera(1);
  var oBox = DzBox3(-50, -50, -50, 50, 50, 50);
  oCamera.frame(oBox, 1);
  print (oCamera.currentViewWidth);
  print (oCamera.currentViewWidth);
  sleep(1)
  print (oCamera.currentViewWidth);
  print (oCamera.currentViewWidth);
  

  Executing Script...
  385.716552734375
  385.716552734375
  300.0887756347656
  300.0887756347656
  Result: Script executed in 0 secs 17 msecs.