Baker Vs Baking systems

Unity Engine
, ,
1

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 ??

2

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

3

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.

1 Like
4

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

using System;
using Unity.Collections;
using UnityEngine;

namespace Unity.Entities.Tests
{
    [AddComponentMenu("")]
    public class TestComponentWithBlobAssetAuthoring : MonoBehaviour
    {
        public int Version;
        public struct Component : IComponentData
        {
            public BlobAssetReference<int> BlobAssetRef;
        }

        class Baker : Baker<TestComponentWithBlobAssetAuthoring>
        {
            public override void Bake(TestComponentWithBlobAssetAuthoring authoring)
            {
                var builder = new BlobBuilder(Allocator.Temp);
                builder.ConstructRoot<int>() = authoring.Version;
                var blob = builder.CreateBlobAssetReference<int>(Allocator.Persistent);

                AddBlobAsset(blob, out Hash128 hash);

                AddComponent(new Component
                {
                    BlobAssetRef = blob
                });
                builder.Dispose();
            }
        }
    }
}
1 Like
5

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.

6

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

7

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.
  5. 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.
  6. 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!

6 Likes
8

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:
8485253--1128422--upload_2022-10-3_10-7-33.png

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:
8485253--1128425--upload_2022-10-3_10-11-37.png

Btw tests cover exactly this, that TemporaryBakingType alive in BakingSystem (just search ChildrenTestComponent):
8485253--1128428--upload_2022-10-3_10-12-56.png

8485253--1128431--upload_2022-10-3_10-13-27.png

Or you can look at MeshRendererBaking which is also process TemporaryBakingType MeshRendererBakingData in BakingSystem
8485253--1128440--upload_2022-10-3_10-16-36.png

2 Likes
9

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.

2 Likes
10

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

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

is not there to replace the

        class Baker : Baker<BakingOnlyPrimaryChildrenTestAuthoring>
        {

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.

1 Like