Official Experimental Entities 0.51 is Available

Where is "Project Settings > Player > Configuration Section > IL2CPP Code Generation > Faster (smaller) builds." menu? I cant find it.

 

Can We get an explanation for the removal of custom batch sizes in IJobEntityBatch now its only by chunk or singular entity which is just F***ing useless. It just seems like a work around with no positive impact and now people who need this feature for certain use cases have to make their own inefficient work around

 

Never made much sense to begin with. A full chunk iteration count is based on the archetype capacity and not some arbitrary batch count. Splitting chunks on worker threads is also not the best idea.
I wonder what's your use-case that you feel so strong about this change.

 

On the topic of Entity development UI, some folks over on the DOTS discord (including me) would greatly appreciate if there was some way to "folder" or group together entities in the hierarchy without chaining transform inheritance.

Something just editor only for the sake of understanding and debugging. For example, in my current project's stress test, I spawn about 500 lights in a "halo" around a single primary entity. Since these lights are static, they dont need to move anymore and there is no need to link their transforms together.

However, that leaves 500 otherwise redundant entities clogging up valuable space on the hierarchy page that other more important entities could exist in.



I speak for a few others on the discord for a way to folder and group entities together only in the editor and not establish any actual relationships between them. Just for visual sake in the DOTS Hierarchy tab like how subscenes are grouped.

 

Putting filters like this seems to operate as an OR (i.e. it will show entities that contain either (or both) of the filtered components). In the old Entities Debugger, selecting multiple components would operate as an AND (i.e. only showing entities that have both the filtered components).

Though I reckon the OR-way can be useful in certain use-cases, the AND-way seems far more valuable (especially for debugging) and it would be a loss if that would no longer be possible.

 

Install HybridRenderer_Version 0.51.0-preview.32 - June 15, 2022 and PlatformsAndroid_Version 0.10.0-preview.10 - January 22, 2021 in the project just created Then I get the following error, is this a bug?


Library\PackageCache\com.unity.platforms.android@0.10.0-preview.10\Editor\Unity.Build.Android\Components\AndroidKeystore.cs(12,25): error CS1929: 'HierarchicalComponentContainer<BuildConfiguration, IBuildComponent>.ReadOnly' does not contain a definition for 'GetBuildTargetGroup' and the best extension method overload 'BuildTargetExtensions.GetBuildTargetGroup(Platform)' requires a receiver of type 'Platform'.


I've already asked this question here, but since I can't seem to get an answer, I've come here.
https://forum.unity.com/threads/unable-to-use-com-unity-platforms-android.1314540/
Is there a workaround?

 

Thank you cyriaca.

I was able to build it successfully, but Entity is not showing up.
Also, for some reason the frame rate dropped from 72 fps to 40-50 fps.

I tried to find the reason why it is not showing up, but I saw someone said that it does not show up when Valkan is used, so I checked the settings, but it was not used from the beginning.

https://forum.unity.com/threads/entities-not-rendering-on-linux-build.1127816/

My project settings have Auto Graphics API unchecked and Graphics APIs is OpenGLES3 only

 

+1
I have missed the discussion on Discord but I'd also highly appreciate a way to group entities in the hierarchy view for debugging purposes outside of entities having any relationships.
I also have groups of certain entity types and usually test with 250k. While I'm always filtering by "c: [componentType]" it would be a lot easier to just group them. Keeping the hierarchy neat and clean.

 

If u mean that your entities don't render, check the rendering layer mask setting in your materials. It was broken in previous versions and now that it is fixed, it can "filter out" entities from being renderer if the value is not the correct one. (int.max for always rendering)

 

I think grouping hierarchies per archetype would be very useful. Or at least per tags components.

Or alternatively, having special filter component on entities. But I think tha would be complex to program it.

 

Thank you TieSKey.

But I don't know where that setting can be configured.

I'm using Universal Render PipeLine/Lit, which is compatible with Dots, but there is no rendering layer mask setting in the inspector.

I see RenderLayerMask in the AdditionalSettings of Mesh Render, but I'm not sure if this is what you are referring to.

Changing it to Everything or something else doesn't seem to make any difference.

 

My bad, it isn't in the material itself but in the renderer component of the entity, yes.

 

Oh no. I'm reading "never".

Also on that front, how about an ability to group together components? Like the LocalToWorld, Translation, Rotation, NonUniformScale components into one "Transform" component group in the entity property inspector.

I have a bunch of decomposed components for optimal burst compilation, 30 and rising on the primary player entity, and I have to scroll and scroll and scroll just to find the components im looking for and depending on the authoring order, they might not even be grouped next to each other.

I have never been more thankful of my mouse's ability to unlock the scroll wheel after scrolling so much.

 

@Kmsxkuse , as far as I understand, Aspects from Entities 1.0 will handle that. We just need to wait for release

 

Right now, an Inspector class could be a solution for your problem.
What I don't know is if it's possible to query all the other data you need to visualize. I see no reason why not though.

Here's a basic implementation that I was using for showing pointer data:

Code (CSharp):

