I’ve got a large plane geometry that I’m coloring as a checkerboard. I’ve got an array of 256 color objects that I randomly assign to the geometry’s faces.
I want to change some of the squares randomly every frame but as soon as I started setting elementsNeedUpdate on the geometry my frame rate tanked. I don’t know what the right path toward performance is. Is vertex coloring (and therefore colorsNeedUpdate instead of elementsNeedUpdate) faster? Would using a buffer geometry here help? The docs say that buffer geometries are best for geometries that aren’t changing much, but I would be changing the colors array every frame, I think.
I’d love some guidance here, I’m pretty new to GL world.
If you create a object of type Geometry, the renderer internally converts it to BufferGeometry. This is normally done only once. But if you change the geometry and set elementsNeedUpdate to true, this conversion is triggered again (assuming the geometry belongs to a Mesh). That’s the reason why it’s an expensive operation. It most cases, you don’t need to set this flag. If you only update colors, use colorsNeedUpdate. This will only update the vertex color data.
Compared to Geometry, BufferGeometry is more a low-level data structure since you directly work on buffer data. Geometry will maybe be deprecated at some point, so i recommend you start working with BufferGeometry right away.
1 Like
As @Mugen87 said it would probably be better to just work with a BufferGeometry directly. To update the colors dynamically, you could probably add all the colors to a texture, pass that along to your shader and then pick a color there.
If you have to update a buffer attribute every frame, you can set the dynamic property to true. In this way, you can tell WebGL that the corresponding buffer data are changed often. This is actually good for performance optimization.
I found that going through my geometry and setting faces[i].color = aColorwas not rendered different if I only set colorsNeedUpdate. I had to set elementsNeedUpdate to get it to render.
I’ll start using BufferGeometry, that’s good to know that it’s the way forward.
@hccampos I’m not sure I understand the suggestion about the texture. Are you suggesting that I change the colors in the texture every frame instead of setting face color?
Do you mean to use that texture with colours like a palette, which you pick a colour randomly from?
Ah, now i see. You’re right, in this case you need elementsNeedUpdate. colorsNeedUpdate only applies to vertex colors so geometry.colors.
@prisoner849 I don’t think so. I want the checkerboard to be static, only changing a subset of the squares every frame. So there needs to be something that records the current color of the square. Right now my solution is to set the color on each face. It sounds like I should probably be setting the color on each vertex since that will be more efficient. But I’m curious if a texture would be the right choice here. I could store the color of each square in one pixel in the texture and then use a shader to paint each square in the mesh that color. I have no sense if that is more or less efficient than setting vertex colors
My personal feeling is that a texture would be better in this case, but it is hard to predict without actually trying it out, as this SO post suggests: https://stackoverflow.com/questions/40626077/speed-difference-between-updating-texture-or-updating-buffers
1 Like