#archived-dots
1 messages ยท Page 69 of 1
makes me feel like that guy never came back to the discord to see my bug report there
wrong image. blender plus HDRP, plus ECS is a headache, but I like how the tutorial ship is shaping up
it's fine we talk about ecs in physics and here we talk about HDRP :)
So - I, like a lot of Unity developers haven't really had a lot of hands-on experience working on a data oriented code base. But I was interested in folks perceptions for an average game that consumes ECS, how much of a code base do you think would be fully entity/systemified. I've got a few folks on my team with AAA experience and have worked on these sort of data oriented code base and swagged it as 20% max (AI, physics, pathfinding) and the rest is more traditional "procedural" code
Basically as we start to have folks kick off projects on 2019+ - understanding "how much" and "when" to employ ECS seems like some good general advice to have at hand
I would suggest dabbling with samples, I mean it's going to help you if you like it or not anyway (since Unity's moving it's own stuff to DOTS)
but the samples (if they're visible) should help, did you try one?
Naw - not yet. I'm on a project mid production on 2017.x - you're right though I should probably poke at it directly to speak a little less ignorantly
why I don't say much here. While I have a general understanding of ECS concepts, I have no idea how Unity has implemented it and for now don't want to break my brain on it since I doubt i''m going to use it any time soon.
haha
the layman's explanation is: you make a little class of the smallest and only data you need, for example just a position (the component), and then you have a system (the code to move it)
that's all. It will be automatically performance by default and fully threaded.
its a lot easier but there's a lot more files and a total change in thinking (no inheritence) so thats the difficult part for people unwilling to change
yup - that part I get my head around. It's just for your "average" shipped game code base, how much of your code is written in this style vs run-of-the-mill procedural
like doing the behavior for a settings dialog in your game is (I think) almost positively not going to be written in a data oriented style?
you would use it for a thousand attack ships, or an army or an rts, or really, anywhere there's far too many of them for poor ol' mono to handle.
and when you get close to those in the army, there's nothing stopping you making the closest ones be monobehaviours
Seems most suited for anywhere you have N mostly independent operations
given that you can have a thousand attack ships for basically the cost of a single monobehaviour, there's a good reason to look into it for anything like what you suggest
yeah
I wonder if it's better suited as an optimization that you retrofit later vs grounds up
or if that refactor (and I realize this is all hand wavey) is more expensive
its recommended as an optimisation atm because it's not really finished and there are not yet enough unity equivalents, so they have hybrid for that
it's not actually possible to make a full ECS only game right now anyway
totally
the intention is you use it where you are slow
but, when you look forward to when ECS is a completed system - it's still only appropriate for a certain class of problems - and most games (short of AAA that know what they're doing) can probably think of it as an optimization
anyways - appreciate the thoughts. I suspect there's going to be a fair number of "how do u ECS" people rolling into here as the system starts to get stable (and increasingly hyped) and the answer is "you probably shouldn't"
Yeah it's fine, I was shipping mobile games based off monobehaviour a decade ago so it's not one size fits all
๐
yes well the way everyone talks it sounds like the new hammer to hit every nail with
^^
even unity making a 100% ECS demo seems to indicate that
"you should make your game 100% ECS"
It leads otherwise intelligent and handsome engineers like myself to ask the dumb questions
lol
I too know your pain, as a fellow handsome and intelligent engineer. ;p
theres a good gdc talk on the architecture of overwatch using ecs, theres no mention of specific % but i just get the feeling its more than 20% of their codebase(but thats just my totally unscientific and luddite impression)
In this 2017 GDC session, Blizzard's Timothy Ford explains how Overwatch uses the Entity Component System (ECS) architecture to create a rich variety of laye...
yeah lets use ECS there too.
let's not forget ecs is not just a thing for perf but also for saving money
for example with ECS you have a closed enough system that the mathematics library and burst can support with determinism, resulting in substantially less bandwidth spent on network costs
though you can do that without ecs
I just like it that its way more modular, i can screw up systems galore and it only sorta breaks my game unlike my old monobehaviour chain of dependencies with the whole thing imploding
ECS is great for anything that runs in a loop, so it's great for gameplay. It's harder to use for one-off events, like interacting with UI. For gameplay though, it really simplifies the code architecture, and I love it. I think going forward the default choice should be to use ECS, so instead of asking should I use ECS for this, it should be why shouldn't I; and if you have a good reason, don't use it.
Btw -- is Unity going to maintain a list of canonical components for eventual Asset Store creations to target? If so, is there a list? (like Heading, Position, etc.)
Or are we supposed to make our own of everything?
I'm probably just confused lol.
There is position and rotation components of some sorts, but... I don't think they're listed anywhere. They're used by the render system(s), so if you can find the source for that you might be able to fish it out.
A proper list of 'this is included in the package' would be nice, tho
yeah i'd think the basics should be there, position, rotation, scale, material
Was hoping for a list to kinda know what's already there... get some ideas and not re-invent the wheel if I can fit into something existing.
Especially if that means that my work can be compatible with future stuff.
yeah, i'm sure documentation will be coming
There will likely be a "list" in the future, but there shouldn't be one now. Main reason for NOT listing them: they have changed the transform system at least 4 times. The first iteration had a transform value and a local transform value (Ie position, localPosition) now we are on translation and localToWorld utilizations for position
I'd love a list, but it needs to be less volatile first
Easiest thing to do now: Open up the package, and look through the Tests folders to just get an idea
It seems like it's not a wrapper around PhysX
I think they use Havok for this.
public struct PhysicsCollider : IComponentData โค
Well, now we know what to expect from the keynote in 90 Minutes ๐
I'll be programming ๐
Unity Physics is a deterministic rigid body dynamics system and spatial query system written from the ground up using the Unity data oriented tech stack. Unity Physics originates from a close collaboration between Unity and the Havok Physics team at Microsoft.
Please announce deterministic lockstep sample 
subscene action
nice ๐
they got brief docs on the package itself
======
Unity Physics is a deterministic rigid body dynamics system and spatial query system written from the ground up using the Unity data oriented tech stack. Unity Physics originates from a close collaboration between Unity and the Havok Physics team at Microsoft. ```
Yeah, Archy posted it above
The most up to date use of Unity Physics is the Samples for it in the main DOTs sample repository and they cover a wide range of use cases not yet covered in these documents, such as character controllers, ray cast driven cars, and examples of all the joints.
so.. repo?
It'll be interesting to see what you think of it when you get to have a play ๐
yeah me too ๐
Watching the GDC direct at Unity's office with other people of the game industry. Lot of hype /o/
I checked the samples repo but they haven't updated it yet for the physics package ๐
All I want is native MateiralProperty mesh drawing
I think it will be directly on dots (not ecs sample one) repository which is rn private
"in the main DOTs sample repository"
that sounds like the samples we got already
unless they do another
oh there's documentation
here's the Transform docs:
this seems to be the cannonical set of Transform components for the time being
ye, I found the address to dots repository (from entity package comments) but it's still private...
https://github.com/Unity-Technologies/EntityComponentSystemSamples updated for physics
yessssss, thanks @dull copper
heh
hahahaha
there's a lot of yellow in these samples
wiiii
"trivial to implement havok physics"
Not sure what's the difference between Havok and Unity new physics
seems like the physics package is more limited, DOTS friendly thing
that you can use on netcode etc as it's stateless and utilizing Burst (so we'll get determinism once it's implemented)
hmm there's no real way to simulate having a dynamic buffer full of interfaces, is there? i have a situation in-job where i have a lot of methods with the same signature that do almost-but-not-quite-the-same math as each other. i need to re-run some of these methods several times with tweaked parameters based on their original results, and i'd like to be able to cache the large amount of reusable math done in each one. the types of the reusable math are common to all methods. this means each cache/buffer element must be able to descibe 1) the cached values and 2) which specific method implementation was used. seeing as i cannot have an interface as an IBufferElement member, i find myself reaching for undesirable constructs like the following:
public struct ThingSolver : IBufferElementData {
public float someReusableMathResult;
public ThingSolverKind solveType;
bool Solve() {
switch (solveType) {
// execute some specific Solve() implementation based on solveType
}
}
}
any ideas on a way around adding this crapton of branching to my jobs? i assume there isn't a practical way to get a map of <ThingSolverKind, Func<bool>> in job. i could give up caching the math if i had to, but i still need to store a collection of ThingSolver to indicate which ones need rerun. the alternative of course being bool rerunSolver1; bool rerunSolver2;...
You could write separate jobs for each thing type and use a static class function library
it's perfectly fine to call code outside of the job structure as long is it's functional (no side effects)
well the results of the various methods depend on one another, useless to do them separately
point being, you could pull the critical fuctions out of the job to make it easier to compose the logic you need per solver type
oh that's kind of interesting, i didn't realize i could, say, maintain a static dictionary in a job-external static class, call into a function of that class that reads the dictionary, and burst wouldn't complain
I thought burst only liked its own collection types and it would hate that
guessing the point is that in the situation i described the dictionary itself isn't burst compiled
can you even burst compile something that isn't a job? this job is where all my big math is, so moving the math out if i can't burst compile it is also useless
I also thought jobs only liked their own collection types - sorry
I haven't explored all this enough ๐
frankly i am not clear on why that even works either, i just assume the job can't "see" the dictionary because it's private to the external static class, so it doesn't care
so wait
Unity acquired Graphine?
I had to google after watching that keynote part again
yes that's what they said in the keynote
hopefully ๐
so far they've not supported SRPs, their plugins have often dragged months behind Unity releases and they haven't supported height map streaming for vertex shaders
so, if they really get it integrated, it will be awesome
@manic aurora - the latest burst releases have added readonly static support. There's several caveats, I'll see if I can dig up the link
EDIT: here it is: https://forum.unity.com/threads/jobs-any-way-to-access-static-data-safely.541070/page-2#post-4329229
i saw that, but it reads like it's only for arrays?
kinda sucks they'll not be streaming this tomorrow: https://schedule.gdconf.com/session/follow-the-dots-presenting-the-2019-roadmap-presented-by-unity-technologies/865465
It will be on YT soon enough I guess
yeah, few weeks probably
I'm hoping to we could get at least slides for DOTS roadmap + regular unity roadmap sessions
as those are the most interesting bits at this point
@manic aurora - yeah, you could bake the lookup if the key can be converted to a unique integer, but for most datasets that aren't massive, a for loop equality lookup is pretty fast
So quick question: Anyone who has used the new physics package, are you happening have a problem with having dynamic physic bodies settle?
Dynamic objects cant seem to settle when only colliding with dynamic bodies
that would make sense
I'm hoping this is a bug atm and not intended behavior with dynamic object interaction:
Yep. Really doubt it is intended XD
stable stacking is an old problem of physics engines (remember tables exploding, once you touched an apple in oblivion?). I'm sure they are still very much working on this, though.
ECS only being done in a short hour window (45 minutes) tomorrow?
So Nvidia is working on a package replacing Unity's PhysX with PhysX 4, Unity is also working on their own PhysX upgrade separately, there's also Unity Physics and then there'll be Havok support.
That's a hell of a split personality syndrom ๐ค
@gusty comet in a dots / ecs world this kind of thing feels very natural and i hope we see more of it ๐
@lilac ermine Ehh, you mean spreading resources around unstead of focusing on one thing?
Unity won't work on the Havok support in the long term and PhysX is a dinosaur, so this is very sensible - what would you want instead? A pure focus on PhysX and a poor interface with ECS?
@solar spire if there won't be long term Havok support, does that mean they'll add Havok just to deprecate it later? ๐ค
Havok will support it
They're working together to get the details down but in the long run Havok does all the work on their end and they request a few features in the protocol layer that likely benefit Unity.Physics anyway
I see.
There is a dropdown for simulation type in one of thephysic components in the examples. You can just switch to Havok so that might be interesting to test later when it is available
If they provide a test that doesn't require you to license!
They're working together to get the details down but in the long run Havok does all the work on their end and they request a few features in the protocol layer that likely benefit Unity.Physics anyway this ๐
so you'll be able to swap implementations "trivially"
i lol-ed pretty hard at that part
it's important to note that full Havok is most likely to cost you a lot of extra $$$
so it's not really direct replacement of anything in the big picture here
it's like external FMOD or WWise integration is to Unity now, additional extension (despite the built-in Unity audio runs on FMOD)
and you license it separately
I'm mainly wondering what Unity is doing with PhysX now as it can't be coincidence that nvidia just came up with their own PhysX plugin for Unity yesterday
well microsoft own havok and they touted it as part of their gamestack platform, im assuming a license agreement but i doubt a hefty cost
considering they've said there will be cost, it's going to cost something
and if they would bundle it with Unity Pro, that would be a huge mistake
as it would drive unity back to the old model that made people leave unity in the past
kinda sucks that we have to wait to the summer to find out
I don't really agree, Havok is a third party, if it's bundled with Unity Pro that would makes sense just like Unity Services is for Unity Pro only. It's not an essential part of the engine, it's something someone else did and, while there may not be a free alternative, it's still outside of the basic features of Unity
that's a dangerous path
Unity 4 had essentials on the free side
and fancy stuff on pro side
this didn't really work well for Unity
if anything, if it's not available to all Unity tiers, I hope it's a thing they license separately
and I don't really agree on it not being essential part if that's the only full blown out DOTS physics offering Unity will have
where Unity Physics package goes will determine how essential it'll be
of course I'd hope DOTS physics could cover all use cases
Unity is already playing catching up on providing the source code access
competition gives full engine and editor sources
and then moving more closed source stuff behind paywall?
I dunno, that's just not great option
From the blog we can see that it will not have caching while Havok will and that would be the main difference
after looking through the new code and demos for Unity Physics it seems that all the fundamentals all there, and then some, and i'm sure they'll build upon it. Are there many things that aren't there yet, which the legacy system can do and should be supported? It seems to me the havok option will be for very advanced use-cases or extreme performance situations, which seems reasonable for the 0.01% that will need it.
what is more performant, C# physics in Unity or Physx right now?
in that case, you shouldn't bundle a thing that 0.01% benefits of into Unity Pro license
it should be a separate thing
also the performance thing is not really something you should be worried about today ๐
it's first public preview
it's buggy, it gets more stable after they iterate on it
if havok is bundled with pro or I get a free license then all is well, and I become a havok fanboy, promoting it endlessly. if not then booo sucks
:D
I don't really mind that they give option to use full Havok, having options is great
just afraid they ruin the tiering system again when they just got it fixed
they haven't said they do that tho
and I'm fairly confident that it'll be an additional offer
yeah i'm sure i've heard Unity in the past talking about how important it was to them to get the structure right so that all developers would have the same tools out of the gate, it would be surprising to move away from that ideal.
but on the other hand they do offer lots of services at additional costs.
services are different tho
this is key element in the game engine
but that being said, I really want DOTS thing to cover most use cases
it's kinda weird to see that they even offer c++ Havok
must have been some deal they made with the DOTS package developement
as Havok team was involved
yeah, to me it sounds like havok probably heavily collaborated on the development, so Unity gets a quality lightweight engine quickly, and havok gets some marketing and an access point to the Unity developer marketplace.
yeah, that's how it sounds like
and that's fine
now only need to wait for nvidia to step up and implement the DOTS api for their physx 4 plugin ๐
i really appreciate that its open source, and i've heard from many unreal engine folks that say its been one of the biggest limiting factors with Unity, that they can't see or extend all the parts that have been closed. So its a huge step in the right direction in that regard.
well unity partnerships have add value and ralph (the guy behind partnerships) is a very smart guy just not as big as lucas is
I upgraded CE's CryPhysX from 3.3 to 3.4 in few days
I implemented PhysX contact modifications in ~week for UE4
I've asked for contact modifications for Unity for years now I think, it's not there
but at least the new Unity Physics package has something like it now
not having the code access limits these things a lot
when you get the sources, you just can do it yourself
and not wait for years and pray if something happens or not
I don't appreciate unsuppoted open source
because ultimately I do use unity because it's saving me time, so there is that.
so i like open source that's bankrolled
yeah, I mean source code availability now for a commercial tool
not some side project from one person ๐
having the sources available helps to minimize the risks
if you don't have it and get a game breaking bug on the engine side, you can't do much
just wait and hope Unity will fix it asap
but we have a lot of examples from commercial projects that went sideways because those fixes took so much time
hmm is there some tweaking you have to do for some of the physics demos? seems like the character controller and vehicle demos play way too fast
it's a bug
strong early showing
they simulate physics at fixed delta time
but run them once per update
it probably happened because entities package recently moved temporarily simulation group from fixedupdate to update
but they forgot to change it on the physics package with this tight schedule
I'd guess the easiest fix is to just modify the physics package to use regular deltatime for the time being
it will not do fixed timesteps for physics but at least physics would simulate at right speed for now
Is the megacity out now or after gdc?
7.1gb nice
@urban rivet Graphine may have patents, but now Unity owns those patents... so they can do whatever they want with them ๐
@solar spire if PhysX is a dinosaur, then Havok is the primordial ooze all life came from, because it's way, way older ๐
Dem Havok barrel stress tests though. 1k, 2k, 15k...
If we can do that kinda physics in unity...
@lime dome yeah, he was really talking about Amplify's end now
but yeah, Unity is safe
Would whatever dissecting the megacity give, still be a standard tech?
Like they started it last year, and ECS has had quite a few changes since then; and hopefully more... although the 30 minute keynote tomorrow is a little disappointing
yes
well, they have their custom tech in it
but it runs on stock packages
there's zero modified packages included
it's probably the first tech demo Unity has released that didn't do that since the package system came here
I don't see Amplify in the conversation but whatever ๐
@lime dome ah, it was on another channel
though it was here since you replied here
[5:31 PM] hippocoder: (don't quote me ;) )```
totally respecting his request here ๐
@lime dome that is why they bought graphine, is my point.
otherwise you cannot have best in class streaming
but anyway that could've been unrelated, just shrug! but looks like I will have to port to ECS to take advantage of perf
yeah I saw you mentioning moving your char controller to ECS
honestly I think that's seeing everything as a nail
but I could be wrong
(don't quote me ๐ )
well I'm usually good at nailing it
owe, touche
I think it's likely for simpler scenarios that the hpc# physics will be faster, a lot of my physics time is spent on OnCollisionStay and it's friends
I dont have a choice really because I need the reliable per frame contact info
because of VR?
because my game relies on reliable contact information to make a rigidbody character, a vehicle, and several other things function well, including audio contact for dragging, rolling and more across a surface, including pushing objects with different masses in playable way without impeding character movement without resorting to kinematics, and so on (there's a more reasons but it will bore you)
in short, I really have good reasons for it. I used to approximate and avoid, and have done years of research avoiding stay, but stay has the best data.
I just can't get to it in physx due to closed box. Also the new physx are in dots so also a closed box
i might as well become schrodinger's cat, and you never know if I'm alive or not because of how long it takes for my reply here.
I can see you typing ;p
there's always observable phenomenon ;p
wait im unclear on the unity dots physics
but regular physics works well enough for hundreds of items moving around as it is
they mention its a collab between havok and unity so its a totally new thing not physx right?
its new
so i'm unconvinced needing 1 character and 1 car justifies jumping to ECS
probably spiked from an existing havok code base
yes thats the use case but
do you want me to get into it?
I'll have a ton of characters and thousands of rigidbodies
which I do in physx right now
I'm just telling you what the requirements are on a technical level for one of those characters
yes tell me of these thousands of rigidbodies, you're burying the lead ๐
lol
but yes ... I would need to port all of my code in my game (I think most of it) to dots
and if i want networking without hassle, I should do it
if multiplayer, probably
it's not atm
but i plan it for the period when I port it
so i release single player -> take some sales -> invest in mp same time as ports
if the pain is less sooner, it's better than a bigger pain later
but the timing is bad
yeah things are in big flux atm
"Our goal which may or may not change is to be out of preview around Q3. " thats unusually fast
(regarding physics)
with what featues tho?
anyone can be out of preview with a few boxes
if its feature equivalent to physx, thats insane
I'm expecting the featureset to remain what it is
it's covering all the basics already
cloth included?
it will likely have way less control really
verlet integration
they are doing nvcloth in 2019.2
for physx tho
but it sounds like it's going to the old side of the engine, yeah
mainly to replace the PxCloth implementation
just make your own cloth in ECS using the new ESC physics
I wouldn't be surprised if the cloth change was transparent to users
if it's really faster, should work fine
cloth intersections are the tricky parts
high performance cloth is really hard though and would require extensive experience in dots to achieve
the actual integration is trivial
yeah that's where the no-scene physics comes in ๐
can use it to calculate the intersection collisions
but most engine users don't want to implement their own cloth solvers
they want something out of the box
๐
like half of the things I've bought from asset store
currently one can paint on the same skinned mesh and have instant flappy bits, it's really great and powerful and does not need intersection or self collision because the skinned mesh by large avoids that taking place...
I've bought quite a few things, and I've only had maybe 2 items depreciate
by having verlet, you would have "cloth on it's own" which I find utterly useless tbh
last thing I bought that got deprecated was Granite :p
so from my experience it's more like a 5% attrition rate
this google announcement is making me vomit, I can't argue while i'm queasy
lol
the more expensive and specific the asset, the higher risk it has to get dropped
the picture is coming clearer that unity's HPC# physics use the same math as havok, but the implementation is up to unity staff, and that they're taking the hpc# physics seriously
art etc packs tend to stay there forever but I don't really buy that stuff
but it will not work with gameobjects, so....
ECS physics is the future
I remain open to being impressed and persuaded that Unity isn't going to be making a HLAPI depreciated pigs ear of it
And Gaia is redundant and FinalIK is redundant
well I'll be patient
so they will do cloth eventually but cloth is not joints
perhaps if I read it right
so...
it's time for me to port to ECS isnt it?
struggles and cries
@lime dome make it hurt less
just try the samples, play around with it
then make prototype with it
see if it even works for you
also, fix the bugs from current version ๐
well given the physics and networking only actually have improved performance if you put your gameplay in the same memory location with no barrier, there's not much of a choice, you will have to port most of yout game unless it's purely cosmetic
hmmm
Gonna read through it when I get home
@urban rivet I really don't believe that is true
they would release a physics preview when im halfway through writing this ecs SAT solver ~_~
networking only need send your position and rotation, and other status of your character
it's not like it's a ton of data
if ECS cant handle moving a few kilobytes between ECS land and Mono land, it's DOA before it starts
I do - I think for gameplay you either go through the physx bottleneck (as yant has described) or you go through the ecs bottleneck (hybrid). This means that since you're pissing away performance by converting data back and forth from monobehaviour and dots worlds, you might as well either:
- remain with physx
- bite the bullet and go for dots physics
for the latter it makes sense you fail to reap the benefits without your code in ecs too
well if push comes to shove i'll stay with non-ECS because it's proven and works
FOMO :p
but I still have to even get into ECS
I haven't worked with it so I can't really say what it can't or can do
if you are old school chances are you will rapidly fall in love OR hate it
well I've worked with ECS before
just on a different platform
and I found it very elegant once I got into it
but it is a whole other way of thinking than traditional coding structures
I guess my hesitation with ECS actually was the lack of physics and networking without going through hybrid
yeah I can get that hesitation
I just cannot stand doing something half arsed. It's like putting the tip in and not going all the way (of a drill bit of course, you know)
i'm really waiting for ECS to mature before I dive into it because I hate learning one thing then having to change midstream
amen to that
2019.3 seems to be when everyone thinks either star wars will un-suck or unity will be ready for dots in general
wonder when they get AI for DOTS
problem for me is, I'm at the crossroads where if I go dots now I can still be on track for a demo in august....
and the thought of having a ton of ai running around, a little army, is fantastic..
man, I'd love to see the GDC sessions on dots now
:(
especially the one we are missing right now ๐
heh, of course it's arowx https://forum.unity.com/threads/where-is-ecs-on-the-big-seven-now.647266/
but it's a relevant question
why if it isn't another arowx thread.
I'm just glad he's not babbling about memristors or such
also how can hybrid be green
and pure is orange lol
if hybrid is GOOD
then pure should be GOODER
pure will always be better than hybrid
actually his graph is defeating me
right so the colour is the state and the column is the api
yeah this visual confuses me greatly
and input being green in 19.2 is going to be news to @midnight sonnet
it's as if arowx achieved determinism and knows when things will be stable and finished
well then he took credit for it
"this is what I want to see from unity" lol
makes it sound like he made it
he thinks ecs is a separate thing, ecs is just a descriptive name for how the program is put together
that unity logo ๐
ofc illegal to do it but good enough
I saw arowx mentioned
โ ๐ฝ
๐ user review
I remember following some descent into madness with his whole making ECS query like SQL
Just for the morning banter
you never go full arowx
that 3d stacking DRAM thread was a ride
if I am converting and injecting a gameObject to Entity how do I find the representative entity without GameObjectEntity?
"you never go full arowx" -hippo
That right there is the quote of the year
you don't need to worry, discord is fully monitored, no abuse will occur
teasing IS another story though :P
o man entity debugger finally showing systems in my non-default worlds, i love this
the physics has me diving back into the world of ECS - I wondered "what if I could make megacity destructable...?"
except I can't compile megacity right now for some reason :/
Hmm how much does the physics cover or is only basic rigidbody stuff at the moment?
Most of the case right now is rigid body
RB + Queries + some Joint stuff
It has all the core elements of a physics engine: rigidbody integrator, narrowphase, broadphase, collision solving, tons of different joints, collision primitives, convex + mesh collision, queries
It is more complete package than most here think it is
It just needs a lot of polish
It is mainly missing caching when comparing to other physics engines
Hello! Is there an alternative link to the megacity demo? Can't download it from the google drive link on the site. Thanks!
https://ole.unity.com/megacity_demo_gdc19 is the link, if it doesn't work then ๐คท
Its downloading thanks!
Hmm... what's the "correct" way to program an ECS system when you have interactions between entities? Ex: Let's say I have non-uniform time of day around a scene... for whatever reason. My thought would be to make a series of time of day entities. My expected approach would be to make a System that operates on pairs of entities that contains specific components... but that's probably wrong. (The obvious way is to have Time be hybrid or some other object that injects into a system but let's pretend it needs to be an entity.) How would you do it?
I'm pretty sure you cannot create a system that operates on two entities, one that contains (series of time of day components) and another that contains (clock hand rotation components)... correct?
(And I know that it's not "contains" it's "has index of" but grammar is hard lol.)
I'm pretty sure that is the correct way, to grab two separate sets of entities. Not sure how you would get that without some black magic tho, which would probably lead to a 'bad' way of doing it
@analog tangle I think the most modern examples of how to approach these sorts of things that you'll find right now is from the new physics demos. eg. https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/UnityPhysicsExamples/Assets/Demos/6.%20Use%20Cases/CharacterController/Scripts/CharacterControllerComponent.cs
Oh wait a minute... component dependencies are per-job, right?
Right so I just need a system with multiple jobs. One that operates on the "time of day" components. Gets the info I need. Passes it to the "clock hands" job.
The system doesn't care all the combinations of components that its jobs operates on, correct? Or is there any exception?
(thanks @tawdry tree and @mint iron btw)
But yeah, is there any exception?
just trying to see what i can get away with in ecs physics using multiple physics worlds. here i have "ghosts" that follow the player by some millisecond interval, each simulated in their own behind-the-scenes physics world, but the obstacles get copied into the each delayed ghost world at their true positions. so the effect is you see player inputs as if they started N milliseconds later, but the collisions are accurate for the ghosts despite not being in the "primary" physics world. i'm aware you can achieve the same effect easily with one physics world, haha.
edit: notably, 4/6 of the simulation jobs are parallelized here. finding pairs requires a complete(), but the rest of each simulation can be scheduled after that!
double edit: this scales bad. too much waiting on main thread in every physics world. lots of idle time
https://gfycat.com/tameunripecornsnake
that very last guy seems to be very confused lol
@analog tangle the system uses all component types accessed anywhere to calculate dependencies. Which data is accessed in which job and in which combination isn't important. You can just do what you want but may not schedule two jobs without a manual dependency between them if they access the same data and one has write access. The method you describe is perfectly fine: Job A reads data into native collections which are passed to Job B which runs over some group and uses the data from Job A.
thanks @visual dock
got a response for why experimental audio api isn't in 2019.2 (needed for megacity audio package): The Audio System in Megacity is built on top of DSPGraph (which is available in 2019.1 as an internal API and inside Unity.Experimental.Audio namespace). We are working at moving this into a package and hoping to make it available in preview to the users as part of 2019.2. In order to do this we had to remove it from Unity's code base in 2019.2.
@manic aurora thats really cool. Do you know if it has a linear increase in performance cost when adding worlds or are they sharing resources?
I noticed that they're rebuilding the bvh's from scratch constantly which is probably taking up a huge amount of time, if they can get an existing one optimizing/rebuilding only what is necessary for moving objects it would be a big improvement.
seems linear (actually worse, because every additional world adds more sync points / completes during processing) to me. in the case of my example can apparently skip updating the dynamics world, which is a nice boost, but the feeling i get from experimenting is that it simply wasn't designed to run LOTS of worlds at once
Is there documentation included with the new Physics package that I'm missing somehow, or is it an "explore and figure it out yourself" sort of thing?
seems like the demos are all we've got right now. i kinda got the basics worked out, but stuff like modifying contacts still mystifies me. although i enjoy that you can hook custom jobs into the physics world chain
oh nice
t's the same docs as with the package
but I still don't know how to read md files nicely locally
I know, I just keep forgetting that option ๐
when I try new things from staging, that link goes nowhere
so I don't usually click it
just letting everyone know seeing as there's apparently 3 of you ๐
oh man that is nice, good find โค
For any physics features that do not cache state, e.g. raw collision queries, we expect Unity Physics performance to be on par with, or outperform, similar functionality from commercially available physics engines.```
ummmm
Core algorithms are deliberately decoupled from jobs and ECS to encourage their reuse and to free you from the underlying framework and stepping strategy. As an example of this see the immediate mode sample which steps a physical simulation multiple times in a single frame, independent of the job system or ECS, to show future predictions.```
doesn't this mean that part will be a) single threaded b) non-deterministic as it can't use burst?
there's a tidbit at the end of collision queries that talks about how it uses burst if you're calling it inside of a burst job yourself
so I wonder if that can apply to the whole thing
well i think the physics simulation applies burst regardless (i.e. their internal jobs), just the collision queries are defined outside of jobs so wont be burst compiled unless they're called from one.
but, yes, the "immediate mode" pool sample DOES run multiple simulation ticks "single threaded" - the physics simulation will leverage multiple threads, but each "tick" requires a .Complete(). you CAN simulate multiple worlds somewhat in parallel, but in the pool case it needs the result from the previous step to calculate the new one
I have playback UI that send events to an audio loader that decompresses audio from disk and sends completion result to an ecs playback system(it will track the progress and sync notes from a chart). What I currently wrote works, but it's awkward cause UI and loader post both to a global event bus and to an ECS one(by creating entities with an event component).
How would you ECS-ify all this?
Not sure about UI, but the goal is to get rid of the global event bus and basically replace it with an ECS event bus instead?
It's not entirely clear to me, from what you wrote.
@dull copper It... depends. They might mean "decoupled from jobs and ECS" in the way that Unity.Mathematics is.
@tawdry tree well I'd like to do everything inside systems. But I have async code that has to be run from System.Task and I'm kinda lost with designing around it. I guess I should maybe spawn event entitities for Mono communication as well ๐ค
You can fire off a job and save its job handle instead of completing it the same frame for a similar effect, I believe
Nah, it'managed code.
I'm using NLayer in one case and UnityWebRequest in other cases for loading audio from disk so.
That'd make things more complicated, yeah. Not sure if there is an actual way to fully ECS it.
I just wonder how to design communication between all this. Like the playback system needs to check if loading failed, if track was paused, if it was resumed, control the AudioSource etc. Maybe I should just make everything poop out event entities and be done with it. Sorry for asking such an abstract question, the paralysis of choice is just killing me.
I think the best thing to do in such cases is to just make something, and then when you (hopefully) got something working, note down both pros and cons(like pain points, perf, etc) of whatever solution you came up with. Hopefully you at least learned something, and got _something_working, and if you're actually working in ECS it should be relatively simple to refactor later, if you ever decide to.
Such is life with preview packages.
anyone know if raycasting can be jobified for the new physics? not really sure how you call the BuildPhysicsWorld system from a job
nevermind started reading the documents
there is a demo with raycast inside job
which example was that? I only saw monobehaviour stuff but i couldve overlooked it
script MousePickBehaviour
it calls CollisionWorld.CastRay(rayCastInput, out var hit) inside a job
Hi people, quick question we still don't have a way to find the origin of JobTempAlloc leaks right ?
Answering myself: always try to restart Unity because it will self repair
ah thanks, didnt think to look there!
eh so I can query a hit in the same job that I schedule the raycast? that seems too easy after all this time of doing two jobs for raycasting with the physx job
@dull copper it means they want you to be able to use it without ECS. So you have the flexibility to use it for performance with custom burst jobs. Like just spawn some colliders and start ray-casting them in a normal non-ECS project.
All the queries are pretty much using burst jobs, so being burst compatable is not an issue - its designed to be (ConvexHull and BlobArray are blittable and could be shoved into NativeArray). I would expect them to be making it parallel compatible if its not already. Most of the jobs are IJob but BlockStream.Writer is used in a IJobParallelFor.
Hi all. Iterating over some entities in a chunk I can access related entity data using ComponentDataFromEntity e.g.
public void Execute(ArchetypeChunk chunk, int chunkIndex, int firstEntityIndex)
{
NativeArray<SomeEntityData> relatedSequenceEntities = chunk.GetNativeArray(SomeEntityDataType);
for (int i = 0; i < chunk.Count; ++i)
{
//relatedSequenceEntities[i].Value points to another entity
//sequenceSettings[relatedSequenceEntities[i].Value] contains 'SequenceSettings' data for said entity
}
}```
My question is, how do I do a similar thing to check if a related entity (`SequenceSettings` entity in this case) has a particular tag/component?
sorry that was a dumb question - I can just use another CDFE with .Exists I think
Reminder that you can put 'csharp' after the first triple backticks to get code highlighting. Note that you need a new line after that, so:
```csharp
//code here
```
You can also do ```cs ```
anyone know how triggers work in the new physics? dont think I saw an example for it in the samples
So what's the style opinion on helper methods in IComponentData? Ex: Converting the value to other units. I think it's a definite win but \_(ใ)_/
The real question is : does it bring you joy ? If not, discard it!
#EntityMarieKondoSystem
(I personally don't have use case for them)
this might be a weird question but is the Unity ECS a "native thing" now? I paused GameDev for some months and wanted to know if there are enough ressources to get into it (beginner friendly). Maybe Entitas is still an alternative? I didn't find many resources out there and when I got one the tutorial looked very "experimental" .. ๐ค thanks for help! ๐
@knotty radish It does bring me joy. :p I like having one place (that's unit tested) to see how many game time ticks are in an in-game hour, etc. :p
(Not time as in Simulation Time. Time as in time of day, which in-universe day, etc.)
A note for other crazies like me that need to mix async Tasks with ECS systems: PostUpdateCommands is not captured inside async methods the way you expect it to and by the end of the task you'll have a reference to a disposed postupdate. I have to run an async IO task from a mono and from there it posts event entities to EntityManager without any problems.
Ah cool. Thanks @gusty comet
Probably not relevant to most people but I don't want to write my own jobified mp3 decoding so stepping on a rake it is ๐ฐ
Very much so, MegaCity for us was a stress test of:
...
Ensuring simulation & rendering and soon integrated Unity.Physics hold up in a world with massive amount of entities```
well, I'm not going to try integrating the physics package to megacity then ๐
Is it possible to iterate components from a Mono? I need to get all AudioLoading events from ECS inside my UI controller.
Okay, nvm. It's possible with .CreateComponentGroup. Weird that it requires a temp job allocator though with ToComponentDataArray. Ah well, components are 0-sized anyway so I can just calll group.CalculateLength().
Yeah I was wondering the same thing
And actually ToComponentDataArray is populating a NativeArray with a Job so TempJob make sense
Just weird that you need to pass an allocator but only one value works
why are people surprised it's a stress test? the moment there is a way to do the same task much more efficiently, is the moment you must assume smart people are doing the demo for another purpose like stress testing :P
in real world scenarios, I don't expect more than 10-20k of live objects in an optimised open world game - and this is on the highest worst case scenario, so imagine the performance of 200k, applied to 20k, and we have a winning AAA streaming and rendering system
you'd be applying all the classic partitioning concepts so it would be a lot less than 200k
brilliant for mobile too
Another dumb thing, why is any info about system update so hidden wtf. Now I have to figure out how to use ComponentSystemGroup since you can't use [UpdateBefore(typeof(EarlyUpdate)] anymore.
Is there .apk of the megacity demo for android?
not that I know of
Is there even a build released? You have to do it all yourself from what I've seen
Just download it, open the project and build
yeah exactly
Just go to GDC and play the demo there.
I have a build if anyone wants a look, will delete from google groups in a few mins
I mean google drive
That's the worst emoji reaction I could get ๐ข
I don't have a computer available at the moment so cannot build myself :)
Anyway, pls help, how do you make a custom update order now? Where one system must be ahead of everything for example.
Well, megacity isn't just about rendering all that stuff and in fact it's ugly, it's unpolished,.... but it's also streaming it all from disc, which is a nice thing
I think you need to wait for the next update to handle update loop order correctly
But how? How do you specify that you want this system to be ran last without getting a warning about non matching simulation groups?
put them in the same simulation group
You could also manage your systems manually but yeah it would work with putting that system in the specific group you want
Okay, I think managed to make this work. I just put the old event removal system in a custom group EarlySystemUpdate that runs before SystemUpdate and destroys all entities with Event component.
The rest of the systems belong in SystemUpdate group.
Can't post events from Monos this way, but I circumvent this by creating unmarked events from monos that are destroyed by relevant systems and then forwarded but this time marked with Event component.
Hi!
Since ecs physics are now released, I wonder if it is time to continue my ecs bullet hell game,
but I am not sure if I should go with the new physics system or make my own 2d system and orient myself on the 3d solvers Unity included for the new physics system.
(I would only need circle and line shapes at first, maybe lines with a certain line strengh, so that would be 3 solvers. circle-circle, line-line and line-circle).
Any tips/suggestions?
@minor sluice Unity is working on 2D ECS Physics atm afaik
at least that what melv suggested on #โ๏ธโphysics the other day
so if you only need 2D physics, might be good to wait a bit
nice to know, thanks! I might just wait a bit more then.
I would assume that it will eventually come, but I am not sure when the time is, since the ecs samples are updated though, I might take a look at their physics samples
(melv = unity's 2D physics dev, in case it isn't known)
oh, I didn''t know. awesome
we got anthony on this group too (yant on the forums), he's doing the physx stuff for unity
maybe I should visit here more often, the other discord servers are general game dev and brackeys, which are somewhat focused on unity of course, but this might feel like the go to place for new unity developments and people working at/for unity
I love dedicated groups like this
those generic groups attract more "tire kickers", people who love the idea of doing gamedev and spend their time mostly talking about it ๐
that's my impression from the generic groups I've been at
I don't usually stay long
the issue is that I am pretty much procrastinating in the other groups ^^
oh yeah, you are right. In fact, I got more done before I joined discord
this group is really nice and clean, a lot of less trash talking than on the unofficial groups
plus I love the presence of Unity staff here
and recently it is more like I start some prototypes and drop it again, but since ecs is now further developed, I might want to revisit what I started back in may 2018.
Aside from that, I will probably try myself at a rollback networking implementation in the next weeks, (similar to what Photon TrueSync was before they shut it down, but p2p)
right now, I'm really waiting to see the DOTS roadmap talk
it could answer so many questions on the immediate future of Unity's ECS
mainly curious where they are going with the AI + when we get the full editor (but I don't really expect Unity to give ETA)
for example, they just got this out https://forum.unity.com/threads/ai-planner.649246/ and since it's been cooking for years, it's not for DOTS
there's been no discussion on navigation either
What is encouraging for me is seeing in the physics examples how they've implemented inspectors for setting it all up, and the examples are easier to consume for a non-technical person in the sense that you can drop in a cube, add some monobehaviors and have it work. That easy interaction is the cornerstone of the application and the speed behind Unity Physics under the hood is still there.
So hopefully that spreads out to all other aspects of the tool eventually. The same sort of workflow that draws people into the software and why they like to use it, just much faster. Sure you will have people that want to spend the time messing around with the low level stuff and its important to have that option, but yeah, momentum will come from the higher level use cases.
@dull copper AI Planner seems DOTS based. BaseAgent inherits from MonoBehaviour but it works with Entities
it is a rather big shift of rethinking to go from the traditional system to their new ECS one,
I wonder if they included all main features you have with the regular approach into the DOTS, if it will also be equally as easy to use it as it is in the current system
accessibility is a big plus of unity, but imo, to utilize jobs and profit from data locality, you have to make some specific preparations.
But, you could still use the ECS system in a sync way without having to use jobs
@final fox really? I only opened otto project I didn't examine the code itself ๐
I'll do some digging, thanks for the heads-up
Yes, I'm fighting against the code generation (the otto project works but I can't do anything from scratch).
Frankly i don't see much of a difference if you're working with it at a higher level. You still have a bunch of objects, its just that your work happens in a separate manager instead of on each object. Conceptually its the same as having a bunch of enemies spawned, and a separate singleton or whatever goes through and moves them all.
public sealed class PlannerSystem : ComponentSystem
๐
what I also don't get.
you can put functions/methods inside your structs, but I guess because you want to benefit of the architectural separation between logic and data, people don't do it?
even though you can be sure that the method only affects data that is component internal
It's considered as "bad design choice", but sometimes "bad design choices" are "good hours preserved" ^^
I too wanted to see the talks from Wednesday GDC but I have yet to see any videos from those talks
it's going to take ~week to see the videos I predict
at least that's how long it took last year for first videos to arrive
hmmm, that AI Planner and latest Entities package don't go along
had to update the AI Planner for some things
hmmm...just opened the ECS Space Shooter project and updated everything - PositionComponent and RotationComponent are gone?
position is now translation
is it TranslationProxy?
I see, so PositionComponent renamed to TranslationProxy and RotationComponent renamed to RotationProxy
@gusty comet where did you get the space shooter project? ๐
I mean, wasn't that in the ancient ECS samples?
current repo doesn't have it anymore
or is that some different thing? either way, a lot of things have changed since
I got it working, idr exactly where I got it let me check
@dull copper https://github.com/UnityTechnologies/SpaceShooterECS
ah, they still have it up
yeah, updated 3.5 months ago which sounds like it would be recent but at the pace ECS is evolving, that's lightyears ago ๐
nice that you got it going tho ๐
should a ConvertToEntity script always convert the hierarchy? getting a situation where a child isnt being converted not really sure how to debug it
should
that's how the HelloECS samples showcase it
I dunno if it works if you have multiple ConvertToEntity scripts in the hierarchy itself tho
@safe lintel
or the hybrid GameObjectEntity thing
well: the child object doesnt get converted unless I add the old GameObjectEntity
but with or withiout extra convertToEntity on the child objects nothing happens
it definitely converts the child on these without any scripts on childs: https://github.com/Unity-Technologies/EntityComponentSystemSamples/tree/master/Samples/Assets/HelloECS
yeah ive seen that demo, thing is I have a monobehaviour (on the child) that implements IConvertGameObjectToEntity and in Convert just logs a message but the message never gets logged
also technically should work with multiple ConvertToEntity scripts in hierarchy as the physics CharacterController setup features this(but it also features GameObjectEntity scripts on the child objects for some reason)
hmm appears if you do inject on the root the child objects dont get injected, but having ConvertToEntity on the child doesnt appear to do anything with either inject or destroy
https://www.dropbox.com/s/x13l6ilhqkkufou/GDC2019-Roadmap.pdf?dl=0 hmm strange no mention of dots animation even though theres a package on staging
it was posted to reddit by https://www.reddit.com/user/lumpex999
yeah dropbox link use is strange but the guy seems to have a pretty strong unity news game so i figured its real
well thank god for reposts because using twitter is just ๐ฉ
the amount of times ive clicked a twitter link and it fails to load is just mind boggling
this is what people were fretting over in that email
wish i could make software that awful and get rich off of it
floating licenses are coming, they were just getting feedback from clients
yes please
looks exactly like how Blender ended up doing it
it's been in 2019 for a while, you can try it out ๐
i hope that window ends up being dockable
feel like an entitled brat but it just irks me the way it isnt currently
@safe lintel you didn't spot DOTS talk slides there, did you? ๐
prob should take this to general
I mean Unity did a separate DOTS roadmap talk
i perused the dots section while i was outside, might have been blinded by the sun if i missed a dots animation segment
@solar spire and lol, I have been polling Will's forum profile in case he'd post that
he shared the previous events roadmap slides on dropbox too
well
this image isn't quite selling me the ease of use
yeah, I'll stop spamming now
that DOTS-only standalone sounds cool, also what I estimated
I think visual scripting reminds me more of scratch and friends than kismeer, blueprints
huh
to me it's super messy
the thing they showed before, the leaked 2019.2 package for visual scripting was nicer
it still used the same style stacking
but that for each node....
lets just hope they'll keep iterating on the UX
I think the stringent limits allow for strong optimisation
we're talking about something artists can slap together that outperforms anything youi're doing in non dots c# land
and artists are everywhere
its if as performant as it should be...
might be cool!
yeah but if you look at that node, does it look easy to use for you?
there's just too much going on in single place
it looks like someone stuffed the whole function inside single node
when the idea on visual scripting is usually to assemble the function logic with the nodes instead
oh
hmmm, that seems like some wip thing, wonder if they meant to set it to public yet
commits made by Joachim
So... for my personal sanity... if I have a JobComponentSystem and I want to early-exit in the situation that I don't need to do any work in that system (ex: timeScale is 0'd during a pause) could I just return inputDeps?
Or does that have any weird consequences?
I'd figure that'd be exactly what I want -- return the previous head of the list of jobs to do without adding my job to it.
that is the intended way to early out if you're manually setting up the data to process in the system
if you use component groups you can mark them as RequireForUpdate(_group); and it won't execute if there are no chunks that match.
If your systems is simple and uses IJobProcessComponent* I believe this is done under the covers.
also, RequireForUpdate works for multiple groups, so if you have group A and group B, but both to do work, it won't run if both are marked as required and no chunks match
if you need to deal with optional groups then you have to do it manually with _group.CalculateLength()
Cool. Thanks @untold night
... >.> I keep forgetting if this Discord has a karma system lol
I don't think it does
I do wish there was "RequireAny" variant if you had a bunch of optional groups but thats something you should generally avoid
@dull copper i actually rather like the direction of the visual scripting look - though of course it will need ux improvements. always preferred more of a blockly or gameflow design than bolt / blueprints
its more familiar to people who are already working with shader and vfx graph
same sort of thing, same ui as well
still a bit concerned what perf would be like. Should I hang up my keyboard?
I greatly suspect that there may be many cases where hand-rolled HPC# code will beat out Viz scripting, since it can't make the same kind of micro-domain assumptions a programmer can. There's a good chance it'll enforce safety where one could conceivably bypass it and that might be the case where you'd want to refactor into hand-rolled code.
Although being able to hand something to a designer and have the system generate thread-safe code kind of beats out any complaints I would have.
Also, when has a Viz scripting system EVER eliminated text-based programming?
Somebody's got to rewrite an entire graph inside a single Blueprint node and it sure isn't the art director
that's just it, the overall contribution of scriptable content pouring out of the art dept would be safe and only require me to basically act like glorfied QA
albiet experienced :P
I'm moe concerned about the networking and how much work all that would be. How much can they automate if we stay inside dots?
it's kind of crazy, think about it. It's like 3drad or limited torque script all over again...
yeah but how many artists are writing collision systems, whole voxel engines, etc. Unless they're that one person who did and the perf is terrible because the node system is still an abstraction over hand-written code, and has a lot of temp vars and such.
t..ttorque sCript trauma flashbacks start playing in background
WHY WAS IT ALL STRINGS?
WHY
but it's also quite safe and that's very compelling for any studio big or small:
- safe
- threaded
- low barrier to entry
- freely edit while playing
THERE WERE MEMORY LEAAKS EVERYWHER
you make salient points
back on topic fine now
good ol torque script. it eventually gave birth to torque2d and the same melv may now handles unity's box2D integration
HOLY CRAP HE DID WORK ON THAT DIDN'T HE
he invented it
something about his name seemed familiar but I couldn't put my finger on it
I suppose you know you've made it big when a large game engine company hires/acquires you for the thing what you made
....twice
since torque2d was his own thing with torquescript and garage bought it, hired him and...
so he gets bought a lot and just goes with the flow
ah, I now remember seeing his name on the torsion splash, holy crap
Should I hang up my keyboard? personally, i long for this day
the keyboard doesn't love you
all you do all day is poke it spitefully
you barely clean it
sometimes you blow on it as if it's a bad smell
Nooooo. I gently pet it... and at times use a highly pressurized air can to help clean it....
One of those 2 things at least seems kind ๐
hello there is this a good place to talk about burst?
also I know this is supposed to be UnityECS, but if I want to share some Svelto.ECS articles, should I do it here?
if anyone read my previous messages, this is the link to my burst problem: https://forum.unity.com/threads/burst-for-standalone-players.539820/page-2#post-4352314
more commits here https://github.com/Unity-Technologies/DOTS-StreamedInstancingSample/commits/master
thanks
We are engaging ECS on our project to a small degree and to that degree it is helpful. There are certain restrictions, and the parts that we would like help the most are not suitable for ECS workflow. i.e. they contain sub-meshes or have certain types of animation on them. Having these in mind we would consider using a different workflow in the future. It is definitely worth it, and hopefully ,as it is still a work in progress, ECS will expand to become more inclusive regarding the types of assets it can work with.
if there are two JobComponentSystems A and B, B has [UpdateAfter(A)]... when OnUpdate in B is called, can I be sure that the jobs from system A are completed?
or do they come in as the "JobHandle inputDeps"?
Pretty sure UpdateAfter is specifically meant to make them... update after the other one.
It was either that one or another attribute that was used to create synchronization points
In your example,
- OnUpdate (main thread) of "System B " is called after OnUpdate of "System A"
- There is no guarantee that the jobs scheduled in "System A" are completed, when OnUpdate of "System B" is called
- If "System A" and "System B" share component types, the dependencies " come in as the "JobHandle inputDeps" "
Oh yeah, the inputdeps themselves are the sync points, herp derp. I really should get around to tinkering more with ECS, right now most of what I know is from like 4 hours of playing around in preview 17 or something plus a bunch of videos and articles of varying freshness
Hey everyone, I'm looking to catch up on some of the latest Unity tech, and I was wondering the best way to get started with ECS. I've seen a few of the high-level keynotes and tech talks, but would love something a bit more focused on actually building with it. Are there any up-to-date tutorials, or sample projects to learn from?
So, they updated the old samples:
https://github.com/Unity-Technologies/EntityComponentSystemSamples
The HelloECS samples show different workflow setups.
The Physics stuff is brand new.
They've updated the Boids samples and added some new feature tests to work off of.
If you have the bandwidth on your machine to handle them, the https://unity.com/fps-sample and https://unity.com/megacity have actual working ECS projects. The Megacity is as close to "Pure" ECS you're going to get outside of UTiny, the FPS Sample will be updated and converted as more ECS features get built, it's already move more things into ECS recently.
I haven't messed with any of the UTiny stuff, so I can't tell you if there's good samples or not but it forces a kind of ECS that will be merged with the main ECS stuff (namely, it's workflow will merge with the main ECS and UTiny will eventually use the same C# stack as main ECS)
Great, thanks for taking the time to share all that @untold night
I'll check out the ECS Samples repo, and maybe give UTiny a look. I'm primarily interested in ECS for improving performance on old and weak hardware, so that could be a good fit too.
can UTiny build to Android?
I Know that UTiny is targeting web/messenger games/instant games as it's "priority zero", I don't think it currently supports anything other than that right now. Once they start merging to the C# codebase then they can probably target everything else.
the normal ECS should work on Android devices now if you make an IL2CPP build.
the best place for up-to-date UTiny information is probably the UTiny forum section: https://forum.unity.com/forums/project-tiny.151/
Cool, thanks again!
@untold night A lot of that is because a lot of the Project Tiny team are ex-Mozilla's gaming division.
(ex: Vlad, Martin)
That makes so much sense
Ah, nice links
Regarding Tiny, does this content just work on mobile browsers as well?
Was there a release for the C++ variation on unity? I remember seeing a plugin once upon a time... The DOTS slides are in C++ so just wondering if it was a common ground to work on
@full stirrup there's no official c++ thing
Unity's closed source engine side code is done in c/c++
but the scripting is on c#
you probably mean HPC#
which is unity's c# subset for DOTS
There is a means to have C++ "drop in files" for Windows Players at least: https://docs.unity3d.com/Manual/WindowsPlayerCPlusPlusSourceCodePluginsForIL2CPP.html
I've not used the feature myself, and I don't know if it applies to any other IL2CPP platform
I've used it
but it's not really like c++ support
it's similar to native dll's with the exception that with that you can build your c++ files on the same dll with IL2CPP build
you still need to write same c# interop stuff for it
that would have made many past project significantly more convenient though. I am both pleased it exists and upset that it wasn't in place sooner.
@urban rivet Here's an example of them running Project Tiny on a web browser in a smart watch. https://youtu.be/EWVU6cFdmr0?t=1907
March 23, 4:00 pm (San Francisco) - Learn about Unity's new solution for creating smaller, faster, lighter experiences that will enable you to reach everythi...
So yeah... it can be either native or web on mobile.
Yeah, and obviously - builds
Does anyone know if the 2D stuff in Tiny is intended to become the 2D stuff for ECS in general?
I think they've already implemented sprites and simple collision among other things.
I was wondering if anyone can give me a little insight into how to make this code more efficient... I'm guessing the biggest problem is that I don't know how to efficiently schedule ECS work.
System that updates time of day entities. https://pastebin.com/FNSuVVta
System that rotates the hour and minutes hand of a clock: https://pastebin.com/ya2My9ND
Tag Components for Time of Day and Clock Hands: https://pastebin.com/Ax0d4pDr
ComponentSystemGroups and Barriers for Time of Day and Clock Hands: https://pastebin.com/PnftdUPC
Not listed:
GameTimeOfDay -> Component that contains an int corresponding to tenths of a millisecond in game time.
GameDeltaTimeOfDay -> Component that contains an in corresponding to the amount of GameTimeOfDay that has been added since the last frame
GameTimeOfDaySpeed -> Component that contains a float, which is the multiple over Time.deltaTime that the game speed runs at. (Ex: 4 = 4 in-game seconds per Time.deltaTime second)
Initial values are set in the spawners.
Some things to look out for:
- RotateMinuteHandsJob and RotateHourHandsJob seem to require a dependency between them... shouldn't I be able to just have them depend on getTimeOfDayJobHandle and combine their dependencies on return?
- I shouldn't need to create my own barrier for UpdateTimeSystem... should I? (It's there in case I wrap over midnight and need to assign that tag to it. I could ignore it until one of Unity's barriers. It'd leave a few systems with an out-of-date date, though.)
- I shouldn't need to .Complete() getTimeOfDayJobHandle... but Unity throws a fit if I don't. Is there another way?
- Anything else that you see inefficient.
It's kinda silly to do these onsie-twosie things on a one-off system, but it's good practice. It's knocking quite a bit off my framerate, though. (Down from ~250FPS to ~190FPS... which is a larger impact than just using monobehaviours.)
I'll be getting food so @ me if you want to reply. I'll respond ASAP.
@analog tangle - looks fine to me.
2 points about perf:
- The editor adds a bunch of safety checks to ECS and debugging GC allocs that can affect performance. You can disable this along with certain levels of logging from the Job Menu. You should always profile in a build to get accurate numbers for pef tho.
- EntityCommandBuffers aren't fully optimized even excluding Burst limitations. They've mentioned somewhere on the forums they'll look at that later. However, since you're using IJObProcess with the command buffer, you can use EntityCommandBuffer.Concurrent structure and schedule the job as .Schedule(this, inputDeps) instead of running it on one core. That can help comp until Ecbs have a perf/burst compatibility pass. You can use the index parameter as the jobIndex parameter for the concurrent ECB calls.
I was talking about performance in a build.
Thanks for the ECB call... I used ScheduleSingle because I was getting errors lol. Makes sense there'd be a Concurrent version.
Although the test world only has one DateTime state so there's not much to multithread :p
Ah if you have a low set of elements the scheduling overhead may not be worth it. You can call Run instead of Schedule and it'll execute immediately on the main thread which for smaller loads may be more beneficial
Curious if it'd give a boost anyway, though... like if the way it's scheduled would be significantly different.
Oh really?
Good to know, thanks! @untold night
Yeah... I should definitely look into Run()
Was wondering how "the ECS pattern" would apply for small numbers of elements.
Yeah... while I haven't fully tested it, switching the one-off systems to "Run()" made things much faster.
yeah, I believe Joachim mentioned in a forum thread somewhere that if your code takes less than ~.15 ms to execute or some such number, that's when it's not worth multithreading it.
I couldn't find the exact number, but Run() does basically exist to run jobs and bursted Job code on the main thread if needed for low data loads.
Yeah. It still seems a bit heavyweight... wondering how much of that is something Unity will iron out... and how much of that is just "meh".
"It" being a bunch of one-off systems that act on single items.
Unless it's a one-time cost for just having anything ECS in the system at all... I'll need to test with that.
I mean, you can't really burst the code right now. Might try it as a componentSystem and see if that's a bit better? You won't have any job overhead at least
Like if your code is simple enough, JobComponentSystem may be overkill
especially if you only expect to have the main one time of day entity
Yeah. It's just toy code at the moment.
I'm not expecting to make an Alice in Wonderland world with varying time of days lol
It's actually a very simple game in terms of time of day.
and digging through the forums, it looks like the range for job scheduling is somewhere on the order of "if it's less than about ~.5 ms, the scheduling overhead beats the job savings"
Yeah... and these guys are 0.05ms under run. I don't think they'd even be picked up on the profiler if they were a Monobehaviour.
I'd definitely convert the main Time of day update to ComponentSystem and see how that fares. If you have a lot of things that rely on that time of day change later in your system chain, that's probably the thing to multithread
Yeah this test is interesting that's for sure lol.
It works right now so I'll leave it like that for the demo, but it'll be something I look into when it's time for retakes.
Thanks again @untold night
Hey guys,
I am just in the beginning for ECS usage but one thing I didn't get in my mind how to do. My plan was to have most of my game logic in ECS and the data stored already in the ECS layout. But how I would create a bridge to get ECS data out of the ECS world into the old Unity eco system? For example I would have the whole movement of my character in ECS but when it actually moves I want to trigger the correct character animation which I sill have to do with animator on a GameObject. Can I somehow easily link my entity to a gameobject in the scene and use that in a ComponentDataSystem?
How you would approach this?
I have an entity bridge script but I'm not at home rn :/ There are many ways. ISharedComponent, keeping a map of entity to mono, posting event entities and queryeing from a mono through a compoment group... Hacky shit.
You can actually ForEach monos from ComponentSystem so that'd be the least hacky.
In your ConvertToEntity inspector disable destroyal and then your entity will have a mono attached.
Then you can just Entities.ForEach((Entity entity, ref DumbComponent MyDumbComponent, MyMono mono) => {});
Hi Guys :D I'm into some trouble right now. I'd like (inside a job) access to some chunks using a entity reference (that I just get from another chunk). How would you do that? I mean, sometimes ago there was something like ComponentDataFromEntity, but with the chunks I don't have a clue of how to proceed.
@oblique fractal it's still CDFE's - assuming you know how to do a normal job/chunk iteration, you're basically already there - something like this I think:
[ReadOnly] internal ComponentDataFromEntity<OtherEntityData> otherData;
public void Execute(ArchetypeChunk chunk, int chunkIndex, int firstEntityIndex)
{
NativeArray<SomeEntityData> entitiesForLookup = chunk.GetNativeArray(SomeEntityDataType);
for (int i = 0; i < chunk.Count; ++i)
{
//entitiesForLookup [i].Value points to another entity
//otherData[entitiesForLookup [i].Value] contains 'OtherEntityData' data for said entity
}
}```
and when you create the job, something like: `otherData = GetComponentDataFromEntity<OtherEntityData>()`
Thanks @amber flicker I give it a try !
Hey guys ๐ I'm starting to implement a custom rendering system for non instanced meshes. I was wondering about the Blob functionality that was implemented in 2019. Should I use that stuff to handle my meshes? seems like it can be serialized with the world. That could be useful. But there is not a lot of information about what is the goal of Unity with this blob stuff.
the most I've seen of it is in the physics samples for building collider / joint data and passing it around.
I'm looking to use it to migrate scriptable Object data
I do think the design intent for it is "immutable after creation" but don't quote me on that until we have clearer documentation
so it may not be the best choice if you're doing a dynamic mesh, then again, we don't know enough yet
I think that this was answered 100 times in the past, but I can't turn my head around on how to dispatch jobs from a system and use the results of it in another system
So, for example, you have a system broken up in two, first one dispatches jobs and the second one, after who knows how much time, force the jobs to finish and do the rest
Switching from OOP is a bit of a challenge
i mean, there are a bunch of ways. kind of depends on the nature of your data. if a dynamic buffer suits it, sometimes it's easiest just to cram the data on an entity in a buffer. if you have some more complex type like a native hash map, you could stash it on a shared component or as a public member on a system that you inject into the next system.
depending on what other work you need to do, you might have better luck declaring a single system that contains a persistent container for your data. then declare two other systems/classes that expose a public method like JobHandle ScheduleWorkForThisSystem(NativeArray<Thing> myDataContainer, JobHandle inputDeps). then in your system that owns the container, you just call both ScheduleWorkForThisSystem, pass the container as an argument, and force the returned JobHandles to depend on one another. i see (approximately) this pattern a lot in the new Unity.Physics - you have some container class that both manages collections and schedules parameterized jobs that use those collections.
I don't think I really get it. Don't you need to inherit from JobComponentSystem to operate on entities in jobs?
If that's the case, returning the job handle from the main thread is required and after that I don't think you have the ability to control it.
Like... The basics. A rotating object that consist of 3 systems. One holds general data, one dispatches jobs to operate on that data, the final one which requests the job to finish and then operate on that data.
I mean, there's a lot of magic going in the background. Like, I don't get it, how do I get archetype chunks then? How do I fill it and pass them to an IJobChunk struct for it to be called from a usual ComponentSystem?
Gah! This is pretty confusing
A system which takes inputDeps as usual, but instead of using it in any way, it just creates the jobs to be queued and store their handles somehow, and returns inputDeps unmodified?
I guess, yeah
I mean, you can probably do it like that, but what is unity doing behind the black box? Maybe it's calling Complete right after scheduling, which fully throws my needs in the trash
I mean, this is pure magic. Where does the ArhetypeChunk come from? How do I get it myself to use in vanilla ComponentSystem? What about the indexes?
Do you specifically need chunk iteration for something? If you just want to rotate an object, you could just define and schedule an IJobProcessComponentData<Rotation> and modify it there.
I suppose yeah, but I would've preferred chunk iteration. Now then, for the sample scripts again. Where do Rotation and RotationSpeed components come from? Aren't they from JobComponentSystem?
Well they're from all the entities that have both a Rotation and RotationSpeed component. My understanding is that IJPCD is basically doing chunk iteration under the hood to gather the data and calling Execute() once for each Entity.
The entities themselves are your data store
I've been thinking. How bad is ScheduleBatchedJobs?
It says that it can hurt the performance, but what if I need to schedule a job at the beginning of a frame and have it done by the end of that same frame? How does unity even decide when it's appropriate to kick-off jobs? Unity is a bit vague on it
iirc the recommended use case for that is like when you're scheduling lots of jobs in a for loop, you should call it every so many schedules. you can pretty much assume that when you leave a component system update, if you scheduled a job, it will be scheduled in a reasonable time. wouldn't stress about it if you aren't scheduling LOTS of jobs
also i've never tested this, but i'm pretty sure any job you return from as a dependency from a system has to complete that frame
But, I mean, what if I schedule a job, come back to it in a bit, call Complete and it didn't even start? That's a magnificent waste of processing.
I could force the scheduling, but then again, Unity says that it's bad for performance.
just unlikely, like, id be interested if you could even make that happen on purpose. by the time something else runs where you can check the job status, it's very likely to be scheduled
I didn't get any answer in the Physics channel, but its related to ECS so; In the doc for the new physics it is said
You can choose to create you own collision worlds which are entirely independent of the physics world. However, if you are performing queries against the same physics world you are simulating, which is common, then you can take advantage of the fact that the broad phase had already been built.
Does this mean you can only simulate one world at a time? And as someone who haven't used this concept before, in comparison of using layers between two types of collision objects to never collide in what circumstances would one be better then the other?
You can simulate multiple physics worlds at a time. Dunno about the rest
Yeah I think there's problems running worlds at fixed rates so that's something Unity is looking at now, if I am not mistaken.
hey does anyone have any suggestion on how to get this "on" To Debug, enable the define: TLA_DEBUG_STACK_LEAK in ThreadsafeLinearAllocator.cpp. This will output the callstacks of the leaked allocations
i am trying to find an undisposed allocation
as in Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak
i assume it is related to this but none of the settings seem to do anything
Before trying anything else, try to restart Unity (had the same issue and it went away with a restart)
There is no way to debug that so I suggest you comment out one by one all of your components queries / injections
if I want to create a few entities at the beginning of my game how would I do that?
I'd need something that runs only when the game is started
you could have a system that disables itself after running. Or an entity conversion that creates other entities and then destroys itself
or have a MonoBehaviour that adds entities via EntityManager during Awake() or Start() and then doesn't do anything else
look at the recent Entity samples repo on github, the later versions of HelloECS demos use ConvertToEntity and the IConvertGameObjectToEntity interfaces
Here's one script: https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/Samples/Assets/HelloECS/HelloCube_06_SpawnFromEntity/HelloSpawnerProxy.cs
ah very nice, there are new samples?
thanks very much ๐
I have been inactive for about a month and did not know
Yeah they've updated the whole samples repo and made a lot of things current:
https://github.com/Unity-Technologies/EntityComponentSystemSamples
Now that ECS is approaching production-ready, a lot of the API docs have moved to official package docs: https://docs.unity3d.com/Packages/com.unity.entities@0.0/manual/index.html
woah, when I was here like a month ago ppl said that production ready will take a few years more
but they probably haven't integrated physics yet?
fully integrated into everything? Nah, several years.
Production ready as in all the basics are covered and the foundation is done? several months
I'd say several years off still for fully production ready ๐
but you can expect something usable at the end of the year
still very excited
I mean as long as I can use it and then get the benefits one by one I am fine
thanks for the informations
@junior fjord did you see the GDC roadmap slides for this?
ECS core is targeted to reach 1.0 by this summer
no not yet
that's pretty ambitious
can I find the talk?
can you share the link?
sounds interesting
still waiting to see this as well https://schedule.gdconf.com/session/follow-the-dots-presenting-the-2019-roadmap-presented-by-unity-technologies/865465
how is that pdf 200 mb size ๐
but there's no publicly shared slides or video for that
those should appear soon in gdc vault tho
I do not have access to gdc vault unfortunately
everyone get access to these sponsored talks
also in past years, all slides have been free for all regardless
ah I thought gdc vault is the stuff you have to pay for
in the end, it's like half of the actual videos go to behind paywall, all slides are free for all
and after 2 years, they release the rest for all
but if you got sponsored sessions, they usually are freely available to all
so if you see Unity presenting things there, if they are about Unity itself, you will most likely see them on the free side from day one they upload them to the vault
but Unity also did sessions on their booth in addition
apparently they recorded them as well so those should appear on the Unity youtube channel within few weeks
@untold night How do I see you everywhere? You're on the forums too all the time lol
This week I just happen to have a lot of light work tasks
so I'm doing R&D and on the forums a lot
nice, I don't know if I should feel honored or jealous : P
Hey, I would be happy if someone has time to look at my problem.
I currently make a voxel game for training with unity and I am currently on a "major" performance issue:
https://puu.sh/D6eEE.mp4
Whenever I move to generate more chunks my FPS go down horribly until the chunks are finished and combined into one mesh, if I generate them inactive and then activate the combined mesh I get a laggspike once I set all the combined meshes active.
Changing from one 1x1x256(height) to 16x1x256 makes it faster but the fps are dragged down far worse.
I use hybrid ECS.
This would be my code: https://github.com/SidiaDevelopment/VoxelWorld/blob/master/Assets/Scripts/Terrain/VolumeChunk.cs
wonder if you should be GPU instancing each block
Just fyi, this is my first project, I do this to make myself known with the engine, ill need to look up gpu instancing at first ๐
Unity makes it generally easy if you're using mesh renderer
just tick da box
mesh combining in C# is ๐
Ok, i will try if gpu instancing helps in a few mins
Any other idea better than mesh combining?
without it my batch count goes through the roof
yup
if they're voxels - you might be able to dynamically batch them
which effectively just shifts the workload down to the native layer
can you elaborate on that?
if your meshes share the same material and are less than 900 vert attributes (and no more than 300 verts) - unity should be able to batch them for you (with some minor caveats)
it does so in engine code, every frame
so there's some CPU overhead
something like voxels seems pretttty ripe for gpu instancing though
so with instancing theres no need for combining/dynamic batch?
correct, instancing basically tells unity to tell the GPU to draw the same mesh X times at appropriate places
it shifts some of the burden to the GPU to handle the instancing - but I've got a hunch you'll be fine
sounds nice, thanks for the help, ill update you on the results, may i ping you if i have further issues?
sure thing
fwiw - handling the mesh baking yourself is frequently the right answer for things like mobile where instancing isn't available on all devices yet
would lag out in the current stance on any mobile device, even my 1080 / 6700k build collapses under the current chunk generation ๐
but i guess for mobile i could just crank down the view range ๐
yeah or just min-spec on GL3.1 (iPhone 5s and above, galaxy S6 and above)
oh i come from webdevelopment, dont remind me of supporting old devices (browsers) ๐
@foggy chasm unfortunately GPU instancing didnt change anything apart from my fps when i leave them all uncombined
my fps still drops to below 20 when generating new terrain
Are there some things you shouldn't do when using Hybrid ECS to make sure to get the most out of it?
entityManager.Instantiate() cant be called within a job? exception is saying something about must be on main thread
Hi guys ๐ I'm asking here but it's not ECS related, just it does use the Entities package:
I want to serailize/deserialize meshes the fastest possible so I just started to do this:
StreamBinaryWriter writer = new StreamBinaryWriter("File.bin");
var vertices = mesh.GetNativeVertexBufferPtr(0);
var indices = mesh.GetNativeIndexBufferPtr();
writer.WriteBytes(vertices.ToPointer(), mesh.vertexCount);
writer.WriteBytes(indices.ToPointer(), (int)mesh.GetIndexCount(0));
writer.Dispose();
Sometimes it works (well it did happen only when I was debugging), most of the time it crash because Memcpy can't access the adress. I tried to use MarkDynamic() but same thing. Someone have an idea about what's happenning?
Oh I think i'm stupid and I just don't give the right size. But I don't know how to find it ^^
the new samples are great
they really are
is there a way to SetComponent or update a component value within a burst job? seems that TypeManager prevents it
my sieve brain cant remember the code syntax for discord but the examples show a good amount of changing component values in burst jobs
what does your current job look like?
i started making an imposter to fix the issues with TypeManager having managed arrays etc so that SetComponent would work. Figured i could extract the Type Index ahead of time and pass it into the jobs, but ended up having to replace pretty much every connected piece, there are so many issues in there.
so that works fine in burst, as the "Instantiate" method has no down line burst incompatible code.
and i figure i'll make another job/system to update the entity positions/properties on the components in a later step.
oh SetComponent by a EntityCommandBuffer isnt yet burstable
Could try ijobparallelfor and EntityCommandBuffer.Concurrent
"Destroy, Create, Instantiate" on ECB are all burstable. I believe Add/Remove should be burstable if you use ComponentType instead of the generics version, but that may have changed since I checked last year.
Right now the best you can do is use ECB.Concurrent to speed up most ECB usage.
looks like in preview27 there's an overload for RemoveComponent that takes a ComponentType but none for Add, only T
Burst got few updates today:```
Changelog
[1.0.0-preview.8] - 2019-03-28
- Fix for iOS symbol names growing too long, reduced footprint of function names via pretty printer and a hash
[1.0.0-preview.7] - 2019-03-28
- Burst will now only generate debug information for AOT when targeting a Development Build.
- Added support for locating the build tools (standalone) for generating AOT builds on windows, without having to install Visual Studio complete
- Fix Log Timings was incorrectly being passed along to AOT builds, causing them to fail.
- Fix editor crash if burst aborted compilation half way through (because editor was being closed)
- Fix issue with job compilation that could be disabled when using the burst inspector
- Fix issue with spaces in certain paths (e.g. ANDROID_NDK_ROOT) when building for AOT
- Restore behavior of compiling ios projects from windows with burst, (burst does not support cross compiling for ios) - we still generate a valid output project, but with no burst code.
- Add support for Android embedded NDK.
- Fix issue where certain control flow involving object construction would crash the compiler in release mode```
could someone explain why the burst compiler generates this error when trying to access a static readonly int[,]? error: Unexpected error while processing function MarchingTetrahedra.MarchTetrahedraJob.Execute(MarchingTetrahedra.MarchTetrahedraJob* this, int jobIndex). Reason: Object reference not set to an instance of an object
something to do with multidimensional arrays?
{0, 0, 0},{1, 0, 0},{1, 1, 0},{0, 1, 0},
{0, 0, 1},{1, 0, 1},{1, 1, 1},{0, 1, 1}
};```
ix = cubeIndex3D.x + VertexOffset[i, 0]; is the line that throws the error, I've verified that the null reference it's complaining about is VertexOffset
I don't understand how this could ever evaluate as null
tried instantiating the class that VertexOffset belongs to before scheduling the job to see if the static constructor wasn't being called or something but it didn't help
and it runs fine when not [BurstCompile]'d ofc
I'm assuming this made it in already considering I don't seem to have this problem when accessing 1d managed static readonly arrays
I'm going to go on the assumption they only support 1D arrays for static readonly data that can be converted
yeah I started writing this before testing 1D arrays, it does seem to only be an issue with multidimensional arrays atm
you could replace it with a 1d array of int3 from the math package
the multi-dim primitive types all have indexers for their components
int[,] is a managed array no? it cant be used in burst then
they have support for copying static readonly managed arrays of primitives and supported types
it seems to be 1D arrays only however
huh, interesting
@chrome pawn you could try this one : https://github.com/jeffvella/UnityAStarNavigation/blob/master/Assets/Plugins/Navigation/Helpers/Collections/NativeArray2D.cs
and bye that I mean, if your bursted job accesses a static readonly int[], it will actually be copied into the job itself when the job is compiled.