Feedback Wanted: Mesh scripting API improvements

We have the SetVertexBufferData but what about the getter? It makes quite hard to modify an existing mesh without this.

 

@Minchuilla You can do that through the ReadOnlyMeshData API introduced in Unity 2020: https://docs.unity3d.com/2020.1/Documentation/ScriptReference/Mesh.AcquireReadOnlyMeshData.html

 

What happens if I import a mesh that has a 64 bit positioned set of vertices into the editor? -- Will those be precisely positioned in the future?

Kinda wondering if this is going to be possible... Maybe a wrapper for when importing this sort of mesh?

 

I have not seen any examples of how to use MeshDataArrays in jobs.

I am sure there is a way to schedule a job that writes to the MeshDataArray from one system and then from another system in the main thread actually call ApplyAndDisposeWritableMeshData with that MeshDataArray.

However, I can not figure it out. Any help would be great.

 

Samples for the MeshData API can be found here: https://github.com/Unity-Technologies/MeshApiExamples-2020.1

 

Thanks!

 

Yes this is what I need, thanks

 

Would be nice if we could have multipe UVs per vertex on the same UV maps to avoid having to stack verts

 

General API feedback:

If I go to a specific part of the API documentation (say, Namespace Unity.Rendering), and it's for an older version, it's because Google took me there. When I see a button at the top that claims to take me to the current version, it lands me on a page that is not the API documentation and not Namespace Unity.Rendering. This basically takes me back to Google because for some unknown reason, it's nigh-unto impossible to find Unity documentation using Unity's website.

Can we please, please get version linking that takes us to the correct page for the current version? If I land on an old version's scripting API page, then I may want that specifically that part of the API documentation for the current version. I almost certainly won't want the manual covering related concepts.

 

Hello all, I just made a non-GC allocating, Mesh.CopyTo() function using the new MeshData API in 2020.1. Essentially it creates a copy of an existing mesh without creating intermediate garbage and without requiring Lists to be already set-up prior to copying. Have a look:
https://github.com/GeorgeAdamon/FastMeshCopy .

Code (CSharp):

