Official New SubScene & ConvertToEntity workflows

@Quantum1000 Does is also separate women and girls?

All this separation......Why?....

 

Bear with me on the phrasing of this question -
With entity conversion/prefab referencing is it an issue that prefabs seem to be, for lack of a better term, "unique" when there are multiple of the same type, originating from multiple entities that also pretty much the same?

Example: I have a "Door" entity, that can be destroyed. Stored on it is a buffer of five "Destroyed door entity prefabs". But if I make a duplicate of that Door entity, for its own buffer are five different(but same) Destroyed door entity prefabs.


How do I go about making it so that I'm not just needlessly creating extra entities for something like this? This situation isn't such a big deal for one off objects, but if say I wanted every part of the game to feature destruction like this wouldn't it be inefficient to have this kind of a situation?

 

It's not that I try to troll you, that was the pure question. There was no solid line to separate between it inherently both in prefab and subscene or in man and boy so we should have put more thought about use case scenario and definition

 

This is somewhat of a complex question. I'll have to find some time to put together a test, but my suspicion is that if you have multiple GameObjects in your scene each at the root of the scene being converted to an entity there will be duplicate prefab entities created.

If my assumption is correct putting the doors as a child of an object in your scene and having them all convert as part of the same hierarchy should yield non-duplicate prefab entities. It's a bit of a hacky solution to be honest, but that said if you then convert that to a subscene that can be loaded you'll gain a little in startup time.

 

SubScenes can be preconverted to ECS representation so you never need to load the GameObject representation at runtime. These SubScene ECS forms can be streamed in very efficiently at runtime. Prefabs are stored as GameObjects inside of bundles (and also stored in the Scene iirc). You can convert a GameObject prefab to an ECS prefab but this happens at runtime.

 

I've had a very annoying problem with upgrading due to changes in the conversion workflow, going from version:

Editor: 2019.3.0a8 -> 2019.3.0b3
Entities: preview33 0.0.12 -> 0.1.1

TLDR: the order that ConvertGameObjectToEntitySystem loops through entities changed (probably reversed). For me in 0.1.1 this caused a parent conversion to be processed before its declared dependencies.

If the parent relies on certain components/buffers existing in the child or a certain archetype created in its Convert() method, then you'll get an exception doing a 'SetComponent<Expected>' because the children's IConvertGameObjectToEntity calls haven't been made yet.

I'm not sure yet if that is because of the order they are added changing, of its due to Entities.ForEach going from chunk based iteration to ToEntityArray(). But I had to step through the conversion system on both versions to nail down what was happening

My setup is:

1) An AddressableAsset prefab called 'Levels' is instantiated at runtime, which starts the conversion process (ConvertToEntity + Monobehavior with IDeclareReferencedPrefabs & IConvertGameObjectToEntity).

2) 'Levels' holds references to other addressable prefabs (the game elements to be used in different levels), which are declared in DeclareReferencedPrefabs() and then in Convert() are added to a DynamicBuffer using GetPrimaryEntity().

In the loading phase before instantiating 'Levels' kicks off the process, I know that all the addressable assets needed will need have been downloaded (but not instantiated), so that's probably not an issue here.

The conversion process is

• Gather all components on the GameObject
• Gather all referenced prefabs
  
• Create all the entities.
• Call Convert() on everything.

It's entirely possible that it worked before only because of luck in transform order. But ideally, it could be reliable where Convert() is called on dependencies before whatever declared them as a dependency.

 

The new conversion workflow outlined in this Unite talk from yesterday is looking really nice I must say! Also great to have a good example of using blob assets.

 

How long until convertion to ECS is implicitly done at (or for) runtime without any effort from the creator's part?

 

