I am working on a minecraft project using Three.js, and I've encountered a performance issue when rendering shadows.
Here is the demo: http://johnhckuo.github.io/Minecraft/
As you can see the FPS drops below 30 and it continues dropping if you stay longer on this page.
I think it's kind of weird because this scale of shadow rendering should be easy for GPU right?
As Don said, You are creating new meshes and materials in the render loop.
Specifically how the sky is generated.
The real culprit can be seen via Chrome devtools, which seems to be that when creating the new material with a map (canvas generated every frame), this new map/texture is then uploaded to the GPU (screenshot attached).
Thing to do to fix your problems may be to:
Don't create new meshes every frame.
Don't create new materials every frame.
Don't create a new canvas for the material every frame, or maybe do this color manipulation within a shader.
Devtools screenshot:
EDIT:
Take a look at this sky shader
Related
I am trying to create a clock with the help of Text Geometry. In order to update the time I need to update the text in Text Geometry which can be done by removing and recreating a new Text Geometry.
Every time I add a new Text Geometry it freezes my browser:
// Remove old mesh
earthClockMesh.geometry.dispose();
earthClockMesh.material.dispose();
group.remove(earthClockMesh);
//add new mesh
earthClockMesh = this.getTextMesh(
new Date(diluatedTime).toLocaleString(),
textMaterial
);
group.add(earthClockMesh);
Anybody know better way way we can update the text in Text Geometry without freezing browser.
Live Example
https://codesandbox.io/s/peaceful-boyd-x859m
You can see the particles gets freeze for a moment when TextGeometry changed
Using THREE.TextBufferGeometry will improve the performance since it produces much less object allocation than TextGeometry. Besides, each instance of THREE.Geometry is internally converted to THREE.BufferGeometry before the first rendering. If you additionally lower the amount of curveSegments, the should be almost no noticeable lag anymore.
three.js R107
The reason for this is that you're deleting the generated geometry, then re-building thousands and thousands of triangles each second. This is very computationally expensive, and you see the animation freeze while the CPU tries to catch up. This is what you're doing:
Text geometry gets disposed
CPU re-builds all characters with an updated second (first bottleneck)
New geometry data gets passed to GPU (second bottleneck)
Scene gets rendered smoothly while no geom is being rebuilt
With real-time graphics (videogames, visualizers, etc), the geometry construction typically happens at the beginning of the app to avoid these mid-game stutters. Try to generate the geometry only once, then swap it out as necessary:
Create a "dictionary" of all 16 necessary characters as individual Mesh objects: 0123456789:/APM,
With this base dictionary, you can .clone() the needed characters, then place them with .position. You can use .clone(false).
At the end of each second, .clone() the geometry from the dictionary into the few characters you need to update.
The beauty of cloning Meshes like this is that the geometry is only generated once. You don't need to spend tons of processing power re-building it.
I'm using BabylonJS V3 with Blender 2.79 to create product visualizations. Many times, it is necessary to define more complex shaders in the JS code. I'm using lines like
scene.meshes[1].material.emissiveColor = new BABYLON.Color3(1, 0, 0);
to define the shaders after export. Usually every mesh can get it's own shader this way. Unfortunately in one case, the shader of multiple meshes is overwritten. Did someone have a similar problem?
All meshes are named individually, they all have a basic (individual) shader from blender. They don't share any datablocks, no instancing or duplication was done. I'm thankful for every hint.
Edit
It seems, the error occurs with the new version (3.0), updating to 3.1 fixes the problem, but introduces errors with the arc-rotate camera. As soon as you click on the canvas, to rotate the view, you can't release the mouse anymore. Are the latest stable releases buggy?
Edit 2
After some in depth trouble shooting we came to the conclusion, that the 3.0 and 3.1 versions and/or their exporter plugins are faulty. Even in the simplest testscenes, this error occurs. Alongside other problems, like broken cameras and displaced geometry.
Be aware that by default materials are shared for performance reason. So this is probably not a bug but a feature.
If you want to change the material for a single mesh you will first need to clone it
I have a webVR application where i have to show the FPS. So, i have been using Sprite with SpriteMaterial to show the FPS.
For the every FPS change, i do the following -
1) Remove the current Sprite.
2) Create a texture with the new FPS (using canvas).
3) Create a new Sprite and set the created texture in the SpriteMaterial.
4) Add the Sprite in the scene.
Output is something like this -
My problem is, when i remove the previous texture, it does not free/invalidate the GPU memory it has taken for the texture. So, every time i create a new texture, GPU memory usage is ascending. Please check the following images -
Initially -
After some time -
I have tried the following code, but it does not clear the GPU memory for the texture -
previous_sprite_mesh.material.map.dispose();
scene.remove(previous_sprite_mesh);
Can anyone please tell me, how should i clear the GPU memory for the texture used before? Also, any other approach to achieve what i am trying to do will be appreciated as well.
Thanks in advance.
Three.js version - 77
I'm working on porting an existing three.js project to WebVR + Oculus Rift. Basically, this app takes an STL file as input, creates a THREE.Mesh based on it and renders it on an empty scene. I managed to make it work in Firefox Nightly with VREffect plugin to three.js and VRControls. A problem I have is models rendered in VR aren't really 3D. Namely, when I move the HMD back and forth an active 3D model doesn't get closer/farther, and I can't see different sides of the model. It looks like the model is rather a flat background image stuck to its position. If I add THREE.AxisHelper to the scene, it is transformed correctly when HMD is moved.
Originally, THREE.OrbitControls were used in the app and models were rotated and moved properly.
There's quite some amount of source code so I'll post some snippets on demand.
It turned out that technically there was no problem. The issue was essentially with different scales of my models and Oculus movements. When VRControls is used with default settings, it reports a position of HMD as it reads it from Oculus, in meters. So, the range of movements of my head could barely exceed 1 m, whereas average sizes of my models are about a few dozens of their own units. When I used them altogether at the same scene, it was like a viewer is an ant looking at a giant model. Naturally, the ant have to walk a while to see another side of the model. That's why it seemed like not a 3D body.
Fortunately, there's a scale property of VRControls that should be used for adjusting scale of HMD movements. When I set it to about 30, everything works pretty well.
Thanks to #brianpeiris's comment, I decided to check coordinates of the model and camera once again to make sure they're not knit with each other. And, it led me to the solution.
Hey im trying to implement shadow mapping in webgl using this example:
tutorial
What im trying to do is
initialize the depth texture and framebuffer.
draw a scene to that framebuffer with a simple shader, then draw a new scene with a box that has the depthtexture as texture so i can see the depth map using an other shader.
I think i look ok with the colortexture but cant get i to work with the depthtexture its all white.
i put the code on dropbox:
source code
most is in the files
index html
webgl_all js
objects js
have some light shaders im not using at the moment.
Really hope somebody can help me.
greetings from denmark
This could have several causes:
For common setups of the near and far planes, normalized depth values will be high enough to appear all white for most of the scene, even though they are not actually identical (remember that a depth texture has an accuracy of at least 16bits, while your screen output has only 8 bits per color channel. So a depth texture may appear all white, even when its values are not all identical.)
On some setups (e.g. desktop OpenGl), a texture may appear all white, when it is incomplete, that is when texture filtering is set to use mipmaps, but not all mipmap levels have been created. This may be the same with WebGl.
You may have hit a browser WebGl implementation bug.