1. public unsafe class StatReferenceBuffer_Inspector : Inspector<StatReferenceBuffer>
2.     {
3.         public override VisualElement Build()
4.         {
5.             var root = new VisualElement();
6.  
7.             var entity = new EntityField("Entity") { value = Target.StatPtr->entity };
8.             //var statType = new EnumField("StatType", Target.StatPtr->StatType);
9.             //var changeType = new EnumField("changeType", Target.StatPtr->changeType);
10.             //var value = new FloatField("Value") { value = Target.StatPtr->value };
11.  
12.             root.Add(entity);
13.             //root.Add(statType);
14.             //root.Add(changeType);
15.             //root.Add(value);
16.  
17.             return root;
18.         }
19.  
20.         public override void Update()
21.         {
22.             base.Update();
23.         }
24.     }

 

Apparently there was a problem with the VR.
This page provides some information.
It may be helpful for those with the same symptoms with OculusQuest.
https://forum.unity.com/threads/dots-for-vr.1049432/

 

As long as you use Vulkan renderer it should work fine.

Quest 2 in both editor, windows standalone (with link) and in an android build work.

performance is another issue with the hybrid renderer on the quest…

 

@uDamian I would like to confirm with u that is that Platform package has been confirmed will be removed at dots 1.0 release and will go back to use classic way to build player runtime i.e. Build Settings?

 

But will the features from the platforms package be ported over or simply scraped?

 

I have seen this article before, but some people were not able to see the entities after the build when using Valkan.
https://forum.unity.com/threads/entities-not-rendering-on-linux-build.1127816/
And I also use Valkan and it does not show up in Quest1.

 

I see. Platform package is really powerful tool that able to have multiple different build configuration to come out different builds for different purpose at target platform. It's really sad that it will be removed in future release.

Another question I would like to ask is about dots addressables. Will dots addressables have good hybrid support for instantiate game object, load game object land scene, load game object land asset that is managed type like Sprite and provide good hybrid support that game object can work in harmony with dots? Currently using game object land addressables is quite hard to integrate into dots especially when u want to use async load addressables.

 

I still find platforms package is really useful tooling that I would like to keep it. Maybe official should keep and maintain platforms package and rethink how the platforms package works in another way. I think platforms package should evolves to be like the extension/additional feature on top of game object land Build Settings. So when u press Build button at build config to get player runtime build, it just feed build config data into game object land build pipeline like PlayerSettings and also feed some build config specific data into Entity at Subscene before starting the build so I get specific player runtime build I want for each build config. Not to mention different player define setup for each build config and the feature list goes on. And also I think it's also essential feature for dots netcode that u can have some specific settings for client and server runtime player build. Without this platforms package, I really think it's damn hard and tedious to achieve the same goal. Can't imagine how to achieve the same thing without plaforms package. I really hope official can reconsider this continue to maintain platforms package in different way.

 

Is there any known issue with the Hybrid Renderer on Linux/Vulkan with more than one Nvidia GPU ? I made a test program that is running very well with a single screen and a single GPU (so much faster than non DOTS version !) but on the production environment with two GPUs and two screens per GPU using Nvidia Mosaic, it freezes with no trace in the log file...

 

Why not scrap out the standard build setting, and continue to support only platforms package? Why leave standard build settings behind you will ask. Because they are awfull as soon as you need to build something more complex, than just a tutorial game. Imagine building several times a week a game and a demo for it (containing only subset of scenes) for three platforms and x86, x64 architectures using standard settings. You can argue, that we can implement our build system for our needs. By why to reinvent the wheel, when platforms package already exists and works perfectly?

 

Wrong place to ask.
You would've found this thread if you searched.
https://forum.unity.com/threads/dots-supported-platforms.822222/#post-8317797
Search before asking. Don't ask in the wrong places.

 

Which category should we submit this issue under in order for it to get it the most attention? Editor, Engineering, or Platforms?

Would love to see the Build Settings improved: would especially love to build for platform X while the editor is on platform Y, I never understood why the reimport was necessary in the editor and couldn't be done by the build process itself.

 

That may be so, but simulating the platform and building for it are still 2 different things. I can initially get behind the approach of “keep code simple, to build you need switch”, but with Unity supporting every platform it becomes kindof a problem if you’ve got 5 platforms to build to. Like, at least give us a buffer that automates the process, like builds for a, switches, builds for b etc. then switches back to the version you started on, that way you can at least do it overnight without manually having to switch every time a build is finished, there’s probably some clever tools designers out there who already did this.

sorry, I’m ranting, thanks for referring to the roadmaps where I’ll make the suggestion.

 

Why there is no word about removing

GameObjectConversionSystem.AddHybridComponent

in upgrade guide?

 

That's just mentioned in Changelog

 

Only see mention about this in 0.18 Deprecated section

 

Has anyone tried DOTS 0.51 with Unity 2022?

With all the big breaking changes in between 0.51 and 1.0 we are likely to ship and maintain our game on 0.51, but 2022 has some nice things to it that we'd like to have down the line, like DX12 support for instance.