what is the proper way to create native static lookup tables for burst usage? while using managed arrays work as long as they are static readonly you can’t reference the lookup table in a variable (for generic use).
and you can’t have static native arrays instead of managed ones (Burst error BC1091: External and internal calls are not allowed inside static constructors)
i could make something like a singleton but that’s quite ugly in my opinion
Lookup tables? Like a HashMap? There’s NativeHashMap for mutable purposes and there’s various implementations of a BlobHashMaps on this forum if you want readonly and efficient hash maps.
not really. a simple lookuo tables such as
public static readonly int3[] CubeNeighbors = {
new int3(-1, 0, 0),
new int3(0, -1, 0),
new int3(0, 0, -1),
new int3(1, 0, 0),
new int3(0, 1, 0),
new int3(0, 0, 1),
};
as said before this works fine on its own but i can’t have a generic function where i can pass this lookup table (or another) into it
example: neighbors with and without diagonals for pathfinding
Create a struct that fully encapsulates the static readonly array and implements an interface. Then have another that does the same thing for a different static readonly array.
that would kinda be
also note that its just for jobs / burst not entities
If you aren’t willing to make the abstraction using interface-constrained generics (compile-time), then you have to use NativeContainers or SharedStatics at runtime, which may be a little slower.
i don’t see why i would need interfaces. i already have a type NativeArray i only need to be able to pass one or another static lookup table of that type to a function.
i only have issue with defining the tables as NativeArray as static (since you cant define them as static), accessible variables that can be used in jobs or normal c#
like jobA calls ProcessNeighbors(data, lookuptableA) and jobB calls ProcessNeighbors(data, lookuptableB)
the above doesnt work with static readonly int3[ ] because i pass it around as variable what burst dislikes
Static readonly arrays are baked into the Burst code generation and don’t necessarily follow conventions of NativeArray and friends. You can’t pass these arrays around by reference in Bursted code like you can with NativeArrays. So instead, you need some handle that knows how to access a particular array instead. That’s what the struct with interface gives you. That’s unfortunately the only way to make this work with Burst right now.
Why not use a blob array ? It will work in burst. You could have a singleton that store all your blob array (lookups) fetch the lookup you need from main thread and pass it in your job.
i dont quite follow but it sounds just like storing the tables in a singleton (via interface) and from there passing the right one to job.
at least that is pretty much what i currently have but i’m not a big fan of doing it that way. but it sounds like there is no way to do it without passing the lookup table to the job so i need something like this either way.
another question i have is about function pointers and data because they are next on my todo list. unless i bake huge lookup tables for all combinations i need function pointers to calculate costs or other things based on the type (replacing abstract class implementations). the question is how can i access data from within the function pointer without the job knowing about requirements of them? i cant find anything about that in the docs
well about function pointers… i want to die…
there is no way i can even remotely create a similar functionality as with abstract classes
main reason being they need to be static as well as other restrictions
but i will try some more and create a seperate thread for that i guess