Question Physics.BakeMesh question

In Unity 2019.3, there is the new Physics.BakeMesh API:
https://docs.unity3d.com/2019.3/Documentation/ScriptReference/Physics.BakeMesh.html

If I bake a mesh at runtime and assign it to a MeshCollider, do the cookingOptions in the MeshCollider have any affect? Do I need to set the MeshCollider.cookingOptions to None if I assign a baked mesh?

There seem to be no cookingOptions for Physics.BakeMesh?

The documentation reads:

I don't understand this. When I assign a physics-baked mesh to a MeshCollider, what is being instantiated? I'm dynamically switching MeshCollider meshes at runtime, like through a flipbook. Would this cause any issues?

 

I think there may actually be a bug in the code that performs the check related to this:
- the Mesh instance hasn't been changed since the last time cooking was ran.

From my experience, the actual behaviour is that the cooking/baking will be performed if the mesh was ever changed after it's initial baking pass, regardless of whether it has changed since the last good bake.

For example:

Modify Mesh
Modify Mesh
Assign sharedmesh
Move collider (bake)
Move collider (no bake)
Move collider (no bake)
Modify Mesh
Move collider (bake) - expected
Move collider (bake) - unexpected

 

Having a similar issue on some procedural meshes..

I'm doing..

// creating or refreshing mesh verts in job system
gameObject.SetActive(false);
collider.sharedMesh = null;
// creating or rebuilding mesh with new data
// setting mesh filter's sharedmesh
gameObject.SetActive(true);
// Physics.BakeMesh( meshID ); in job system
collider.sharedMesh = mesh;

This seems to result in the following errors:

[Physics.PhysX] Foundation: Invalid deregistration detected. // on the null set
[Physics.PhysX] Foundation: Invalid registration detected. // on the refreshed mesh set

And to top it off, it seems to be rebaking the mesh anyways when setting the sharedMesh ;_;

 

Unfortunately, after restarting Unity this problem seems to have vanished, so now I cannot duplicate it to file a bug report..

 

@yant However, the double bake does still happen for me. I made a repro, here's the case: #1197040

 

Ever get a chance to look at this? I just updated to 2019.3.0f3 hoping it would be fixed, but I'm still seeing the bake show up in both the job system and the main thread.. (schedules a job to bake a bunch of meshes, then next frame completes the job and sets the meshes to the sharedMesh parameter of their mesh colliders)

 

Oh, is the issue that a single mesh class instance being rebaked multiple times is not yet supported? I suppose I can work around this, although it does seem like a waste of heap space, in my case it may be acceptable as a workaround. I'll try it, thanks!

 

I can confirm that currently it only seems to bake on fresh meshes. Can't await the fix, i run a procedural Terrain-Generator on mobile:

I use custom meshes paired with Terrains that are only used for their TerrainColliders. Terrain Colliders can be updated about 10 times quicker than an equivalent CookingOption.None-meshcollider
(~1ms vs 10ms, cant be threaded -> lags).

I already do threading on everything else, so finally having the option to thread mesh-collider generation is the best news ever! If this is fixed i can consider any mesh for my terrain, not just heightmapped terrains.

Question: are there any plans to expose the collider-data for a more direct tinkering? E.g. i could use the Terrain-Collider generation speed but with some flipped quads (for polystyle)

 

My game is all procedural, so i am really interested in this.
Can you please give a link to the issue tracker page, so i can vote on this?

 

Is there any indication in the profiler if the mesh pointer can't be shared with PhysX? I'm currently writing an import pipeline to create "physics meshes", which are regular meshes ran through Physics.BakeMesh and saved as asset. I then assign these physics meshes to a MeshCollider at runtime and would like to know whether this works without overhead.

 

When you do get a chance to look deeper at this and work on fixing it, can you ensure that the previously baked collision mesh is still somehow valid until we swap to the new one? Or is it writing to the same buffer, so this is not possible? I may need to make a new mesh anyways (or I suppose, in the future just keep two and swap between them on update) to ensure collision is still valid while the new one is being baked..

 

I use transformations (including non-uniform scales) of a set of primitive MeshCollider objects to construct collision shape. I get colliders from pools). Needless to say, i'm getting a lot of Physics.Bake now left and right. It would be nice, if we could Physics.Bake(meshID, convex, transform) or Physics.Bake(meshID, convex, pos, rot, scale) if it has to be blittable.

