Discussion Baker Vs Baking systems

Hello,

With the new baking workflow I understood that the bakers and baking system served the same purpose.
But from what I can see when experimenting with it, the baking systems complement the bakers. They are NOT substitue for them.

So you have to make a baker. And then if you need to do additionnal things like create blob assets or add companion game object, you use a baking system.

Is this correct or did I miss something ??

 

Is there any examples of setting up blob assets in a baking system?

 

Best I can find for now is in the physics package in the '..\Library\PackageCache\com.unity.physics@1.0.0-exp.8\Unity.Physics.Hybrid\EntitiesBaking\BakingSystems\BaseShapeBakingSystem.cs' file.

 

I'm still unclear on what the differences should be but so far creating or instantiating additional entities should be done in Bakers and not BakingSystems, I have gotten either errors, warnings or silent failure trying to do so in systems.

Creating blob assets can definitely be done in bakers(there's a test of such in their test coverage) and doing so appears to "register" the blob with the baker.

from TestComponentWithBlobAssetAuthoring.cs

Code (CSharp):

1.        
2. using System;
3. using Unity.Collections;
4. using UnityEngine;
5.  
6. namespace Unity.Entities.Tests
7. {
8.     [AddComponentMenu("")]
9.     public class TestComponentWithBlobAssetAuthoring : MonoBehaviour
10.     {
11.         public int Version;
12.         public struct Component : IComponentData
13.         {
14.             public BlobAssetReference<int> BlobAssetRef;
15.         }
16.  
17.         class Baker : Baker<TestComponentWithBlobAssetAuthoring>
18.         {
19.             public override void Bake(TestComponentWithBlobAssetAuthoring authoring)
20.             {
21.                 var builder = new BlobBuilder(Allocator.Temp);
22.                 builder.ConstructRoot<int>() = authoring.Version;
23.                 var blob = builder.CreateBlobAssetReference<int>(Allocator.Persistent);
24.  
25.                 AddBlobAsset(blob, out Hash128 hash);
26.  
27.                 AddComponent(new Component
28.                 {
29.                     BlobAssetRef = blob
30.                 });
31.                 builder.Dispose();
32.             }
33.         }
34.     }
35. }
36.  

 

Yeah I've used that pattern for about 4 simple blobs. Works well. My personal issue is then instantiating and setting up rendermeshs but thats another topci.

 

Actually I would also like to know what the pattern for rendermesh setup for a Baker(and not baking system) should look like

 

I'm still working through this and have yet to verify, but after reverse-engineering the physics code, I think these are the rules:
1) Bakers run only if something in their authoring component or a registered dependency has changed. Only bakers can register dependencies.
2) Baking systems run always (or check to run if you have query filtering).
3) Baking can run multiple times on the same world due to the "incremental" nature of it.
4) Baking systems see cached entities from previous bakes, including baking entities and BakingTypes, but not TemporaryBakingTypes.
4) If you have BakerA and BakerB, then the following three scenarios have to result in the same set of entities with the same set of components, including baking entities and BakingTypes but not TemporaryBakingTypes. Entity IDs and order in chunks don't seem to matter as much (though I have no idea where chunk components fall into the picture).

A) BakerA and all baking systems run in the first bake pass. Then BakerB and all baking systems run in the second bake pass
B) BakerB and all baking systems run in the first bake pass. Then BakerA and all baking systems run in the second bake pass
C) BakerA and BakerB run together in a single bake pass along with all baking systems.​

5) You need to dispose unused blobs, but because blobs are deduplicated, that requires ref counts which requires knowing when a previous bake pass generated a specific blob for a specific use case that is no longer in use in a subsequent bake pass.

(5) has been the thing I've been trying to make sense of. It seems you need an exact 1-1 correspondence between an authoring component/baker pair and the generated blobs produced in order to incrementally track changes. If you build your blobs using bakers, this happens automatically. If you want to build your blobs in baking systems, then you have to capture the request from a specific baker/authoring pair, then use the authoring component's instanceID as the UnityObject association for generated blobs using BlobAssetComputationContext. Such strict association seems critical to make incremental baking work correctly, or else you suffer memory leaks.

In 0.50, I built an abstraction around BlobAssetComputationContext which I called Smart Blobbers which handled a lot of the API's awkward index tracking nonsense. I'm working on a Smart Blobbers 2.0 that operate very differently but still abstract away the BlobAssetComputationContext. I have all the code written for it. I'm currently porting my old Smart Blobbers my project requires to the new design. And then I will test and debug. Hopefully it works.

Remind me to update you all on this as well as rendermesh setup when I get around to that.

And if anyone who knows more about the system than me cares to answer, here's some lingering questions I have:
1) Is my theory correct?
2) How does World.UpdateAllocator factor into baking systems?
3) Does it make sense to cache baking system setup (like type handles and such) inside of OnCreate()?
4) How do chunk components play in? Those seem like they would cause diff conflicts all the time because the order of entities will be constantly changing.

I hope this helps!

 

I believe that this point needs to be corrected, as it can be confusing for people, as it feels (by how it's written right now) that

TemporaryBakingTypes

never appear in

Baking Systems

, it's valid if we speaking about seeing previous bake pass

TemporaryBakingTypes

, but in current pass

Baking Systems

see entities with

TemporaryBakingTypes

as any other if they've been added explicitly by

Baker

.

You can see

BakingStripSystem

which is responsible for stripping them:


And this system runs

after

Baking Systems

(specifically after systems in

BakingSystemGroup

and

PostBakingSystemGroup

in this method, but of course

PreBakingSystemGroup

also runs before in method above in call hierarchy) as you can see in

BakingUtility

in

PostProcessBaking

:


Btw tests cover exactly this, that

TemporaryBakingType

alive in

BakingSystem

(just search

ChildrenTestComponent

):




Or you can look at

MeshRendererBaking

which is also process

TemporaryBakingType

MeshRendererBakingData

in

BakingSystem

 

I tried to clarify that in the scenarios themselves. But you are right. I was referring to the persistence of changes in separate baking passes, focusing on the incremental behavior. [TemporaryBakingType]s are indeed seen by baking systems. In fact, that's kind of the whole point of them. It was never my intention to suggest the contrary.

 

Tahnk you for that ChildrenTestComponent exemple. It ocnfirms me that the

Code (CSharp):

1.     [WorldSystemFilter(WorldSystemFilterFlags.BakingSystem)]
2.         partial class BakingOnlyPrimaryChildrenTestBakingSystem : SystemBase

is not there to replace the

Code (CSharp):

1.         class Baker : Baker<BakingOnlyPrimaryChildrenTestAuthoring>
2.         {

but complements it allow for additionnal operations that are not possible inside the baker itself.

Not sure what scenario could need it but I guess I'll figure it out when I run into a road block with bakers.