Can I read 'Player Width' into a variable? Edit: Yes! :^)

[Branigan]

Is it possible to get Player Width and Player Height into a variable and use it to manipulate other variables?

E.g. I want to overlay a map,. but I want it to scale according to the Player Width/Height so it always fits the screen and is correctly proportioned.

Ideally I'd want to set the Map size to something like 90% of Player Width or Player Height, whichever is the smallest, so it works in both Portrait and Landscape modes without expanding outside the frame. I don't want to use scrolling either.

Currently I've bodged it with a short list of Logic block tests that check Player Width/Height and set various Map Image sizes accordingly, but it's not very elegant and I'm probably missing something obvious.

Are there proxy variables for these values that I can manipulate or check further, or is there just a better way to do what I'm attempting?

[Branigan]

Just so I'm clear, is it NOT possible to do something like set a map size to 'Player Width' x 80%?

The logic testing method of a list of various tests of Player Width and Height with >= and < and setting several different Map Widths is pretty hacky, and I'm assuming people want their Panoramas to work on a variety of devices, so I'm just hoping I've missed something obvious, although I'm not finding it in the docs.

So, if I'm not missing something fundamental: Feature Request: Consider making Player Width and Height (and any other variables that might be useful if you think about it) able to be used in more maths functions and comparisons than True/False Add/Subtract and Mod so things can work on all devices/aspect ratios.

[snowlexx]

Just so I'm clear, is it NOT possible to do something like set a map size to 'Player Width' x 80%?

what's wrong with just setting the map size to 80% width?

[Branigan]

what's wrong with just setting the map size to 80% width?

Because unfortunately, that doesn't work the way I need it to. While I said I want to set an image to Player Width 80% (or 90%), I want to do it after I've checked a few things, including what Player Width is.

Just using scale like that makes the map image scale non-proportionally and elastically with whatever the Player Width or Height is when the browser shape changes, so it deforms. I can't see a way to keep them separate, or related to a single scale value that is derived from the Player Width or Height. While you can lock the aspect ratio while adjusting the values, this does not carry through to any manipulation of their scales, because you can only set explicit values in pixels or percents for each individually in the logic block.

What I want is for it to be 80% of Player Width while its height is less than Player Height (minus room for navigation icons), but as Player Height changes then its height and width will both change. So I want its height to be a proportion of what 80% of Player Width is after it's been checked that it is not less than Player Width. Which is why I want to put whatever that result is into a variable.

If that's confusing, Imagine the map image is a square.
On a mobile in Portrait mode, it can be 80% of Player Width, but it will only be ~40% of Player Height.
On a mobile in Landscape mode, it will be ~40% of Player Width, but can be 80% of Player Height.
On a Desktop in Landscape mode (assuming normal 1920x1080 display proportions) , it will be ~45% of Player Width, but can be 80% of Player Height.
On an older Desktop in Landscape mode (4:3 ratio) , it will be ~60% of Player Width, but can be 80% of Player Height.

If the Desktop has a superwide aspect ratio, like 5120x1440, then you're back to something like a mobile in Landscape mode again, although it'll now be ~22.5% and 80%.

All these different requirements are why it's a problem if you leave the FoV Mode in the default(?) of Vertical (Portrait mode?? Why?) and why when you change it to Diagonal, things start to get a bit squirrely, as code that hasn't been checked as much acts a bit weird. But that's a separate issue.

Because I can't check if Player Width < Player Height or vice versa, I currently I have a hacky mess of checking various Player Widths and Heights with >= and < etc. trying to use actual numbers of pixels to compare against, which will inevitably fail on different resolution displays that are outside the ranges I'm checking against. So on an 8k Desktop display, or a 4k Mobile screen, then while the map will retain its proportions, it can't scale up, so will end up looking too small.

Pixels are not the right thing to be measuring against, unless we assume displays will never get bigger, higher resolution, or change their aspect ratios ever again.
Image the mess if text never scaled up or down according to the resolution of the screen: you'd have large letters on small screens and small ones on large screens.