This is a very helpful video, thanks for linking it! Unfortunately it looks like there's still no answer to the thing I've been struggling with. The question of: "how do you instantiate Convert-and-inject-game-object prefabs without that conversion world overhead during runtime?" seems to still be unanswered as far as I can tell. You can't use the declare referenced prefabs flow as you only get the Entity. If the GameObjectConversionSystem offered a way to get a version of the GameObject that was basically just the stuff that is getting "thrown away" at least then I could store that somewhere to be associated with the entity so that I could spawn that at the same time I spawn the Entity prefab later on. (EDIT: Actually thinking some more about it, I could probably simply strip out the ConvertToEntity monobehaviour from the GameObject after conversion and use that... . I'll have to give that a try)

 

@diesoftgames I've thought a bit about your problem and I might have a solution, but it's likely going to require some indirection. Instead of using the convert-and-inject-game-object workflow you can try converting to a pure entity, but when instantiating the prefab go and construct the GameObject and attach it to the constructed entity. This way the entity conversion shouldn't be happening every time and you'll be able to still use a game-object. I am however uncertain what your use-case is, because if you're expecting to have a reference to the GameObject after it's been constructed there'll be some extra work to do to ensure that you can grab that as needed.

 

I will need the GameObject because I need access to the things that aren't ECS friendly which get trashed (Animator, Sprite, Audio, Collider2D, maybe one or two others that I use in some prefabs). That's why I wanna see if I can: in the Convert method take the GameObject Prefab reference and strip it of any MonoBehaviours that are IConvertGameObjectToEntity, then attach that GameObject Prefab to the Entity using SCD. So then whenever I spawn the Entity Prefab, I would grab that GameObject Prefab SCD and use it to instantiate a GameObject and that associate any relevant legacy components with the Entity using SCD.
Once I get a chance to give that a go I'll report back in how that goes.

 

This is where I start to question the point of this workflow at all. Would it be possible (and easier?) to simply have two prefabs, ECS and non? Seems you have to manually link those two worlds no matter what you do.

 

I think I'd be doing the same linking in both cases though no? I think I'd only be saving myself the step of manually stripping out conversion components from the GameObject, but a) that would happen at conversion time so no performance overhead and b) it would prevent me from accidentally getting the "two sides" of the prefab out of sync somehow since they'd be happening in the same GameObject authoring space.

 

I hope it's okay if I ask here. Any ETA on Inspector tooling and entity serialization in editor like Project Tiny? I hoped to hear something about that in Unite videos, but didn't hear a word. After all, conversion is a pretty awkward system compared to how things will work.

 

much extra work on the coders side to use this, I hope this does not double development time in the end...

 

@Joachim_Ante - would it be possible to hook into the GenerateAuthoringComponent pipeline (or have the tools exposed to make our own similar Attribute) to make custom modifications for components that implement custom interfaces or for concrete generic components?

I have some things that generate pre-loading wrappers for custom configuration singletons, being able to massage them a bit or use my own wrapper MonoBehavior (assuming one gets generated) would be useful.

 

can it handle cases where the referenced entity must have a specific component / match a query?
e.g. what you can do in MB with

public Rigidbody target; // instead of GameObject

also assert that the reference should be or not be a prefab

 

My first thought when watching that presentation was that unit conversions are fairly simple things. It feels awkward that you need to implement the conversion behavior for the entire component if you just want to convert degrees to radians on one field.

It would be nice if you could annotate fields on the component with something like:

Code (CSharp):

1. [GenerateAuthoringComponent]
2. struct MyComponent {
3.     [FieldConverter(typeof(RadiansToDegreesConverter), "optional name to show in the inspector")] float angle;
4. }

Where CustomConverter is:

Code (CSharp):

1.  
2.    interface IFieldConverter<T1, T2> {
3.       T2 ConvertAuthoringToRuntime(T1 authoringValue);
4.    }
5.    struct DegreesToRadiansConverter : IFieldConverter<float, float> {
6.       public float ConvertAuthoringToRuntime(float authoringValue) {
7.          return math.radians(authoringValue);
8.       }
9.    }
10.  

But I think things like DegreesToRadians and FrequencyToPeriod are common enough conversions that they can be included in-box as well. I haven't really thought this through all the way, but it seems feasible.

 

why does the SRP Batcher in URP not compatible with Subscenes only for Mobile devices ?
it's killing my FPS

 

