Mesh Pooling with WritableMeshData

Hi, I can’t seem to figure this one out.

When I run ApplyAndDisposeWritableMeshData on an empty mesh object, it will allocate vertex and triangle arrays.
However, if I provide a mesh that already has vertex and triangle arrays of sufficient length, will it free the arrays and re-allocate them, or simply leave it alone and fill the arrays?

I’m trying to figure out what the correct way is to pool my meshes in this scenario (procedural world with lots of meshes of different sizes constantly getting created/destroyed).

If anyone could take a peek at the source code and let me know that would be tremendous! Or let me know if there’s another way of finding out :).

Thanks a ton!

Any reason you can’t just look?? If we have it you have it.

If you can’t look then start with the profiler to find out if it even matters.

All the C# source code is available for reference: UnityCsReference/Runtime/Export/Graphics/Mesh.cs at master · Unity-Technologies/UnityCsReference · GitHub

Most IDE’s can just decompile on the fly, too.

1 Like

Thanks @spiney199 , I didn’t realize that was available. I’ll post the answer to my question in a moment.

1 Like

Doh, it looks like I’ve hit an impasse.

ApplyToMeshImpl(mesh, m_Ptrs[0], flags) called in ApplyToMeshAndDispose

Looks like this function is in the C++ part of the engine. There wouldn’t happen to be a repo for that would there?

Tyvm!

1 Like

There’s no publicly accessible reference for the C++ code unfortunately.

1 Like

Hmmm… In that case I suppose I have a lot of benchmarking to do. Or perhaps a benevolent being will descend down to the forums and bless me with hidden knowledge XD. It would be amazing if unity released like a blog or something with in-depth docs on the mesh class.

Every extra bit of “in depth docs” they add constrains and inhibits them from changing it in the future.

This is why they release an API specifying what can be done with a particular object.

HOW it is done behind the scene is intentionally omitted so that they can implement what they deem to be “the best” way to do it, as well as change it without invalidating past documentation. As long as the API remains the same, they can do whatever they think is “the best” behind the scenes. “The best” in this case is generally going to be a generally-optimal solution that assumes the most prevalent use cases they anticipate.

Again I ask, do you even have a problem? Or are you just benchmarking for the sport of it?

Start always with the profiler: Window → Analysis → Profiler

Every piece of unnecessary code you write is stuff you have to carry around your project forever into the future.