I need to be able to compare sizes against a number that is not measured in pixels - although it is derived from the display size in pixels - and currently I can't see how to do that.

[Branigan]

Does not one ever want to place a map or a floorplan on their tour and have it shown at the correct proportions no matter what the size, resolution or aspect ratio of the viewing device is?

I've seen several tours where people have had weird maps and overlays that jump and skip about or get cropped when the browser window size changes, but assumed they were made with older versions of Pano2VR and they couldn't be bothered to update them to a later version. Get paid, move on.

I'd simply like to set the scale of an image to a % of whichever is the smaller of Player Width or Player Height. That way it always fits the screen and is never cropped and the proportions are correct in landscape or portrait on desktop, tablet or mobile and will work on HD, 4k or 8K displays.

Is that really not something that's currently possible?

[Josh]

Hey Branigan,

I'm not a developer or programmer so unfortunately I can't really give you specific assistance however having just watched the most recent webinar on extending skins with js I'm fairly confident that this is possible, but you'll need some js magic to make it work. Perhaps Thomas can help, he did mention in the webinar that the best place to reach him was on facebook.

Anyway, from what I can gather you'll need to get the players current dimensions with

Code: Select all

pano.getViewerSize()

and then use the output of that to write a variable in the skin using

Code: Select all

pano.setVariableValue ('varname',value)

where 'varname' is your skin variable name and 'value' is the returned value from the previous command.

This isn't really a working solution, pano.getViewerSize returns a js object containing height and width and I'm not sure how to get just the height or width into the 2nd command. For help with that you'll need to consult a js wizard. I hope this gets you on the right track, good luck.

https://ggnome.com/doc/javascript-api/
https://www.youtube.com/watch?v=N0cLKF7j5uU

[soulbrother]

I want to set the scale of a picture to a % of the smaller value of player width or player height. That way it always fits on the screen and never gets cut off, and the proportions are correct in landscape or portrait on desktop, tablet or mobile phone and work on HD, 4K or 8K displays.
Is that really not something that's currently possible?

This will never work satisfactorily as an "automatic" process, as there are several issues to be resolved:
1. Format and the available space:
For example, if a landscape image is displayed on a portrait screen with correct proportions, there will always be a large "unused" area.
2. Details:
Once a large image is displayed too small, important details may not be visible.
3. Layout:
In addition, the entire design, including all other controls, must be considered for both: landscape and portrait mode.

So what is the solution?
With pano2vr, all possibilities are available, but this requires a relatively large effort on programming in the skin.

Just like when designing a website, the most important task should be the design:
Define in advance how the different elements should be arranged and how these images (maps or other content) should be displayed.
What makes sense, what would be not ideal?

There are more questions about this process:
- If the user can be expected to rotate the mobile device, a note is sufficient: "Please use your device for optimal display in landscape format".
- On which screen sizes do you want to optimize the VR tour?
- With the desired content, is it generally possible to view this VR Tour on mini screens (320x640px) in such a way that it can be operated and read without problems?
- Can all pictures (or maps) be scaled without any problems? Is it possible to recognize the necessary details without any problems?
- You should also consider and investigate which alternative designs are possible to solve a specific layout task.

Overall, it is a complex task... and a lot of work, to optimize every detail in a layout, so that it fits for ALL possible screens.
And for shure it is not possible with % rules only.

[Branigan]

Hey Branigan,

I'm not a developer or programmer so unfortunately I can't really give you specific assistance however having just watched the most recent webinar on extending skins with js I'm fairly confident that this is possible, but you'll need some js magic to make it work. Perhaps Thomas can help, he did mention in the webinar that the best place to reach him was on facebook.

Anyway, from what I can gather you'll need to get the players current dimensions with

Code: Select all

pano.getViewerSize()

and then use the output of that to write a variable in the skin using

Code: Select all

pano.setVariableValue ('varname',value)

where 'varname' is your skin variable name and 'value' is the returned value from the previous command.

