Official DOTS development status and next milestones – June 2022

What I meant about serialization is that not all serialization formats are deterministic, JSON serialization for example.

Also, my understanding is the old conversion systems did not even use burst. So any math you did in them was non-deterministic.

 

It doesn't care about the authoring type. Just the inputs for blob generation.

More or less. It gets executed inside the Execute method of an IJobFor job.

For the "simple" version of Smart Blobber, yes. The advanced version also allows for deduplicating inputs, which gets used for meshes and audio sources.

Yes. Blobs are ready before the main IConvertGameObjectToEntity callbacks happen. Though I could have made a custom callback later in conversion to do the main thing.

That's the issue. Whatever requests the blob asset has the context of where that asset goes. If I have to split the request and post-process into two separate objects, then I have to transfer that context somehow. I want to make it easy to transfer that context with as little boilerplate as possible (or make the transfer unnecessary) because I expose the "Smart Blobbers" as public API for a library and I want that library to be easy to use.

The other option is to not have parallelism or input deduplication, but that would drastically increase baking times and be the opposite of "performance by default".

 

As I see this thread is very active recently, I've to ask, what about other stuff you can tell us will be in 1.0?
Personally I'm not too excited about the Baker or Aspects. Great features to have, don't get me wrong, it's just talked about a bit too much and now I'm thinking is 1.0 everything about authoring and aspects?

So, maybe can you talk about other improvements outside of Bakers, Aspects and Enabled/Disabled comps that you are most excited about?

Some more specific questions I have:
- how is the enabled/disabled comps going? will it hit for 1.0? (also something I'm not too interested in but I still want to know)
- core performance improvements?
- SystemBase performance improvements?
- burstable ECBS for usage in ISystem
- will CreateEntityQuery be burstable in ISystem?
- Will NativeContainer be finally usable in ISystem?
- Have NativeContainers seen the rewrite yet?
- Did any NativeContainers improve in performance? Some are, not great, for parallel processing and kind of a pitfall unless you know.

 

Have a read through this. https://github.com/Unity-Technologi...d7bf2806af04fc9fa31dc52535/Ported/combat-bees The answer is "yes" to most if not all of your questions.

 

For this 1.0 Baker I still have question to ask. I want baker code to available at editor only. Does Baker now able to create editor only assembly definition without getting any compile error at baker authoring monobehavior? At 0.51, u will get this issue especially when u are using editor only API and u need to set assembly definition back to include all platforms to fix it. It seems like after u try to use git to quickly switch to a commit then after that u will see authoring monobehavior script has warning saying compile error and reimport the folder that has related authoring code and assembly definition can't fix it.

 

So will IConvertGameObjectToEntity be auto-converted to use the Baker API, be deprecated with an expiration date, or outright removed in 1.0?

 

@bogdancoder 1) Another question I would like to ask. Is that 1.0 release not longer able to use GameConversionSystem to do advanced authoring? If yes, what is the equivalent API to do the same thing at Baker?

2) What's the API changes for blob asset authoring conversation from 0.51 to 1.0 Baker? Is that become much more easier to do it?

 

Will DOTS 1.0 fix the performance issue (scheduling issue?) with LocalToParentSystem.UpdateHierarchy?
https://forum.unity.com/threads/sou...tsystem-updatehierarchy.1175111/#post-8385831

 

I want to thank you for listening to me and being involved in this discussion. I've felt conversion/baking has been underrepresented in these forums. And while the simple and common use cases are fairly straightforward, I've always felt the APIs fall apart with increase complexity that requires rapid iteration.

Actually, that's just because under the hood Smart Blobbers use BlobAssetComputationContext API, and that API requires GameObject references. What do the GameObjects get used for? Not sure. I don't think it works as intended though, because the BlobAssetStore seemingly gets dropped on the floor between conversions.

The actual code flow for Smart Blobbers is as follows:
1) Early setup callbacks
2) Setup filtering
3) Invoke filter function
4) Remove filtered out instances and in the case of the batching variant, remap duplicates
5) In the case of batching API, invoke post-filtering callbacks
6) Run parallel build blobs job
7) Extract hashes from blobs and feed them into BlobAssetComputationContext. Note: At this point the BlobAssetComputationContext API assumes that I have hashes but haven't actually built the blobs yet. So rather than use the API to find out which blobs I need to build, I use the API to find out which blobs I need to keep.
8) Dispose unused blobs and fulfill handles

What you describe is what I think BlobAssetStore.AddUniqueBlobAsset() did, which was not scalable.

There are three issues in what you describe that my solution solves.

First, I differentiate between pre-generation input deduplication and post-generation blob deduplication. Pre-generation is like a Physics broadphase algorithm. It is course-grained, sometimes produces false positives, and is cheap. Instead of trying to compute a deterministic identifying hash which is often just as expensive as computing the blob asset itself, it simply has to look at all the inputs passed into conversion and identify which ones are guaranteed to generate the same blob asset. That means nondeterministic inputs like UnityEngine.Object.GetInstanceID() are viable. The Filter function in the Triangle Soup example shows exactly this. GetInstanceID() is never seen by BlobAssetComputationContext. Only the truly deterministic hash generated from the blob asset itself makes it to BlobAssetComputationContext.

Effectively, this is an optimization that comes from batch reasoning. Bakers don't appear to have any batch reasoning capability. Plus, a baker is locked into a single type of authoring component while my solution allows many different authoring components to request the same type of blob asset. That's my second issue with the Baker design.

Yeah. That's actually the crux of my third issue with the Baker design. Generating a single blob asset in parallel is most of the time not practical. However, generating multiple blob assets in parallel to each other is practical. That only works if I can gather all the blob asset requests for a specific blob type and batch-reason about them. It also opens the door for other optimizations, such as using one large MeshDataArray instead of many individual instances, which you can see in the Triangle Soup example's PostFilter() method. Again, the lack of batch reasoning is removing massive optimization potential.

I hope my assumptions are wrong about bakers, but as I see it now, I'm mentally preparing for a significant regression in blob asset generation.

 

How will companion gameobjects workflow change in 1.0?

Will they be internally pooled or will instantiate/destroying an entity with a companion gameobject also result in GameObject.Instantiate/Destroy(and the resulting gc from such an operation)?

Also which api's in 1.0 will specifically not have a api updater from .51 and will need to be manually updated ourselves?

 

Oh wait. Since both GameConversionSystems and ConvertToEntity component are being removed, does it means there's no way to do runtime conversion at player runtime build even u create a baking system for further processing? So 1.0 baker now become editor only authoring tooling? Or u still can write both GameConversionSystems and ConvertToEntity component equivalent yourself for runtime purpose that they are removed to avoid promoting bad practice for ConvertToEntity component?

Are there any breaking changes for EntityManager related APIs in 1.0 to do something outside of Systembase/ISystem? General use case like query required entity and then add/remove/update component to entity to specific world i.e. client/server world at MonoBehaviour.

 

Hi everyone, there is a new release for ECS, more details over here!