Watch this if you've never tried JOBS in Unity (Tutorial)

[@madpingui5007]

Awesome video im just starting in JOBS system! Few fixes i can potentially see: 1. you dont need to do complex math to get the direction angle to the player you can just do lookRotation = Quaternion.LookRotation(Vector3.forward, direction); direction being the positions substracted normalized, that saves math calculations in all 15000 units. 2. There is no need for IsDone since awake always happens first than any update. 3. TransformAccessArray should be Disposed on OnDestroy ideally. 4. Also there is no need to create a _enemyTransforms, you can just _accessArray.Add() every enemy once its instantiated. Hope this tips help a little bit. Thanks!

[@Noixelfer]

Also, you can calculate the distance first and use it to get the normalized vector a bit more efficient (by dividing PlayerPos - transform.position to the distance). And considering that most of the enemies will be outside the given range, you can do an early exit by comparing the square magnitude towards the enemy and only rotate the enemies that are far away.

[@naolshow]

The overhead at the end is not from job side, you are not disposing the rotation native array. And also you should not allocate and dispose the arrays each time since you are using the Persistent allocator, so either keep their reference by creating them at awake and disposing them in on destroy or simply allocate them and dispose them in update with a temporary allocator.

[@RobLang]

Really cool overview. Really appreciated the look at 15,000 individual jobs because I think the overhead would catch many out!

[@majin2909]

I know you since 1k subs, I am glad u didn't gave up and are that far on youtube, hope you are making a good living now, at least good enough to survive

[@OIndieGabo]

Just to add my take on "why 2 libraries for Jobs exist" and also why we keep seeing libraries (namespaces) with the same name. I am not sure if this is exactly the case but the JOBS library is an isolated solution. It might not necesserally been written to work solely for the UnityEngine. It is a solution on multithreading in a specific scenario. So you have the solution "Unity/Jobs" (using slashs so youtube does not mistake it with a link). It contains everything to make Jobs work. And then you need an implematation that actually takes advantage of that system and applies its usage in the way it needs to its own solution. That's why you have the "UnityEngine/Jobs". It is basically the UnityEngine having an implementation on how to use the Jobs library, wich happens to be made by Unity (the company).

[@bcreusot]

Side note on performance improvement, (the rotation not being disposed and persistant have already been addressed). You should swap using Distance for DistanceSquared (ie : comparing the squared distance instead of the normal distance). The normal distance, include a squareRoot in its calculus which is def more costly that squaring the constant you are comparing it to.

[@magnusm4]

I love JOBS and the GPU based VFX Graph along with burst compiler and such cause it's both an optimization but also a fun and rewarding challenge to learn while making a game. But the best is what you show in the beginning. Lots of stuff. You can make a simple 2D or 3D game but the scale of your particle effects and size can be impressive and still performant. It also makes smaller projects much easier to not get stuck on optimizing and less punishing for it.

[@b5fan504]

A good video. I suspect some people may benefit from clarity that, essentially, every time you say 'thread' you could say 'core'. That's what you're allowing here; to spread more work across more CPU cores. I also like that you touched on their being no free lunch; it comes with its own overhead as everything does.

[@TheArghnono]

Excellent tutorial!

[@videogamer305]

Okay.. Im going to give this another shot. I need to start showing viewers how to make cool games and get more viewers. tough. Great video man

[@danielwertz8724]

Im a godot developer but love your videos. Feel like i still got a little out of it. Helps that I use c# in my day job and use threading frequently. Thanks for the vid!

[@AliHosseiniDev]

Oh boi that was a nice explanation.

[@redragon1229]

Cool video. I want to point out that although the ~x2 boost in your example does not look that impressive, actually, excluding rendering and other processes, Jobs can be HUNDREDS of times faster than the same single-threaded calculations. In this example the difference is not so significant because, I think, most of the performance hit is the rendering. Also, as @naolshow pointed out: this can be further optimized.

[@user-uk9er5vw4c]

nice content, thanks!

[@muspuxx6866]

Why, at the end of the video proving it's ineffective, do you use an array but only utilize one element?

[@privatdetektivenkant5975]

Give me more!!!!!

[@정동우-n2x]

I love it

[@PhiLudo]

cool stuff

[@Dragoncro0wn]

Is it a bad idea to make the thread function like an update loop? Always running in the background doing its own tasks

[@HumanityAsCode]

You would probably run into a race condition doing that

[@HumanityAsCode]

Isn't this ECS with more steps? If you're operating on a list of 'entities' as it were why not skip the job and go full ECS

[@lightbug6103]

Why are you using that _isDone flag? Regarding the MonoBehaviour code, there are small things that can be changed in order to improve performance: 1. Using a list of enemy transforms instead of GOs, so you don't need to access the transform for the 50k enemies. 2. Grabbing the player's position before entering the loop instead of calling "_playerTransform.position" every time. 3. Using Tansform's "SetPositionAndRotation" instead of ".position" and ".rotation". 4. The following operation "direction * dt * moveSpeed" can be rearranged to improve performance like this: "dt * moveSpeed * direction" or just "direction * (dt * moveSpeed)" 5. I know Time.deltaTime is not a big deal, but I usually cache that as well. I'm not saying this is gonna beat Jobs, but it could make a difference nonetheless.

[@dawid6211]

As far as i know, it is a bad practice to call Schedule() and Complete() on the same frame

[@k-6353]

Hi, I've seen JOB system when I started using Unity but i thought it was way too advance for me (i still do). All in all, Does this mean i cant implement JOB system into AI bots? or is there another way to optimize? Currently, I reach 20fps after spawning nearly 100 AI bots, equipped with Movement(patrol, chase many more), Combat etc. I get 15 fps with 350+ bots with their main AI script disabled. Would be greatly helpful if someone could lead me into a direction

[@rrainix]

How are you instaniating 15 thousand enemies so fast?

[@Coco-gg5vp]

First

[@GostGostcic]

this video is so bad, he could make this code 10x faster with jobs but he made so many mistakes in the video lol

[@OIndieGabo]

This comment means nothing if you are not pointing out how the solution would actually be improved. There is no harm on pointing mistakes out and explaining them so everybody can grow on it. What you did here is just offensive. And if this is was your intention it becomes clear why we should not listen to what you are saying and just ignore you in the future.

[@GostGostcic]

@@OIndieGabo [ReadOnly] works only on native containers not the normal variables, boid Transforms should have null parent (this is extremely important) and updated only with TransformAccess.SetLocalPositionAndRotation(...), then he should show profiler because this is not the bottleneck (because can handle 100k+ updates per frame easily), he is doing something else wrong. i could go on... but the point is, dont watch this, he is missing the point of the JOBS and what they do.

[@ehabelbwab1783]

@@OIndieGabo Agree

[@frankrenzulli4354]

I CAN'T FKING HEAR YOU, TURN UP YOUR VOICE PLS :(((((