https://github.com/Unity-Technologies/multiplayer#lagcompensation:
A sample showing a way to implement lag compensation based on Unity Physics. In a game based on the Unity NetCode the client will display an old world state, lag compensation allows the server to take this into account when performing raycasts so the player can aim at what is actually displayed on the client.
#archived-dots
1 messages · Page 116 of 1
Ohh, that's useful, I'll need to look at that sometime, thanks
if someone doesn't know know that mechnanism, it's basically done so that the server can tell if the individual client had a shot using the data they had at the time of the shot
if they only compared to true data on server, clients with bigger ping would always miss their shots, so instead the hits are checked per clients available data
I only just got my FPS controller networked yesterday
Been working on it for a few days, really confused as to why it didn't work
Turns out I accidentally had 2 CommandSendSystems
Instead of a Send and Receive system
Guess I just forgot to change the inheritance, because I renamed the class name 😂
this page explains that even in more depth: https://www.gabrielgambetta.com/lag-compensation.html
(it's a great article series for explaining the basics of fps shooter netcode in general)
Neat. I used to research netcode a lot, but this seems pretty good as well, thanks
it's really well structured and easy to understand, highly recommend it
especially the page with client-side prediction and server reconciliation is golden
I made this post a few years ago: https://www.reddit.com/r/GlobalOffensive/comments/6yij1l/the_grand_post_of_csgo_network_code/
I think that was around the time Overwatch was being released as well, and they had some interesting things on netcode
My main problems was just implementing all this in Unity NetCode
Considering the problem I described above 😂
@dull copper I actually think I used that page you linked when I started with netcode as well 😄
Haha, I just remembered that the latest multiplayer sample repo had that LagCompensation example added.
Thanks ptrefall
is it possible to cancel a dependant job if parent job 'returns' a specific value ?
i am using a bursted job to do some stuff and want to update my UI according to that, but that bursted job might not always change it's value, so i was just wondering if i could do that instead of my UI updating every frame
you can't cancel mid-job
@opaque ledge No, because it would break determinism
You can sort of do it implicitly, by having the output of the job saved in a component, and then having the other job read that component to figure out whether it should run
Of course the job will run, but the contents can vary depending on the results of the previous job (in which case, the content can simply be return)
yeah, thanks
What's the state of UI Elements and UI Builder now? Are they still editor only?
ah, I guess they are
there is a runtime version but its 0.0.4
let me find the link for you
There used to be documentetion here to show how to 'unlock' it via package manager https://github.com/Unity-Technologies/UIElementsUniteCPH2019RuntimeDemo/tree/master/Assets/UIERuntime
thank you
and I guess they will require a 2020.1 soon
so I'll hold off using it for now
got more than enough early-adoption stuff going already
well i am using it on 2019.3.3 right now and its working fine, but i am not doing anything fancy
hm, ok. I'll give it a try then
I only need it for a developer console for now
holding back on doing much where things are still very early
but want to use it
The only problem i encountered was dealing with enabling/disabling gameobject that holds the panel, but to enable and disable i am setting opacity to 100 and 0 respectively, no problem then
i wish unity had a built in console 🙂
do you know if they built the data binding solution for runtime UIElements yet?
for runtime ?
probably yes for editor, not sure tho never used it for editor
for runtime there is a binding for list view, not sure about others
you need documentation to install it?
surely you could just place it in your manifest and it would be there
at least that's what I did when it first popped up in bintray
i think its official package now
first package was on bintray last august already 🙂
Does Run also creates a sync point ? or just waits for jobs to finish ?
or perhaps they are the same thing 🤔
From documentation When you call Entities.ForEach.Run() the job scheduler completes all scheduled jobs that the system depends on before starting the ForEach iteration
And next sentence is If you also use WithStructuralChanges() as part of the construction, then the job scheduler completes all running and scheduled jobs.
is there a difference between completes all running and scheduled jobs and completes all scheduled jobs🤔
hmmm...idk sounds the same
I imagine Run() would complete dependency A, but not B, C if it doesnt rely on it
and WithStructuralChanges() -> completes ABC?
jobs that the system depends on is the important part, if your system touches components Comp1, Comp2, and there is a running jobs that touches only Comp3, then Run() will not complete that job, and WithStructuralChanges() will.
(unless something changed in how the auto-dependency resolution works since I last looked at it circa 0.2)
Ah wonderful - that's how I read it before I doubted myself how it worked
hmm 🤔
Well anyway, i dont know any better i just wanted to know if i should just use EntityManager directly if i am doing Run
i think that translates it to ComponentDataFromEntity<T> via compiler extensions
if you use the EntityManager directly
in the latest release 0.7
@opaque ledge you can record everything into command buffer and use burst with run🤔
yeah, i was accessing class data components tho, so without burst unfortunately
Hey, what's the best way to learn what the hell DOTS even is? Everything I see requires foreknowledge of what it is, and apparently it's some form of ECS even though unity itself is already an ECS I thought and none of it makes any sense without any foreknowledge
There's tutorials on How but nothing about What or Why
Hey, if I have a GO with "Convert to Entity" in my Scene, then query for that said GO and add a Component to it. Will I have two sync points? One for the Conversion and spawning and the other for the adding of components?
Or even three?
Unity's own pages seem to be just marketing fluff
DOTS is data oriented tech stack - I'd say it's the overarching term to encompass entity component system in Unity
Isn't Unity already an ECS? GameObjects and Components?
i'd say look at the pinned messages on this channel and get started with the samples
@unique mantle Took me a bit to understand it well aswell and how it works and how to make it work, but its not overly complicated.
I'd suggest watching some unity talks about ecs and DOTS to get a better understanding
nope - gameObjects and components would be more traditional OOP
I've watched four talks fully and not a single one explains what it is, just how, I thought I'd be able to figure it out but it makes less and less sense the more they talk about it
you have entities (which are ids) that are mapped to data tables
Mind you, I had to watch some of those talks 2-3 times to fully grasp the idea
systems run on entities and data tables so you can do you manipulations
so you can think entities as particular keys to data tables
Isn't OOP just that? Data records called objects with a set of functions to manipulate it called methods
Does Unity seriously copy the functions with every instance?
entity component system tries to separate logic from data
I thought it worked like C++, where methods are actually global functions with a receiver structure (sort of)
well you have singular systems - so for simplicity - 1 instruction and a collection of likewise data
Sort of like batching draws?
similar - yes
I've written a 2d batching game engine and this makes far less sense than OpenGL
So batching all object stuff? I was under the impression that Unity did it already like every other game engine
this was the article that introduced me to it years ago: http://gamesfromwithin.com/data-oriented-design
Picture this: Toward the end of the development cycle, your game crawls, but you don’t see any obvious hotspots in the profiler. The culprit? Random memory access patterns and constant cache misses.
but batching is a part of it - but its not necessarily just rendering data
could be anything really
Oh, a lisp-like thing with records instead of objects with behaviour
Okay, how does ECS fit into it? Isn't that entities with behaviour?
its just a database thing really, formatting the data into single arrays then pushing it through a method/system as fast as possible
Components with behaviour, rather
I've got to head out - but ppl on this channel would be able to explain 🙂
ECS is just the Entity Component System
ECS is where Entities are made up of Components that perform a single task or set of tasks each right? Like the exact thing Unity's built on?
Unity calls Entities GameObjects but other than that
you can convert gameobjects to entities but they are not the same
I meant a generic ECS, not Unity's mislabelled apparently not ECS system
As far as I understand it ECS is the exact opposite of DOD, it's an OOP concept
what's mislabelled about Unity's ECS?
The System is the one that perform the task.
Entities are representations of a collective of Components.
Is that what you are asking or is it about how they perform on the low level?
Components are just data by the way. just ints, floats, strings etc..
if you think OpenGL makes sense it might be a lost cause 😛
Okay Unity's concept of an ECS isn't an ECS
there are two ECS strategies, loosely the MonoBehaviour side and the lol value types/Burst side
I don't understand where you are getting this Unity ECS isn't ECS?
Entities are bags of data with components holding behaviour and also their own data in every other ECS I've heard of
pretty much all the distinction comes down to the technical aspects of Burst
Entities don't hold any behaviour or code, only data as in ints, floats etc
No Entities dont hold any data
DOTS and friends are mostly just built on top of that
If components are just data, what's the purpose of wrapping them in separate objects? Isn't that what you're trying to avoid with DOD? Also I was describing every other ECS
components are bits of data likely accessed together
The whole problem is that I can't find any info on what Unity's ECS even is
it's ambiguous-- there are two.
@north bay well yeah exactly they are refs to the data
DOTS is ECS. MonoBehaviour and friends are also ECS
No wonder it's weirdly labelled, these are the same folks who came up with the Grid Layout Component
DOTS is probably closer to what you're thinking of when you are talking about 'new ECS in Unity'
the lack of documentation is a different (but entirely valid) problem/complaint
Entities are not objects. You can see it that way if it makes it easier for you but its a misconception that will lead to misunderstanding.
The point of grouping components together (ie; data), is to make the whole program much faster to go through memory
So entities are data and components are data as part of entities, where does the behaviour come from?
Entities are not data.
You what?
Systems
They are just a representation of a group of components
Which isn't data?
its just basically a ref/address/pointer in the memory
Entities?
nope, not at all
they're implemented as a plain boring int, for the most part
Oh, reference id system
Yeah this is the furthest thing in existence to an ECS by the common definition
You could make for example an entity. its nothing. its empty. just a floating entity that will later represent a character.
Then, you add a few components to that entity; Health, Mana, Damage. Anything that has values.
Now to make use of the entity, you need a System to operate what and how those values change.
will hard disagree with you there. It's more a relational database than anything
relational DBs tend to be pretty data-focused
So ECS is OOP? Objects with fields/properties in them?
no, ecs is largely composition
does it seem like this convo is going in circles 🤔
I feel like even the DOTS proponents here are kind of misrepresenting it (in a benign way)
Unity has an ECS system already
that's fine, cool, and also good
Misrepresentation is a bit of a recurring theme in Unity it seems
there is a 'new ECS' system built to take advantage of some low-level C# stuff and JIT
that system is called DOTS
But Entities are bags of data components? Are the data components shared, QuakeC style?
it has slightly different conventions for how code ought to be laid out
Actually come to think of it this reminds me a hell of a lot of QuakeC
it's actually got a lot in common with Hadoop
if you want to put functions in your components structs then knock yourself out
Unifying all entities into a single type of structure with batch functions?
I think the main benefit of DOTS is a pattern that better supports multi-core processing
What is this convo doing?
DOTS is Jobs, Burst, and ECS. If you want to know more about any of them there's lots of videos and information out there
Unity's monobehavior is a "component design" paradigm not an ECS paradigm...
in fact, certain designs (thinking of SCD) actually need that anyway
Just because it has the word component in it
ECS and 'component design' are the same thing
Common definition of ECS last I checked
There is no "system" part of the MonoBehaviour paradigm
Unless you write your code in that manner, and then you would be implementing ECS principles yourself
Yeah because Oriented is a vital class in DOTS
not following?
pointed attention to the S in ECS
I'm still not following, sorry
"there's no system part of unity" the ECS itself is the system, it's in the name
System has special meaning in DOTS, but that might be an unintentional ambiguity
the physics engine is a kind of system, I think
the messaging (OnUpdate(), etc.) would largely fit the bill
Anyway enough semantics, Unity's ECS is entities holding components, how does it work in a DOD thing?
yeah but that "system" is on the component, so it can't be separated as easily for multithreading, I think
The main point of ECS performance-wise is that your data is in densely packed arrays so you avoid on cache misses when your systems iterate over the data. It's also much easier to write and automatically handle multithreaded code
@slim nebula that isn't the problem with multithreading, it's data visibility and shared object contention
are we talking about DOTS or ECS the general CS topic
The problem with everything I've found on DOTS and the ECS is it's all "These are the advantages! Switch to it now! What is it? No-one knows!"
doesnt sound like you've been looking in the right places
its way simpler than OOP to me when you do get it
yep, so DOTS/'New ECS' is all about Burst and some of the changes in Unity to take advantage of it pretty hard stop
it definitely isn't simpler today 😄
This is a good talk:
https://www.youtube.com/watch?v=mL4qrt-15TE
Get a high-level overview of the Entity Component System (ECS) and turn-based game loops, and see a proof of concept built using ECS. The session covers some of the pitfalls and also shows concepts of ECS in a slightly exotic context.
Speaker: Florian Uhde - Three Eyed Games
...
like the basic idea is simple
Unity's site and all the talks from Unite 2019 relating to it not good sources?
I do agree the documentation surrounding changes isn't very good
but when you actually write game logic with it, and not just spin some cubes, it's gets more complicated quickly
how did you manage get "what is it no one knows" from official videos?
I can more easily figure out how to organise my data when its all separate and I need a simple system to run through that data, where as OOP I was frequently stuck figuring out was in a object in my abstract thing
Unity's site is just marketing fluff and horrifying lack of documentation just like addressables and the talks required foreknowledge on what it is
there's some halfway decent (if specialist) stuff made by some community members
I may just have horrible luck but this exact thing happens every time something new happens, everyone talks about something as the next big thing but the details are missing
https://unity.com/dots/packages is it that bad?
you shouldn't really expect proper docs or even great workflows for things that are in preview
Then why is everyone regarding it as the most important thing in all of game design or something along those lines? Everywhere I go, DOTS, every forum thread, just use DOTS
Its true that the documentations are lacking. Changes happen every update and sometimes they are not even mentioned, but that's a given, since it's not even officially released yet
it feels easier/faster to me
The documentation for ECS even has a little comic at the top that tells you what ECS is https://docs.unity3d.com/Packages/com.unity.entities@0.7/manual/index.html
I haven't seen people from Unity telling you to actually use DOTS now unless you want an adventure
of course they promote it as it's their main thing they are developing to advance this engine right now
but you shouldn't mix promotion and things that are production ready now
I'll try that RPG talk again to see if it'll click and to see if it's explained what it is
there are also huge, huge things that are important to know in practice, like 'how do MonoBehaviour-derived components fit into the overall player loop' that are not really even specced out
as far as I can tell
'use DOTS for everything' is officially not viable
@unique mantle I found it very very interesting because the program works much faster, is lightweight and is pretty intuitive to code. Since all the systems and components are seperated, you won't find yourself with a huge script to get lost in.
officially, they estimate DOTS is production ready for most parts in 2 years now
Yeah, that sort of stuff is my biggest question about ECS, is how it actually works to make a whole damn game with all the hacks and cruft you have to cram together
I have not at all found it difficult to find information about the what and the why
entities itself is probably going out of preview soon
yep-- data-oriented thinking demands that question but the official response seems to be ????? right now
but there's a long road for the rest of DOTS packages still
which is a little puzzling
And the What is the problem I'm having, but I hope there's atleast one talk that actually explains it without skipping the explanation because everyone else knows it already
@gusty comet that frankly sounds like you've had issues on code stucturing before
OOP doesn't force you to write three page long functions
you really shouldn't do that
What are you having trouble with between Jobs, Burst, and ECS?
I have no clue what any of them are, since every talk and tutorial assumes you know it already
@dull copper Agreed.
Burst is a compiler of some sort is what I gathered and ECS is some system that is not actually strictly an ECS
But it still forces you to do otherwise
I'll just watch another talk and see what happens
@gusty comet yeah I do like that in DOTS that it pretty much enforces certain code structure
in past code structure in unity projects was "whatever works" as there hasn't been any framework to enforce things like there is in unreal
while ECS isn't a game framework, you still have to assemble your code in specific way with it
or well, not in the same sense anyway
It has a lot of potential and scope. Which is why it's fascinating more than anything
I wonder if dwarf fortress uses that kind of system at all, and if not, what it could do with it.. but who knows
these are gound up tutorials
for dots and netcode
well the first two are netcode, the last is just dots
So, I'm fairly certain I get some of this ECS thing, but doesn't this mean just completely scrapping the whole GameObject and Component system we've all become used to? Completely destroying all existing code? It's basically a completely different engine
Huh, this is so monumental a change I think it genuinely should just be another engine
it largely is/will be
pretty much
And they're gonna keep calling it Unity confusing everyone in two years time
UE3 to UE4 was a pretty fundamental shift
that seems to have worked
don't know if I should refer to it as the Game Engine that Shall Not Be Named
Unity 2022.1 is not the same engine as unity 2021.4
Wow
I hope they give it atleast a new major version number or something even though they scrapped the version number system for some reason
unity changed to a package format anyway
instead of bundling everything with the engine
no, it's just based around a (roughly) quarterly release schedule, i.e. 2019.1 -> 2019.2 -> 2019.3 -> (theoretical) 2019.4/LTS
it's decoupled
possible to have a new version of ECS without having a new version of unity
I hope they'll atleast move the existing GameObject-based docs somewhere else instead of leaving them there even when there's a new system (EventSystem, AssetBundles, UI)
so in unity 2022.1 you'd prob just import all the ECS packages if you want to work with ECS
or the monobehaviour packages if you wanna keep working with monbehaviours
(or both)
When's the editor going to get entitified?
they're band-aids over the portions of Unity that cannot easily be refactored out of reference types, mainly
there are already some internal ideas about that
and a preview package
right now you have GO/MonoBehaviour conversion systems
ECS is a cool concept actually, it's still not an ECS but it's one hell of a system
why is it not an ECS
unproductive semantics argument
because components aren't behaviour and entities aren't data
no
components are data and systems are behaviour
isn't that what ECS is supposed to be
Ever read Game Programming Patterns?
when people say unity's ECS isn't real ECS they're usually talking about monobehaviours
the new one is
yes
The practical ECS approach as most other engines call them is entities are sometimes data but components have the behaviour and also their own data
basically unity's GameObject system but it varies a bit
Actually a stupid but accurate thought would be calling this one the ECSS, Entity, Component and System System
@unique mantle The one who wrote that book himself is saying that components are data
Maybe ECaSS?
Fine, sure, okay, because no other engine matters in Unity-land
Anyway Unity ECS is cool
It's a bit of a syntaxfaff right now but still cool
this is a pointless semantics argument-- even according to the strict definitions there are still lots of "systems" in native Unity code operating on MeshRenderers or RigidBodies, etc.
Is Unity UI entity-based yet?
Yeah, GameObject based UI works
IMGUI in general really seems like the way to go (but this isn't a DOTS discussion)
An IMGUI as normal game UI sounds interesting
new UI replacement is going to be not-gameobject based
doesn't use ecs internally tho
right, UI isn't really a data problem
this is the "why can't we run the OS just off the GPU lol it will be fast" argument
it will not be fast
Retained UI works better in my opinion for production, IMGUI works better for development and that's why every prototype has that god-awful black gradient
that's web development brain damage rather than real design
Can Systems do IMGUI stuff right now? They would be the best suited for a dev imgui
yes, absolutely
Or just incorporate dear imgui and be done with it
just not in a job
Imgui is a bit more monolithic, systems would be the one calling it
This is all very fascinating and will take a hell of a lot longer than 2 years from now
I mean, you could potentially make a complete game with ecs right now
True
Just some features that are already existing in unity you will have to build yourself
I wonder if a fork of Unity or something will show up for those who want GameObjects
The hybrid is great if you still want to use gameobjects.
Besides, not everything has to be ecs. Just the heavy stuff
reminder that Unreal completely dropped its script interpreter in between UE3 -> UE4
I suspect everything will be Systems eventually
Soon tm
GameObjectSystem would be just like any other. Kind of surprised they didn't directly expose things that way with the update groups
it'd be great tho
Sees 250+ messages Yay stuff to learn!
reads it aww
haha yes, I just got through it as well
saved me on the ui.runtime though, so was worth it
UI Elements is a reminder on how long its been since I had to touch anything web related
But I still like it
Adjusting style in unity's gameobject hierarchy based UI solution was a nightmare
yeah, unfortunately tho its only for screen space, so no world space 😦
hopefully in time
yeah, screen space suits me just fine for now
first tiny 2D examples out now
or "first" but on this wave now 😄
https://github.com/Unity-Technologies/ProjectTinySamples got not TinyGems and TinySpaceship which are 2D
The package provides tools to work with 2D content, such as Sprites and Physics 2D. This package works exclusively with Project Tiny.```
Rendering
Sprite conversion
Sprite Renderer conversion
Sprites/Default Material conversion
Sprite Atlas conversion
Runtime 2D rendering pipeline
Editor 2D rendering pipeline
Physical Collision Detection
Primitive colliders conversion
Compound collider conversion
Rigidbody2D conversion
Physics broadphase
Broadphase querying API
testing on that gems now
if it even builds
my interest on this is that I have one weird use case for the 2D physics but might just do my own solvers for it
hmmmm, I can't even play the 2d tiny in the editor
there's no camera rendering on game view
game clearly runs on the scene view tho
see all the graphics moving there
¯_(ツ)_/¯
ah, as I suspected: You have to keep the Main Camera SubScene open in Edit mode at all times to see anything being rendered in the GameView window
that would have been my next try
it's weird that it does work in the scene view still
that was in known issues
heh, that gems example takes 70.6MB with windows IL2CPP build option
that's like way more than you'd expect for such a simple game even on old unity
oh wait
it didn't wipe pdb's
wonder why since I did use release conf
ok, without those, it's now 6.41 MB
regular unityplayer dll is like 26 MB
@remote coyote so, win-il2cpp: 6.41MB for this gems, web-wasm build was 2.52MB
didn't test other options
wonder when they will add multithreading support🤔
to what?
to tiny
that's a lot better
huh? so they run job system on main thread now?
there's nativejobs.dll on the IL2CPP build
how does it compare to a simple web game in terms of pacakge size though I wonder
last time i checked it wasn't multythreaded in build
I'm not really on the web game ball, so I don't know what they will be competing with
clearly smaller is better for web games
I don't really care about web here at all
but dots runtime is what we'll eventually use to deploy our games with unity
yeah, same
not sure about that🤔
its interesting to see anyway, thanks for testing Olento
np
@warped trail why do you doubt it? they've said they want to unify tiny and regular dots for years, and they are constantly going to that direction
I haven't tested building pure dots apps outside tiny examples but would expect that to get more common once we get all needed things running properly on ECS side
or you mean like, there's so much existing systems on the old MB side that people will not go for pure DOTS?
I'm not really expecting pure dots games to be a big thing for years now (but it's still clearly direction where Unity is heading at)
as far as i understood tiny is not using unity at all
unity is like external editor for tiny😅
it's not that different from regular DOTS, just slimmer systems
you can mix and match too
in the early versions, tiny was completely separate thing
tiny uses third party api for things🤔
at least for desktop they are using glfw for input and window handling and bgfx for rendering
they use glfw for input too
well, beyond this apparently
this is my main big concern for tiny right now
you have to make two systems basically
why? I mean, they've said they want you to be able to mix and match these tiny systems with full systems if needed
one system for editor testing and one that will work in builds
basically you can take the lightweight or fully blown out version depending on your projects needs
ah, you mean like that
yeah, I don't even know how tiny runs in editor right now
you can't use any UnityEngine stuff
sure, but not really expected either on pure DOTS
the idea is that we get rid of all of that in the builds eventually
but the thing i like about Tiny is that build time = compile time in regular unity 😑
I think the renderer is the main thing preventing us from doing "full" games on pure DOTS right now
we'd need pure DOTS renderer instead of the hybrid one
and obviously most of the DOTS libraries are super raw and early still
but the renderer has to be the key thing missing atm + they've said that will happen
i wonder if in the future there will be something like 2 engines 😅
the thing I'm waiting the most for DOTS is to get rid of the whole conversion system :p
maybe they will slowly rewrite packages to be engine agnostic and transition will be painless
and by the time this transition will start, you will be get used to conversion workflow 😂
Joachim's said that he's become convinced Conversion workflow is actually the ultimate preference though right? More pure-DOTS stuff will of course be great but I think the intention is to always have e.g. GO's at design time?
I'm actually quite certain that the conversion workflow is only "preferred" because the dots mode was kinda failure, you have to have both GO and ECS worlds present for authoring hybrid right now
and in general, people resist change
so that's something that would make people think they actually want this conversion setup
doesn't mean it's better in any way tho
pretty sure that's the direction and how I've seen him position it /shrug
yeah, it's pretty clear they are going with conversion workflow now
I do hope they can get very basic editor functionaly returned at some point
what pains me the most is that this current setup pretty much ruins the scene view's usability, it used to be a real strenght for Unity to be able to examine things there while the game was running
now we can't even select objects from the scene view live while the game is running, and it's pretty basic thing
I mean, can't do that officially
agree that's basic functionality (that someone on the forums has implemented a version of) - I'd hope that comes soon
there's 3rd party things like https://github.com/JonasDeM/EntitySelection
yeah, this is the thing you mentioned probably
https://forum.unity.com/threads/when-if-ever-are-pure-ecs-dots-editor-tools-coming.701909/#post-5057558 is a relevant post
There is not going to be a world anymore where unity will have the same data at runtime as it has at edit time. Better get used to it. 😄
Yup 🙂
tbh, editing other than graphics setting at runtime isn't that common, at least has never been for me, any parameter change you'd do like that could just be done in scripts too with debug input
main thing I want that functionality for (to be able to select and examine values) is purely for debugging purposes, to see that things do what they are supposed to do
any news about new entity debugger?
is there even going to be new entity debugger? I know they've been working on making it better but I don't remember them saying there will be completely new one?
@dull copper Maybe you don't, but it's very valuable for AAA devs with giant production lines. Imagine a designer being able to change a player live in a playtest. Or imagine that the company is doing something XBox exclusive. These are both cases where LiveLink is super useful
well, livelink is probably there for that reason 😄
Wasn't that what you were taling about?
tbh, editing other than graphics setting at runtime isn't that common, at least has never been for me, any parameter change you'd do like that could just be done in scripts too with debug input
for the record, that entity debugger was a prototype and the DOTS Editor team is building a new one (yeah yeah, always the answer is 'new thing') from Topher
@bright sentinel livelink takes that to another level tho, making it more feasible again
but it's bit different thing to edit the materials + geometry vs change NPC data on the fly for debug purposes (which was more of what I was talking about)
for the level editing/visual tuning, being able to do it live is really handy
@warped trail ah, that's cool
@bright sentinel I think it was in the context of being able to live inspect entities by clicking on their 3d representations in editor-view (as there are cases when e.g. a script instantiates an entity rather than it has come from a GO representation) - and I think 0lento was just saying the inspection aspect wouldn't need to be super powerful but it's very useful to at least debug what values are there/associated with it. Livelink is great for what it does.
Ah yeah, that makes sense, my bad for not reading everything
Not at all - some of it was not explicit either 👍
and err @dull copper let me know if I'm putting words in your mouth 😅
nah, that's pretty much what I meant
I'm not really great at explaining myself in the morning 😄
Morning? Where do you live? 😂
well, I live in finland, it's 12:23 here 😄 but I'm still waking up slowly
TIL Finland isn't on the same timezone as other Scandinavian countries
it's not
about that runtime edit though, I do have one use case for it that I've been planning to test in few ways. I'm currently using scriptable objects for feeding in certain data to the conversion scripts right now
but I'd also want to be able to update that data at runtime when I tweak the SO
it's technically doable, just need to store some refs and implement system that resets the data once SO gets update
alternative way would be to tweak the data at runtime via some input and just write it back to SO on demand
so.. I guess there are use cases where that kind of runtime editing would still be handy, especially when you tweak some parameters on the fly
I'm still working out something similar but my thoughts are I guess you've got to be a bit careful that you work with the conversion workflow rather than against (i.e. SOs to blobassets might be against imo)
ah, my thinking here is that the SO's are mainly an editor thing, I only use them to copy data during the conversion and after that they are not used anymore in the actual build
it's just for convenience that you can edit data that persists
and also so that you can ref the same conf to multiple places easily
just to make that more clear, I'm not converting SO's, just copying the data during conversion, so the most naive possible approach
in ideal case, SO's wouldn't even exist in the build but it's not really going to change anything in a way or another in practice
yea, cool - I do something slightly similar
@hollow sorrel we talked about the examples a bit here: https://discordapp.com/channels/489222168727519232/497874303463850004/685415283669729466
I didn't notice they got docs uploaded already 🙂
btw, I did try Windows .NET option too. it was 7.24MB for that gems
so tad more than IL2CPP
.net build was like 30 seconds on my system, IL2CPP took 2,5 minutes and webasm 3,5 minutes
(don't have editor open anymore so those are not exact timings)
collections and mathematics alone take 973KB on that .NET build
heh, they don't have text rendering(?)
that's from the tiny spaceship example
technically now that they have sprites, it wouldn't be that difficult to implement some simple text setup 🙂
Really rough recording and hard to see (4k 100% scaled monitor, sorry!) but this is what I'm working on https://www.youtube.com/watch?v=f46zU8jF2TE&feature=youtu.be - it's creating a ScriptableObject with the animation data serialized that you can fire from code or a built-in component. The lib is all DOTS-backed so this kinda shows the hybrid edit-time workflow of SO serialization and live entity conversion without using LiveLink. Of course the idea is this all works seamlessly with entities/subscenes & LiveLink too. The idea being you design animations once and reuse wherever (including inside other animations). Tbh mostly sharing because I've been working on this for over a year and I'm excited all the pieces are finally starting to come together.
So the hybrid renderer works by turning entities back into gameobjects specifically designed for rendering? I suspect that won't last
https://github.com/Unity-Technologies/2D-Entities-Starter
2D Entities Starter is a template project, which has everything setup for you to get started with the 2D Entities package.
@unique mantle That's only intermediate. Building a new renderer takes a lot of time, so for now they're just hooking into the other renderers they have
But they're definitely working on a pure DOTS renderer
but hybrid renderer does not turn entities back to gameobjects🤔
I mean entities are so insubstantial is that even necessary 🤔
that's what it says on the package page anyway
Wish 2D entities wasn't dependent on Tiny. But I guess it's a matter of time before it will work everywhere.
Is this where we talk about AI Planner?
imo, better talk in forums.
or just ask maybe someone knows something 😄
i dont think AI planner is ECS ready yet so...
I requested a long time ago that ML channel would allow generic AI too but it's still ML
so, there really isn't that good place to discuss it here
I can understand why you'd want to keep ML and AI separate, but they are very closely related
I'm just trying to play with the idea of using AI planner to generate levels, but i'm having trouble getting started and I'm hoping I can brain storm with people
from what I understand, its really just a good A* framework
thats probably an oversimplification, but its a graph search ai
yeah, something like that
its goap i think
😄
I've tried to watch few talks on it but the guy presenting it is so excited it's hard to follow him
I guess it's a french thing
it's nice to see people liking what they do though
Goap is actually easy, even if i understand everyone can understand 😄
there is actually an implementation for Unity that i used to use
tho i never really tried to create complete AI for it. but i know the basics and have some ideas about use cases
https://docs.unity3d.com/Packages/com.unity.ai.planner@latest for the ai planner docs btw
should probably just try to follow this and it would make more sense
I suppose going through a typical scenario would be good to atleast get comfortable with the tool
is your question about GOAP or 'how to do stuff in AI Planner' ?
I can help a little if former
its more how to use this type of ai solution solution for dungeon generation
I should just do some more basic stuff first so I can get comfortable with the system and maybe that will help me get started
I do suspect that some of the issue is that this type of system basically requires you to be able to do a good job defining the problem domain
im kinda surprised they dont appear to mention goap in the docs, seems like it would be kind of a handy thing to alert people to existing/prior knowledge of it
what got me on this idea is that the way it deals with decisions is similar, but not the same, as graph grammars
checking a set of pre-conditions is much like the pattern analysis you do
yeah I don't see that actually working
it's cost minimization
I feel like you need significant extra work to do anything with it
You very well could be right, the framing of the problem is not really on point
you really want like L-systems or something
nah, all these old generative frameworks are super limited
GOAP is neat but it's very much about cost minimization/"efficient pathing through limited option space"
and I think the action/level feature mapping isn't the best
there's like wave function collapse model as a generative level generator too
Structs implementing IBufferElementData and marked with a GenerateAuthoringComponentAttribute attribute should have exactly one field specifying its element type. However, 'ElementTest' contains 4 fields.Please implement your own authoring component.
that seems limiting
nah, just annoying thats all 😄
you can group them up in a struct if you really want auto authoring that bad
WFC is neat, but your control is limited at best
is that not partially the point of automated level construction 😛
not really
its a byproduct of automated level construction
Level generation isn't just about getting something automatically
when you're trying to push the bounds, its about establishing knobs you can tweak to get results out of your generator that are good for the environment
The vast majority of level generation ends up being "Implement L-Systems, done"
or "Implement random tile selection" done
and honestly its pretty pathetic how little game developers have innovated in this space
Most use the same algorithms that were used in the 80s
WFC is a new concept, but it fails in the same way as most simple level generation algorithms, it goes full deep into randomization, and doesn't consider additive context
I almost wonder if solutions are mostly outside games too
there are better concepts outside of game dev
but the fact that they are not developed with game dev in mind makes it hard to put them into that context
just because it they were developed as toys rather than tools
honeslty, the only place anyone should be focusing their effort if they want "next gen" level generation, is developing a Machine Learning system
I dont want to wrap my head around that though
I mean yes, but applied to mass data sets it yields great results
the problem is generating the data set
You need levels that have some pre-build descriptor of what the expectation is
and then a level designer to go and make a level that fits that descriptor and also has some kind of tagging setup
and then repeat that like 1000 times
I would still push back on that pretty hard
regression-based methods are going to have huge predictability problems because of how they work
Thats a really fair point, you're not going to be able to predict those unexpected outcomes either
again outside of games, but there's an interesting tidbit by Nassim Taleb (personal politics aside) about linear predictive models being innately ill-prepared for dealing with high-variance input
there is a fundamental representation problem
more entropy
this is why I wish we had a channel about procedural generation or something like this
I mean these ML algos are implicitly biased by their input
which in a sense is the point, you're trying to bias predictions towards a resutl
yep. Mathematically, it is proven at this point that any NN-based approach is a funny-looking polynomial regression
I mean, honestly, I think the flaws are a feature in the context
but the lack of predictable outcomes, and worse the inability to specifically deal with bad outcomes would be a problem
perhaps a GAN can deal with it by having models which test very specific factors
like a model for "Can a character traverse this space?"
anyways thats a bit off topic
the whole AI PLanner concept does seem more and more wrong, but I still want to play with it
Sooo~~~~ I have a campaign scene (think of total war campaign scene) and every entity(campaign entities not ECS entities) on that campaign scene has a world UI, and these UI position themselves according to camera's rotation, so they will always look oriented no matter what is camera's rotation BUT this is taking like 0.7, 0.8 ms with around 70 entities and i am afraid i will have much more entities when my game is ready, and i dont want to spend 2-3 ms every frame for world UI positioning. So i came up with 2 solutions.
-
Giving tags on entities in camera's view so i would only process those, giving that entities in camera's view will be low (probably 10-15 max), but that means every frame i have to clear tags and add them again which would introduce some burden on Sync points, and perhaps this can be a good solution for my case but there could be scalability issues if this is to be 'generalized solution'
-
Have a dynamic buffer that has the entities that is inside camera's view, and retrieve that singleton dynamic buffer and check if entity is there when i am processing, if its then i would process if it isnt then i will skip.
Has anyone created a solution for this ? What do you guys think
I probably will start my tests tomorrow but i wanted to get some ideas/suggestions before doing that
0.8ms for 70 entities looks whack
even on the worst case scenario of stuff like 1 entity per chunk you still should be better than that
well, 0.4-5 for 90 entities 😄
what kind of heavy math are you doing there?😅
yeah, lets see the systems/jobs? sounds like it can be optimized
just setting transform's position according to entity's translation and transform's rotation according to camera's rotation
sec
var cameraRotation = GetSingleton<CampaignCameraRotationData>();
Entities.ForEach(
(BasicUIMonoSystemData mono, in Translation translation) =>
{
var entityPosition = translation.Value;
var cameraRot = new Quaternion(cameraRotation.Value.value.x, cameraRotation.Value.value.y, cameraRotation.Value.value.z, cameraRotation.Value.value.w);
var canvas = mono.Value;
canvas.transform.position = new Vector3(entityPosition.x, entityPosition.y - 2, entityPosition.z);
canvas.transform.LookAt(canvas.transform.position + cameraRot * Vector3.forward, cameraRot * Vector3.up);
canvas.transform.Translate(Vector3.back, Space.Self);
})
.WithoutBurst()
.Run();
BasicUIMonoSystemData.Value is MB that controls/attached the world UI
ah so its actually accessing monobehavior transform
ok that makes a lot more sense
cameraRot could be moved outside the foreach. on first glance i would do the equivalent for lookat and translate in a job and then have another job that just syncs the resulting data into the actual transforms
Yeah you need to always make there main thread .run . Without burst stuff the minimal it can be
Also there's a transform accesses array that you can use in a job to set the transforms
But you should just look for the CopyToTransform system in entities package, transforms, hybrid
It's been a long time but I remember seeing about 20k transforms a frame being reasonable
I am using this for my camera, but not sure how i can set my canvas' position manually with this
and also thanks @safe lintel its taking 0.3-0.35 now 😄
hmm perhaps i should make canvas UI attached to an entity and attach a CopyTransformToGameObject and simply modify that entity's position rotation and canvas will automatically be in sync ?
Well, i will take a look tomorrow thanks
heyho! anyone knows if there's a way to use a NativeSlice as a buffer for mesh.SetVertices(); ?
I think you can reinterpret a native slice as an array
and just pass it to mesh.SetVertices(...)
So.. I just started switching over to SystemBase's.. started using HasComponent etc.. all was working well.. eventually Unity crashed then on restart code no longer compiles. nvalidProgramException: Invalid IL code in 'name of system' - seems I can reliably get the error by including any of the new Get/Has/Set Component calls - has anyone else seen this? (Burst disabled btw)
psuong, how would I do that without creating memory garbage? I'm pretty sure ToArray creates garbage
its only usable in ForEach, you cant use with Job.WithCode @amber flicker
sorry reinterpret it as a NativeArray
ToArray doesnt create garbage, it just allocates
Yea just using it in foreach but didn’t know about that thanks C1
ah i dont know then, i only got that error when i tried new methods in Job.WithCode and doing ForEach(ForEach isnt supported in burst yet)
care to show a portion of your code ?
Away from machine.. though realised I said compile time but it’s actually runtime in editor.. I do have multiple foreaches in one system though
CurlyOne yes, it allocates... garbage
ToArray does allocate garbage
I havent tested yet but perhaps if you do get same component in ForEach and inside ForEach could also cause that
thats probably dispose sentinel creating that garbage, try to turn off your native collection checker(i forgot the name)
ToArray retuns T[] so its not the disposal sentinel - you can do CopyTo(NativeArray) with temp memory
i mean Native collection is inside unmanaged space right ? no CLR doing garbage stuff there
aaaah nevermind, i thougt ToArray returns NativeArray
Yea I thought that too - been a while since I used the slice API
what is the difference between NativeArray and NativeSlice btw ?
slices are a span between some startIndex and some end index
so effectively a part of the array
yeah, copying it is an option, but I thought since Mesh.Set-InsertAnythingHere-() already copies stuff to the mesh's buffers it would be a waste of CPU
or am I wrong?
Yeah sorry, i only saw ToNativeArray in DynamicBuffer, so i thought that would also return NativeArray
tho not sure why its called ToNativeArray if it doesnt actually convert to NativeArray but to managed array 😄
so I just did the CopyTo and dispose the native array- the bursted mesh api example just stored a copy to a persistent native array and passed it to the mesh.
hmm yea the problem here is that my vertex lenghts are going to change, also my indicies will be stored in a mega-array kinda thing that will be able to store indicies for 32,767 different submeshes
I have something similar just not to that scale - but I ended up storing them in a dynamic buffer on an entity
dynamic buffers behave like lists? or what are they exactly?
yes they are a list
hmm thats not good, one of the things I was trying to also avoid was checking the length before adding an element
I mean like IT checks it
but if I allocate enough memory at start and I know it will fit then I can avoid the check
yeah but its a list it will just expand
yes trust me it would be worth it 😄
786K vertices at absolute worst case scenario (average scenario would be like 20-30K) per 32x32x32 chunk (voxel terrain)
and I want to load as many chunks as I can
per second
oh but I would be storing these only temporarily until SetVertices
oh does that crash it?
On dynamic buffers you want to use AsNativeArray to get a pointer not a alloc. Also a reinterpret before that
Like if you have a buffer element wrapping a float3 that's your vertex position
Just reinterpret it as a float3
Then asnativearray it
Then you can shove that into the mesh API or grab a unsafe pointer to it for the raw mesh api
Cool didnt know there was api support for passing a pointer
I made a voxels generator yesterday in a few hours using that. The first rough pass does like 20-40 meshes a frame on main thread
Not the ecs hybrid rendering, legacy
Hello, i have this problem
https://github.com/Unity-Technologies/multiplayer/issues/83
I stumbled upon FixedListFloat64 when I'm looking for a way to have fixed sized arrays in a struct. Any idea what it's for and how to use?
any guide to read the Assembly code output in jobs debugger better? what does green vs purple fonts imply? scalar vs vectorization?
you can google instruction name in google and see what this instruction does 🧐
They are quite useful, i use it for fixed string mostly for localization purposes, if you want to have fixed size arrays and want to put them in your components then fixedXXX is way to go.
you can just do new FixedXX() and do Add method to do your stuff
I've read those but I'm a bit confused at:
An unmanaged, resizable list that does not allocate memory. It is 128 bytes in size, and contains all the memory it needs.
How is it resizable yet having a fixed size?
just think as, they are resizble to a fixed size 😄
it is resizable to some some extent(128 bytes)😅
list has Length property, you can use that to process your list, so even if its fixed size, the actual number of elements inside that list is changed.
that does not allocate memory
How does that even work?
imo, think the list as a struct, and thats it, and think generic you pass as a 'helper' for internal calculations.
such as data retrieved, length propery etc
I mean, how can you store the numbers without memory?
Or maybe I just don't understand the terminology here
dont think it as a list, its just a struct that is partioned by the generic you contstruct with
i think it means without GC memory
so if you lets say do FixedList128<Entity> right ? so Entity is 8 bytes, so i can but 16 entities in that 'list'.
FixedList.. think of it as a helper for partioning a byte struct
Native containers allocates on runtime, and they are not blittable so you cant put them into compontents
Okay.. So why would I use FixedLists over a buffer?
perhaps you want an array-like field in your component that you are sure it wont exceed a maximum amount of bytes.
But wouldn't I be able to achieve the exact same thing with a buffer?
you would be seperating a component data into a component data and a buffer.
Hm, that's true. So why would I ever use a buffer over a FixedList? 😂
if you are sure that you want it forever expanding 😄
Ahh, okay gotcha
i mean think like this, i have a component that has multiple values of same type, so that component in Entity A could have only 3 of them, Entity B could have 7 of them, and you dont want to create a field for those values like field1, field2, field3 etc. and you have to check if they actually have valid value, so its much better to use FixedList<T> in those kind of situtations, you can also use dynamic buffer but it doesnt make sense because they will be always used together.
Like i said tho, i never needed to use them, i am using FixedString for localization/UI
Oh okay, so another feature of a buffer is that you can access only single elements without the overhead of the other ones, but in a FixedList you'll get the whole list?
yeah probably thats the case.
because its basically a struct, its just partioned so it can be used as list
👍
i might have talked like i know all about FixedList but i dont 😄 it just makes sense if it would work like that
perhaps Topher or any other experience people could answer better
Well it makes sense what you're saying, but thanks for the headsup, I'll remember to be wary of them when using them 😄
when I use the SetPosition SetUVs stuff with nativearrays, is the nativearray copied or just the reference?
probably not copied, i heard that nativecollection is basically just a pointer
when you do var array2 = someNativeArray for example both array2 and someNativeArray points to same array
yes I know that
but the question is what happens in the Set* Functions
also why is there no SetTriangles function?
well i never used those methods so i wouldnt know
I mean there is but with no nativearray support
do you convert your mesh data to Vector3 and stuff?
no i never did mesh stuff
but if that method sets position of the mest according to NativeArray's contents then its probably by reference, wouldnt make sense to copy if you are just reading
ah ok it is called SetIndices not SetTriangles
yeah but I am no expert on this GPU stuff, I mean it will get copied to the GPU is some sense anyways
the question is if this happens directly or, if I modify the nativearray later, the mesh is copied again (or if I need to call some kind of updateMesh function)
what class is this ?
all on the mesh class. They added support for working with meshes using NativeArrays in 2019.3
before you always had to convert your stuff to List<Vector3> before using the mesh class I think
public unsafe void SetVertices<T>(NativeArray<T> inVertices, int start, int length, [DefaultValue("MeshUpdateFlags.Default")] UnityEngine.Rendering.MeshUpdateFlags flags) where T : struct
{
if (UnsafeUtility.SizeOf<T>() != 12)
throw new ArgumentException($"{nameof(SetVertices)} with NativeArray should use struct type that is 12 bytes (3x float) in size");
SetSizedNativeArrayForChannel(VertexAttribute.Position, VertexAttributeFormat.Float32, 3, (IntPtr)inVertices.GetUnsafeReadOnlyPtr(), inVertices.Length, start, length, flags);
}
it gets getUnsafeReadOnlyPtr, so its pointer, but its read only
Hi all. I'm thinking ahead for scene and game state management in my project, and my gut feeling is to go with ECS for managing this over a singleton design. Is this a reasonable approach or am I missing something that would mean it's more sensible to stick to the traditional way of doing this in unity?
@junior fjord i don't know if this could help, but have you looked at this?https://docs.unity3d.com/2020.1/Documentation/ScriptReference/Mesh.MeshData.html
I think I'll try with the Set* functions for now
@warped trail
@opaque ledge yes looks like it
thanks
@opaque ledge If I use FixedListFloat128, how many floats can it store?
Is it 32 or 128?
float is 4 bytes, so 32
Okay thanks, that's good to know.
isn't a couple of bytes in fixedlist is reserved for counter?
That got me thinking, I have some components that are just a fixed sized float arrays and I've been using DynamicBuffer for them.
"An unmanaged, resizable list that does not allocate memory." My guess is no
Is there any benefit to using these fixed lists rather than dynamic buffer, to warrant rewriting?
i recall this message was posted here FixedListByte4096 has only space for 4094 bytes... 😅
@lusty otter I literally asked the same question like half an hour ago
If you scroll up a bit, you'll get the discussion with me and @opaque ledge
😄
(Not to be patronizing, just thought it was a funny coincidence)
yeah
Because it is quite confusing
if I am sure that my system won't write to the same position twice, can I pass in a NativeArray with write access somehow?
Or are there problems because the processor can always only work on bigger chunks of the nativearray?
@junior fjord That is the exact reason why NativeDisableParallelForRestriction was made
Just slap it into your lambda (e.g. Entities.NativeDisableParallelForRestriction().ForEach(...))
ah ok cool
Hmm I guess I'm asking more of if there is any performance/memory/etc benefits
the reason I am asking is that from my half-knowledge I somehow remember that even if two threads don't write to the exact same position it is still a problem
Because both satisfy my need.
since they cannot work on very close positions either
because they work on cache lines?
Well probably you will gain performance, because if you use buffer as extra to your component that means unity has to pull them both when processing them but if the array is already inside of your component then Unity will only pull your component. As for memory, probably dynamic buffer is better because it will only take up to how many memory it needs, while fixedlist will always have same size whatever they are being used or not.
FixedListFloat128 can store 31 floats🧐
What do you mean by pull them both?
Do you mean a component that has a few fields, plus a buffer, so you have to pull both of them when processing in a system?
you have to do Entities.ForEach(ref Component, ref Buffer)
Ah okay yeah, so mine is just the buffer itself, then that performance gain doesn't apply to me then.
which will even has worse performance if you exceed internalbuffer capacity
what is your use case ?
(ref Component, ref Buffer) will get you NativeArray<Component>(),NativeArray<Buffer>()
i am just trying to say that if your struct has some fields and needs a array-like field, FixedList is pefrect for that, for everything else Dynamic buffer would be better i think.
Yeah that's the situation I'm in, that clears things up 😄
Also keep in mind the larger a fixedlist, the fewer entities will fit in a chunk (same as dynamic buffer initial capacity)
just profile it and you will get your answer😅
yeah, so dont use FixedList4k for 'just in case' 😄
is this fixedlist some kind of new alternative to dynamicbuffer?
Why are there FixedListFloat128 etc if you could just do FixedList128<float>?
Are they specially optimized for float or it just looks nicer.
there is FixedList<T> if im not mistaken
no idea Burrito, never used it, but perhaps there is an advantage
nope, im wrong😋
for example in FixedString there is a constructor that takes a string and ToString also works properly, while in FixedList<char> it wouldnt be like that probably.
I think we also have to keep in mind that Entities is still in preview, so maybe these things are still being figured out by Unity
everyone be silent, Topher is writing 👀
are these fixed sizes arbitrary unless you just so happen to need to keep batch process chunks of data specifically of the fixedList's size or are they based on hardware architecture, namely the logic gate and storage matrix on DDR4?
just the architecture since it's being stored in a physically distinct area in memory for efficiency I was thinking it would fit nicely in a nook of the ram stick
Is a nook an actual unit of storage size in RAM or are you saying it would fit nicely in a physical part of the stick in the same way my kitchen table fits nicely in my breakfast nook?
"RAM stores the data in memory cells that are arranged in grids much like the cells are arranged in a spreadsheet, from which data, in the binary form of 1's and 0's, can be accessed and transferred at random to the processor for processing by the system's software."
grids of cells* that are read through pins
I guess it has more to do with the number of pins on the stick honestly
but the number of pins correlates to the grid layout
Yes, I know what RAM is. I was just asking if you were saying there was a preferable range of physical space on the stick for data to go. I'd never heard of that.
I was leading up to the use of byte arrays vs buffers, is tehre any point?
also trying to figure out the best way to code a RAM stick in ECS ```public struct AND_GATE_Component : IComponentData
{
public bool inputA;
public bool inputB;
public bool output;
}```
my system creates a struct MeshData (basically a struct that contains a few NativeList for vertex positions, and triangles). I want the system to run in parallel and afterwards save that meshData to somewhere.
My idea was to use NativeHashMap<Entity, MashData> but that does not work since "one of the struct members of MeshData is marked as Nativecontainer"
Is there another way to do this?
Interesting
but this is just silly, because it can't even be an accurate simulation in this way; it would need to iterate through too much before passing a "unit of time" actually
the clock output seems most important, that way it can iterate in a more dynamic manner
You simulating an entire PC? Maybe simulate on the component level?
@junior fjord there is nativestream 🤔
Can't be accurate simulating something as small as gates because it will always take longer than reality.
but proportionately accurate with respect to time I mean
but I'm prolly abandoning the idea, thanks for the back and forth though, it helped me understand some things better
peace
Np, good luck
@warped trail thanks
did not know about that
does that somehow help in my situation?
I mean basically I create a struct MeshData in a system for each entity and all I want is a way to pass that data to outside of the system
@light sage pro tip. Something like a ram simulation (redstone?) is a horrible idea to do in ECS
something redstone style is not linear stuff, cables are connected to stuff and you propagate the signals on a graph. Unity ECS sucks at graphs
using Jobs and stuff like that is still good idea, just not that good idea to have the stuff on the ECS itself
I think it depends on the approach
there are ways to do it that can utilize the batching
if its more like a cellular automata (redstone/wireworld) is still not a good idea, you want to put that on its own data structures
the thing is the random access
unity ECS is amazing at iterating linear on stuff and doing calcs
well SRAM them, just a cache
it has high overhead (and i mean really high) on random access
yea, I know that, it's why they removed [inject] so long ago
if something on mainthread or another job needs to access a given grouping of components mid-job, that defeats the purpose
but I'm thinking it can be done efficiently with buffers/arrays
one typical "trick/design pattern" on cellular automata type stuff, is that an entity is not 1 tile, but a grid, like 32x32 tiles. This way you can keep the cool systems/ecs architecture, but it will perform much faster
yup. Wireworld is like that
the game Noita (all cellular automata) does something like that too. Their simulation is all split into smaller grids, it makes save/load and the calculations easier to do and multityhread
make's since, that's why I was asking about the fixed array sizes earlier kinda
It's a challenge, but I feel like it's a good way to learn
yea, thinking about, positional codepency is pretty hard to overcome with ecs
but let me find the link rq
thats very much one of the biggest weak points of ecs
in all implementations, random access (get component data X from a random entity) is pretty slow
This isn't the specific link I was reading a while back, but I believe it's the same user, the one talking about using bit operations to circumvent random access
someway to just filter through components and use bitwise math, it made more sense to me at one point today
so the bitwise functions are like conways rules, but the number of entities themselves just get's too large I guess...
Updated a simple path finding project to entities 0.7.0 and now i get some "error DC0011: Every Entities.ForEach statement needs to end with a .Schedule() or .Run() invocation"
In all cases there is a .Schedule() or .Run().
Any idea?
So to be clear, the only change you did was to update the package?
Have you restarted Unity and your IDE afterwards?
Yep and no. Let me try that. Btw. going back to 0.6.0 removes the errors.
weird, if they all have Schedulr or Run then that sounds like a bug
Uhm... updated again to 0.7.0 and no errors anymore 🙄
The upgrade path was:
- 0.5 -> 0.7 -> errors
- 0.7 -> 0.6 -> errors removed
- 0.6 -> 0.7 -> no errors
if I want to have a global constant array, how do I do that?
I have public static NativeArray<float3> corners = new NativeArray<float3>(cornersArray, Allocator.Persistent); in my static Global class, but that gives me Jobs can only allocate Temp memory
If you want it to be something you can put in a component you would use BlobAssets
it is like a constant 6 element array that I only initialize at game start and never change
You can't use mutable statics in jobs or burst by default. From the compiler/bursts perspective any static array is mutable even if you declare it as readonly. You have to put it in SharedStatic or a BlobAsset.
Other than that the only static data you can safely use in jobs/burst are ones you can actually declare as const which means only the basic data types.
ok, thank you for the clarificatoin @zenith wyvern
erm ok so this question is probably pretty basic. I have created meshes in one of my jobs (a few entities that have a DynamicBuffer for VertexPosition and an int buffer for indexes). I want to draw these meshes now..how?
I do not have any gameobjects with meshfilters anymore as I used to earlier
You have the mesh data, you need to get it to a mesh. Meshes have SetVertices/SetIndices methods that accept NativeArray<T>. You can reinterpret your dynamic buffers to the correct types (float3 for verts, int for indices) and use AsNativeArray to change them into nativearrays that can be passed to the mesh. This doesn't do any copying so it's pretty fast too
Something like
var verts = vertBuffer.Reinterpret<float3>().AsNativeArray();
var indices = indexBuffer.Reinterpret<int>().AsNativeArray();
mesh.SetVertices(verts);
mesh.SetIndices(indices, 0);
Unity has introduced newer apis to make passing the data to the mesh faster but this is a good starting point
ok, can I do this from a job or has it to happen on the main thread? And how do I actually then render that mesh?
(I actually already have nearly that code in one of my systems, but the meshes are not rendered yet, I only have the mesh instances)
Do I need to create gameobjects and assign MeshFilters to them from some mainthread system now or what?
Passing the data to the mesh has to happen on the main thread. You can render with Graphics.DrawMesh (which has to be called in Update) or Graphics.DrawMeshNow (which has to be called in OnCameraRender or similar functions if I remember right)
and what do you mean by newer API? This VertexAttributeFormat stuff where you can actually set what goes to which stream?
Or you can just use the mesh directly in a mesh filter like you just said, up to you which way to go
and what do you mean by newer API? This VertexAttributeFormat stuff where you can actually set what goes to which stream?
@junior fjord
Yes
ok so I still need a gameobject that calls Graphics.DrawMesh?
Or the "MeshData" api in 2020 which is even faster and you can use inside jobs
ok, I'll wait until there is documentation on that or any simple example
I know not enough about graphics to understand it from what I found up to now
I mean the newer API
The "Combine Mesh" scene demonstrates the job api
oh man thats great thanks
I did not know that exists
I only read through some weird google docs thing where they introduced the new features 😄
ok so I still need a gameobject that calls
Graphics.DrawMesh?
@junior fjord
You don't need a gameobject. In my roguelike I call it from a system insideOnUpdate
so I could do it in a Entities.Foreach.Run right?
then I either apply the meshes to some meshfilters on gameobjects or use Graphics.DrawMesh?
You would need WithoutBurst as well, but yes
I don't think there is a "recommended" way, but it's the way I've been doing it and it seems like the best way as far as I know
Once we get the new version of HybridRenderer it will probably be better to just use that even for dynamic meshes
yeah I am somehow not very up to date on what will happen next or what to wait for
it seems the information is so scattered
ok thanks, I'll go with that for now 🙂
It has been 1 month since i started to get my ongoing project to ECS, and at beginning i was like this is scary, what was chunk, how am i suppose to bridge ECS to MB etc. and then 1 week later i was like "YAY i can move stuff around", and now i see my project growing and improving, i am kinda proud of myself 😄
There is still much to learn for me, hopefully in time^^
Just wanted to share, and wanted to thank all of the people here that helped me 😄
Got some questions about entity storage
In EntityDataManager, I imagine entities and version numbers are allocated parallel to chunks?
Since different chunks can have different component data array lengths, does that mean entities and versions themselves are allocated with a different memory allocation strategy to account for size variance?
And then are entities stored as offsets from their chunk address?
And if so, since 16kb is less than the address space of a short but more than the address space of a byte, are they packed? Is version stored in the remaining bits, or in separate arrays, or interleaved with whole int16s? And how much storage do version numbers themselves take?
And then, for consistent entity to component index mapping, and reusing entities, I imagine they use something like a free list to store unused indices instead of swapping them...
But then for querying entities within a chunk for something like component removal, do entities have to be iterated until the matching index is found? And if a free list is used, how do you not get erroneous data from the free list? Is it something like a bit flag, or do all entities use something like a sparse set to map back and forth from dense data to the “indices with holes” in the entities array? I read that component removal works like a swap-back method, which sounds sorta like sparse sets, but I can’t find anything on the specifics of entity mapping and reuse
@spring hare entity indexes dont really exist, they are an index into a "entities" array
this entities array is global, and contains pointer to chunk/archetype, and version
so no, its not actually allocated parallel to chunks
but chunks do have an array of entity ids in them
So there is just one global entities array, with each entity pointing to...
Chunk + offset?
Is the entities array just a pointer array?
That wouldn’t make sense because entities would be mapped to multiple chunk data... I guess they’d have to be chunk pointer with an offset int of some size?
If chunks have entity ids, then it sounds like the entity array and each id in the chunk do kinda work together like a sparse set
yup
So then the entity memory overhead would be 8 bytes for chunk pointer + number of bytes to represent chunk offsets + number of bytes to represent version + any padding + number of bytes to index back into entity array from within a chunk + whatever padding happens inside the chunk?
chunk pointer + index within the chunk
bigger overhead is entityID itself
Entity handle is 2 32 wide int
or was it 64? i dont remember
also, in the way unity ecs works, you will get most of your overheads from fragmented non-full chunks
so entityid overhead itself is really not so big
I guess it kinda evens out a bit because more and larger components mean fewer entities per chunk anyway
nah, chunks contain entity index, which i think its 32 bits
so in the chunks, its just 32 bits per entity of overhead
its really not so much overhead per individual entity as an absolute total
Huh, so I guess that puts the ECS entities at a 32 bit address space limit?
not exactly
Seems pretty reasonable
32 bit amount of entities is absolutely insane
Yeah
4.294.967.295
4.3 thousand million entities
the most insane tech demos (megacity) i think was 5 million
mayority of games wont go past 10k
Do we know what the overhead of offset + version is inside the entities array?
32 bit + 32 bit (gotta pad it anyway i think). but im not completely sure of whats the exact layout
Okay, so basically just 2 pointers per index
With chunk + version + offset
ok indeed 32 + 32 for entity handle
so 32 entity index, 32 entity version
unreal engine has the exact same thing for their uobjects. unreal engine has a bigass array that holds every single UObject in the engine
this array is entity-like. 2 arrays, one has pointer to object, other has object version. a WeakPointer (handle) holds 32 bits of index, and 32 of version
Wait, so no chunk pointer per index of the big entity array?
oh in unity it does hold a chunk pointer per index
Ohhh gotcha
but yeah likely 2 pointers (at 64 bit), one for chunk, and other is half version, half offset
would need to go check implementation
Wonder if they do anything with the left over offset bits
Since less than half are used
would be a good place for flags
Yeah
It’s funny, I was thinking of sparse sets vs archetype implementations since reading those skypjack articles and looking at flecs and EnTT
But archetype systems kinda do sparse sets too
Just I guess with no sorting
And more superstructure
not really. Big difference is chunk vs lots of sets
entity id size has MASSIVE overhead in entt
because the sparse sets contain an array of all the entity ids they hold
in entt the default entity is 32 bit. 20 bits for index, and 12 for version
similar happens in entitas
Huh, I thought it would be just 64 bits total for mapping
in entt and entitas, to check if an entity has a given component, you check in the sets
which act a bit like hashmaps
entityID->component
and like hashmaps, they have to store the entityID on themselves
so that repeats
a lot
I like using sparse sets but I just do it explicitly for systems that I know have one specific order
if an entity in entt has 20 empty components (zero-size), that entity has more than 20 ints of overhead (more around 40 ints)
I guess if you’re doing all sorts of component adding and removing and matching then you’d need more
in unity ecs the overhead is constant, no matter how many components you have
ah yeah that for sure. the sparse-set itself is a useful data structure for a bunch of things
i used them on a renderer once
but yeah, its mostly about "lots of hashmaps" vs "extremelly strict memory ordering"
I keep using them to rewrite awfully-performing systems at work that are low hanging fruit for one specific ordering and also do a decent number of insertions, removals, and iteration
there is a cppcon talk about slotmap, which is a version of the sparse set fairly well made
They’re pretty good as a compromise data structure haha
http://CppCon.org
—
Presentation Slides, PDFs, Source Code and other presenter materials are available at: https://github.com/CppCon/CppCon2017
—
We already have array, vector, and unordered_map, what other data structures could we possibly need?
As it turns out, there are a...
shows some tricks to implement those better
video is kinda because they want to add slot_map to the cpp standard
also colony, which is also similar-ish
Point two indices at each other, remove dense by swap back, out a bunch of methods out there for add and remove with different parallel data arrays
And then reserve and an add that doesn’t check for expand
Really bare bones
colony is also fun. Its basically a "bag" structure. You insert something, and get a handle/iterator back
colony guarantees that no matter what, pointers are allways safe
and iterators
Nice
when iterating the colony will have holes, but has trickery to make the hole-skip fast