Fly In problems. Hiccups and Fighting Limits

Q&A about the latest versions
Post Reply
Branigan
Posts: 231
Joined: Tue May 19, 2020 3:43 pm

I'm trying to fly in from a Little Planet to a Rectilinear view, then slowly autorotate.

Problem 1: Can't go from Fisheye at any FoV to Rectilinear without a big hiccup in the middle.
Problem 2: Even going from a top down, fairly zoomed out Rectilinear to Rectilinear view has problems - I have a limit on looking up of 20 degrees, but even resetting everything to roam freely doesn't work.
Problem 3: I did get a nice version of a small tile zooming up from the blackness, then rotating in to settle on the Default Rectilinear view, but I reset everything and lost that and have never been able to make it come back since.
The closest I can get to is a really small tile appears for about a second, then jumps to a much closer view, hiccups and then spins in to the default view.

Problem 4: Even after settling for a fairly mild "look up and rotate into Default View" the 'Start after Fully Loaded' AutoRotate doesn't work.

I find I'm fighting against the Limits I need to set on the Top angle (no sky up there in an aerial Panorama) and the Max and Min FoV, because when I reset them, I get slightly more mobility, although it's still fairly "stick in a number and hope". But, I need those limits there to restrict movement and zoom levels once the Fly In has finished.

So, bug or 'feature'? Anything else I should be doing? Any limits I can have set themselves after the Fly In is complete if I reset them all at the start with some magical Javascript?
Branigan
Posts: 231
Joined: Tue May 19, 2020 3:43 pm

I found how to get back the Fly In from a dot: I need to turn off all limits, which unfortunately I need for the rest of the panorama to work - for the aerial example.

No limits Rectilinear to Rectilinear Fly In looks like this:
.
flyin1.gif
flyin1.gif (3.24 MiB) Viewed 3217 times
.
But because I have a partial sky (taken with a drone) I need to set Viewing limits.
.
whylimits.jpg
whylimits.jpg (453.69 KiB) Viewed 3217 times
limits.jpg
limits.jpg (44.04 KiB) Viewed 3217 times
.
Which makes the Fly In look like this:
.
flyin2.gif
flyin2.gif (3 MiB) Viewed 3217 times
.
At least that's relatively smooth motion; but with or without limits, a Fisheye to Rectilinear Fly In doesn't work, with big hiccups during the transition. It's hard to see as this GIF is only at 10fps, but imagine it looks about as jerky as this in the middle, but smooth at the start and end.
.
flyin3.gif
flyin3.gif (4.53 MiB) Viewed 3217 times
.
So are people not supposed to try and blend from Fisheye/Tiny Planet to Rectilinear as a Fly In? I have other panos with no limits I'd like to do with with but still can't - that's where I started exploring this - due to the hiccuping. The effect the Viewing Limits has on the starting position is just another wrinkle.
.
User avatar
thomas
Chief Gnome
Posts: 2611
Joined: Fri Sep 01, 2006 3:56 pm
Location: Vienna, Austria
Contact:

You don't have to depend on the default flying. You can make your own animation to your likings in the animation editor, and use this as your flyin. Just long press on the + button in the animation clips:
Screenshot 2020-07-15 18.46.18.png
Screenshot 2020-07-15 18.46.18.png (40.84 KiB) Viewed 3196 times
With this, you can choose the right time for the projection transition and tweak other aspects.

You can find the documentation here: https://ggnome.com/doc/animation-about/
MfG, Thomas
Branigan
Posts: 231
Joined: Tue May 19, 2020 3:43 pm

thomas wrote: Wed Jul 15, 2020 6:46 pm You don't have to depend on the default flying. You can make your own animation to your likings in the animation editor, and use this as your flyin. Just long press on the + button in the animation clips:

Screenshot 2020-07-15 18.46.18.png

With this, you can choose the right time for the projection transition and tweak other aspects.

You can find the documentation here: https://ggnome.com/doc/animation-about/
Well, thanks for that, but,
a) That's not really answering the problem, which is: why can't I just depend on the default Fly In at all? and
b) If only that were true...see my other post as to why Animations are broken unless I'm using FoV Mode: Vertical...which I'm not, because: when is that ever useful? :?

It's a little frustrating to report an issue; ask if it's my lack of understanding or the program that's at fault; get told I "probably" did something; explain again that I didn't; and ask "So, what is the answer?" then: <crickets>.

The poster who asked about juddery hotspots first asked a year ago (Thu Jul 25, 2019) and after a few perfunctory responses the next day was finally told yesterday: "It's fixed. Have you tried upgrading?" No point, they're still juddery in the latest version, which baffles me as to how that isn't already a known problem. It's literally the first thing you see.

I understand you're responsible for (some of? all of?) the coding; so what does it take for a bug to get on your 'fix list'? What do you need from us and in how much detail?
Is there a scoring process based on numbers of reports, inconvenience and severity; or is it lucky dip? What else is on your radar and how long is the list?

Can you share any information about the next point release and will there be a list of all the fixes in it - like BorisFX do when they release new versions of Mocha - as well as listing all the bugs that weren't fixed this time around, but that you're aware of?
User avatar
thomas
Chief Gnome
Posts: 2611
Joined: Fri Sep 01, 2006 3:56 pm
Location: Vienna, Austria
Contact:

Branigan wrote: Thu Jul 16, 2020 1:12 am Well, thanks for that, but,
a) That's not really answering the problem, which is: why can't I just depend on the default Fly In at all? and
You can still use the default fly in, but if you are not happy, or it doesn't produce the results you like, you can use a custom fly in.
b) If only that were true...see my other post as to why Animations are broken unless I'm using FoV Mode: Vertical...which I'm not, because: when is that ever useful? :?
We will look into this bug
It's a little frustrating to report an issue; ask if it's my lack of understanding or the program that's at fault; get told I "probably" did something; explain again that I didn't; and ask "So, what is the answer?" then: <crickets>.
Currently, there is a lot going on and a day has only 24hrs
The poster who asked about juddery hotspots first asked a year ago (Thu Jul 25, 2019) and after a few perfunctory responses the next day was finally told yesterday: "It's fixed. Have you tried upgrading?" No point, they're still juddery in the latest version, which baffles me as to how that isn't already a known problem. It's literally the first thing you see.
I don't know how many times I have explained this, but I can do it again.

The issue is, that our hotspots are HTML DOM elements and they are not rendered in WebGL, so those elements are painted separately, and sometimes the DOM layer is painted a frame earlier or later as the WebGL canvas. As the browser makes this decision, we have no influence on how those two layers are painted.

Another problem with this is that DOM elements can only move on the pixel grid, WebGL elements can move on subpixels. There can always be a subpixel difference in the position.
I understand you're responsible for (some of? all of?) the coding; so what does it take for a bug to get on your 'fix list'? What do you need from us and in how much detail?
Is there a scoring process based on numbers of reports, inconvenience and severity; or is it lucky dip? What else is on your radar and how long is the list?
Bugs, like the jitter can not be solved, without a technology change. If we would render the hotspots in WebGL you would lose all the benefits of using HTML elements, like the whole skin action/logic block/modifier stack
Can you share any information about the next point release and will there be a list of all the fixes in it - like BorisFX do when they release new versions of Mocha - as well as listing all the bugs that weren't fixed this time around, but that you're aware of?
Currently, the bug tracker is not publicly available anymore as we didn't had the time yet to migrate it to a new server after we switched to our new homepage. We will make it available again, when we are ready.
MfG, Thomas
Branigan
Posts: 231
Joined: Tue May 19, 2020 3:43 pm

thomas wrote: Thu Jul 16, 2020 2:51 pm You can still use the default fly in, but if you are not happy, or it doesn't produce the results you like, you can use a custom fly in.
See? 24hrs in a day or not, this is what I'm talking about. :( Normal Fly In is broken. It hiccups in the middle. It's unusable. No one has said they'd look into the BUG. :roll:
thomas wrote: Thu Jul 16, 2020 2:51 pm I don't know how many times I have explained this, but I can do it again.

The issue is, that our hotspots are HTML DOM elements and they are not rendered in WebGL, so those elements are painted separately, and sometimes the DOM layer is painted a frame earlier or later as the WebGL canvas. As the browser makes this decision, we have no influence on how those two layers are painted.

Another problem with this is that DOM elements can only move on the pixel grid, WebGL elements can move on subpixels. There can always be a subpixel difference in the position.
Well, I'm not really interested in blah blah excuses as it's quite obviously whole pixels off and it's not just about timing on different frames; because if you move really slowly you can make it settle in the wrong, whole pixels off, position. All I hear is you're doing it wrong and getting a lousy result and have given up. Well, time to look harder and find a way to fix it. :D

The 3D distorted Hotspots move in perfect sub-pixel accurate syncronisation with the background. They do not lag, jiggle or skip. Are they not also HTML DOM elements? :?:
They do jump around when there is any hint of a Modifier anywhere near them, making them semi-useless, but when they don't have those: they move smoothly and stick to the panorama like glue.

There is the slight problem of them looking much blurrier than the background itself (check the resolution of the French Windows; they're more detailed than the hotspot), and it would be useful if they could (option...) retain their higher resolution image, while still staying in place. Not interested in excuses about how hard/impossible it would be; just interested in a better result.

What are you interested in?
.
3Dhotspot.gif
3Dhotspot.gif (3.49 MiB) Viewed 3159 times
.
So, do whatever you have to do to make un-Distorted Hotspots use the same maths to calculate their 3D Distorted POSITION, then apply it to their 2D IMAGE. While you are in there, consider adding the option (or just updating the docs if it's already hiding in there) to make them actually scale correctly - while still displaying as 2D - as they move across the screen, so they don't look like they're shrinking as they approach the screen edge.

These are the fundamentals that the whole program hangs on, so how you've got away for it so long is a mystery, but just because you have: it's no excuse to continue disappointing your paying customers any longer than neccessary.

All the best, :wink:
Post Reply