Dynamic inputs for the job system

Has anybody figured out how to efficiently use the job system with dynamic content, for example with a point cloud that is changed runtime by adding/removing points? It seems that having to rebuild to TransformAccessArrays and NativeArrays for the jobs is pretty expensive so it would not be an option to update these every frame and there doesn't seem to be any mechanism for updating the arrays efficiently after they have been set for the first time.

In my case we have a large number of objects that are individually rotated every frame - this would be a perfect match for the job system but because these objects are added/removed/enabled/disabled dynamically every frame, I see no efficient mechanism for rebuilding the input data for the jobs.

 

You use JobComponentSystem for this suff? Or only Jobs in old approach? NativeHashMap, NativeMultiHashMap, NativeQueue, Concurent extensions, PostUpdateCommand command buffer - solve all this needs.

 

We are on 2018.1 so jobs only and we've only got NativeArrays. The problem is that while I'm running the job from Update(), objects that are part of the job can get enabled/disabled so I'd need to separately keep a list of modifications to the current job setup, then apply that before running the job again on the next Update() - I obviously can't modify the input arrays of the jobs while the job is executing. This means additional garbage generation.

It seems that TransformAccessArray has a mechanism for deleting items from the array by moving the last item in to the place of the deleted one, so would need to do the same for my NativeArrays that I also need. I also need to pre-allocate larger NativeArrays so I don't need to re-allocate them every time a new item is added. As an additional pain-in-the-butt when reallocating a NativeArray it doesn't offer a mechanism to initialize it with the existing array data, the copy-methods only copy between arrays of the same size so looks like for-loop is the way to go.

Given that the operation I'm trying to accelerate is basically "a.rotation = b.rotation" and I've already got 200+ lines of code for all this, it's not exactly robust solution.

 

The way I handled this with jobs is first I created a partitioned game object pool, being that such a thing is generally useful anyways for the most efficient transform hierarchy, and especially in the context of jobs where you really want to just allocate once.

Basically a partition has two NativeArray's. One for the transforms and another for metadata. So the jobs iterate over the metadata and then act accordingly based on whether the object is active or not.

On top of that the logic for obtaining an object from the larger pool uses partitions in sequence. So I know which partitions need their jobs to run, and I know for the one partition that is just partially used what it's index is. So I'm only iterating over data where an action is needed.

FYI the entity system is available in 2018.1 it's in a package.