#[Q] Reference types in Jobs

1 messages · Page 1 of 1 (latest)

humble sonnet
#

In a multithreaded job, i want to instantiate prefabs from a pool, which requires a reference to that pool.

But same as for burst, it seems that job structs only accept native types (non-blittable data). So i can not reference a GameObject for example.

But how else would i achieve multithreaded instancing of already pooled objects?

tight kettle
#

Why would the pool itself not be at risk of race condition in a multi threaded context ?
You can always try to use GC handles but you are probably headed for trouble 😵‍💫

humble sonnet
#

omg wayne games : () i watched your tutorials man, thank you for putting these out!! 👍

#

i get back to your answer, i just want to make sure i understand everything correct before i write back

humble sonnet
# tight kettle Why would the pool itself not be at risk of race condition in a multi threaded c...

For the race conditions, i would second these (for now) as i could use global counters or switches that involve tolerance values. Refering this topic i'd have the question though, why a native type like int for example would not be prone to race conditions- are these catched by unity or why is native type ok to use?

My current problem is more this; can i even use the job system for pool instantiation?

#

This was how i tried it, but then got the error that told me i cannot use reference type in jobs:

image.png
#

Inacse anyone is interested in my initial problem:

Coming from Monoworld and OOP, i prototyped my (3D) game, which requires spawning and despawning up to 1500k animated units within just a second. Looking at profiler that time, this lead to microlags where physics spiked to high in one frame (eventhough i used pooling and coroutines).

I then recoded everything using HPC# (removing managed lists, dicts, replacing them with arrays, shrinking code logic, etc). I also distributed spawning among several frames. But this still is not enough, it still feels not fluent and spawns > number 500 - 1000 units cause still microlags.

I then heard about DOTS, which seemed the solution to my problem. But turns out it is not production ready and i couldnt make my game in the current state of DOTS (1.0).

I was then pointed out to use bursty and the jobsystem without Entities, to get the benefits of multithreading.

...and here i am now, trying to multithread the actions that caused spikes in mainthread.

rustic zephyr
#

making instantiation async is your best bet I guess

humble sonnet
rustic zephyr
#

also preallocating pools, so game process doesn't get lags while doing

rustic zephyr
#

no work arounds

#

GameObjects are part of C++ half of engine

humble sonnet
#

Ah ok, dang, i wonder if my game is even possible to do without DOTS then 😵‍💫

rustic zephyr
#

1500 animated objects doesn't sound like smth trivial

humble sonnet
#

i even removed all dicts and lists and replaced those with arrays

rustic zephyr
#

that's not really an issue

#

allocating memory is expensive

#

so what you might want is to allocate all your objects before game started

#

and then instead you don't instantiate, but just enable them

humble sonnet
rustic zephyr
#

then spread it ever more

humble sonnet
rustic zephyr
#

also, do you really need 1500 of them?

humble sonnet
# rustic zephyr also, do you really need 1500 of them?

Unfortunately yes, the game depends on these massive waves like in the game "they are billions", where you have a base and then big hordes of animated zombies storm towards that base. 1500 is kind of the max number though, i tested with this number and it seems i wouldn't need more

#

Incase you are interested, here is the wavespawner script before trying to job it:

📎 ManagerWaves.cs
#

(not to check for the details, but if you overview it a moment, you will see i implemented all the things for more perforkmance already)

rustic zephyr
#

that will not be trivial

#

you might want to check alternatives on animator or whatever components you use

#

I'v seen smth on asset store about instanced animation

#

other way around - you could try Kinemation

#

from latios

#

this will be pure dots way

#

and require rewriting most things from scratch

#

there's probably more things to consider

#

I don't know all of them

humble sonnet
#

i saw this (kinemation) in a big forum thread in unity forums, i was about to try this but was then adviced not to use entities as i will get problems at other places

rustic zephyr
#

yeah, you will

humble sonnet
#

but it seems dots may be the only working solution

rustic zephyr
#

if you really want dots and animation - look at latios framework

#

it's the only pure dots framework with animation

#

he also developped his own physics

humble sonnet
#

...
What remains a question is the jobsystem (which should enable multithreading): if i can't use reference types there, then it is (for mono world atleast) not of much use, as i couldnt job more complex tasks like, fetching object from pools, right?

rustic zephyr
#

jobs are create with burst in mind

#

their best use case - heavy game logic

#

as in: calculation of some values

#

positions/damages/stats and etc

humble sonnet
#

like positional movements, and math functs like lerp, slerp, etc?

humble sonnet
rustic zephyr
#

any math will work with burst, as long as it doesn't have reference types

#

in pure dots, literally all game is unmanaged, so pretty much everything is multithreaded and bursted

#

but, there are so few ready solution for it and several critical bugs

humble sonnet
#

i am very unsure at the moment if going back to DOTS or not. It seems the right solution to my problems, but then i may get stuck on other places. The game is critical to me, this is my first serious project which i planed to go on steam with when ready.

#

i will look into kinemation again, i think this is the best thing to do right now, thank you for this tip 💪

#

(will try to get a poc working, and then see where to go from there)