Also - this fix can't come fast enough. Creating new Mesh instances just because we need to change the mesh is insane.

 

There is only one thing i want for christmas, it's Physics.BakeMesh.

 

Did anyone do this yet?

 

I submitted #1197040 awhile ago, but I have no idea how to track this as the link in the original email requires some kind of login and there's no hint as to how to register or sign in or anything..

Edit: Ah, there was a second email much later: https://issuetracker.unity3d.com/is...ng-the-mesh-results-in-a-double-collider-bake

 

https://unity3d.com/unity/beta/2019.3.0f5

Does it contain a fix?

 

Thanks for the Update!

So what is the current Workaround?
I tried creating new meshes each time but i still wasn't able to trigger the threaded meshbaking in a way that the mesh didn't need also trigger baking in the main loop.

 

What is the time estimate for the fix? Proc gen stuff uses 2019.3 features heavily (like setting NativeCollections to Mesh), falling back to earlier versions is not an option. GC traps are everywhere.

 

It doesn't work for me. I see a Mesh.Bake PhysX collisionData on the main thread anyway every time I instantiate a prefab containing meshcollider that references a previously baked mesh using Physics.Bake Mesh. Is there any way to determine was the bake successful or not? May be it is because I am using PhysicsScenes?

 

We get a lot of this type of errors (in the player 2019.3.0f6 Win64 Mono):

Couldn't create a Convex Mesh from source mesh "p_BigRock_01_b_N" within the maximum polygons limit (256). The partial hull will be used. Consider simplifying your mesh.

After a few (not always the same amount) of reloading the scene, we start get these:

Code (CSharp):

1. [Physics.PhysX] Foundation: Invalid registration detected.
2. (Filename: C:\buildslave\physx\build\physx/source/foundation/src/PsFoundation.cpp Line: 201)
3.  
4. [Physics.PhysX] Foundation: Invalid deregistration detected.
5. (Filename: C:\buildslave\physx\build\physx/source/foundation/src/PsFoundation.cpp Line: 216)

And after that we get a crash on exit. Can these be related? (The errors and the crash)

 

I don't think it is. TerrainCollider internally uses Heightfield, while MeshCollider uses either TriangleMesh or ConvexMesh (depending on convex setting). I'd prefer Unity to decouple TerrainCollider from TerrainData and expose methods for direct update of heightmap (which PhysX supports).

 

Did not work for me. I wasn't able to avoid rebaking on assignment in the main thread.
Do cooking options break it? Can we in any way verify if the bake was performed on the thread?

Anyway, we should wait for a second person to test this, my code got messy because i had only an hour to test this, so it might just be me.

EDIT: Was my fault, the custom build works!
https://forum.unity.com/threads/physics-bakemesh-question.741257/#post-5545537

 

cooking options break it, I believe intentionally

 

This is what the Editor uses per defaul:


I created my MeshColliderComponent via script without touching the default cooking options. And after that failed, i tried to set it manually to this state. Same behavior. Has anyone else tried so far?

 