1.  
2. #define USE_UNSAFE // Comment this line to use the "safe" version of copying.
3.  
4. using Unity.Collections;
5. using Unity.Collections.LowLevel.Unsafe;
6. using UnityEngine;
7. using UnityEngine.Rendering;
8.  
9.  
10. /// <summary>
11. /// Author: George Adamopoulos
12. /// Version: 1.0.0
13. /// Date: 2020-05-03
14. /// License: GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007
15. /// </summary>
16. public static class FastMeshCopyUtility
17. {
18.  
19.     private const int SHORT_SIZE = 2;
20.     private const int INT_SIZE = 4;
21.     private const int FLOAT_SIZE = 4;
22.  
23. #if UNITY_2020_1_OR_NEWER
24.     /// <summary>
25.     /// Attempts to copy the data of the current <see cref="Mesh"/> to another one, as fast as possible,
26.     /// with minimal allocations (a few tens of bytes in scenarios with very large meshes).
27.     /// </summary>
28.     public static void CopyTo(this Mesh inMesh, ref Mesh outMesh)
29.     {
30.         if (inMesh == null) return;
31.  
32.         if (outMesh == null)
33.         {
34.             outMesh = new Mesh {name = "Mesh Copy"};
35.         }
36.         else
37.         {
38.             outMesh.Clear();
39.         }
40.  
41.  
42.         using (var readArray = Mesh.AcquireReadOnlyMeshData(inMesh))
43.         {
44.             //-------------------------------------------------------------
45.             // INPUT INFO
46.             //-------------------------------------------------------------
47.             var readData = readArray[0];
48.  
49.             // Formats
50.             var vertexFormat = inMesh.GetVertexAttributes();
51.             var indexFormat  = inMesh.indexFormat;
52.             var isIndexShort =  indexFormat == IndexFormat.UInt16 ;
53.            
54.             // Counts
55.             var vertexCount = readData.vertexCount;
56.             var indexCount = isIndexShort ? data.GetIndexData<ushort>().Length : data.GetIndexData<uint>().Length;
57.  
58.             // Element Size in bytes
59.             var indexSize = isIndexShort ? SHORT_SIZE : INT_SIZE;
60.             var vertexSize = 0;
61.  
62.             for (var i = 0; i < vertexFormat.Length; i++)
63.                 vertexSize += vertexFormat[i].dimension * FLOAT_SIZE;
64.  
65.  
66.             //-------------------------------------------------------------
67.             // OUTPUT SETUP
68.             //-------------------------------------------------------------
69.             var writeArray = Mesh.AllocateWritableMeshData(1);
70.             var writeData  = writeArray[0];
71.             writeData.SetVertexBufferParams(vertexCount, vertexFormat);
72.             writeData.SetIndexBufferParams(indexCount, indexFormat);
73.  
74.             //-------------------------------------------------------------
75.             // MEMORY COPYING
76.             //-------------------------------------------------------------
77.             NativeArray<byte> inData;
78.             NativeArray<byte> outData;
79.  
80.             // Vertices
81.             inData  = readData.GetVertexData<byte>();
82.             outData = writeData.GetVertexData<byte>();
83.  
84.         #if USE_UNSAFE
85.             unsafe
86.             {
87.                 UnsafeUtility.MemCpy(outData.GetUnsafePtr(), inData.GetUnsafeReadOnlyPtr(), vertexCount * vertexSize);
88.             }
89.         #else
90.             inData.CopyTo(outData);
91.         #endif
92.  
93.  
94.             // Indices
95.             inData  = readData.GetIndexData<byte>();
96.             outData = writeData.GetIndexData<byte>();
97.  
98.         #if USE_UNSAFE
99.             unsafe
100.             {
101.                 UnsafeUtility.MemCpy(outData.GetUnsafePtr(), inData.GetUnsafeReadOnlyPtr(), indexCount * indexSize);
102.             }
103.         #else
104.             inData.CopyTo(outData);
105.         #endif
106.  
107.             //-------------------------------------------------------------
108.             // FINALIZATION
109.             //-------------------------------------------------------------
110.             writeData.subMeshCount = inMesh.subMeshCount;
111.  
112.             // Set all submeshes
113.             for (var i = 0; i < inMesh.subMeshCount; i++)
114.             {
115.                 writeData.SetSubMesh(i,
116.                                      new SubMeshDescriptor((int) inMesh.GetIndexStart(i),
117.                                                            (int) inMesh.GetIndexCount(i)));}
118.  
119.  
120.             Mesh.ApplyAndDisposeWritableMeshData(writeArray, outMesh);
121.  
122.  
123.         outMesh.RecalculateBounds();
124.     }
125.  
126. #else
127.  
128.     /// <summary>
129.     /// Attempts to copy the data of the current <see cref="Mesh"/> to another one, as fast as possible,
130.     /// with minimal allocations (a few tens of bytes in scenarios with very large meshes).
131.     /// </summary>
132.     public static void CopyTo(this Mesh inMesh, ref Mesh outMesh)
133.     {
134.             // PRE-UNITY 2020 WAY OF COPYING
135.             outMesh.indexFormat = inMesh.indexFormat;
136.             outMesh.SetVertices(inMesh.vertices);
137.             outMesh.SetNormals(inMesh.normals);
138.             outMesh.SetUVs(0,inMesh.uv);
139.             outMesh.SetIndices(inMesh.GetIndices(0), inMesh.GetTopology(0), 0);
140.             outMesh.SetColors(inMesh.colors);
141.     }
142. #endif
143.  
144. }

 

Interesting, have you run any tests on the runtime? is there any speedup relative to the 2019 version of copying?

Also with which macros did you run the performance test on the github page where you got 80 Bytes gc?

 

Both the

UnsafeUtility.MemCpy

and the

NativeArray.CopyTo

generate the same amount of garbage, since behind the scenes, the

CopyTo

is a

MemCpy

+ safety checks.

A test I run just now using the old way of copying, shows that the 2020.1 way is ~1.5x faster (150ms vs 90 ms excluding RecalculateBounds) and creates 875.000x less garbage (73 MB vs 80 B), if I'm not mistaken. (All that's for a 98 MB mesh with Positions, Normals & Tangents)

 

