Rules and Whys behind Blobs and Colliders

For reference, this thread is a follow-up to the discussion in the Unity.Physics thread as the topic is quite complex and I feel these questions in particular deserve their own thread.

From the other posts on this forum, I've gathered two very different interpretations of what Blob Assets are supposed to be:

Interpretation 1: Blobs are immutable data accessible to jobs that are loaded and unloaded with prefabs and subscenes.

This interpretation makes total sense to me for things like animation curves, static meshes, noise fields, and plenty of other things. But it does not make sense for Colliders since there's dozens of use cases where a developer would want to modify a collider.

Interpretation 2: Blobs are lightweight mutable objects that are allocated on a specialized heap. They can be accessed from jobs on any thread any provide no mechanisms that I am aware of for reader-writer safety.

This interpretation makes me not want to use them in any code other than maybe highly specific and internalized code that only the highest level of code ninjas are allowed to touch.


Some will suggest that the second interpretation allows for a sort of polymorphism to take place which is required for Colliders.

Others will suggest that it allows for the dynamic sizing of Mesh Colliders.

In no way am I trying to call anyone wrong on these matters. I am simply trying to fill the gaps in my understanding on this not-well-discussed topic. To do that, I'm going to show how I am currently solving the problems with colliders in my CCDE. In particular, my solution maintains mutable colliders with thread safety and polymorphic-like representation of colliders while only using Interpretation 1 of Blobs.

My hope is that this serves as a frame of reference for discussion. In particular, I would like to know what downsides my approach has that Blobs solve. And I would like to know how Blobs compare to my approach with respect to performance, API usability, and thread safety. What I am sharing isn't the actual code but does show the relevant strategies that I am using.

Code (CSharp):

1. using Unity.Collections.LowLevel.Unsafe;
2. using Unity.Entities;
3. using Unity.Mathematics;
4. using UnityEngine.Assertions;
5.  
6. namespace Ex.Collision
7. {
8.     public struct SphereCollider : ICollider
9.     {
10.         public float3 center;
11.         public float radius;
12.  
13.         //ICollider methods not shown here
14.     }
15.  
16.     public struct MeshCollider : ICollider
17.     {
18.         public BlobAssetReference<MeshColliderData> meshData;
19.  
20.         //ICollider methods not shown here
21.     }
22.  
23.     // Collider is the only collider type which implements IComponentData.
24.     public struct Collider : IComponentData, ICollider
25.     {
26.         // By default, m_colliderType is set to ColliderType.Null.
27.         // m_colliderType can only be modified through assignment.
28.         // However, assignment also includes casting operations from the specialized
29.         // collider types.
30.         private ColliderType m_colliderType;
31.         public ColliderType ColliderType => m_colliderType;
32.  
33.         //This is a union for the specialized data
34.         private ColliderSpecializationStorage m_storage;
35.  
36.         public unsafe static implicit operator Collider(SphereCollider sphereCollider)
37.         {
38.             Collider collider;
39.             collider.m_colliderType = ColliderType.Sphere;
40.             UnsafeUtility.MemCpy(&collider.m_storage, &sphereCollider, sizeof(SphereCollider));
41.             return collider;
42.         }
43.  
44.         public unsafe static implicit operator SphereCollider(Collider collider)
45.         {
46. #if ENABLE_UNITY_COLLECTIONS_CHECKS
47.             Assert.AreEqual(collider.m_colliderType, ColliderType.Sphere, "Error: Collider is not a SphereCollider but is being casted to one.");
48. #endif
49.  
50.             SphereCollider sphere;
51.             UnsafeUtility.MemCpy(&collider.m_storage, &sphere, sizeof(SphereCollider));
52.             return sphere;
53.         }
54.  
55.         public unsafe static implicit operator Collider(MeshCollider meshCollider)
56.         {
57.             Collider collider;
58.             collider.m_colliderType = ColliderType.Mesh;
59.             UnsafeUtility.MemCpy(&collider.m_storage, &meshCollider, UnsafeUtility.SizeOf<MeshCollider>());
60.             return collider;
61.         }
62.  
63.         public unsafe static implicit operator MeshCollider(Collider collider)
64.         {
65. #if ENABLE_UNITY_COLLECTIONS_CHECKS
66.             Assert.AreEqual(collider.m_colliderType, ColliderType.Mesh, "Error: Collider is not a MeshCollider but is being casted to one.");
67. #endif
68.  
69.             MeshCollider mesh;
70.             UnsafeUtility.MemCpy(&collider.m_storage, &mesh, UnsafeUtility.SizeOf<MeshCollider>());
71.             return mesh;
72.         }
73.  
74.         //ICollider methods not shown here
75.     }
76. }

