Question How do we work in DOTS conversions? Is it appropriate to set up scenes normally, then convert once?

hello

DOTS has some changes or is it the same?

https://docs.unity3d.com/Packages/com.unity.entities@0.16/manual/conversion.html



" 1. Live Conversion in Edit Mode
When in play mode, the Subscenes will always stream in the runtime scene sections. When not in play mode, the existence of the converted entities depends on both the "Live Conversion in Edit Mode" option and on the availability of the authoring representation (Subscene in edit mode).

When a Subscene is in edit mode, the authoring GameObjects show up in the Hierarchy window of the Unity editor and can be interacted with. The runtime representation for the authoring scene referenced by the Subscene will only be available if "Live Conversion in Edit Mode" is enabled, and since every change in the authoring representation can potentially make the runtime representation obsolete, this conversion will happen every time something is edited. "

im reading and it has a section:

Code (CSharp):

1. Conversion systems 101
2. The conversion process is a succession of component systems that update only once each. A big difference between those and regular DOTS systems is that conversion systems straddle two worlds, they read from one and write to the other.
3.  
4. Conversion systems inherit from GameObjectConversionSystem and run from a temporary conversion world (authoring world), which should be treated as read-only input. During update, they write to the destination world (converted world), which is accessed through the DstEntityManager property of each system.
5.  
6. In the example below, note the use of GetPrimaryEntity to access the entity in the destination world that corresponds to the provided authoring component. Adding an Entity parameter to the ForEach lambda would provide the entity from the authoring world instead, which would be pointless since conversion systems should not modify the conversion world and only write to the destination world.
7.  
8. Here's the "hello world" of conversion systems, that does a 1:1 conversion of all authoring components of a certain type to their ECS equivalent.
9.  
10. // Authoring component
11. class FooAuthoring : MonoBehaviour
12. {
13.    public float Value;
14. }
15.  
16. // Runtime component
17. struct Foo : IComponentData
18. {
19.    public float SquaredValue;
20. }
21.  
22. // Conversion system, running in the conversion world
23. class FooConversion : GameObjectConversionSystem
24. {
25.    protected override void OnUpdate()
26.    {
27.        // Iterate over all authoring components of type FooAuthoring
28.        Entities.ForEach((FooAuthoring input) =>
29.        {
30.            // Get the destination world entity associated with the authoring GameObject
31.            var entity = GetPrimaryEntity(input);
32.  
33.            // Do the conversion and add the ECS component
34.            DstEntityManager.AddComponentData(entity, new Foo
35.            {
36.                SquaredValue = input.Value * input.Value
37.            });
38.        });
39.    }
40. }
41. In a GameObjectConversionSystem, ForEach will not create jobs. It runs on the main thread, without Burst, and this allows accessing classic Unity without restraint. This is also why it doesn't require a call to .Run() or .Schedule().
42.  
43. Also note that the entity query looks for classic Unity components, in this case FooAuthoring that derives from MonoBehaviour. Since those are reference types, they do not require ref or in.
44.  
45. Conversion World (the input)
46. When a conversion starts, an entity is created in the conversion world for each GameObject that should be processed. In the case of a whole authoring scene, that's typically all the GameObjects it contains and all the GameObjects from all the referenced prefabs (recursively). Prefabs are discussed in detail further on.
47.  
48. Each component on those GameObjects is then added to the corresponding entities. This is a mechanism rarely used in DOTS, because using classic Unity components is something that doesn't scale. Those components are reference types and each access from ECS accesses memory in an inefficient way.
49.  
50. The only reason this is done this way is to allow conversion systems to access authoring components using entity queries.
51.  
52. Note that disabled authoring components are not added to the conversion world, so the queries from the conversion systems will not pick them up. And inactive GameObjects turn into disabled entities, but the conversion happens normally.
53.  
54.  

seems we should only make custom DOTs code/jobs and rarely use conversion of monobehavior?

can someone explain to me what is the simplest change or difference to working with DOTS unity,
should i stop the creation of prefabs and scripts? just make job scripts and entities with converted 3D models using live edit conversion mode while working>?