It’s not clear to me from the docs when I should use mesh.setVerticesData vs. mesh.updateVerticesData. I have a tessellated plane mesh I’m changing the vertex positions of, and I was using updateVerticesData. Then I made another version and I accidentally used setVerticesData. Everything still looked correct, so that made me wonder which of those functions should I use in various situations? Is one more performant? More or less memory usage?
You must use
setVerticesData() the first time (probably not a surprise). I have only been able to use
updateVerticesData() afterward, and when the size of the data has not changed. I imagine update being better as long as it is possible.
One thing I have not tried is using replacing with something smaller, but I have a bad feeling about that.
updateVerticesData is better for perf when you can use it, see my answer here:
One more question regarding the “updatable” aspect of a mesh’s geometry. I don’t need to update my vertex positions every frame, just every few seconds (a few hundred frames). During those few seconds of nothing happening, is there a performance penalty for having updatable == true? In other words, is it better to call setVerticesData with updatable false, even though it makes a new VertexBuffer, or is it better to call updateVerticesData which doesn’t seem to have an updatable option and presumably leaves updatable == true? I guess what I’m asking is, what does updatable really mean in terms of performance on an every-frame basis, and how does that compare to remaking a VertexBuffer every few seconds?
cc @sebavan, I’m not sure there’s a big perf hit to use updatable vs non-updatable buffers, if any. So, if the buffers must be updated, even infrequently, I think it’s better to create them as updatable from start.
I do think that in most cases updatable won’t harm
Is there such a thing anymore of “pinned memory”, which can be directly accessed by both cpu & gpu?
updateable arg maybe an indicator to use that memory when true. I make sure I only set it to true when mesh has morphing data / shapekeys, which will always be the same # of tris. No sense in wasting it on static geo.
Will probably continue to do this, but not sure it does anything.