This isn't really a working solution, pano.getViewerSize returns a js object containing height and width and I'm not sure how to get just the height or width into the 2nd command. For help with that you'll need to consult a js wizard. I hope this gets you on the right track, good luck.

https://ggnome.com/doc/javascript-api/
https://www.youtube.com/watch?v=N0cLKF7j5uU

Thanks, I'll give that a look.

[Branigan]

Overall, it is a complex task... and a lot of work, to optimize every detail in a layout, so that it fits for ALL possible screens.
And for shure it is not possible with % rules only.

Not really, it should be a walk in the park.

Display Width is known internally and it's what's used in Logic tests to set sizes of various things if you want to e.g. scale a Map . Problem is you have to do clunky nonsense like multiple tests in a list. E.g.:
Display Width => 2000, set Scale = 2.0
Display Width => 1200, set Scale = 1.2
Display Width => 1000, set Scale = 1.0
Display Width => 800, set Scale =0.8
Display Width => 600, set Scale = 0.6 etc.

It's already scaling everything else it draws, including adjusting the FoV correctly, as long as you have FoV Mode:Diagonal set, rather than left in the unhelpful default setting of Vertical, which is for Mobiles in Portrait mode. Those that don't change it wonder why their panos look rubbish on mobiles: because they adjusted the settings to work on a desktop while in the wrong mode. Those that do find lots of other bugs appearing, so you're kinda stuck either way. But, with the ability to get the actual number of Display Width (and Height) into a variable you could set a map to be scaled to 80% of whatever it was for any FoV, display size, or aspect ratio.

You'd actually also want to check Display Height because comparing Portrait and Landscape modes, the larger of these swaps around. So what you actually do is use the smaller of these as the value to scale your map against, to make sure it's always fully within the screen boundaries.

Pano2Vr knows what these values are in order to use them internally for its logic tests; we just need them exposed in a way that we can do more maths with them than the current limited options.

This is such a fundamental requirement I was originally expecting someone to post: "It's on this page of the docs if you looked a bit harder." but, nope...

[soulbrother]

Sorry to ask, but for me, the field of view mode (for displaying the panorama) should not have any influence to a map (or any other element), that is displayed via the skin and therefore drawed one level "above" the panorama, so it should be independent from any panorama angle?

Do you have a link to your (test-)tour, so that I can see, what you are talking about?

[Branigan]

Sorry to ask, but for me, the field of view mode (for displaying the panorama) should not have any influence to a map (or any other element), that is displayed via the skin and therefore drawed one level "above" the panorama, so it should be independent from any panorama angle?

Do you have a link to your (test-)tour, so that I can see, what you are talking about?

Have you got FoV Mode:Vertical? If so, then that's the setting for a Portait mode, i.e. upright mobile, panorama.

FoV Mode: Horizontal would be for purely Desktop panoramas, i.e. Landscape, and FoV Mode: Diagonal adjusts for all shapes and sizes. FoV Mode:Max seems very similar to Diagonal and anyway it was Hopki that told me it should be Diagonal, so that's good enough for me.

As I assume most are trying to make panoramas for all shapes and sizes and aspect ratios of browsers, it's a puzzle why the default is not Diagonal.

Whichever FoV mode you currently have, drag an image into the skin and put it in the middle, set to centre scaling and centre position to about 80% of the screen. Happy with that?

Export the pano and check in your browser. Image looking OK? Cool.

Right, now deselect your browser from Full screen mode and adjust the width until it is looks like a mobile screen. Did your FoV change, or are you now looking at a small window into your original panorama? If it's only a small window on an unchanging panorama, you had FoV: Vertical and that's how it looks on a mobile: i.e. wrong. Your image has been cropped by the screen edges. I hope it wasn't anything important.

If the FoV changed, then you had FoV Mode:Diagonal, a) well done and b) what happened to the image you put on the screen? Does it still fit? Change the shape and size of the browser, to square, tall + thin, short + fat, square. Does it still fit in every case?