I'm not sure if the feature exists, but I have been looking for a way to tag GameObjects in a SubScene to not be included when the SubScene is converted to it's entity representation. It would be really helpful to just throw on a "DontConvert" MonoBehaviour onto a GameObject in the scene, and it would in turn then not become converted into the entity format and neither would it's child hierarchy.

As an example, I'm building up a bunch of subscenes to randomize between during gameplay, so I don't want to have them added in the actual main scene in the editor. The way I would like to do it is to open the subscene as a Scene (which is possible) and just work inside that scene. I'll have a bunch of people working simultaneously on different subscenes, so it's really beneficial if each person could work exclusively in their own scene. While in this scene we want to add some ambient lights and potential other GameObjects to simulate the lights that would be instansiated during gameplay, but we don't want to build these lights with the scene, they're only in the scene to assist with the editing.

 

AFAIK SubScene is highly tied to the DOTS conversion system and there is not way to use GameObjects and MonoBehaviours at run-time with it. What you want can be easily achieved using additive loaded scenes instead of SubScenes (which will have the same result in the end of the day).

 

Apologies for not being clear enough. I'm not intending to use any GameObjects in the Subscene during runtime at all. These are purely during editing in the Unity Editor while having the Scene asset open. In the example with the lights, the SubScene is completely dark when editing without having added some lights to it. We're also adding some other GameObjects to the scene that are purely there for editing purposes. But I don't want to build these lights or editor objects into the entity representation. The lights are instansiated during gameplay via other ways.

The "DontConvert" MonoBehaviour I mentioned was meant to just be used as a tag behaviour for the Conversion, to inform the conversion that the tagged object hierarchy shouldn't be converted. Just like the already existing "StaticOptimizeEntity" MonoBehaviour.

 

OH, I see, sorry for the misunderstood, this surely is some nice addition to have, thanks for the explanation.

 

Hello,

I love the fact that you work on simplicity of use to avoid us writting boillerplate code for every components.

I however don't like the fact that I have to add indivual authoring component to a game object and have to have the knowladeg of what component are requiered for the entity to behave a certain way. It's ok for a developper but as a disigner, I would be confused.

So I came up with the following workflow :
- Fore each data type I have an authoring component (the result of the [GenerateAuthoringComponent] intriduced at unite) (for instance Health or AutoAttack)
- Then for each system, I create a custom authoring component with the necessary [RequireComponent()] with the authoring composent type that represent the IComponentData used by the system.
- Then I have even higer level authoring component that reference the "system" authoring components in the [RequireComponent()]

