-
-
Notifications
You must be signed in to change notification settings - Fork 35.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BatchedMesh: bufferSubData
causes lag
#27980
Comments
I added calls to
Before: After: |
I'm a little off topic perhaps, but note that you could switch between LODs generated by meshoptimizer without changing the vertex buffer at all. Update the index, set draw range, nothing else needs to change: |
That's very interesting @donmccurdy thanks for sharing |
bufferSubData
causes lagbufferSubData
causes lag
Yeah there's currently no way to update only the geometry index (or any specific attribute) when setting data in the BatchedMesh geometry - but perhaps something like an "options" object can be added to // both lods share all attributes except for index buffer
lod0 = ...;
lod1 = ...;
// initialize the geometry
const id = batchedMesh.addGeometry( lod0 );
// swap LoD by only updating the index buffer
batchdMesh.setGeometryAt( id, lod1, { attributes: [ 'index' ] } ); |
Description
Hi, I'm currently stress testing with 20 instances and ~300.000 vertices each.
We have LODs generated and I reserve the vertex space of LOD 0 for each instance so the float32 buffer ends up being ~ 9.000.000
When LODs switch and setGeometry is called i noticed quite a few big lags which seem to be coming from the call to bufferSubData with the whole buffer.
My question is if this is currently expected or if I might be doing something wrong here.
Solution
I would hope this could be optimized by providing the ranges array and the batched mesh could keep track of which ranges have changed. Could this be a possible improvement?
Alternatives
Clamp the max size of a BatchedMesh (on my side)
Additional context
https://mastodon.gamedev.place/@marwi/112145459503913620
The text was updated successfully, but these errors were encountered: