Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Few new-to-DOTS questions:

Discussion in 'Entity Component System' started by Shablo5, Jul 9, 2019.

  1. Shablo5

    Shablo5

    Joined:
    Mar 2, 2015
    Posts:
    40
    Played around with the HelloCube sample project. Says Entity instantiation/destruction can't be run on worker threads due to race conditions. I feel like the talks at the past few UNITEs talked about this whole new workflow preventing race conditions? Are Entities just so fast to instantiate or destroy (talking hundreds of thousands here) that you'll never need to parallelize them? God I wish that was a word, parallelize.

    Second question, is IConvertGameObjectToEntity and all the boilerplate shenanigans that come with it temporary? Even in the HelloCube sample or the boids sample it's all game object/prefab conversions to entities for what seems to be rendering. Is converting GO to Entity going to be more streamlined in the future?
    Also, is this the fastest way to render 3d entities, or will it be faster to ditch game objects/prefabs entirely and do everything relating to meshes or vertices manually in ECS? Whether or not you can do this yet (i'm not sure if you can do 3d rendering completely in ECS yet?)

    If there's no downside to converting from prefab/GO to Entities in terms of performance, then does that mean I can keep most of my pre existing unity knowledge/workflow and only use pure ECS/DOTS in very small areas, and just use ConvertGameObjectToEntity in all the others and wham bam im done? That simple?

    I'm sure i'm misunderstanding a lot, but these are my questions after working with the sample project HelloCube. Thanks for reading!
     
  2. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    4,222
    To answer the first question, Unity telling you that you can't do something because it is a race condition is how the new workflow prevents the race condition from occurring. Worker threads iterate over entities based on the components attached, so changing what components are attached to an entity or adding and removing an entity during one of those worker thread iterations is a race condition.

    If you have enough entities where you need to instantiate stuff on multiple threads, you use multiple worlds and ExclusiveEntityTransaction.

    GameObjectConversion is not temporary. I suspect they are working on a simpler approach to make default ICGO2E classes as an attribute for when that's all people need. But having separate authoring and runtime representations is super useful. Monobehaviours have always had quick and dirty methods to customize the inspector but that used to be a bad idea is it mixed authoring and runtime logic. Now I can take advantage of that freely and make massive Editor-heavy Monobehaviours that set up dozens of smaller components. It's an improvement.

    GameObjectConversion process results can be baked into subscenes at build time, so at runtime the game loads pure entities and can blast through huge amounts of data efficiently. It also converts GameObject Prefabs to Entity Prefabs so the prefab concept exists in ECS as well. You can't modify meshes and vertices in a job-friendly way yet. There's newer API coming in 2019.3. You can also use compute buffers for most dynamic mesh use cases which are pretty job-friendly.

    You have to convert game logic to ECS by yourself, but authoring (doing stuff in the editor and inspector) doesn't change much.
     
  3. Shablo5

    Shablo5

    Joined:
    Mar 2, 2015
    Posts:
    40
    I have no experience with compute buffers, but I believe i've read multiple times that they're slow, but jobifying the code using them would speed them up?

    "Monobehaviours have always had quick and dirty methods to customize the inspector but that used to be a bad idea is it mixed authoring and runtime logic. Now I can take advantage of that freely and make massive Editor-heavy Monobehaviours that set up dozens of smaller components. It's an improvement."

    Can you give me a bit more of an explanation on this, or perhaps an example of old vs new regarding this? I think it just went over my head unfortunately, i'm not sure how it relates to my question.

    I think I misunderstood GO -> E conversions, thinking it converts logic too, but from what I understand from you, the conversion is just in terms of the editor/inspector/etc? So you can use the old editor workflow, build everything you want in gameobjects and unity components, and bake them as entities? But why is that useful? Maybe i need that example above.

    Also, hybrid renderer, not usable for meshes? Have to wait til 2019.3?
     
  4. thelebaron

    thelebaron

    Joined:
    Jun 2, 2013
    Posts:
    851
    Logic doesnt get converted, you write your dots logic code in either ComponentSystems or JobComponentSystems. The GO->E workflow exists so you can mix and match what you want from the monobehaviour way with the DOTS way, as a ton of things currently don't exist in dots land yet. Conversion also exists so you can use established workflows like prefabs and editor placement using gameobjects as placeholders* for what eventually gets turned into an entity at runtime, as dots editor support only exists for Tiny mode at the moment.

    *Or hybrid entities, combining both Entity Components and old Monobehaviour Components
     
  5. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    4,222
    GO->E workflow exists because the GameObject authoring workflow is rock-solid and being able to convert GameObjects into lightweight entities in the Editor and pack them into subscenes gives the best of both GameObjects and Entities.

    Monobehaviours have attributes like [Header], [Space] [Tooltip] ect as well as callback functions like OnValidate and OnDrawGizmos. These make the simple inspector layouts easy, and now we can add additional variables to these authoring Monobehaviours to help with authoring that won't be a part of the runtime data. One authoring Monobehaviour can add dozens of small IComponentDatas to the converted entity. There's not really an old versus new for this, just a "this is a bad idea" is now a "this is a good idea" because the critical game logic moved somewhere else.
     
  6. Shablo5

    Shablo5

    Joined:
    Mar 2, 2015
    Posts:
    40
    Could you possibly show me one of these monobehaviors / gameobjects in your inspector, as well as the script accompanying it?

    I believe I get the jist of it, what i don't understand is what you see in your inspector when you click on the gameobject holding the monobehavior. Because to me it sounds like there would be nothing there, since you can't use the old style of components. But would there be a transform since every GO as a transform? Again, just confused on the particulars, and a screenshot if you have one would certainly help.

    Thanks.
     
  7. tertle

    tertle

    Joined:
    Jan 25, 2011
    Posts:
    3,753
    There's 2 way to convert game objects.

    - Convert and Destroy
    Once gameobject is converted to entity it is destroyed and to inspect it you'd need to use the entity debugger.

    An example I can quickly pull out

    upload_2019-7-11_14-20-5.png

    This will be converted to a pure entity. I have 2 custom IConvertGameObjectToEntity monobehaviours attached which will add custom components. It also has the new Unity.Physics components. The gameobject will be destroyed as soon as the scene is played.

    - Convert and Inject
    Once gameobject is converted, the original game object is kept and the transform is injected into entity. This way you can still use classical monobehaviours and components, such as camera etc.

    upload_2019-7-11_14-20-55.png

    However for example, maybe I want my camera to also be an entity but there is no support for a camera component yet, so you can keep the game object around but I can still find and manipulate the entity in systems. Since the transform is injected you can get access to the gameobject and use it like you previously could.

    I could still have a regular monobehaviour on this game object that will still work.