Cool thanks for sharing the code and the extra details!

 

Just excited to test the new API! Definitely a step forward. @Aras It would be interesting to see if such a kind of usage makes sense.

 

Note that the above code won't copy over bind poses, weights, blend shapes or the original bounds. If your mesh uses multiple vertex buffer streams, you'll need to modify it to support those as well.

Unfortunately, it's not currently possible to copy over bind poses or blend shapes without allocating garbage, but if you require that data to be copied over regardless, here is a similar set of APIs that I currently use in a project (I haven't checked if this compiles, I just stripped the relevant code out of my project, so YMMV):

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.Rendering;
3.  
4. public static class MeshUtility
5. {
6.     const MeshUpdateFlags DontUpdate = MeshUpdateFlags.DontRecalculateBounds | MeshUpdateFlags.DontResetBoneBounds | MeshUpdateFlags.DontValidateIndices;
7.  
8.     const MeshUpdateFlags DontUpdateOrNotify = DontUpdate | MeshUpdateFlags.DontNotifyMeshUsers;
9.  
10.     public static int GetIndexCount(Mesh.MeshData data)
11.     {
12.         int count = 0;
13.  
14.         for (int i = 0; i < data.subMeshCount; i++)
15.             count += data.GetSubMesh(i).indexCount;
16.  
17.         return count;
18.     }
19.  
20.     public static void CopyMeshData<T>(Mesh.MeshDataArray sourceArray, Mesh.MeshDataArray destinationArray)
21.         where T : unmanaged, IVertexLayout
22.     {
23.         CopyMeshData(sourceArray, destinationArray, VertexLayout<T>.Layout);
24.     }
25.  
26.     public static void CopyMeshData(Mesh.MeshDataArray sourceArray, Mesh.MeshDataArray destinationArray, VertexAttributeDescriptor[] attributes)
27.     {
28.         for (int i = 0; i < sourceArray.Length; i++)
29.         {
30.             var source = sourceArray[i];
31.             var output = destinationArray[i];
32.  
33.             output.SetVertexBufferParams(source.vertexCount, attributes);
34.             output.SetIndexBufferParams(GetIndexCount(source), source.indexFormat);
35.  
36.             for (int s = 0; s < source.vertexBufferCount; s++)
37.                 output.GetVertexData<byte>(s).CopyFrom(source.GetVertexData<byte>(s));
38.  
39.             output.GetIndexData<byte>().CopyFrom(source.GetIndexData<byte>());
40.             output.subMeshCount = source.subMeshCount;
41.  
42.             for (int m = 0; m < source.subMeshCount; m++)
43.                 output.SetSubMesh(m, source.GetSubMesh(m), DontUpdateOrNotify);
44.         }
45.     }
46.  
47.     public static void CopyTo(Mesh source, Mesh destination)
48.     {
49.         using (var sourceArray = Mesh.AcquireReadOnlyMeshData(source))
50.         {
51.             var destinationArray = Mesh.AllocateWritableMeshData(1);
52.             CopyMeshData(sourceArray, destinationArray, source.GetVertexAttributes());
53.             Mesh.ApplyAndDisposeWritableMeshData(destinationArray, destination, DontUpdate);
54.         }
55.  
56.         destination.name      = source.name;
57.         destination.bounds    = source.bounds;
58.         destination.bindposes = source.bindposes;
59.  
60.         destination.SetBoneWeights(
61.             source.GetBonesPerVertex(),
62.             source.GetAllBoneWeights()
63.         );
64.  
65.         if (destination.blendShapeCount > 0)
66.             destination.ClearBlendShapes();
67.  
68.         if (source.blendShapeCount > 0)
69.         {
70.             var vertices = new Vector3[source.vertexCount];
71.             var normals  = new Vector3[source.vertexCount];
72.             var tangents = new Vector3[source.vertexCount];
73.  
74.             for (int i = 0; i < source.blendShapeCount; i++)
75.             {
76.                 var name   = source.GetBlendShapeName(i);
77.                 var frames = source.GetBlendShapeFrameCount(i);
78.  
79.                 for (int f = 0; f < frames; f++)
80.                 {
81.                     source.GetBlendShapeFrameVertices(i, f, vertices, normals, tangents);
82.                     var w = source.GetBlendShapeFrameWeight(i, f);
83.                     destination.AddBlendShapeFrame(name, w, vertices, normals, tangents);
84.                 }
85.             }
86.         }
87.     }
88. }

