A quick question about the performance of a buffer attribute with dynamically changing values.
I have an
InterleavedBuffer that represents a
Float32Array with an item size of
I’m using a
SharedArrayBuffer to let a worker-thread simulate my particles. Everything works just fine. However, for some reason the buffer isn’t used as a pointer when bound to the WebGL context (does that make sense?).
I have to set
buffer.needsUpdate = true to actually see the changes, which makes me think that Three makes a copy of the entire buffer before uploading it to the GPU. The reason I’m making this assumption is because my framerate dips from 320 FPS to 24~40 FPS
Is there a way around this?
I’m already using
DynamicDrawUsage on my buffer.
tl;dr: How can I bind a pointer of my array buffer, rather than copying its contents to the GPU using Three?
edit: Since the entire particle “pool” is allocated statically anyways, chaning the buffer Usage to
StaticDrawUsage has increased the performance somewhat, and everything still seems to work. It still isn’t optimal though. I wonder if what I’m trying to do actually works since system RAM and GPU memory are two separate things
To ilustrate: simulating ~1000 particles is perfectly fine:
However, simulating ~10.000 in a single emitter causes frame drops that I my profiler is somehow missing. (notice the FPS at top left compared to all the timings on the right).
The only thing I can think of is that
InterleavedBuffer.needsUpdate = true causes the renderer to perform a lot of work. I’m not familiar enough with the internals of the renderer itself, but if anyone can confirm my suspicions, that would be greatly appreciated so I know where I could possibly start optimizing.
edit 2: Just as I uploaded the second screenshot, I noticed the env-map update taking an enormous amount of time. I’ll investigate further…
edit 3: The env-map update time in the screenshots isn’t happening real-time, but only when the environment (skybox and such) changes.
edit 4: When the first call to
WebGLRenderer.render() in the pipeline is being made and the
.needsUpdate is set to
true, it starts slowing down drastically.