Can I use ECS/Jobs/Burst?

Background: I'm working on a 3d simulator with: ~dozens-to-hundreds of kinematic objects with custom physics that move and manipulate ~hundreds-to-thousands of non-kinematic objects without custom physics. Thousands of the latter type of objects can get created/destroyed during runtime. Almost none of the objects in a scene are ever stationary (or sleeping in physics terms).

Is the current state of ECS/Jobs/Burst sufficient to build a project like this?

Q1: Most importantly, can I take full advantage of the 3d PhysX engine in pure ECS, and use convenient primitive- and mesh-based colliders, physics materials, and custom kinematic motions?

Q2: I have designed a number of prefabs of different combined objects that have been created by composing various meshes, transforms, colliders, etc. - is it difficult to convert these back and forth to entities with the appropriate component data? Can I still graphically design complex objects in the editor if I want pure ECS?

Q3: Does ECS impose heightened minimum system requirements on my end-users? For example, I see that at minimum GPU instancing is a required functionality.

Q4: Can tertiary components like menus, huds, etc. still by made in classical/GameObject/MonoBehaviour world?

Thanks!

 

Q4 yes. For now you don't have really other option with ECS.

Q3 I think so. But you really need test on target hardware. However, unless you run on integrated GPU, probably most of 5 years old dedicated GPUs will be sufficient. Not sure about mobiles.

Q3. For now best solution is having predesigned (imported) mesh as prefabs. However, people are working with meshes generators/manipulators in pure ECS. You probably could create own tools for editor mesh manipulation, to ECS, but don't expect any out of box solution, any time soon.

Q1. Currently pure ECS has no official physics API. Hence you can not use physX directly. However people been posting different methods, including custom physics engines. But there are few ways now, for interlinks entity with Game Objects,.to grab for example positions.

 

Ah well that was what I was afraid of. Implementing our own physics is out of scope for now, and was one of the key advantages to us of using Unity. From designing our own engines in the past, its obvious to us an ECS model is the way to go for code cleanliness and performance, but looks like we'll have to plod along in classic for now.

If we want the coding benefits of ECS, is there any (performance) harm in using hybrid ECS in order to use PhysX, but have rendering be done using an ECS system? Will an ECS rendering system really provide much benefit over batched/instanced rendering done classically? Or will the overhead of copying game object transform info (for the PhysX motion) to component transform data (for the ECS rendering) actually be worse? I am aware there are builtin scripts that do this.

Does Unity staff have any comment on when PhysX is coming to pure ECS, if at all?

 

Unity team is working on physics engine, which will work on CPU, if I am correct.

For now as you mentioned, you should be fine, using ECS for rendering and PhysX for physics. That way you are mainly bound by physics, rather than rendering meshes count.

And of course, you typically don't need render all meshes in one frame.

So technically, at current state, make sure that PhysX is able to handle count of objects you need, without rendering. Then start moving into ECS rendering, and do another benchmark/profiling. Run some stress tests, so you wont be catched by a surprised.