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

Official Experimental Entities 0.51 is Available

Discussion in 'Entity Component System' started by mfuad, May 13, 2022.

  1. mfuad

    mfuad

    Unity Technologies

    Joined:
    Jun 12, 2018
    Posts:
    334
    Hi everyone! A new experimental version of Entities and other ECS-based packages are now available, making them usable with both Unity 2020 LTS and Unity 2021 LTS.

    If you are just getting started, refer to our installation & setup guide. For those who will be upgrading from Entities 0.17 to Entities 0.51, we have put together an upgrade guide that includes common tips during that process.

    Minimum requirements:
    - Unity 2021.3.4+
    - Unity 2020.3.30+

    As a reminder: Experimental releases are not supported or recommended for production, but provide early access for those who want to try out ECS in their projects. This also helps us make progress on development through everyone’s feedback.

    What’s new
    The main update in this release is compatibility with both Unity 2020 LTS and Unity 2021 LTS. We have also fixed several issues since the Entities 0.50 release in March. For a full list of changes in each package, refer to the changelogs in our documentation (linked below):
    We have also updated the following packages, which are automatically included when installing the Entities package:
    Again, thank you to everyone who has taken the time to report issues since the Entities 0.50 release. A lot of the changes and fixes in this release were a direct result of your feedback, and we will continue to release patches with bug fixes as they get resolved.

    Known Issues
    IL2CPP requires the use of generic sharing to work when using Unity 2021 LTS. This can be enabled via Project Settings > Player > Configuration Section > IL2CPP Code Generation > Faster (smaller) builds. Depending on how generic types are used by your game, there will be an additional runtime cost in IL2CPP builds with generic sharing enabled. We are actively looking into this issue; please share any feedback you have to help guide our efforts towards addressing this.

    We will also follow up with those of you who have already reported issues. If you encounter a bug, please submit a bug via Help > Report a Bug in the Unity Editor. This will help ensure we have the information needed to properly investigate the issue.

    Notable Highlights
    For those who have been waiting for compatibility with Unity 2021 LTS, here is a recap of updates since the Entities 0.17 release.



    Entity Authoring
    • The Entity Debugger window has been replaced with several new windows that are now more embedded within the Editor:
      • Entities, Components, and Systems windows to search, select, and inspect via the Inspector
      • A Hierarchy window that shows the full Entities hierarchy and allows for selection of entities
      • Archetypes window to show all current archetypes and details for each
    • Two new Profiler modules to profile ECS structural changes and memory:
      • Entities Structural Changes profiler module can record which world/system produced a structural change, and how much time it cost per frame
      • Entities Memory profiler module can record which world/system allocates memory chunks, with additional details per archetype
    • Entities Journaling to record and explore ECS events, using static APIs and the IDE Watch window, and understand data lifecycles and debug your game
    • Note: The com.unity.dots.editor package has been merged with com.unity.entities
    System and Entities API Improvements
    • A new simplified
      SystemBase
      type that allows for implicit job scheduling and the ability to schedule jobs to run both sequentially and in parallel
    • Entities.WithFilter(NativeArray<Entity> entities)
      allows filtering
      Entities.ForEach
      so that it only iterates over a set of entities
    • New
      IJobEntity
      job interface, for implementing re-usable and burstable jobs that iterate over entities
    • The list of chunks matching an EntityQuery is now automatically cached internally, significantly improving the performance of most EntityQuery operations between structural changes (especially in titles with high empty archetype counts)
    Improved Debugging
    • Visibility into the generated C# code for inspection and debugging
    • The most commonly-used Entities types now have debugger type proxies, significantly improving the ease of inspecting their state during in-IDE debugging sessions
    • More debug functionality is available in standalone builds, including debug checks and per-Entity debug names
    Netcode Updates
    • Physics can be predicted, making it possible to build games where players are directly interacting with and affecting physics objects in the world.
    • Ghosts can switch between being interpolated and predicted at runtime. This allows a client to dynamically predict everything that is close or important without paying the cost of predicting everything.
    • Improved support for streaming sub-scenes and loading prefabs on demand across various client-server configurations.
    • Commands can be sent without explicitly setting the command target on the connection, enabling a client to control multiple ghosts. This also enables changing which ghost a client is controlling at runtime - for example when entering a vehicle.
    • The code-gen has changed to source-generators, making them more robust and less likely to go out of sync.
    Rendering Updates
    • Hybrid Renderer V2 (HRV2) is now the default option and replaces Hybrid Renderer V1 (HRV1), which has been removed. This ensures users are now supported with a GPU-persistent data model, removing the main thread bottleneck of HRV1, and improving render thread performance.
    • HVR2 also has a broader compatibility with a range of shaders, and equips users with previously missing HDRP and URP features.
    Unity Physics and Havok Updates
    • Collision and trigger events now share a common interface, and simulation systems have been refactored to allow multiple physics worlds.
    • Integration between Unity Physics and the Universal Render Pipeline (URP) has been improved, with new shaders in the sampler, and URP compliant materials.
    Sharing feedback
    As mentioned earlier, a lot of the changes in this experimental release are a direct result of shared feedback. This forum is the best place to open discussions and ask questions. If you encounter a bug, use the Unity Bug Reporter in the Unity Editor, accessible via Help > Report a Bug. Please include the name of the package (with version number) in the title to help our team triage things appropriately.

    We have also enjoyed seeing what the community has created so far. Continue sharing your projects in this thread!

    Looking ahead
    To learn more about what we are working on, you can refer to this post and our public roadmap where you can share feedback and submit ideas.

    Thank you again to everyone who has continued to take the time to share feedback. We look forward to hearing from you!
     
    Last edited: Jun 22, 2022
    Zypo, Clonkex, Micz84 and 20 others like this.
  2. Deleted User

    Deleted User

    Guest

    I just want to say: Thank You! You're heading Right with your communication & connection to the community. Keep it that way, guys! :D
     
    Zypo, charleshendry, NotaNaN and 2 others like this.
  3. eizenhorn

    eizenhorn

    Joined:
    Oct 17, 2016
    Posts:
    2,683
    We just landed June update for our game and now can safely migrate to 0.51. Thanks DOTS team, just in time!
     
  4. xCyborg

    xCyborg

    Joined:
    Oct 4, 2010
    Posts:
    632
    Hi, I have not tested Entities yet, and frankly feel much intimidated to do so,
    But I just want to say from what I've seen in this post:

    Is there any chance of packing everything above in as little windows as possible?
    -For instance, add Components and Systems as drop down items in the Hierarchy for each Entity.
    -Making Archetypes and all analysis in a single compact window.
    -Somehow merge Entities with GOs and toggle between them.
    -And get rid of boiler plate to get as close to previous C# starter file as possible.

    Doing this would be fantastic and would insure maximum number of adoption for the new system when it gets out!
    -Thanks in advance.
     
  5. xCyborg

    xCyborg

    Joined:
    Oct 4, 2010
    Posts:
    632
    I find that quite counter-intuitive and cumbersome, less is better!
     
    MNNoxMortem likes this.
  6. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    You can arrange any windows as you like. Pin them, move to side, group, make floating group.
    Also, there is many cases, when for example you don't to want to track systems execution, when working with entities, or vice versa.

    Old entity debugger had completely different purpose and it was expected to be eventually obsolete.
     
    Mayumichi likes this.
  7. Quique-Martinez

    Quique-Martinez

    Joined:
    Oct 1, 2013
    Posts:
    141
    Hi, is it possible that the ECS samples do not work with this version? Thanks.
     
  8. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
  9. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    If Entities are analogous with GameObjects, we split everything into their proper dedicated windows for the same reason why GameObjects have different windows for their various views and workflows. You wouldn't expect a Hierarchy, Scene, Inspector, and Profilers for GameObjects all locked together into a static monolithic EditorWindow. This is all further developed in our Entities 1.0 hybrid GO/Entitiy workflows (see below) that would not be possible if we stayed with the Entity Debugger approach.

    This will be the case for Entities 1.0! See the complete workflow in action here:
     
  10. thelebaron

    thelebaron

    Joined:
    Jun 2, 2013
    Posts:
    851
    Tangentially related but I do hope that there are plans or designs on better window and workflow management down the road, its getting quite tedious going to window > multitude of nesting subwindows to choose from. Similarly Assets > Create > Huge dropdown list that is a pain in my small project, assuming its a pain in big projects too.

    Just about every other 3d DCC program has better workflows regarding how this is tackled. Maya has its workspaces, blender has its tabs, zbrush has its palettes(I know a lot of people hate its ui but its extremely customizable through drag and drop).

    I did see this teased a while back on some roadmap talk a long time ago(sadly I think years). I know I can technically program something but that only helps me and ideally this is something that everyone could benefit from.
     
  11. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    Unity has right approach for what they do.
    There is no issue here, since you got all tabs and you can adjust your menu's as you like. Having tabs sections as you like. You open it and keep it open as long you need.

    upload_2022-6-27_23-11-4.png

    Having opened too many stuff at once as you propose, displaying everything, specially what is not needed at given use case, is a major workflow issue.

    For example old EntityDebugger shows many things, but in many cases, like just viewing entities, chunks and systems are unnecessary and slows down the debugging process.

    In the top right corner, you have also Layout selection
    upload_2022-6-27_23-15-53.png
    You can save any layouts as you need. So you don't need click so many things once is saved.
     
    Last edited: Jun 27, 2022
  12. Guedez

    Guedez

    Joined:
    Jun 1, 2012
    Posts:
    827
    Maybe place 3~ layout buttons besides the layout dropdown? It's not like there is no space there for that, but if you just have to click a button rather than navigate a drop down, maybe people will be more inclined to actually use the layouts feature? Somehow I made my uber layout that has everything all at once and just settled for that, even knowing that I could do better with the feature.
     
  13. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Separate from DOTS, there are indeed designs and plans to extend the existing Layouts feature in the Editor and have it become more of a workspace management feature. But no ETA on this currently. For now, I found it helpful to eagerly create my own Layouts for working with Entities. You can even save them to a file and add them to version control for the rest of the team to use.
     
    Clonkex, bb8_1, PhilSA and 4 others like this.
  14. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    6,221
    Now that you added more modes to the scene view, simplicity is muddled so we need:
    1. a special color around the scene view frame to indicate authoring
    2. click in the game view to select objects in authoring view
     
    Last edited: Jul 8, 2022
    thelebaron likes this.
  15. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    Sorry for the negativity but I can't stop feeling that unity is trying to sell us a "sorry, we couldn't achieve parity with existing workflows" product as something "look at this new awesome workflows that increase productivity so much".

    "Things changed in the scene during play mode are reverted upon leaving play mode", this has been a rule since I have memory of unity (I started on v3). Now you are breaking that rule for part of unity, making us manually change between "modes" that are hard to differentiate, very easy to forget/miss the currently active one leading to things getting changed permanently without us realizing. (Which actually happens in the presentation)

    "Changes to things in the scene outside of play mode stay until u close the scene, and u can save them" is another rule of... well not unity, but pretty much every software out there. Why challenge that behavior?

    "The Scene View reflects what's currently in your game but without the constrains of the player's camera" is yet another well stablished and to be blunt, irreplaceable, workflow of unity (and other game engines). It allows us to easily check, understand and debug things as they happen. This new proposed workflow still show us the numbers in the inspector yes.... because ofc I can tell at a glance that at its current Y=0.5 some object outside of the player's camera frustum is penetrating another from bellow and causing some unwanted physic interactions..... (sorry for the sarcasm but heck, it's so obvious it hurts)

    Prefabs instantiated on an scene can be changed (with some very specific limitations yes) and if u want to apply some of those changes to the prefab u have a nice menu to do so. Why not reuse this well stablished unity workflow for this too?

    I know entities are not gameobjects. I know some things are really really hard or almost imposible to replicate. What I don't like here is unity trying to sell it as it is better than the current go workflow when it clearly isn't (at most they could be a match).
    Maybe I'm just being over sensitive because well, u know, the original over-selling of DOTS and all the friction it created back in the day.

    Sorry again for the rant tone but there are some legit questions there too.
     
    exiguous and Elapotp like this.
  16. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Scene view modes have always existed. Definitely already there in 0.17. You could choose, via the DOTS menu, whether the Scene view is in Runtime mode (renders Entities, you see them moving in Play mode) or Authoring mode (renders GOs, and they don't move in Play mode since GOs are stripped from the runtime after conversion). So this part is not new in 1.0. That said, we of course plan to add the same clarity to the Scene view regarding these modes as we did for the Hierarchy and Inspector. This will be done in future versions.
     
  17. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    You will have the option to lock all the windows to always show Authoring-only data in Edit mode and Runtime-only data in Play mode - reproducing the exact same behavior as pure GO Unity today. The only difference you'll see is that Runtime data is CLEARLY marked orange/red so it's abundantly clear when a change will be lost when exiting Play mode. Something that is very much not clear today, especially for new users.

    The opposite confusion, where users change values in Play mode without realizing and then having to redo that work after exiting Play mode, has been a problem this whole time. It's why we added the full-Editor color tint feature for Play mode. This is the main problem we wanted to fix. Because this tint in itself is a lie. If you are in pink-tint Play mode and select a Prefab Asset, you can easily assume that changes in the Inspector will NOT be saved, but in fact, they will. So we had to do something here.

    And adding this new way of working does not replace our goal to achieve parity between Entities and GOs. That's still a long-term goal. In the meantime, it would be silly to not take advantage of the unique possibilities that the Entities offers and try something new. It's not a guarantee this new Authoring vs. Runtime workflow will be an improvement, which is why it makes even more sense to try it out for Entities only, with a limited scope, before considering it for broader adoption.

    How does this behavior change in the new workflow? If you're referring to being able to enter Play mode with unsaved changes in your Scene and without being forced to save, this is also not new. You were always able to do that.

    Please clarify. I'm not sure how the new workflow adds any relation between the camera and what you see in the Hierarchy. Like, what is the issue here? And again, you can force and lock the data mode of the Hierarchy to make it behave like it has always behaved in Unity.

    Again, what is the issue here? What has changed the goes against this pattern? You can still modify Prefabs exactly the same way you could before.

    The over-sell was all about performance. This topic, around Authoring vs. Runtime, has nothing to do with performance. It is all about our efforts to properly integrate Entities into the existing Unity Editor and achieve a reasonable balance between consistency with GOs workflows and taking advantage of new Entities possibilities. Going all the way and making Entities EXACTLY the same as GOs would have left way too much on the table and would have been essentially lying to users about what is actually happening under the hood.
     
  18. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    Hi @uDamian. From what I understand, Entity Debugger will be deprecated and removed but at current dots 0.51 release the tooling at Windows > DOTS still can't get equivalent tooling features at Entity Debugger as following:
    1) Chunk Info to visualize all the chunks sorted by archetype with chunk utilization, component read write and etc
    2) Filter the entity and chunk by selecting specific component and it will only show Entity and chunk that match with the selected component
    3) Select chunk and it will only show all the entities in that chunk

    I hope dots 1.0 release will get similar tooling features when removing Entity Debugger. Currently there is Archetypes windows but lacking the tooling features I mention.
     
  19. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    If that will be an option then I don't have any further complaint with the mode changes.

    Yes but I think that is a lot less likely. Selecting things in the scene and selecting assets is a clear different action from our side so different behaviors are perfectly reasonable (having a background color change in the inspector to clearly differentiate when we have a go or an asset is welcome though).
    The only odd ball there are materials inside a renderer component of a go which will edit the material asset.... that is a "surprise" factor that works against UX.

    Good to know.

    I was trying to say that having a manual persistence mode and a transient mode is quite unconventional. Not inherently bad, just weird.

    Seems I missed the part where its said that changing modes in the scene view allows it to render the "current real time state" of the scene.

    I was trying to suggest (in a poor way) the use of this behavior for all scene objects in play mode instead of the mode change. So, changing something in play mode generates an "override" that we can then chose to permanently apply to the GO (well, not permanent permanent, just add the change to the scene file which in turns then needs to be manually saved for a real permanent change.) Upon leaving play mode, unapplied overrides are discarded and forgotten.
    Sorry for being extremely unclear.

    Fair enough.

    Thx for taking the time to answer to my long and "ranty" post.
     
  20. Tony1974

    Tony1974

    Joined:
    May 26, 2018
    Posts:
    10
    Hi.

    Updated to 0.51 and latest 2021 LTS and during game play I constantly receive errors similar to the following:

    Code (CSharp):
    1. IndexOutOfRangeException: Index 15 is out of range of '15' Length.
    2. Unity.Collections.NativeArray`1[T].FailOutOfRangeError (System.Int32 index) (at <4a31731933e0419ca5a995305014ad37>:0)
    3. Unity.Collections.NativeArray`1[T].CheckElementReadAccess (System.Int32 index) (at <4a31731933e0419ca5a995305014ad37>:0)
    4. Unity.Collections.NativeArray`1[T].get_Item (System.Int32 index) (at <4a31731933e0419ca5a995305014ad37>:0)
    5. Unity.Rendering.SimpleCullingJob.Execute (Unity.Entities.ArchetypeChunk archetypeChunk, System.Int32 chunkIndex, System.Int32 firstEntityIndex) (at Library/PackageCache/com.unity.rendering.hybrid@0.51.0-preview.32/Unity.Rendering.Hybrid/HybridV2Culling.cs:351)
    6. Unity.Entities.JobChunkExtensions+JobChunkProducer`1[T].ExecuteInternal (Unity.Entities.JobChunkExtensions+JobChunkWrapper`1[T]& jobWrapper, System.IntPtr bufferRangePatchData, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at Library/PackageCache/com.unity.entities@0.51.0-preview.32/Unity.Entities/IJobChunk.cs:401)
    7. Unity.Entities.JobChunkExtensions+JobChunkProducer`1[T].Execute (Unity.Entities.JobChunkExtensions+JobChunkWrapper`1[T]& jobWrapper, System.IntPtr additionalPtr, System.IntPtr bufferRangePatchData, Unity.Jobs.LowLevel.Unsafe.JobRanges& ranges, System.Int32 jobIndex) (at Library/PackageCache/com.unity.entities@0.51.0-preview.32/Unity.Entities/IJobChunk.cs:368)
    Since these errors are all occurring within the Entities/HybridV2 packages and the stack trace does not lead back to any of my code I have no idea what is causing it or how to fix it.

    The issue appears to be due to an invalid index reference for the variable finalindex into the chunkInstanceBounds array within the SimpleCullingJob struct of HybridV2Culling.cs. See below:

    Code (CSharp):
    1.                                 var finalIndex = (j << 6) + bitIndex;
    2.  
    3.                                 scratch[instanceOutputOffset] = processedInstanceCount + finalIndex;
    4.                                 // IndexList[batchOutputOffset + batchOutputCount] = processedInstanceCount + finalIndex;
    5.                                 // Debug.Log($"DEBUGCULLING Partial {externalBatchIndex}: [{batchOutputOffset + batchOutputCount}] = {processedInstanceCount + finalIndex}");
    6.  
    7.                                 int advance = FrustumPlanes.Intersect2(Planes, chunkInstanceBounds[finalIndex].Value) !=
    8.                                     FrustumPlanes.IntersectResult.Out
    9.                                     ? 1
    10.                                     : 0;

    Has anyone else had this issue and were able to fix?
     
  21. Arnold_2013

    Arnold_2013

    Joined:
    Nov 24, 2013
    Posts:
    281
    Hi, I would suggest you create a new post for your issue. It will be easier to find and follow than when it is in the middle of this thread. Your description is fine, someone will be able to help with ideas on how to solve this.
     
    Tony1974 likes this.
  22. Tony1974

    Tony1974

    Joined:
    May 26, 2018
    Posts:
    10
  23. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    1) The only thing that won't be available in 1.0 is the Chunk utilization graph. You won't be able to tell how fragmented are your Chunks for an Archetype, other than comparing Capacity against number of Entities in the totals. Something like this might be added back in the future. The justification for its de-prioritization was mostly around the fact that users can't do much about this information, apart from creating a fairly in-depth defragmentation system. If you can provide some details as to why you found this visulization useful, that would go a long way to re-prioritize its return.

    2) This is totally possible in the Archetypes window. Just type name of your Component in the search bar and you'll now see only the Archetypes that have said component.

    3) You're right, we don't have individual Chunk selection anymore, and we won't for 1.0. Again, any info you can provide as to why it is useful for you to select individual Chunks would help not only prioritize the feature's return, but also potentially help me give you some alternative ways to achieve the same.
     
  24. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    4,217
    There's primarily two ways chunks become fragmented.
    1) Lots of shared components that are unique.
    2) Adding a zero-sized tag component to a query with a small number of entities each frame. That gets defragmented by adding and removing a non-zero-sized component in the process.
    These are both easy for us users to resolve once we know it is the problem. But figuring out that it is a problem hurting our performance is the hard part and what the Entity Debugger feature resolved.
     
  25. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    Please make sure this tool is available. It is important analytical and debugging feature. Makes no sense discontinuing it, specially if you already have this utility working.

    It is hard to justify need for such tool, if dots dev team doesn't develop games. But game devs do. Seeing how chunks are fragmented and utilised, helps a lot with optimizing the code and entities itself. Specially with ECS World.

    Also, not everyone will sit with a calculator, to compute entity size in the chunk.
     
  26. xCyborg

    xCyborg

    Joined:
    Oct 4, 2010
    Posts:
    632
    Thanks for replying, no I wouldn't expect that, but 2 Hierarchy windows, 2 Scene views, 2 Inspector windows, and 2 Profilers? That would certainly be confusing.
    Surely there must be a way to represent entities (and even components and systems) in the old Hierarchy window, it just needs commitment.
     
  27. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    Thanks for the details. From our experience, it has not been generally easy to resolve issues like this, but I agree that it's a real source of performance issues.

    That said, while not equivalent or equally clear-cut, you can still get major clues about fragmentation issues by looking at the data the Archetypes window and the Memory Profiler does provide.
    1) You can see the number of unique shared components (ie. segments) and compare that to the total number of Entities, the capacity, and the number of chunks.
    2) You can compare the Entity count with the Capacity and see if there's a large gap + you can see the sizes of all the Components and quickly identify how many tags are being used + you can monitor the number of structural changes involving said components/tags to get an even more accurate view of the problem or cause.
     
  28. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    4,217
    That's been contradictory to my experience. The few times I ran into this it was easy to fix once I understood the problem.

    I'm not convinced your suggestions are that great of a workflow for discovering issues. Usually what happens is a chunk iteration job is slow, so I look at the query and look at the distribution of chunk occupancies. Sometimes the issue is that there are two different code paths that cause entities to match the archetype. One of them fills chunks, and the other doesn't. Your proposed workflow wouldn't catch that, but the graph does.
     
    Antypodish likes this.
  29. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    As I said above, this feature won't be in DOTS 1.0. It's a combination of priorities and limited resources. Some stuff just didn't make it. Doesn't mean we think it's of no use. But it wasn't as simple as just keeping the Entities Debugger around. Look for the feature's return in a future DOTS release.

    We actually do work on projects internally to stress test our features. This specific aspect was not identified as a must-have feature, especially given the existing numeric information already provided. I appreciate that we don't cover all possible use cases and as such, the frag. visualization feature is still on the table. It just needs to wait for other higher priority tasks (for other use cases).

    Not sure what you mean. All the numbers are already there. Correct me if I'm wrong, but most of the time, the question is simply: is there fragmentation or not. It's rarely something super specific like: are there 100 chunks with 1 entity, and 1 chunk with 100 entities. If iteration over your chunks takes a long time and you suspect fragmentation as the cause, you can get a sense of the amount of fragmentation by just looking at unused Chunk capacity.

    Again, specific use cases and examples would go a long way to re-prioritize this feature. What exactly can you identify and specifically solve for using the Entity Debugger that you no longer can do using the DOTS 1.0 workflows?
     
    thelebaron and apkdev like this.
  30. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    I did say it wasn't ideal, but I still maintain that it's _sufficient_. With this example you gave, looking at just unused capacity, I would still be able to differentiate between these 2 code paths, even if I can't exactly see that fragmentation pattern.

    Just to be clear again. I fully understand why the graph would be useful. I'm just trying to be helpful to both:
    1. the team, so we better understand use cases and priorities
    2. you and other users, so there are alternatives while the team implements better workflows
     
    thelebaron and apkdev like this.
  31. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    In DOTS 1.0, the DOTS Hierarchy will be able to serve as the one and only Hierarchy. It handles GameObjects and Entities. For example, when working with just GameObject (ie. no dots, no subscenes), you should be able to use the DOTS Hierarchy instead of the built-in Hierarchy and not notice much difference. It's true that for 1.0, the DOTS Hierarchy won't be 100% at parity with the built-in Hierarchy, but that's the plan.
     
  32. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    Actually is that possible to query more than 1 component at Dots Hierarchy and Archetypes windows? If yes how to write the syntax?

    I see. I hope after dots 1.0 released the graph visualization should be next highest priority feature to implement. I think it's super important that I can just see the graph in 5 seconds I can figure out why it slow.

    Another high priority feature I would like to have is mathematical model visualization that I can understand the data much better.
     
    Last edited: Jul 20, 2022
    DreamingImLatios likes this.
  33. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    4,217
    I think you misunderstood my use case. Both codepaths exist at once, and their combined result is what generates the statistics the profiling tools show. I'm trying to detect that one of the codepaths is problematic. And to further complicate things, entities might also be destroyed, reducing occupancy, but not in a way that is actually harmful because if everything is working correctly, the next spawn will fill in the gaps.

    Really what I am trying to figure out is if new entities are falling into existing chunks or creating new sparse chunks when there is a whole mess of things going on. The fragmentation graph was able to show this quite effectively.

    Anyways, I do appreciate your responses. The feature not making the original 1.0 cut wouldn't be the end of the world for me. But if the feature were to be backlogged for over a year after the 1.0 release, that's a different matter.
     
    iamarugin likes this.
  34. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,754
    I appreciate for the reply. And also for sharing what is coming and what is deprioritized.
    We do recognize, that feedback from the community on the DOTS development is important.
    Especially after long silence.

    While I do get the point on deprioritisation certain features, I am concerned that once feature from debugging is deprioritized, it may be long time, before it will show up, if at all.

    My perspective is that and as also others has pointed out earlier, visual representation of chunks fragmentation is very helpful, to recognize immediately various of problems.
    I am yet to see what is coming in new debugging tools for 1.0. It is just hard to justify atm. without seeing tools.

    Also, maybe because I think you had tools in hand, like this chunks graph, seems like you could just reuse it.
    Unless there is such big internal DOTS code changes, that whole thing breaks.

    My point here is, that stress testing in isolated environment, doesn't show all problems ahead.
    Things become more apparent, when building actual real product, with many various systems, jobs and entities.

    In the past, when @Joachim_Ante was active on the forum, we were asked often by DOTS dev team for use cases. And people here on the forum did try at best to explain in specific scenarios, why A or B feature is potentially useful in DOTS.

    I will give 2 example case scenario.
    Having various components, maybe tags, that shows fragmentation. Something which need be mitigated in game project. Graph did show nicely what and where were problems. Also we could click on specific archetypes, and see all entities. I thin this is very neat solution and feature.

    Second use case is amount of data, which leads to amount of entities per chunk. So if your debug solution is providing these information, I am happy to be this way.
    Amount of components in entities leads to less entities in a chunk. With graph, it was nice to see, how the packing of entities in chunks was allocated. Reducing data size of the component (i.e. from float to byte), was able be represented entities allocations in chunks and some numbers too. Hence fragmentation. That was nice.
     
    DreamingImLatios likes this.
  35. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    The one thing that is still holding me back to learn and work with entities is physics interoperability, and it's something I'm not seeing (at least not clearly) on the Roadmap. For the 1.0 release:
    1. Will DOTS Physics collide with PhysX?
    2. Will it be possible to apply both FixedUpdate- and Job modifications to Rigidbody- and Velocity data on the same GameObject?

    I play around a lot with physics, including external code written for game objects. Using Unity Physics is kind of a life-ender in that you can have a very simple DOTS physics world with 1 weird Rigidbody physics character and now you can tick 2 days off your schedule rewriting complex code for compatibility, rather than for optimization.

    The 2nd point is less important, however it would be nice for gradually converting code to DOTS physics. I may write a new physics feature using DOTS for all Velocity data (e.g. PhysicsWindSystem), but at the same time have some objects use Rigidbodies because they have some custom Component (e.g. CharacterMover) that uses rigidbody.AddForce() and friends. It wouldn't be a lot of trouble to write some static methods that can be reused for both FixedUpdate and Jobs, but it would be less trouble if I didn't have to do that at all.

    I think these things are really important to providing a better integration path between DOTS and GO. A lot of asset store assets inhabit that awkward space of suppressing DOTS altogether, not to mention that newcomers to Unity scripting should most certainly start out writing MonoBehaviours before diving into ECS, at least as things are now. Without this step, I feel DOTS and GOs are missing an important bridge - try explaining your boss you want to take worktime for a 2 week course that allows you to write game-breaking code.
     
    Vectrex and TieSKey like this.
  36. Harry-Wells

    Harry-Wells

    Joined:
    Oct 13, 2013
    Posts:
    73
    Just because there's code written for GameObjects and there isn't as much code written for Physics doesn't mean it's a good idea to push together two physics frameworks. One framework has to take responsibility for performing all the simulation. There will need to be a synch layer to translate between the two incompatible concepts of physics worlds and transfer the correct state. Even if this were a feature, you'd then start making more and more assumptions about what you can do as a newbie, like receive physics events from UP to classic just because your collider happens to participate in UP simulation. Were features along these lines attempted, I'd say this is a worse solution than just learning Unity Physics properly from the ground up. Not everything has to have a granular incremental conversion path from a large extant codebase. Physics is a worse example of something to use a hybrid approach with than say animation, there's a strong physics framework for both GameObjects and for Entities so you're better off doing what you can to reframe your thinking to work in ECS than try and use a hybrid approach just because you don't want to convert legacy code. You can try porting over physics or character simulation code once you have a handle on Unity Physics. It's not too difficult. You can learn how the simulation behaves / updates and what the API offers, like PhysicsComponentExtensions which should be sufficient for many non-kinematic rigidbody scenarios.
    I say physics is a worse use case for hybrid than animation because there's no solution for animation planned through to 1.0, though here's to hoping Kinemation (and Myri Audio) become feature-rich enough for production projects.
     
  37. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    Sorry for being this blunt but, saying that u can throw in a lot of extra studying and extra work to rewrite/change a lot of things and get something working is a "non-answer". Ofc u can do that, u can almost always do that, it's obvious and therefore beyond CaseyHofland's point......
     
    Vectrex and CaseyHofland like this.
  38. Harry-Wells

    Harry-Wells

    Joined:
    Oct 13, 2013
    Posts:
    73
    Well, you know. To be blunt right back, that wasn't the entirety of my point. I also argue that hybrid physics isn't a good idea in general. Thanks.
     
  39. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    Mmmmm u mention that, yes, but I didn't see any tangible/objective reason backing your affirmation so I took it as simply your personal taste/opinion.
    I would like to hear some "material" reason for that affirmation if u have some (honest, not being sarcastic here).
    Given the amount of features and the amount of asset store stuff that doesn't work with entities, having an automatic way to force the 2 physics engines to interact would help a lot, even if with a lot of caveats.
     
    Vectrex likes this.
  40. Arnold_2013

    Arnold_2013

    Joined:
    Nov 24, 2013
    Posts:
    281
    We don't even get Animation in the 1.0 release. There is no audio solution. In hybrid renderer V2 URP you get 1 realtime directional light. Most assetstore shaders don't work because you need Dots instancing. There is a lot that would be nice to have right now :)

    DOTS physics especially the Havok implementation is nice.

    It would make me very sad if development time was devoted on 'cross physics system' support with the current state of the project. If you want you can use componentObjects and copy all the data every frame from one physics system to the other. But you lose some performance.

    PhysX = Nvidia
    Dots Physics = Microsoft (Havok)
    So chances are very slim that the physics data can be easily/performantly exchanged between the one and the other. Even if you could go to very low level code.
     
  41. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    Mmmmm but wound't a 'cross physics system' help us workaround some of those limitations?
    For example, your mostly static "world" is ECS but then your few characters (which don't really need any performance boost) could be GO and work seamlessly in terms of physics.


    Why copy all the data? Interoperability and replication are different things. Maybe only a handful of GO need to interact with ECS so helper entities with all the required components are created and then state is sync only for those GO. Or the other way around, (although quite unlikely) only some entities need to physically interact with GO physics so helper GO are created and sync back.

    Again, interoperability is not replication. I think having such a feature would actually help a bunch, specially given the current state mentioned in the first (quoted) paragraph.

    Yes, we can code that manually, we almost always can, but we use an engine to not having to write everything ourselves (and unity folks should be able to make it a lot more efficient by maybe bypassing managed land, etc).
     
    Vectrex and CaseyHofland like this.
  42. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    862
    This line of discussion is not helpful off topic and destructive mods please delete.
     
    iamarugin likes this.
  43. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    Care to elaborate on why? What do u consider "on topic" for this thread? The starting post says "share your feedback" in bold.
     
    Vectrex likes this.
  44. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    862
    It is not helpful because ECS already has superior physics; one of the few core areas where it is already better.

    Its off topic because it is not about 0.51 or even any other future numbered version of ECS that will ever be released. This topic is for feedback for 0.51, from actual users of ECS, not for dubious architectural change suggestions.

    It is destructive because the logical outcome of following your wishes is nothing less then the serious curtailing / cancelation of ECS.
     
    Last edited: Jul 26, 2022
    iamarugin and charleshendry like this.
  45. TieSKey

    TieSKey

    Joined:
    Apr 14, 2011
    Posts:
    223
    Wow, that's extremely subjective and I disagree with most of that.

    It is valid feedback, we are saying "it would be valuable for 0.51 and 1.0 to have limited, out of the box interoperability between the different physics systems". Idk what architectural changes u talk about, this could be achieved by some stand alone "sync" systems/monoBehaviours without changing anything about existing ECS or UP.

    You can disagree with that ofc, but it doesn't mean it is "off topic", destructive and a call for removal. That's extremely rude and borderline censorship.
     
    Vectrex likes this.
  46. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    954
    These threads have a history of going offtopic and in circles with feedback that's just not relevant for entities as a whole. I do agree that a PhysX <-> DOTS physics is that kind of discussion and much better off in another thread. There's a DOTS Physics sub-forum, so why not do it there? Entities != Physics
     
  47. Micz84

    Micz84

    Joined:
    Jul 21, 2012
    Posts:
    447
    Interoperability between DOTS Physics and Nvidia PhysX is not an easy task. They have different philosophies of doing physics simulations. Making it work would probably take a lot of time, that can be spent somewhere else and the performance of such a solution would be worse than PhysX's. You would lose things like physics prediction and roll back. To sum up, it is not worth it.
     
    iamarugin, mariandev and Mockarutan like this.
  48. CaseyHofland

    CaseyHofland

    Joined:
    Mar 18, 2016
    Posts:
    610
    The idea would be to put sync components on your more complicated game objects so you can continue development: these would slow down performance, but allow your simple game objects to take full advantage of ECS, increasing performance. From a pure systems perspective I agree with you about its impracticality, but it’s also not practical to spent months porting over old work because 1% of things in your game uses weird physics components and black-box physics libraries (work I don’t mind, but only as long as it doesn’t grind further development to a halt).

    I understand how impractical it is, from a system perspective, to put some main thread 2-way coupling sync point in an otherwise beautiful architecture, but without it ECS still seems impractical for me from an adoption perspective. Unless I find a company who’s going pure ECS, who’s going to use it?

    I also hope not to be associated with any controversy about this, I’ves got chill. Just an honest farmer with an honest opinion about hybrid ECS, that’s all.
     
    Vectrex likes this.
  49. Occuros

    Occuros

    Joined:
    Sep 4, 2018
    Posts:
    300
    The correct place for this suggestion is:
    on the roadmap: https://unity.com/roadmap/unity-platform/dots
    on the physics subforum in a new thread.

    Let's keep the discussion focused on already confirmed or planned features on the roadmap, and give the dots team actionable feedback on their road to 1.0.
     
  50. uDamian

    uDamian

    Unity Technologies

    Joined:
    Dec 11, 2017
    Posts:
    1,231
    There are indeed a lot of changes between DOTS 0.17/0.50/0.51 and DOTS 1.0. We also moved all tooling to UI Toolkit, so we couldn't use all the Entity Debugger custom UI as-is. There were also a lot of usability and accessibility problems with that chunk utilization graph - many users did not know how to interpret that graph - and we would have had to fix those issues to bring that control in-line with the rest of our workflows. All of this contributed to the de-prioritization.

    Fully agree. We did also do a fair amount of collaboration with shipping DOTS games, but at some point we needed to draw a line and ship a reasonable 1.0. Iteration will definitely continue after 1.0, but we with a lot more real-project feedback from all the teams that were waiting for DOTS to come out of experimental before trying it out.

    Thanks for the scenarios. Helps paint a clearer picture.
     
    Antypodish likes this.