if you want to repeat or adapt it in vanilla it’s a THREE.WebGLCubeRenderTarget and a THREE.CubeCamera. the resulting texture is thrown onto a sphere as the environment map (envMap) and the cube-camera is synced with the scene camera (which is not supposed to actually move the scene). most of the code is just glue and for portaling https://github.com/pmndrs/drei/blob/master/src/core/RenderCubeTexture.tsx but fbo.texture.isRenderTargetTexture = false was something i searched for an entire weekend. threejs flips cubemaps and the prop that solved it doesn’t seem to be documented.
that’s just the model. it was baked in blender, if you move things it shows. it’s bruno simons threejs-journey level 1, on the real website you can’t see it — you’re not support to look there.
Neither the website nor the codesandbox loads - I tried FF & Edge.
“1 of 11 errors. Could not load /level-react-draco.glb: NetworkError when attempting to fetch resource.”
Other than that, it’s a very clever technique, the same used in real world to capture photo and video 360 panoramas from a mirror sphere with minimal distortion.
I’ve implemented a variable deg camera up to 180 with a shader with a different far harder technique…
But yours is far more compatible in three.js
You could scale the sphere on the camera axis to achieve a variable degree too.
that’s most likely your anti virus, if you’re on windows. i think i’ve read something about it being buggy - it just blocks random assets for no reason and creates a bunch of problems. codesandbox has probably been flagged by it. if you switch it off or remove the black list it should be fine again.
I’ve implemented a variable deg camera up to 180 with a shader with a different far harder technique…
But yours is far more compatible in three.js
You could scale the sphere on the camera axis to achieve a variable degree too.
could you add some more details about the scaling?
i have two problems to crack before fully making it re-usable:
scaling is so arbitrary, i just make it big enough so it fits my screen but i think it should be reactive to screen size
i have a very hard time with the pointer event compute. the spinning box in the shelves is interactive, but the sphere distorts the image so that the pointers are off. we have a compute that can interpolate events but the math … how would i even find the correct ray?
I don’t think so - I never have such problems with Kaspersky.
But it worked in Opera for some reason.
In my screen (16:9) there is gap in the corners, but it’s not arbitrary.
Just calculate the distance between the center of the user’s client area with one of the corners, that will be the sphere radius (Pythagorean theorem): r = sqrt ( (w / 2)^2 + (h /2)^2 ) where w and h are the client area width and height dimensions.
It’s a bit of a puzzle, but the fact that you’re dealing with a sphere and a rectangle (the client area), makes it easier. It’s just geometry.
i implemented the radius and it works beautifully, thank you so much! now it’s finally window-size stable and the effect is more pronounced. the video i recorded almost looks tame in comparison.
do you have any hints on the second math riddle? tracing pointer events back to the actual meshes?
just another tool, i guess the same can be said for everything, postprocessing etc. there is overhead of course but you don’t need full res for the render targets because each is only a small patch of the screen. by default it’s using 896 but could be lower even.