This allows any collider to be allocated on the stack in any job and used in queries with automatic destruction on leaving scope. There's no special creation function or allocation required. Standard constructors are fine. Casting does not require the user to use unsafe code. Primitive colliders are stored directly in chunks with no indirection to the heap during IJobForEach. And it is impossible to accidentally copy the header of a blob to the stack.

So my questions:

• What are the rules with Blobs and Unity Colliders with regard to thread safety?
• What are the rules with Blobs and Unity Colliders with regard to memory management?
• What additional problems do Blobs and Unity Colliders solve that my approach overlooks?
• What problems does my approach solve the Blobs and Unity Colliders do not?

I'm hoping to learn a ton from this and perhaps others can learn from it too!

 

Thank you so much! That clears up a lot of confusion I had! Sounds like Blobs are going to be the best of everything once their API is made safe (but even now the rules make it very obvious to me how to not screw them up). I'm guessing blobs also allow references to resources owned externally, which would make a ton of sense with regards to the Havok integration.

I guess my final question is related to memory management. So let's imagine I have a game where a spawn randomly-sized enemies (and thus create new blobs). The enemies then have the ability to duplicate themselves thus sharing their blob references. They also get destroyed pretty frequently too.

How do I make this not memory leak? Do blobs have some special mechanism for this use case? Or do I need to manually keep track of which blobs are being used?

 

I knew that much, but what happens if that mega blob fills up because new colliders are created every frame? I know that is very unlikely for simple colliders like sphere colliders, but for a constantly deforming mesh collider that seems like a real issue. Eventually something is going to have to go through and clean up all the abandoned and unused colliders that were generated at runtime. I guess I'm wondering if I would have to do that manually and if so are there any tricks to do that more efficiently?

 

@Joachim_Ante - on this note, and to add to what I asked in the other thread:

How do cross-scene blob references work, or is there not yet a solution for that?

 

Will the static analysis warn when you make the mistake of assigning a blob struct member to a non-ref local variable? When you do so currently and access a BlobPtr or BlobArray on that copied struct, the pointer math under the hood will cause it to return junk memory (which could easily cause a crash from out of bounds memory access).

 

Sorry.
For some reason the last part of your previous post didn't show up on my screen this morning. But the mega-blob not being the proc-gen blob target would have tripped me up, so thanks for clarifying that!

And thanks for clarifying blobs in general. It is really clear to me now the rules and roles they play in DOTS, not just for Unity.Physics, but in general.

I think I'm still going to keep my CCDE's representation of colliders until the Blob API and tooling near a more finished state. The good news is that both representations have the same data access constraints which means I should be able to port code between either representation without having to redesign an algorithm. I now have a pretty good roadmap in my head for rebasing my CCDE on top of Unity.Physics.

I'm pretty excited to try these out with a heightened sense of direction as to what I'm doing. SDFs sound like a good target for these guys.

 

Great, glad to hear. Wasn't immediately obvious to me what was going on when I did it on accident. As a former C/C++ guy I'm having fun with all the unsafe code lurking around in the implementation. Very awesome stuff.