Sorry I’m not able to provide the code and failed to repro the problem in PG.
I’m trying to make a terrain like unity, when I update the texture for the height, it cost about 12ms while it cost only less than 1ms with the texture for color.
The two textures have the same size(1k) and start with a blank context, and using the same image to draw on the texture, the only difference is I will restore the texture buffer and update the mesh with updateVerticesDataDirectly which will maybe thought a CPU heavy task(cost less than 5ms for the two things)?
So what other things will affect the update time probably? And hack ways to update part of the texture to reduce the update time is welcomed.
Updating rendering texture is only a matter of uploading its data to the gpu. Whereas, changing the height means recomputing a new mesh based on texture height.
I think you might be able to do the update in a webworker. You can also subdivide the terrain in smaller part and update each part more often.
another solution, depending on your need is to do an NME shader where the mesh vertex position.y is read from a texture. But if you need to do CPU side collision, you’ll do more work.
2 Likes
Actually 12ms is not really unacceptable if I limit the frequency, I was just curious about why two same size textures have so different update time.
And the NME shader is really a good solution for updating the position, I’m using nodeMaterial only for the fragment now and I just forgot to make use of the vertex part! It is a much more elegant solution and some other problems are able to be solved, thank you so much!!!
3 Likes
I believe the reason is I wrongly clear the whole context before I draw. I have rewrited that part and it works fine now.
Otherwise, taking use of the vertex part is really a good solution, I can easily get 60fps now.