Suppose you want to do 360 panorama demo using equirectangular texture. Easy way would be to use sphere mesh, with enough triangles distortions are invisible, and the client is happy. The few of us, who are dealing with “make me another matterport” bullshit, are not so lucky – we have to project images onto complex meshes and, therefore, write the shaders. Continue reading ‘Sampling equirectangular textures’
Posts Tagged '3D'
Tags: 3D, alternativa3d, geometry
Well, I am just reposting it here now in case Alternativa3D wiki currently hosting it will go down, like their forum did.
While all the top google hits for this problem revolve around messing with matrixAutoUpdate property, I thought I’d share this simple trick:
object.matrix.copy (...); // or fromArray (...), etc object.matrix.decompose ( object.position, object.quaternion, object.scale );
This only really works with the matrices that can be represented with three.js’ position/quaternion/scale model, but in practice this is vast majority of the cases. You’re welcome.
Tags: 3D, geometry, three.js
Ok, this post is still about three.js and GLSL shaders, but unlike raytracing loads of cubes or relativity simulations, this is something more down-to-earth. In this post, we shall discuss some possible alternatives to gl_FrontFacing in your WebGL apps… Continue reading ‘On the alternative to gl_FrontFacing’
Have you ever heared about raymarching distance fields? That’s how all those awesome shaders were made. Very simple and beautiful concept, but it comes with the price to pay – many, many iterations. Which means these shaders are slow. And even if your hardware is from 2015 and they are not slow for you – you will still notice. Here is the screenshot of this infinite cubes demo (3x magnification):
Do you notice the gaps between the cubes? Maybe allow me to reduce the number of iterations (64 to 20) to make them more apparent (this time 2x reduction):
What happens here? I shall call this “black hole effect” :) The rays that go near the surface are slowed down to a crawl, and need more iterations to escape:
See, there are so many iterations I could not even be bothered to draw them all in this gif :) The same thing happens in the shader – the ray never reaches its target.
Is there anything else we can do?
I was thiking that maybe distance estimation should take into account ray direction. If you can do that, your shader will get quite a boost. But, for this particular shader, I could easily solve for intersections with cube faces instead. More iterations bring more of them in, and I just keep the closest face the ray hits:
As you see, we have some “overdraw”, and some cubes are never complete, but it works faster than classic method. Which makes me happy enough to write this post, because now I have enough performance to do the next step… to be continued ;)
How do you handle the problem of 2D overlays in three.js-based app? You can go for camera-oriented planes, I guess, or maybe use sprites, but with just a few of them overlays why not just use DOM? The trick is to wrap the canvas in overflow:hidden element with display:relative or absolute, and place your overlays in there. This method has several problems that needs to be addressed.
When do you show and hide the overlays?
Object3D add() and remove() methods dispatch ‘added’ and ‘removed’ events, but this is only part of the story. You have to check if other objects obscure your overlay anchor, or else it will incorrectly show up on top of those objects. In simple cases, you could calculate this analytically, but general solution would have to rely on something like ray casting.
Yes they can, by overriding Object3D’s updateMatrixWorld() method, which is called on every object when you render the scene. Of course, you still have to call original method, too.
The above method implementation will look like this. As always, feel free to discuss this stuff in comments.