Pano2vr 6.1.10 is still broken. Transitions and Autorotation fail.

[Branigan]

Transitions are still broken and the new update did not fix them. I just updated to Pro specifically to get transitions and the other minor advantages of Pro over Lite.

I'm using Diagonal as the Display FoV Mode because it's the correct one to use for Panoramas to automatically adjust themselves to different aspect ratios, but apparently no one is testing anything in that mode.

Here's a simple test. Set FoV to Diagonal. Setup two Nodes and link one to the other. Set the Target for the second one on arrival and then export and play it.

What happens? When you arrive at the second panorama you are TOO ZOOMED IN. This is because it takes the FoV value of the Target and mangles it twice(?). Once for the fact that being Diagonal, the actual FoV isn't what you think it is (put some text in the skin to show it on the screen to check) , and again when it adjusts the Target FoV value to compensate for that, forgetting(?) it's already done it once(?). Or something...

The only solution (and as I was using Lite before, this was my only option for having Target angles anyway and I reported this as a bug months ago) is to manually DELETE the FoV parameter (or type it in without one if using Lite). So instead of it saying -49.8/0/90 it has to say -48.9/0/ . Then when whatever it is in the Node's Viewing Default Parameters (90 again) is used instead and is adjusted once to the correct FoV Diagonal-modified values.

So what happens with Transitions when using Zoom In on both sides of a Cross Dissolve? Same problem. When you arrive at your destination using a Zoom In, it apparently Zooms In further FROM an already incorrect FoV to some other worse value, instead of zooming in TO the correct value.

If 'Wait for Transition' is Set On (it should be Off, but this separates things to make it clearer) it's even more comical. It Zooms In, (correct) Cross Dissolves on the last image (Correct) over an image of the Destination with an FoV that's already too Zoomed In (Wrong) , then Zooms In even further (Wrong^2).

What is should have done was allow a number of degrees to Zoom in FROM the start FoV (like 10), and a number of degrees to Zoom in TO the Destination FoV (like 10 again) all while doing a simple, seamless Cross dissolve. You can do this with photos in about 5 seconds in any photo slideshow program.

So, if both the Start and Destination FoVs were 90 degrees, the Start goes from 90 to 80 as it Cross dissolves over the Destination going from 100 to 90. With no hiccups, stops, skips or aborted autorotation. Yes, autorotation should also work through the transition arrival if it's set.

Going back to a simple Cross Dissolve doesn't even work. With Autorotation set, only the first location actually autororates. Thereafter all other locations do a sort of mini-hiccup where they start, then stop rotating after half a second or so, while attempting to Cross Dissolve. It actually looks fairly interesting when it works , but half the time it just doesn't bother and drops you straight in the destination with no dissolve at all and no semi-autorotation/abort either.

Again, this is all in Diagonal FoV mode. Instead of only testing in Vertical, which - if the name doesn't give it away - is intended for Portrait style displays, can the maths be properly tested in all modes for the next release?

[Hopki]

I belave at one point it was said, to be able to change the FoV in both zoom in before and after would help, this was a relatively simple thing to add so we did it.
The FoV mode for the player, on the other hand, is not so easy and has the potential to break other things so it will be looked at in a future beta.
As though you could use an action with an action filter.

As an example: use a player state change, set view, $(ap)/$(at)/90.
Then use an action filter to only do this is if the player is in landscape and has touch..

Regards,

[Branigan]

I belave at one point it was said, to be able to change the FoV in both zoom in before and after would help, this was a relatively simple thing to add so we did it.
The FoV mode for the player, on the other hand, is not so easy and has the potential to break other things so it will be looked at in a future beta.
Regards,

Yes, that would have been written by me when I first found the bug.

However, that's not all that was done, was it? The original had values of 0-50 where one side was using it as 0-50 and the other as 50-0. All that literally had to be done was split them up so that we could separate them instead of them half-sharing a single value and each using it differently.

But, no.... Now we have 0-70 and 70-120 and it doesn't work as well(!) as it did before. Was the problem not clearly explained enough?

That FoV Mode needs sorting because not using Vertical breaks everything. We're not all (actually no one is) creating tours for giant upright mobile screens.
They are however massaging the values to look correct on a desktop and wondering why they then look bad on a mobile screen because they're using the wrong FoV mode.