I have a strange problem which has been bugging me for quite a while now, the issue is best explained by a short video:
As you can see the objects in the scene have a jitter when you move the camera around but also a similar thing happens every now and then when the camera is not moving. It's been driving me crazy for a while now. This video has been taken on a Tinkerboard with TinkerOS, but the same issue is also there on a Tinkerboard with FlintOS.
On a regular laptop there is no issue and everything is moving smoothly. I'm not sure if this is a bug or if it is expected behaviour seeing the differences in hardware, so I was hoping somebody could shed some light on this.
Here is a WebGL report from the Tinkerboard:
Here a WebGL report from my laptop:
Obviously there are differences but I have no idea if any of these difference would explain this behaviour.
Can anyone clarify?
Thanks!
The most likely issue is precision; most mobile GPUs map mediump variables in shaders to FP16 data types, most desktop GPUs map them FP32 data types.
What are your shaders here? Try using "highp" everywhere you compute positions.
Related
I've been following some tutorials to make this simple sandbox with a test .glb file.
https://codesandbox.io/s/zen-black-et9cs?file=/src/App.js
Everything seems to work except the shadows. I can't find any missing castShadow/recieveShadow/shadowMap declarations anywhere... just not sure what I'm missing.
Thanks if you can point to my mistake!
Increasing the shadow map size to such a high value is no good approach since it's bad for performance.
Instead, decrease the frustum of the shadow camera. Use the following values:
shadow-camera-near={0.1}
shadow-camera-far={20}
shadow-camera-left={-10}
shadow-camera-right={10}
shadow-camera-top={10}
shadow-camera-bottom={-10}
Keep in mind that you can visually debug and thus better optimize the shadow camera by using THREE.CameraHelper.
I figured it out - it was the shadow-mapSize-width and height. 1024 wasn't enough, I had to bump that number much bigger (works at 10240). Not sure why this is the case, perhaps my imported model is of a different scale or something. But it works now!
The SMAA post-processing example is by far the best antialiasing method in my tests, but it's extremely complex and I'm worried that most-likely it's not WEBGL-1.0, so it won't run on older PCs and devices at all.
Anyone knows what version is it?
And what is the actual load on GPU, is there a tool to inspect the milliseconds per frame? Relying just on dropped framerate is next to useless.
You can use the SMAAPass with WebGL 1. WebGL 2 is not even supported by three.js. Looking at the respective shader code, I would say it should also compile on older hardware.
I don't have any concrete performance measurements but I can guarantee that this pass will add noticeable overhead to your application, especially on mobile devices.
three.js R92
I am currently trying to dive into the topic of WebGL shaders with THREE.js. I would appreciate if someone could give me some starting points for the following scenario:
I would like to create a fluid-like material, which either interacts with the users mouse or «flows» on it's on.
a little like this
http://cake23.de/turing-fluid.html
I would like to pass a background image to it, which serves as a starting point in terms of which colors are shown in the «liquid sauce» and where they are at the beginning. so to say: I define the initial image which is then transformed by a self initiated liquid flowing and also by the users interaction.
How I would proceed, with my limited knowledge:
I create a plane with the wanted image as a texture.
On top (between the image and the camera) I create a new mesh (plane too?) and this mesh has some custom vertex and fragment shaders applied.
Those shaders should somehow take the color from behind (from the image) and then move those vertices around following some physical rules...
I realize that the given example above has unminified code, but still it is so much, that I can't really break it down to simpler terms, which I fully understand. So I would really appreciate if someone could give me some simpler concepts which serve as a starting point for me.
more pages addressing things like this:
http://www.ibiblio.org/e-notes/webgl/gpu/fluid.htm
https://29a.ch/sandbox/2012/fluidwebgl/
https://haxiomic.github.io/GPU-Fluid-Experiments/html5/
Well, anyway thanks for every link or reference, for every basic concept or anything you'd like to share.
Cheers
Edit:
Getting a similar result (visually) like this image would be great:
I'm trying to accomplish a similar thing. I am being surfing the web a lot. Looking for any hint I can use. so far, my conclusions are:
Try to support yourself using three.js
The magic are really in the shaders, mostly in the fragments shaders it could be a good thing start understanding how to write them and how they work. This link is a good start. shader tutorial
understand the dynamic (natural/real)behavior of fluid could be valuable. (equations)
maybe, this can help you a bit too. Raindrop simulation
If you have found something more around that, let me know.
I found this shaders already created. Maybe, any of them can help you without forcing you to learn a plenty of stuff. splash shaders
good luck
I'm trying to copy the shadowCascade functionality from http://threejs.org/examples/webgl_morphtargets_md2_control.html to my project. I did this 1:1 however I only get a a little bit of shadowing at a certain angles and rotations, and often cut off. Further, enabling shadowCascade from start throws shader errors. I have to wait for some time until I can set shadowCascade = true.
I tried to find documentation, links or hints explaining how shadowCascade works and what all those parameters do, without success so far.
All in all I'm rather confused, I don't really understand what is happening and why. Thanks in advance for some clarification and help!
Here's a screenshot
Edit: Here's a video of the effect
The shadowCascade code has not been a significant focus of development in more than a year. There may be problems. If you want to pursue this, and track down possible bugs, that would be great. Some issues may be due to your device and/or browser, however.
For now, I would suggest you use a directional light with the character as the target and a tight shadow box.
three.js r.66
The following code writes no data to the back buffer on Intel integrated video cards,for example, on a MacBook. On ATI cards, such as in the iMac, it draws to the back buffer. The width and height are correct (and 800x600 buffer) and m_PixelBuffer is correctly filled with 0xAA00AA00.
My best guess so far is that there is something amiss with needing glWindowPos set. I do not currently set it (or the raster position), and when I get GL_CURRENT_RASTER_POSITION I noticed that the default on the ATI card is 0,0,0,0 and the Intel it's 0,0,0,1. When I set the raster pos on the ATI card to 0,0,0,1 I get the same result as the Intel card, nothing drawn to the back buffer. Is there some transform state I'm missing? This is a 2D application so the view transform is a very simple glOrtho.
glDrawPixels(GetBufferWidth(), GetBufferHeight(), GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, m_PixelBuffer);
Any more info I can provide, please ask. I'm pretty much an OpenGL and Mac newb so I don't know if I'm providing enough information.
I've always had problems with OpenGL implementations from Intel, though I'm not sure that's your problem this time. I think you're running into some byte-order issues. Give this a read and feel free to experiment with different constants for packing and color order.
http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_tips/chapter_5_section_25.html
I know it's OSX guide, you can probably find similar OpenGL articles on other sites for other platforms. This should be applicable.
I've always had problems with OpenGL
implementations from Intel
This is kind of what I'm worried about, but I have a hard time believing they'd screw up something as basic as glDrawPixels, and also, since I can "duplicate" the problem by changing the raster position vector, it makes me think it's my fault and I'm missing something basic.
I think you're running into some
byte-order issues
That was my first inclination, and I've tried packing differently, with no result. I also tried packing the buffer with values that would present a usable alpha if swizzled, with no result. This is why I'm barking up the raster pos tree, but I'm still honestly not 100% sure. Note that I'm targeting only Intel Macs if that makes a difference.
Thanks for the link, it was a good read, and good to tuck away for future reference. I'd upmod but I can't until I get 3 more rep points :)
It's highly unlikely that a basic function like glDrawPixels might not be working. Have you tried some really simple settings like GL_RGB or GL_RGBA for format and GL_UNSIGNED_BYTE or GL_FLOAT for type? If not, can you share with us the smallest possible program which replicates your problem?
The default raster position should be (0,0,0,1), but you can reset it to make sure.
Just before calling glDrawPixels(), try
GLint valid;
glGet(GL_CURRENT_RASTER_POSITION_VALID, &valid);
This should tell you if the current raster position is valid. If it is, then this is not your problem.