Hi Silvia, nice post. Thought to add a note, since I've been on this topic lately.

Usually setting ViewVertical & ViewPoint is enough to get a good result. ViewVertical defines a directed line in space, and ViewPoint a point (obviously). Looking from the point there is one rotational degree of freedom, which is then fixed to the vector of ViewVertical. Perspective can be controlled by taking near or far ViewPoints, with limit to infinity approaching ViewProjection->"Orthographic" (?). The problem is with bounding box. Using some of the previous chess assets:

glist1 = Show[GameState[TwoKnights], 
     Graphics3D[{Black, Sphere[{0, 0, 2}],
       Sphere[RotationMatrix[Pi/50 #, {0, 0, 1}].{0, 64, 0}] & /@ 
        Range[100]}],
     ViewPoint ->  100 ({Sqrt[2] Cos[Pi/50 *#], Sqrt[2] Sin[Pi/50 *#], 1}),
     Boxed -> True, ViewVertical -> {0, 0, 1}, 
     PlotRange -> {{-65, 65}, {-65, 65}, {-2, 16}},
     ImageSize -> 500] & /@ Range[0, 100];
ListAnimate[glist1]

This is not what we want, and setting Boxed->False does not change much. According to stack exchange, there is another option to set "ShrinkWrap"?? Anyways, here's an improved rotation:

glist2 = Show[GameState[TwoKnights], 
     Graphics3D[{Black, Sphere[{0, 0, 2}],
       Sphere[RotationMatrix[Pi/50 #, {0, 0, 1}].{0, 64, 0}] & /@ 
        Range[100]}],
     Boxed -> False, Method -> {"ShrinkWrap" -> True},
     ViewPoint -> 100 ({Sqrt[2] Cos[Pi/50 *#], Sqrt[2] Sin[Pi/50 *#], 1}),
     ViewVertical -> {0, 0, 1}, 
     PlotRange -> {{-65, 65}, {-65, 65}, {-2, 16}},
     ImageSize -> 500] & /@ Range[0, 100];
ListAnimate[glist2]

This looks much better, though the animation still has a bit of jitter. If I were to mask out the black spheres on the boundary, probably it would look slightly more smooth.

Hi Brad, I tried your Penrose tiling example on 12.3 for Windows 10 and recorded ListAnimate's result on my screen with an external camera. I think the testing result on my side is "pixel-perfect". Please check attached notebook for detail.

However, I do remember seeing the jittery issue on certain older Mathematica version. (I can't really remember it, maybe 11?) As my personal understanding, since version 12, there has been some change in FrontEnd in order to support 4K display, which might be related to this kind of issues. I guess they are likely OS-related.

-- you have earned Featured Contributor Badge Your exceptional post has been selected for our editorial column Staff Picks http://wolfr.am/StaffPicks and Your Profile is now distinguished by a Featured Contributor Badge and is displayed on the Featured Contributor Board. Thank you!

The "jittery issue" is a problem with Mathematica, possibly having a low level dependency on operating system, see also this earlier thread.

You are right about SphericalRegion being a smart option to set, but why should I have to if I've already entirely bounded the content by a great circle? It does fix the "zitterbewegung":

In user land I would expect this output, without jitter, whether or not I set SphericalRegion.

Just to show you how ugly this issue can get, here's another failed call I came up with working on the Penrose tiling thread. Obviously this would not be good to send to twitter:

When I was making this I'm sure that I changed to zooming camera to hide "extra entropy $\Delta$". To make it more obvious, I use the following function:

JitterTest[path_, file_] := Export[  path <> "JitterTest" <> file,
  Map[ImageSubtract @@ # &,   Partition[Import[path <> file], 2, 1]],
  "AnimationRepetitions" -> \[Infinity]]

The problem, I guess, is with rasterization from vectors. There should be no noise interior to edge growth, and definitely no difference whatsoever in repeated frames at the end of the animation. If this error can't be trackbacked to the source and fixed on my end, then this is another reason, contra Jon McCloone, that Wolfram Language is not like open source. Especially if it ultimately has to do with Linux.

In last Weekend's thread about Taking the Autoglyphs by Root Pulling, you can see the chosen vector views use Polygon[] rather than Line[]. The reason for this choice is that I noticed similar problems and overlap inconsistencies with Line[]. The best solution I can think of presently is just to rasterize vector objects then ReplacePart them into a data array and output using Image[], as I did for the second bitmap view.

Ultimately when displaying to a screen bitmapping is always an issue. Even if we finally start to get some weird machines or weird gadgets with hexel displays (hexagonal tiling) rather than pixel displays (square tiling), bitmapping will still be an issue.

Another interesting page I found in the manual is How To | Connect a Gamepad. The idea for camera control on isometric view strategy game is clicking $L$ or $R$ shoulder buttons would cause a smooth rotation between one of four symmetrically equivalent, fixed viewpoints. Then arrows and letters can be used for scanning and selecting, menu navigation, whatever, etc...

Thanks again for the extra Option, nice knowledge you have.

--Brad

Hi Brad, I'm not sure I fully understand the view config you want, but I noticed in your code MapThread[Arrow[{#1, #1 + #2}] &, {viewPt, viewVec}] , which might not be doing what you meant for.

ViewPoint is the position of the camera in a scaled coordinate system, while ViewVector is either the position of the camera or a pair of positions corresponding to ViewPoint and ViewCenter, BUT either way they're in the "absolute" (or non-scaled) coordinate system. So adding an absolute vector to a scaled position does not give immediately meaningful result.

Also, if we are using explicit ViewVector option in Graphics3D, then ViewPoint won't affect the result, as according to the documentation:

Explicit settings for ViewVector override settings for ViewPoint.