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)