Thank you for looking into this! I checked your script, it seems that Physics.Bake() will still only happen once for the lifetime of the mesh.
EDIT: Oops, I used the old Editor on my first tests, in 2020.1.0a24.3012 it works as expected! (in the current version 2019.3.03f it doesn't)

Thank You! Can we expect this in the next stable release? I need to test this on an Android device

Spoiler: Script description

I adapted your script to include Threading (see below). Just paste it, needed objects are created procedurally. I also used a larger mesh so that the baking should take some milliseconds. So you can see in the console-messages if assignments cause baking:

Controls:
Press 1: Update the mesh and Bake it in Update, the assignment in FixedUpdate should not take long
Press 2: Update the mesh without baking it, the assignment in FixedUpdate should take long
Press 3: Update the mesh and bake it in a second thread, the assignment in the callback should not take long
Space: Drop a test collider

Here is the script:

Spoiler: Script

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. using System.Threading;
6. using BakeThreads;
7.  
8. public class CreateTriangle : MonoBehaviour
9. {
10.     private Mesh mesh;
11.     private MeshCollider collider;
12.     private MeshFilter filter;
13.     private MeshRenderer renderer;
14.     private GameObject    lagIndicator    = null;
15.     private    GameObject    dropCloneSource    = null;
16.     private    float        spawnDelay        = 2.8f;
17.     private    GameObject    curClone        = null;
18.  
19.     private BakeThreadHandle bakeHandle = null;
20.  
21.     //counter for better console messages
22.     public static int jobCounter;
23.  
24.     public void Start()//public IEnumerator Start()
25.     {
26.         //Target mesh
27.             mesh = new Mesh();
28.             collider = gameObject.AddComponent<MeshCollider>();
29.             filter = gameObject.AddComponent<MeshFilter>();
30.             renderer = gameObject.AddComponent<MeshRenderer>();
31.             filter.sharedMesh = mesh;
32.         //LagIndicator
33.             lagIndicator = GameObject.CreatePrimitive(PrimitiveType.Cube);
34.             lagIndicator.transform.position = new Vector3(-5F, 0F, 0F);
35.  
36.         //LagIndicator
37.             dropCloneSource = GameObject.CreatePrimitive(PrimitiveType.Cube);
38.             dropCloneSource.transform.position = new Vector3(-5F, 5F, 0F);
39.             dropCloneSource.AddComponent<Rigidbody>();
40.  
41.         //borrow material from primitve
42.             renderer.sharedMaterial = lagIndicator.GetComponent<MeshRenderer>().sharedMaterial;
43.  
44.         //init our bakehandle for threading (see bottom of this script)
45.             bakeHandle = new BakeThreadHandle( OnFinishedThreadedMeshBake );
46.     }
47.     private static void Generate( Mesh targetMesh, float timeMod )
48.     {
49.  
50.         //generate array (COULD BE THREADED)
51.  
52.             //https://www.patrykgalach.com/2019/07/29/procedural-terrain-pt1-plane/
53.             int width = 180;
54.             int depth = 180;
55.             float scale = 0.05F;
56.             // Defining vertices.
57.             Vector3[] vertices = new Vector3[(width + 1) * (depth + 1)];
58.             int i = 0;
59.             float y = Random.Range(-15F,15F);
60.             for (int d = 0; d <= depth; d++){
61.             for (int w = 0; w <= width; w++){
62.                 vertices[i] = ( new Vector3(w, y, d) - new Vector3(width / 2f, 0, depth / 2f) )*scale;
63.                 i++;
64.             }}
65.             // Defining triangles.
66.             int[] triangles = new int[width * depth * 2 * 3]; // 2 - polygon per quad, 3 - corners per polygon
67.             for (int d = 0; d < depth; d++){
68.             for (int w = 0; w < width; w++){
69.                 // quad triangles index.
70.                 int ti = (d * (width) + w) * 6; // 6 - polygons per quad * corners per polygon
71.                 // First tringle
72.                 triangles[ti] = (d * (width + 1)) + w;
73.                 triangles[ti + 1] = ((d + 1) * (width + 1)) + w;
74.                 triangles[ti + 2] = ((d + 1) * (width + 1)) + w + 1;
75.                 // Second triangle
76.                 triangles[ti + 3] = (d * (width + 1)) + w;
77.                 triangles[ti + 4] = ((d + 1) * (width + 1)) + w + 1;
78.                 triangles[ti + 5] = (d * (width + 1)) + w + 1;
79.             }}
80.  
81.         //assign to mesh (CANNOT BE THREADED)
82.             targetMesh.vertices = vertices;
83.             targetMesh.triangles = triangles;
84.             targetMesh.RecalculateNormals();
85.     }
86.     public void Update()
87.     {
88.  
89.         lagIndicator.transform.Rotate(0F,0F,60F*Time.unscaledDeltaTime);
90.  
91.         //BAKE in Update
92.         if(Input.GetKeyDown(KeyCode.Alpha1)){    jobCounter++;
93.             Debug.Log("═════Key 1═════════\nBAKING IN UPDATE, assignment should NOT take long [ job:"+jobCounter.ToString().PadLeft(4,'.')+" ]");
94.  
95.             Generate( mesh, Time.time );//Generating vertex arrays etc. could be threaded too, but assigning .vertices|.triangles etc. to mesh, cannot be threaded
96.  
97.             float start = Time.realtimeSinceStartup;
98.             BakeMeshCollider( mesh );
99.             print("[ job:"+jobCounter.ToString().PadLeft(4,'.')+" ] Meshcollider Baking in Main thread took:\n"+BakeThreadQueue.GetMS(Time.realtimeSinceStartup -start)+"" );
100.  
101.             assignmentPending = true;
102.         }
103.  
104.         //Don't Bake
105.         if(Input.GetKeyDown(KeyCode.Alpha2)){    jobCounter++;
106.             Debug.Log("═════Key 2═════════\nDON'T BAKE assignment should take long [ job:"+jobCounter.ToString().PadLeft(4,'.')+" ]");
107.  
108.             Generate( mesh, Time.time );//Generating vertex arrays etc. could be threaded too, but assigning .vertices|.triangles etc. to mesh, cannot be threaded
109.  
110.             assignmentPending = true;
111.         }
112.  
113.         //Bake in Thread
114.         if(Input.GetKeyDown(KeyCode.Alpha3)){    jobCounter++;
115.  
116.             Debug.Log("═════Key 3═════════\nBAKING IN THREAD, assignment should NOT take long [ job:"+jobCounter.ToString().PadLeft(4,'.')+" ]");
117.  
118.             if( bakeHandle.occupied ){
119.                 print("One Thread is already active");//for simplicity, only  threadhandle allowed in this example
120.             }else{
121.  
122.                 Generate( mesh, Time.time );//Generate could be threaded too
123.  
124.                 int meshID = mesh.GetInstanceID();//caching because 'targetMesh.GetInstanceID()' cant be called in worker thread!
125.  
126.                 //prepare & start thread (long version)
127.                 //ThreadStart threadstart = delegate {  MeshUpdate_Threadable( meshID, bakeHandle ); };
128.                 //Thread t = new Thread( threadstart );
129.                 //t.Start();
130.  
131.                 //prepare & start thread (one line version)
132.                 new Thread( new ThreadStart( delegate { BakeMeshCollider_Threaded( meshID, bakeHandle );})).Start();
133.                 bakeHandle.startTime = Time.realtimeSinceStartup;
134.                 bakeHandle.occupied = true;
135.             }
136.         }
137.  
138.         //Collison Test Object
139.         if(Input.GetKeyDown(KeyCode.Space)){
140.             if(curClone!= null){ Destroy(curClone); }
141.             curClone = GameObject.Instantiate(dropCloneSource, Vector3.up *10, Quaternion.identity);
142.         }
143.  
144.         BakeThreadQueue.CheckFinishedThreads();
145.     }
146.     private bool assignmentPending = false;
147.     public void FixedUpdate()
148.     {
149.         if( assignmentPending ){
150.  
151.             float start = Time.realtimeSinceStartup;
152.             // there will be no bake here because we baked in Update() before
153.             collider.sharedMesh = mesh;
154.             assignmentPending = false;
155.             print("[ job:"+jobCounter.ToString().PadLeft(4,'.')+" ] Meshcollider assignment in FixedUpdate took:\n"+BakeThreadQueue.GetMS(Time.realtimeSinceStartup -start)+"" );
156.         }
157.     }
158.  
159.     //NO THREADING
160.     private static void BakeMeshCollider( Mesh targetMesh  )
161.     {
162.         Physics.BakeMesh( targetMesh.GetInstanceID(), false);
163.     }
164.  
165.  
166.     //THREADING
167.     private static void BakeMeshCollider_Threaded( int targetMeshInstanceID, BakeThreadHandle bakeHandle  )
168.     {
169.         Physics.BakeMesh( targetMeshInstanceID, false);
170.  
171.         //report that the bake has finished
172.         lock( BakeThreadQueue.bakeFinishedQueue ){    //threads need to lock things that may be accessed by multiple threads at once
173.             BakeThreadQueue.bakeFinishedQueue.Enqueue( bakeHandle );
174.         }
175.     }
176.  
177.     //used as callback on our handle
178.     private void OnFinishedThreadedMeshBake(){
179.         float start = Time.realtimeSinceStartup;
180.         collider.sharedMesh = mesh;
181.         print("[ job:"+jobCounter.ToString().PadLeft(4,'.')+" ] Meshcollider assignment after threaded baking took:\n"+BakeThreadQueue.GetMS(Time.realtimeSinceStartup -start)+"" );
182.     }
183. }
184.  
185.  
186.  
187.  
188.  
189.  
190. namespace BakeThreads{
191.  
192.     public class BakeThreadHandle
193.     {
194.         public    readonly System.Action    callback;
195.         public    bool    occupied;
196.         public    float    startTime;
197.         public BakeThreadHandle( System.Action callback){
198.             this.callback = callback;
199.         }
200.     }
201.  
202.     public static class BakeThreadQueue
203.     {
204.         public static Queue<BakeThreadHandle> bakeFinishedQueue = new Queue<BakeThreadHandle>();
205.         public static bool    allowMultipleDequeues = false;
206.  
207.         //check every Update if thread is ready
208.         public static void CheckFinishedThreads(){
209.  
210.             for(int i=0; i<bakeFinishedQueue.Count; i++){
211.  
212.                 BakeThreadHandle handle    = bakeFinishedQueue.Dequeue();        //get finished task handle
213.                 Debug.Log(  "[ job:"+CreateTriangle.jobCounter.ToString().PadLeft(4,'.')+" ] Finished baking in another Thread!" +
214.                             "BakeThread took about \n"+GetMS(Time.realtimeSinceStartup -handle.startTime)+" to complete" );    //measure time it took
215.  
216.                 //do what must be done after baking has finsihed
217.                 handle.callback();
218.                 handle.occupied = false;
219.  
220.                 //early exit if we only want one dequeue per frame, e.g. if the callback is a large non threadable function and performing multiple might cause lag
221.                 if(!allowMultipleDequeues){ break; }
222.             }
223.         }
224.  
225.         public    static string GetMS( float seconds, string msDecimalPlaces = "F6" ){
226.             return ""+(1000F *seconds).ToString( msDecimalPlaces ) +"ms";
227.         }
228.     }
229. }
230.  
231.  

 

i tested on version 2020.1.0a25.3171 and Physics.Bake() is only working once, then Mesh.Bake PhysX moves to the mesh assignment.
when we can get the fix in a public version.
Constantly moving the heavy calculation out of the main thread would be very useful for me.

 

I could not edit my post...So.
Mesh.Clear() does Not work, only work around I found is to create a new Mesh every time.

 

Try the script in this post: https://forum.unity.com/threads/physics-bakemesh-question.741257/#post-5545537

- Create a new 3D project in 2020.1.0a24.3012 (https://beta.unity3d.com/download/5...429.93567035.1583100738-1295778461.1543368316) not 2020.1.0a25.3171
- Insert the scipt into the asset folder and put it onto an object in your scene
- press 1,2,3 or Space and watch console

 

It worked on 2020.1.0a24.3012, I just thought that 2020.1.0a25.3171 being more recent was going to work as well, my bad.

 

@yant not sure if my physics bug is somehow related to baking but there seems to be something really off when instantiating an object, scaling it and doing a raycast against it, all in the same frame. The raycast will still act on the unscaled size. I have to put in a "yield" to let one frame pass in order to fix this behavior. Is this intended? What worries me: QA is going to simply close it now since I cannot supply my 20Gb project that easily. Not sure if it ever reached you: Bug 1222033

 

Thanks for info, can't wait these fixes for 19.3

 

Wow, this is great, thanks!

 

I tried with the 2019.3.10f but I still get the "Foundation: Invalid deregistration / registration detected."...
My mesh colliders all have the default cooking options. Weirdly, appart from that error that pops every frame it does work as expected.
Any idea what I could have done wrong ?

Here's my code if that can help

Code (CSharp):

1. //public Dictionary<Mesh, MeshCollider> meshesToBake;
2.  
3. NativeArray<int> meshIds = new NativeArray<int>(meshesToBake.Count, Allocator.TempJob);
4. int j = 0;
5. foreach (Mesh mesh in meshesToBake.Keys)
6. {
7.     meshIds[j] = mesh.GetInstanceID();
8.     j++;
9. }
10. BakeJob bakeJob = new BakeJob(meshIds);
11. bakeJob.Schedule(meshIds.Length, 1).Complete();
12. meshIds.Dispose();
13. foreach (Mesh mesh in meshesToBake.Keys)
14. {
15.     meshesToBake[mesh].sharedMesh = mesh;
16. }
17. meshesToBake.Clear();