Edit: Upon posting this, I realized after all this time that GetIndexCount could be improved further to cover more cases:

Code (CSharp):

1. public static int GetIndexCount(Mesh.MeshData data)
2. {
3.     int count = 0;
4.  
5.     for (int i = 0; i < data.subMeshCount; i++)
6.     {
7.         var subMesh = data.GetSubMesh(i);
8.         count       = Mathf.Max(count, subMesh.indexStart + subMesh.indexCount);
9.     }
10.  
11.     return count;
12. }

A potentially even better option would be to calculate the index count from the length of the NativeArray returned by the source MeshData's GetIndexData:

Code (CSharp):

1. public static int GetIndexCount(Mesh.MeshData data)
2. {
3.     if (data.indexFormat == IndexFormat.UInt16)
4.         return data.GetIndexData<ushort>().Length;
5.  
6.     return data.GetIndexData<uint>().Length;
7. }

 

Good call for Blendshapes + BoneWeights.
As I rarely use them in my workflow, I didn't think about them when making this prototype. It's weird how Unity left them out of this new API, no?

Thanks for spotting this silliness on my part regarding total index count. I was testing storing per-submesh index counts, and left this one there.

 

It definitely feels like a missing piece of the API, yeah. I make use of them often so not having any non-allocating versions is a bit of a pain.

 

Taking a guess this might be because the future direction is DOTS animation which doesn't store that data on the mesh.

 

I tested out the new Mesh APIs in 2020.1 and only managed to encounter some performance problems and editor crash issues... (Cases 1245844, 1245825)

Wondering what's the status of these new APIs? Are they badly WIP or should they be stable enough to at least use? Should it be expected to hit crash issues when playing around with native collections and Mesh APIs?

 

I'd like to emphasize this request by @richardmatthias. We need the ability to draw a vertex buffer without any index buffer (ID3D11DeviceContext: Draw equivalent).

 

I think some "helper" functions to more easily draw/create connected quads (without resorting to untangling the tris) would be SO DAMN USEFUL.

Also, now that unity has its own SPLINE data construct...

Being able to perform a "deform" operation along a spline while drawing a group of these (e.g. a "grid" of quads) at the mesh level would be EVEN MORE USEFUL.

Please, please, pretty please??

@Aras

I find myself needing to triangulate procedural surfaces from 2d shapes as well (see Archimatix), so if the Mesh-level API would just let me take in a few of the Unity splines (to automatically generate a "surface" across them), this would lead to ALL SORTS of very performant (an EXTREMELY USEFUL) procedural modeling tools (we totally need in Unity.)

