Hi there,
I’m looking into the PhotoDome.
If I use the url of my panoramic image in a PG I get the result below
Any thoughts on how to resolve this?
Also about the PhotoDome, is there an option for optimized loading?
Like in round.me or services alike the view which is in focus is loaded in hi res, and the part of the panoramic view in the back had a preview texture, and is only loading when it gets in focus.
My next question about the camera control, is it possible to reverse the mouse movement so that it doesn’t move in the opposite direction.
Thanks!
Pieter
Hi Pieter_van_Stee,
That red checkered error texture indicates a loading error, typically meaning there was a problem with the URL. The dev console available through F12 may give you more specific information about what error was encountered, but mostly likely it just couldn’t find your texture.
I don’t know of an “optimized loading” mechanism; I think we’d need to have some special formats/configurations for that, and I don’t think that’s supported right now.
Regarding camera control, we may have what you’re looking for in our old Spherical Panning snippet. Does that achieve what you’re going for?
Thanks for replying @syntheticmagus
The error I get is the following:
Access to image at 'https://www.claar.be/*****/2.jpg' from origin 'https://playground.babylonjs.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
But as you can see the link to the file is an online resource on our webserver. I can’t share it here but if I open the link itself it works for sure.
About the panning method, that definitely should work. I expected more like an optional flag to be able to enable this in a shorter way, but technically this will work.
Thanks!
Pieter
Hi Pieter_van_Stee,
I see. So, what’s happening is that your webserver that’s hosting the file is rejecting the Babylon Playground’s request to access the resource due to CORS policy. Basically, when the code you’ve written tries to fetch the resource, your webserver tries to confirm that the code sending the request was hosted by the same origin (i.e., your own webserver); and since it’s not, the webserver refuses to fulfill the request as a security policy because it doesn’t know that this request is trustworthy. To resolve this, you’d either need to set your webserver to allow this kind of request, run your Playground on the same webserver as your resource, or move your resource to a server that has CORS enabled.
If changing security policy on your webserver isn’t an option and you want to be able to test this locally (i.e., on your own computer with complete control), I’d recommend following the first two steps of this golden path to move your code and assets into local repos. The asset host described there is already set up for CORS, and moving the code will enable you to run your code in an HTTP site so that you can access the HTTP server into which you’ll drop your file. It takes a few steps, but it shouldn’t take much time, and it’s one of the simplest ways to set up a fully-controlled test environment without turning down security measures on your real webserver.
Hope this helps, and best of luck!
2 Likes
Hi @syntheticmagus
Thanks for clarifying all that. That makes sense.
I’m already working with local hosted instances of my bjs tests.
In this case I just quickly modified a PG sample.
I’ll try to test this case on a local instance. I’ve already been reading the post about the golden path which sounds very interesting and promising.
With the local setup I’ve had a few issues before when transferring my code from the PG to a local server. I’ll create another post about this cause it’s an entirety different issue.
Thanks again
Pieter