For an ebtity that can take damage and autoattack, I have something like that :
- Simple Components :
- HealthAuthoring (represent the current health value),
- DamageReceiveAuthoring (a buffer that represent the damage taken by the entity at this tick)
- AutoAttackAuthoring (repsrenet the auto attack parameter, range, interval,...)
- "System" components :
- CanAutoAttack (just require the AutoAttackAuthoring )
- CanTakeDamage (require HealthAuthoring and DamageReceiveAuthoring
- High level :
- DefenseTower (require CanAutoAttack and CanTakeDamage )

This allow me to define behaviours from the editor without the risk to miss a component data or having duplicates because it adds everything it need automaticaly.

It look like that :

Spoiler: Inspector

As you can see the issue is I have many components on my game behaviour and my data is widly split accros the inspector...

I could hide my "system" authoring components but on a dising perspective I would rather know chat the game object can do than know it has a health component.

So I went the other way around. I hide the base components and created a new Authoring Component Inspector to edit all those data components.

It look like this :

Spoiler: Authoring Component Inspector

Has you can see it's much cleaner than the classic inspector. Components are sorted by names and the data is synchronized with the authoring components. So if you left the component in the other inspector it'll always have the correct data.

Has for the classic inspector if you hide all the component data it's also much cleaner :

Spoiler: Cleaned Up Inspector

You can also stack the two windos if you want to have a clear picture of everything :

Spoiler: Stacked view

If you are interested in that workflow, let me know, I'Il put up a simple repository with all the source to share it.

EDIT : It's work in progress and there are some issues with that , espaecialy if you hide the data components, when removing higher level authoring component don't remove the base data component they brought in leavin garbage behind...

 

Unity dots 1.0 is planning to be released in 2020.1.
Will it support 2d renderers 2d animation and shader graph and also autoconversion of those systems?
If not then when is 2d support in DOTS is planed?

 

For those interested or curious, I solved the issue I could think of and put up a repo with 3 scenes :
https://github.com/WAYNGROUP/AutoringWorkflowDemo

ConversionWorkflowWithGeneratedAuthoring
Just adding component data one by one having no clue of the underlaying systems
Pros

• great granualarity
• not duplicate components

Cons

• data component don't provide any hint to the underlaying systems

ConversionWorkflowWithCustomAuthoring
Having some sort of correspondance between the custom authoring component and the system. Also to show the issue with custom authoring component that work with overlaping data component (Health in this case)
Pros

• Custom authoring components give hint to the underlaying systems and what can be expected in term of behaviour

Cons

• Requiere lots of additional coding.
• Introduce the posibility to have duplicate data components.

ConversionWorkflowWithRequireAuthoring
Using simple monobehaviour in conjonction with the Require attribute to define behaviour based on the underlaying systems.
Pros

• Custom authoring components give hint to the underlaying systems and what can be expected in term of behaviour
• Very little coding requiered (just teh system itself and a simple monobehaviour)
• the Require attribute take care of avoiding duplicate component data

Cons

• Add aditional components to the game object
• Can be hard to clean up gameobject as inspector don't remove unecessary data component when removing hte Custom authoring ones.

Solution to Cons:

• Open the Windows > AuthoringComponentInspector :
  • this will provide a list of all data component with editable properties (synch with the calsic inspector)
  • The AuthoringComponentInspector has a button to synchronize the authoring components of the game object with this inspector. It take into account newly added data component, removing the non required data component from the game object itself and add missing one if and exisitng custom authoring component was updated.
  • The sync can be made automatic, just edit the script Editor > AuthoringComponentInspector to set autoSync = true.
  • To clean the calssic inspector, you can HideInInspector the generated data components

 

Here's how I did it:

Code (CSharp):

1.  
2. public class ExcludeFromConversionAuthoring : MonoBehaviour, IConvertGameObjectToEntity
3.     {
4.         public void Convert(Entity entity, EntityManager dstManager, GameObjectConversionSystem conversionSystem)
5.         {
6.             dstManager.AddComponent<ExcludeFromConversion>(entity);
7.         }
8.     }
9.  
10. public struct ExcludeFromConversion : IComponentData { }
11.  
12. [UpdateInGroup(typeof(GameObjectAfterConversionGroup))]
13. public class ExcludeFromConversionSystem : GameObjectConversionSystem
14.     {
15.         protected override void OnUpdate()
16.         {
17.             EntityQuery entityQuery = this.DstEntityManager.CreateEntityQuery(ComponentType.ReadOnly<ExcludeFromConversion>());
18.             this.DstEntityManager.DestroyEntity(entityQuery);
19.         }
20.     }
21.  

 

I created a specific thread in WIP to follow this "project"
https://forum.unity.com/threads/requirement-based-conversion-workflow.756308/

 

FYI - None of the links in the OP work anymore

 

DefaultWorldInitialization.GetAllSystems needs a cache. The overhead it causes for creating conversion worlds is out of hand. I'm spending 77% of EnterPlayMode time here.

 

I dont suppose anyone knows how I get the GameObjectConversionSystem to run. Like where I put it or what I do with it because I'm trying to copy this project and it doesn't seem to work at all.

https://github.com/Unity-Technologies/unite2019-scenedatatodots

 

Maybe its necessary to have a subscene. So it gets called when the subscene is saved/converted

 

Yeah I have a subscene, I posted a new thread because I'm confused as hell with how these subscenes work.

https://forum.unity.com/threads/can...roject-to-work-in-my-own.770630/#post-5131424

 

When is next release ?

 

time to update your post, Joachim

 

Hello, first time poster here!

My game uses a multi-scene streaming system that implements a large world (64 scene tiles of 1sqkm each). I'm investigating using the SubScene functionality within each of these scenes, and have started by converting the trees in one of them. In scene view everything works, however at run-time I move the origin of the loaded scene objects to create a grid system (which then is moved around the player as they run around).

My problem is that the SubScene doesn't inherit any parent transform (which I can understand) but there doesn't seem to be any way to manipulate the position of the SubScene object during run-time - it is just fixed to 0,0,0.

Is this something that can be done with SubScenes, and is it planned if not currently supported? If (as mentioned by someone above) the plan is to have a single fixed scene origin that you load SubScenes into (so never changing origin position) then I can abandon this and move on to a different solution!

 

World-moves-around-player is not a natural concept in Unity, so you will instead want to write an IJobForEach that updates the position of each entity in the subscenes. Or you can have a parent Entity in each subscene with a tag component, and use that to update the positions of everything, though this approach will be a fair bit slower than updating the position of the entities directly as it does a lot of random access writes. You could also have a handle entity that each entity in a subscene references and use that to update positions.

I guess what I am saying is that while the solution doesn't exist out-of-the-box, DOTS and subscenes are still probably going to be the easiest and most performant solution for your use case.

Start a new thread if you get stuck!

 

Thank you very much for those ideas - I hadn't come across the tag component. I understand what you are suggesting. I'll do some prototyping and see what approach gives the best performance for my volume of entities!

 

One thing to watch out for is objects that are marked as static in the scene. My understanding is that the conversion system will optimize those and only build a `LocalToWorld` for that entity. If you then move the root scene around those items won't be moved with the others. It's a performance optimization that allows the Transform systems to essentially skip it because there is no potential for a parent transform to update the current one.

https://docs.unity3d.com/Packages/com.unity.entities@0.1/manual/transform_system.html the documentation here does have some information, specifically Section 3: Default Conversion (Basic).

 

I've realized the SceneManager.LoadScene doesn't destroy entities that were created from GameObjects with ConvertToEntity in the scene being unloaded. Is there a recommended pattern for this?

 

You can create a MonoBehaviour that destroys the Entity in OnDestroy for that.

 

Hi all!

I'm new here. I have a question regarding the conversion workflow. I have scanned the forum and believe this is the right place to post this question, correct me if I'm wrong.

Short version: why does the subscene persist IComponentData and not ISystemStateComponentData?

Long version:
I have a bunch of systems (called CachedSystems) that detects entity addition and removal by using ISystemStateComponentData, do some heavy computation to cache some info. It's fast enough for realtime adding of a few entities per-frame (which happens during gameplay), but not fast enough for millions of entities (which happens during loading subscenes). Therefore, to speed up loading of a subscene, I write a GameObjectConversionSystem to loop through these CachedSystems during Rebuild Entity Cache. It works, but all ISystemStateComponentData are not persisted. They are persisted the moment I convert them to IComponentData, but I lose the ability to detect entity removal! Is there a solution for my scenario?

Thank you for reading!

 

Here is the new link of the HelloCube project that holds all the samples linked in the first post: https://github.com/Unity-Technologi...mples/tree/master/ECSSamples/Assets/HelloCube

 

They are explicitly removed. I believe the explanation I read somewhere was that the data is supposed to be for a specific component system?

Is there a reason you cannot use for example a dynamic buffer to store that data? Or you could store it in a singleton entity?

 

is there any estimate when this thing will land?

 

May be it is already
https://docs.unity3d.com/Packages/com.unity.entities@0.2/manual/index.html

Actually have not looked inside yet

 

it's not, unless it's super well hidden. I played around with new 0.2 packages and couldn't figure any way to active such mode which lead me here asking if there's an estimate for it coming out.

I also did expect it to be on this round of releases, hence the confusion.

edit: it's now in com.unity.dots.editor package