I had this same issue and it caused a missed deadline. Our workaround was to create a sphere/circle of regularly placed points with the horizontal and vertical steps starting from the poles at a similar degree as the default VR turntable/sphere. Then we moved the camera to each point, re-aimed, and queued for render. This way if a render fails, we can just select that point, move the camera, and go.

To do this, you'll need to calculate a "regular placement" of points on a sphere. I put this in quotes because we weren't concerned with the displacement in the up-axis being uniform, only the displacement between angles. Our best guess was the the Default VR sphere starts and ends about 6.25° from the poles and is waistline aligned with the sphere (thus a single vertical step is a regular turntable)

For each point in the VR turntable/sphere :

`x = radius * cosine of θ * sine of Φ`

`y = radius * sine of θ`

`z = radius * cosine of θ * cosine of Φ`

where :

`θ = the current vertical step * the vertical increment * (π/180)`

`Φ = the current horizontal step * the horizontal increment * (π/180)`

*π/180 because our calculations need to be done in radians*

The increments can be calculated :

`vertical = ( 180° - (2 * 6.25°))/ total vertical steps`

*6.25° is how shy of both polls the sphere turntable starts/ends*

`horizontal = 360° / total horizontal steps`

To center theses on the equator, we remapped the vertical steps from [0,n] to [-n/2, n/2].

`if( total_vertical_steps % 2 == 0 )`

{

new_start = -total_vertical_steps / 2;

new_end = total_vertical_steps / 2

}

else {

new_start = ( -total_vertical_steps + 1 ) / 2;

new_end = ( total_vertical_steps + 1 ) / 2

}

Store all of this in a python dictionary with the indices being your frames and the values being a list of x,y,z coordinates. Then it's simply a matter of accessing and updating your camera.

*update (converting to Keyshot terms got me confused, we were using geographic terms; this should be accurate now)