Since these things are done on the mesh-level, we could use them to draw gizmos, bones, whatever. Anyone could make meshes (and therefore make more visual tools) much more easily (since we'd just need to focus on the SHAPE of the model, rather than the individual triangle structure -- which holds A LOT of people back).

Anybody @Unity Game for this? D:

 

Can I use new mesh API for vertex compressing? Currently, Unity compress internally "non-readable" mesh assets's vertext to Float16 when building player if "Vertex Compression" is enabled in Player Settings.

So If I created custom mesh with other vertex format, like UNorm8, is it serialized preserving its vertex format?

 

Would this be more performant with shader graph ?

 

yes..

 

Kinda off-topic but are improvements for dynamic mesh colliders part of the new API or purely physics based?

Does calling Physics.BakeMesh in runtime bring any benefits to reduce PhysX.CollisionData impact every frame?

UPDATE: https://forum.unity.com/threads/multithreading-mesh-bake-physx-collisiondata.728561/#post-4871393

How do you guys update mesh colliders in runtime then?

 

Seems like there would be an API call to return a compressed-vertex mesh:

i.e. compressedMesh = ReadCompressedMesh(WriteCompressedMesh(standardUnityMesh, compressionMethodEnum));

Or something similar. Yeah?

 

I implemented my own compressing method, which convert to lower-precision format mesh. (float32 --> float16) and it works with MeshRenderer.

But I found that float16 meshes does not work with following unity features: SkinnedMeshRenderer, Lightmap baking, StaticBatching, Projector.

 

Yeah -- We need a LOT more flexibility (and control) with meshes in Unity. Scriptable-Mesh Rendering Pipeline anyone?


This would definitely be useful ESPECIALLY when dealing with open-world mesh-modification scenarios. I am working on something requiring this right now. D:

 

Does anyone has the issue that mesh doesn't get rendered correctly? My mesh sometimes disapear while the player can still see it.

Code (CSharp):

1.     _mesh.Clear();
2.    
3.     _mesh.SetVertexBufferParams(_eVertices.Count, _vertexDescriptor);
4.     // pass vertices and uvs here
5.     _mesh.SetVertexBufferData(_eVertices, 0, 0, _eVertices.Count);
6.    
7.     _mesh.SetIndexBufferParams(_triangles.Count, _indexFormat);
8.     _mesh.SetIndexBufferData(_triangles, 0, 0, _triangles.Count, MeshUpdateFlags.
9.     DontRecalculateBounds
10.     );
11.    
12.     var subMeshDescriptor = new SubMeshDescriptor(0, _triangles.Count, MeshTopology.Triangles);
13.     subMeshDescriptor.bounds = new Bounds(new Vector3(Extent, Extent, Extent) * ((float)Size - 1f), new Vector3(Extent, Extent, Extent) * 2f * Size);
14.     subMeshDescriptor.vertexCount = _eVertices.Count;
15.     _mesh.subMeshCount = 1;
16.     _mesh.SetSubMesh(0, subMeshDescriptor, MeshUpdateFlags.
17.     DontRecalculateBounds
18.     );
19.  

It seemed that my bounds isn't calculated correctly but when I checked it with Gizmos.DrawWireCube(transform.position + GetSubMesh(0).bounds.center, GetSubMesh(0).bounds.size) method it looked ok. Using MeshUpdateFlags.Default doesn't work either.

Using Mesh.RecalculateBounds() after all of the code above works, but I don't know why then MeshUpdateFlags.Default doesn't work. Both bounds looks the same with Gizmos.DrawWireCube method.

 

How about BlendhShape APIs? it still not have NativeArray version of Get/Set blendshapes. It need very expensive Vector3[], Vector4[] allocation.

Also, it currently need whole size of vertex array even the blendshape changes very small part of the mesh. If it provide that method which has partially modified vertices as parameters, like this AddBlendShape(name, positionDelta, positionDeltaStart, positionDeltaLength, normalDelta, normalDeltlaStart, normalDeltaLength, ...) then skipping 0 values, it can save many temporary allocations.

 

Yeah, blend shapes desperately need an API revamp (maybe something similar to the MeshData API?), the functionality in there right now is showing its age. There's actually a bug related to texture UVs when using the new MeshData APIs alongside blend shapes too (they get all corrupted unless the UVs are in a separate vertex stream or are added after the blend shapes) which I need to remind myself to make a bug report for.

 

Graphics.DrawMeshInstanced with NativeArray<Matrix4x4> would be so nice.

 

And the mathematics matrices for that matter

 

One big one I would like is for MeshData.SetVertexBufferParams to accept a native array and not just an array.

Without this I can't fully chain my jobs cause I have to wait until the mesh is calculated to get the vertice length and then I have to call this before executing my mesh build job (which generates a sync point).

Attached are the sort of attributes I'm working with. I'm about to look into setting this data one at a time instead but I don't really want to do that since it wasn't long ago I switched to using VertexAttributes in the first place and it was a lot of work to restructure the data!

 

Ha thankfully I just checked the change log for the next alpha (2020.2) and noticed this, thew!

https://issuetracker.unity3d.com/is...rparams-function-is-not-compatible-with-burst

 

Would be cool to have a Mesh.SetBoneWeights(NativeArray<BoneWeight> weights) (the default BoneWeight struct)

 

did you see mesh api samples? why you think it can be used in jobs?

 

I don't understand your question :/

These new mesh functions can be used with jobs and even be burst compiled now since they back ported this fix to 2020.1.5 (before this version, you couldn't set mesh flags on a job since the only input was a traditional rather than native array)

 

@Aras
We would very much like to see a user-specified "position scale" value that can be applied to meshes so that the SNorm16 format can be used. This is something that we did in our previous engine for nearly every model and it allowed us to get optimal precision over something like the half-float format with optimal memory usage.

This Vector3 position scale would be multipled by the SNorm16 vertex positions in the shader to rescale them to the proper size as well as certain operations in the editor such as when it performs 'pick' operations using only the visible mesh. Trying to do this with a localToWorld scale is very much *not* desired as we also want to update our glTF importer to use the SNorm16 format for nearly all of our models as we have with our previous engine, and we do not want to have them all have a non-uniform (transform) scale applied. This is basically just a fixed-point to floating-point conversion factor.

The scale needs to be a full Vector3 as we're able to optimize the precision per dimension. For example, our custom terrain editor could then support significantly larger sizes and provide much better height-precision than when using the half format. Even all of our smaller props would benefit from the increase in precision over using half-floats.

 

@Aras

Is there any way to manage procedural meshes when they are located outside of the 5000-8000 meter unit range without them losing precision?


I ask because I have meshes from Houdini's Unity Plugin that uses 64 bit positioning in my world and need to modify these parts of my world in Unity sometimes through digital assets that position these verts far away from the origin while editing -- as far as Unity is concerned -- inside the same mesh.

Is there any solution to this?

 

@Aras
Could Mesh.ApplyAndDisposeWritableMeshData support jobs? Using MeshInstancesId like Physics.BakeMesh, this way we wouldn't need to be Main Thread dependent between those two calls, applying the Mesh Data and then baking the collider right away.

Edit: please, sync points are multithreading enemy

 

Not sure related but I wish we could share vertex buffer between mesh

I have create a custom terrain mesh with noise. And I need to create multiple mesh for each LOD. But all of them can just use the same vertex buffer, And just decrease the detail of index buffer

And so I wish we would have a mesh that can share vertex buffer. Or a mesh that support LOD by itself. Or the system that allow us to draw with raw vertexbuffer and indexbuffer directly

 

What would be _nice_, @Aras, my friend, is to simply have programmable geometry for these sort of things (i.e. such as LODs, impostors, and culling chunks).


Programmable geometry (i.e. at the Houdini "group" level -- where primitives, points, lines/edges, and faces can be programmed with UVs, offsets, decimation, and/or LOD algorithms based on volumetrics or textures and scattering) would greatly help environment design -- which is sorely lacking. D:

Plz? -- Pretty plz w/cherry on top?

 

Hi,

I started to try things with new mesh API, and realized that Dynamic Batching does not work at all. I tried to use Float32 for position as Aras mentioned in one of the posts and basically use Float32 everywhere, but my identical meshes still do not batch. Meshes are just a few quads. Interestingly, Frame Debugger shows absolutely identical parameters for the draw calls, but does not provide any reason why draw calls are not batched.

Is it a known limitation of the new mesh API that it always breaks Dynamic Batching? Maybe I am missing some more conditions that attributes should satisfy in order to be dynamically batched? E.g. UNorm8 should not be used, or something?

Does anyone have the same issue? I'm using Unity 2019.4.18f1.

 

I'm replying to myself and maybe to someone else who faces the same problem.

In Unity 2019.4.18f1 in order to make Dynamic Batching work with your custom vertex layout, attributes should satisfy these minimum requirements:

• Position attribute should have exactly 3 components of type Float32
• There should be only one vertex stream, the stream 0.

The first requirement is ok for now as some data could be packed into the 3rd float if it's not used for Z coordinate. But the second requirement is much more limiting. Imagine, that there is a mesh with vertex colors. And each frame you update vertex colors to create some effect. In case of a single stream, it is required to cache the entire vertex data array per instance as the entire vertex data should be uploaded when colors are changed. On the other hand, if it's allowed to have the second stream, then per instance cache is not needed as colors array could be built separately from the reset of vertex attributes. Some static buffer could be used for it. A lot of memory could be saved this way.

Is it possible that Dynamic Batching will be improved, so that it could batch vertex buffers of the same layout with multiple streams?

 

Is there a chance that Mesh.AllocateWritableMeshData() could become thread-safe? Right now we are not allowed to allocate that data from another thread (throws an exception). We can fill it from another thread, but allocation still must happen on the main thread apparently - this slows down my mesh generation and adds another level of complexity (allocate in main thread -> fill data from other thread -> apply to mesh in main thread again)...

 

Hey guys, I looked at the API and can see some interesting use for it, but there is a part I'm still a little confused about. I'm loading GLTF geometry at runtime, and I mean a *lot* of it. Sometimes each GLTF file has a mesh with 20k vertices for instance.

Anyway, I do most of the work on a separate thread and it works fine, but I have yet to figure out a way to copy the data to the mesh without a severe performance hit (I measured about 1ms for a 20k vertices mesh). I tried native arrays and mesh.SetVertexBufferData, but it still copies the data, I guess.

So my question is: with the new API, is there a way to set vertices and indices on a mesh WITHOUT a serious hit on the mean thread ? (assuming of course the data has been prepared on a separate thread)

 

Did you check out this API?
https://docs.unity3d.com/2020.1/Documentation/ScriptReference/Mesh.AllocateWritableMeshData.html

it's basically the 3rd way of doing things by now

 

@Aras One thing that would be nice not that we can have fully custom vertex buffer layout is to not have warnings spewed if the position attribute is missing or not of type float3

 

Just want to repeat the request to make Mesh.AllocateWritableMeshData usable outside of the main thread, but I'd also like to extend that request to Mesh.MeshDataArray.Dispose as well. I currently fill in mesh data on another thread, and if I encounter an exception or some other kind of failure, I want to dispose of the mesh data to avoid a memory leak. Since the Dispose method can only be called from the main thread, I have to queue it on the main thread using my own dispatcher class.

It would also be nice to have a Mesh.ApplyWritableMeshData method as an alternative to Mesh.ApplyAndDisposeWritableMeshData so I can re-use mesh data arrays, and write code like this without getting double-free errors:

Code (CSharp):

1. using (var array = Mesh.AllocateWritableMeshData(meshes.Length))
2. {
3.     //
4.     // fill in mesh data here
5.     //
6.  
7.     Mesh.ApplyAndDisposeWritableMeshData(array, meshes);
8. }

A non-disposing variant of ApplyAndDisposeWritableMeshData actually already exists as a private method and can be called via reflection, but making this part of the official API would be ideal.