#ecuzzillo1106 any idea what is the meant

1 messages · Page 1 of 1 (latest)

noble solstice
#

i doubt anybody thought about it. it seems to me that you are using transform hierarchies in a rather unique way

#

i'm sort of curious about what your overall scheme is and why these things are in the hierarchy relationship they are

glossy stratus
#

it looks like this basically.
What I want is to process all entities from System to each Planet and attach SharedComponent that matches system
So whole hierarchy of system will have same unique shared component that differs from other systems

#

I don't want to attach any components manually to each individual prefab

noble solstice
#

i'd say that's surprising in itself. how many entities are in a given system?

#

(i'm surprised you want each system to have entirely separate archetypes from every other system. i would think you would have things in common to process between different systems)

glossy stratus
#

for the default scenario 😅

noble solstice
#

that's not a very big number

glossy stratus
#

yeah, but add to it other systems

#

number of which is about to jump into around 50

noble solstice
#

ok, but having a unique shared component for each one means they cant' be batched together in a chunk

#

which slows everything down

#

why do you want to do that?

glossy stratus
#

shared component is required for game logic

#

that separates

#

entities that coexist in same world

noble solstice
#

paste some of said logic?

glossy stratus
#
        private partial struct FillMapJob : IJob
        {
            [DeallocateOnJobCompletion] public NativeArray<ArchetypeChunk> chunks;
            public NativeMultiHashMap<int, TargetData> map;
            [ReadOnly] public EntityTypeHandle entityHandle;
            [ReadOnly] public ComponentTypeHandle<LocalToWorld> ltwHandle;
            [ReadOnly] public ComponentTypeHandle<StarNormal> starHandle;

            public void Execute()
            {
                var count = 0;
                foreach (var chunk in chunks)
                {
                    count += chunk.Count;
                }

                map.Clear();
                if (map.Capacity < count) map.Capacity = count;

                foreach (var chunk in chunks)
                {
                    var entities = chunk.GetNativeArray(entityHandle);
                    var ltws = chunk.GetNativeArray(ltwHandle);
                    var starID = chunk.GetNativeArray(starHandle)[0].systemID;

                    for (var i = 0; i < entities.Length; i++)
                    {
                        map.Add(starID, new TargetData { entity = entities[i], position = ltws[i].Position });
                    }
                }
            }
        }
#

here I create hashmap of all potential targets for target finder

#

based of their system index

#

which is key in HashMap

#

so later AI can use that map to know

#

which objects exist in the same system

#

and which it can interact with

noble solstice
#

curious why is this not using ijobchunk?

glossy stratus
#

legacy code, still haven't upgraded project past conversion

noble solstice
#

and starnormal is a shared component huh

glossy stratus
#

no, it used to be a copy of it

#

but IComp

#

will be removed as soon as I finish migration

#

since there are unmanaged shared comps now

noble solstice
#

i wonder if you didnt' need the copy since the archetype knows the shared component index of all its shared components

#

which is unique for each unique shared component value

glossy stratus
#

yeah, but index didn't really match systemID

#

so

noble solstice
#

oh right

#

you can map that back later, but probably not any more convenient

glossy stratus
#

anyways, key point is how I add components to children of transforms

#

is there even a way to query through game objects like old conversion system?

noble solstice
#

i have no idea but i'm sorry to report that i think you are unique here, and moreover you are using transform hierarchies as a grouping system, which is definitely a bad pattern

glossy stratus
#

in runtime, there are no trasnform hierarchies

#

they only exist in authoring

noble solstice
#

true

#

which i agree is better

#

wait but hold on

#

this job you posted

#

that only runs at startup, right?

glossy stratus
#

no, it's running every tick

noble solstice
#

do solar systems get stuff added and removed from them?

glossy stratus
#

it grabs targets not for planets/systems

#

but for spaceships/NPCs and etc

noble solstice
#

hmm

#

so here's my idea

#

the root of the solar system gets converted to some entity, let's call that the root entity

#

on that root entity, you can put a component with a list of all the system's targets

glossy stratus
#

oof

#

yeah, I get what you mean

noble solstice
#

when you bake the parent, i bet it'll let you look at its gameobject transform children, and you can write down some ID of each of them

glossy stratus
#

I already did similiar stuff trying to solve gameobject field reference

glossy stratus
#

in BakingSystem, there's no access to game objects

#

at least, not that I know of

noble solstice
#

no i mean in the baker

#

of the parent

glossy stratus
#

yeah, you can actually GetEntity

#

of any game object

#

in subscene

#

it'll be a valid entity

#

but you can't modify it's archetype in any way

noble solstice
#

but you dont' need to

#

if you just write it down in the collection on your parent object

glossy stratus
#

yeah, that's what I'll have to do I guess

noble solstice
#

then when objects enter and leave the solar system, you modify that collection

glossy stratus
#

overall it feels like it added one extra step to conversion, ngl

#

if previously you solved everything at once, now you make extra step by creating temporary baking components

noble solstice
#

so in general, my increasing opinion is that baking is just the best. can be painful up front, but the restrictions mean that it's much harder to destroy your iteration time

glossy stratus
#

I understand doing ECS in runtime, but in baking...

noble solstice
#

well, wouldn't you know, baking is in the iteration loop, and you want the iteration loop to be fast

#

soooo

#

restricting what you can do in a baker means that it's way easier to guarantee correctness while not always rerunning all bakers on everything all the time