You can see it doesn't fit, so how might we make sure it always scales and fits correctly to 80% of the Display Width or Height (whichever is the smaller) - i.e. doesn't overlap navigation buttons or thumbnails - and does not change its aspect ratio? i.e always square, or 4:3 or whatever it happened to be when you first made it?

That's what I want to do and currently (not checked out the javascript option, busy with other things) cannot.

[soulbrother]

It will be interesting, if any other guy will understand this, cause I do not.

Either you talk about the panorama fov mode,
OR
the theme is: a map (or other elements coming from the skin)?

In the map adjustments (skin editor) I cannot find any fov settings, so I don´t understand what you are talking about.

[Branigan]

It will be interesting, if any other guy will understand this, cause I do not.

Either you talk about the panorama fov mode,
OR
the theme is: a map (or other elements coming from the skin)?

In the map adjustments (skin editor) I cannot find any fov settings, so I don´t understand what you are talking about.

Did you try changing the shape of your browser and seeing how the FoV changed (or did not)?

If you don't know what I'm talking about, you may have the FoV Mode set to the default setting of Vertical, which is for upright, portrait, 9:16 mobile screens.
For both those and landscape 16:9 Desktops/Laptops/Tablets etc. it should be set to Diagonal ( Hopki confirmed this was the correct setting in a support email) , but which then reveals several bugs...because apparently no one changes to it and discovers them.
.

wrong.jpg (54.68 KiB) Viewed 4625 times

.
It would be like if the default setting for mouse movement was the annoying "move mouse one way, panorama shoots off in the opposite direction, just to confuse and frustrate users", instead of the drag method; which is obviously more sensible and used on every touchscreen device ever. Oh wait, it is defaulted to that and you have to change it to Drag.

It's like the designers of Pano2VR are intentionally trolling their users with all these contrary defaults for some bizarre reason.

[Branigan]

....from what I can gather you'll need to get the players current dimensions with

Code: Select all

pano.getViewerSize()

This isn't really a working solution, pano.getViewerSize returns a js object containing height and width and I'm not sure how to get just the height or width into the 2nd command.

Thanks for the pointing me in the right direction.

After a few false starts with not understanding the syntax (long time since I coded anything and I can barely spell javascritp) it was as easy as adding this to a hidden Text box after declaring a couple of variable to hold the values. If not hidden it displays "true" to show it read the values successfully.

Code: Select all

javascript:pano.setVariableValue('var_disp_width', pano.getViewerSize().width*.80);
javascript:pano.setVariableValue('var_disp_height', pano.getViewerSize().height*.80);

I'm sure I must be reinventing the wheel here, but now I'll check which is the smaller value, then calculate how to set the scale to a value that will be proportional to that.

It only changes when I both resize the browser and refresh the display, so I thought the value might be cached; but a logic test detects it continuously as the browser width changes, so maybe javascript in a text box runs differently?

Doesn't matter as it only usually needs to read it once on whatever it starts on to get the size and aspect ratio.

[Josh]

No worries mate, but the cred really goes to the Gnomes on this one - I got all that info from the webinars they've been doing. Thanks for posting up your code so far, it'd be great if you'd post up what you work out as your final solution also. It really helps out the community when complete answers are available in the forums.

EDIT: I just remembered, you can probably also sort your value update issue with another bit of js. See https://ggnome.com/doc/javascript-api/ Scroll down the page until you find Events, looks like you can set up a listener for an event "sizechanged" and then use that to trigger a recalculation on the width height variables you've defined.

SUPER EDIT: I got caught on hold so I did a little bit more on this one. This code listens for an event "sizechanged" defined in the Javascript API, and when the size changes it dumps the player dimensions (in this case, height) into a variable defined in the skin (in this case, "d6"). You should be able to rescale your map in real time using this, as now the height and width values of the player are exposed in real time via a variable in the skin.

Code: Select all

pano.on("sizechanged", function() {
pano.setVariableValue('d6', pano.getViewerSize().height);
});

J