#archived-dots
1 messages Β· Page 98 of 1
Although wouldn't be very surprised if you could do
Entities.WithAll<Thing>().ForEach((ArchetypeChunk chunk) => {}).Run();
and have it work because Lucas Meijer is a mad wizard
hmm.. is it related to generics? Another way of describing it is wanting .ForEach(in Entity e, in MyComponent m, in MyOptionalComponent op) to run even if MyOptionalComponent might not be present. In a full-fat job I would do this by doing NativeArray<MyOptionalComponent> ops = chunk.GetNativeArray(MyOptionalComponentType); and then if(chunk.Has(MyOptionalComponentType)).. etc
For cases where I have optional components I usually just define two separate queries, one with the component and one without
yea, me too - but can't do that with a Job lambda atm right?
ForEach(in Entity e, in MyComponent m, in MyOptionalComponent op)
that will just require the MyOptionalComponent to be there
indeed - I want access to it in the ForEach but only if it's present
and I don't want to incur the cost of CDFE
What I mean is I'd do:
Entities.WithAll<MyComponent, MyOptionalComponent>().ForEach(...).Run();
Entities.WithAll<MyComponent>().WithNone<MyOptionalComponent>().ForEach(...).Run();```
really trying to avoid that given how ridiculously verbose this job already is..
So adventures with the new dots netcode so far:
- generated code that wont compile
- following tutorial references a system/type that doesn't exist (here: https://docs.unity3d.com/Packages/com.unity.netcode@0.0/manual/quickstart.html)
- tried sample repo instead, runs at like 30 fps in editor... okey it's in editor
- tried to use profiler on standalone build... it wont connect
... i mean, sigh.
huh, sorry for that. running on my end with 300fps
my project, not a sample
does the ghost codegen not work for you?
well it does now
Is this still the simplest way to use random inside jobs? https://forum.unity.com/threads/mathematics-random-with-in-ijobprocesscomponentdata.598192/#post-4009273
Seems like there should be a more elegant way
I think it is as simple as it's going to get if you want determinism and thread safety
(and no mutexes)
I think that confuses a lot of people still, they're not used to seeing deterministic random π
I guess there's no way to do that using the new Entities.WithAll.Foreach in JobComponentSystem?
NativeArray<Random> rngs = GetRands(); Entities.ForEach((int threadIndex) => {rngs[threadIndex].NextInt()}).Run();
Oh, you can just pass in non-local variables into the lambda and that doesn't cause problems?
(the threadIndex arg has to have a specific name, but the compiler error will tell you what to call it)
rngs is a local variable
it has to be in the same scope as the Entities.ForEach() call, otherwise the codegen gets confused
but otherwise no restrictions afaik
But then you can't use the same seeded randoms between jobs right?
well, you can copy the array, but the other job would get the same random results as the first one
or if one job depends on another you can just use the same rngs
And I'd have to assign the rng back to the original array after the job I guess to maintain it's state
(copying the array is a bad idea tbh)
The thing is, prngs are just very fancy counters. If you look at your code, replace all Random with int, and all NextInt() with ++, does the code still make sense?
In this case I guess it would yeah, I'm just doing test stuff
(apart of the numbers not being very random obviously)
Im looking at the thread and you'd only need that if you want to keep determinism right? If my system doesn't need that can I just reinitialize the rand every update, pass it into the job, and be done?
@onyx mist sure, you just need to have a source of randomness to reinitialize
I use unityengine.random.range
## [Physics 0.2.5-preview] - 2019-12-04
### Upgrade guide
* By default, `PhysicsColliders` that share the same set of inputs and that originate from the same sub-scene should reference the same data at run-time. This change not only reduces memory pressure, but also speeds up conversion. If you were altering `PhysicsCollider` data at run-time, you need to enable the `ForceUnique` setting on the respective `PhysicsColliderAuthoring` component. This setting guarantees the object will always convert into a unique instance.
* Any usages of `BlockStream` should be replaced with the `NativeStream` type from the com.unity.collections package.```
Each day we crawl slowly toward the 2019.3 release
actually... the changelist is quite massive, dunno about spamming it all here :p
so.... about the new build system
is there any example or documentation how we should trigger this from command line for automated builds?
oh nice, been waiting on the new physics package π
yeah me too, will finally continue my physics experiments with it π
been waiting for the entities update to land and then the physics update as it didn't land at the same time
physics samples updated here as well as expected: https://github.com/Unity-Technologies/EntityComponentSystemSamples
ah sweet, so its probably in pacman already
yep it is
btw regarding the shared colliders, any idea what they mean with "that share the same set of inputs" ? Like the same shape+params? ie meshcolliders pointing to the same mesh, or a box colliders of a certain size?
anyone who knows how ecs actually works that has a few min to spare? i'm feeling like i'm banging my head against a wall.. and would just like someone to help me outline a simple ai system and component process (so i get an idea where i should start)
like i don't mean full code, just like.. should i use a regular system? jobs, what components i would probably need, and how to access them
I have a weird behavior, I canβt explain to myself. I use an exported fbx, nothing special just a sphere at 0,0,0 with size 1,1,1. If I use that sphere as Mesh on a game object that gets converted to an Entity with a RenderMesh. The sphere is exactly rendered at the vector of the Translation component. If I create the entity in code and add a RenderMesh with the same sphere as mesh, it gets not rendered at the vector of the set Translation component, but a different position, which seems to be the Translation vectors direction with a bigger length. The entity also has a Scale component, but the length is not related to the set scale .
@winter veldt describe what you want the AI system to do
trying to make it simple... i'd like a chainable task system. just start with a "move to" task, that sets a target, is set active, and upon completion starts another move task. eventually i'd like to have other task types (pickup item, use item, etc) but for now, moving is fine.
main thing is that i'm thinking i'm just doing things completely backwards or something so i'd like to hear how others would approach it, so i can get a bit more understanding how things work
rule 1 of the ECS, not everything has to be on the ECS
the individual tasks is probably a good thing to have as either components, or entities
but the task system/tree might be a good idea to keep on an OOP mindset, and just connect it to the ecs
specially now that you can have class components that are normal C# and can point to normal C# stuff
@vagrant surge you can what now?
latest ECS release allows components that are Class instead of Struct
those Class components are "relaxed" compared to the structs
so you can point to normal C# land stuff
with some caveats (you cant use Jobs on them)
so wait. you can create component classes.. can you have methods and stuff in them?
i dont know if they work with inheritance, likely not
so virtuals are worthless
but you can use them to point into an actual C# class that does have methods
you can basically have C# poco types
Something similar I do in my project. Warning that this is not designed to be super fast, just easy to work with. I'd have
AiMoveTo {float3 Target}
AiTask { Entity ExecutingActor}
NextAiTask {Entity NextTask}
Active {}
now a MoveTaskSystem would do
{
bool reachedTarget = DoTheMoving(task.ExecutingActor, moveTo.Target);
if (reachedTarget){
EntityManager.Destroy(e);
EntityManager.AddComponentData(nextTask, new Active());
}
}
for something like an AI, i think hte current jobs + ecs tryharding is a bit too much for the "think" part
for the actual tasks themselves, yeah the ecs is cool (they do have an Update()) every frame
but stuff like the "AI script" is something that does nothing, maybe an update() once a second, or only on response on events
for one of my C++ experiments what i was doing is that i had fairly "normal" OOP classes as "brain", that were the AI script, and the actual AI actions were on components
i also had AI "sensors" on components
also did the same thing on an unreal project. I had a BehaviorTree script that was the high level logic, and it would set/unset options and stuff on the components that handled frame-to-frame movement, aiming, combat decisions, and sensors like visibility checks
@worldly pulsar ok. see this is the issue π i've never seen nor used Entities and WithStructuralChanges().. looking at the documentation, it also has no description as far as what it does.
It's new, and I wouldn't exactly recommend using this as is, just as a sketch of concept. You'd probably want an EntityCommandBuffer in there to destroy the current task/set the next thing active etc.
@vagrant surge i could see that being the much more sane way of approaching things.
And for the DoTheMoving() part I actually do something similar to what vblanco said, where I'd just set a MoveTarget component on the executing actor and then just check if we are at the goal
for an "exact" example of how all that stuff worked:
I have a melee enemy. He does a random movement around his spawn point as "wander", and when he sees an enemy, he enters combat mode, and will periodically find a random "combat position" near the target, and move there, while attacking on a timer
so i had a behavior tree with stuff like Wander, Combat -> MoveToTarget->Attack
the relevant part was the "combat"
when an enemy enters combat mode, he will be finding "good positions to attack" naturally. This was done in its "combat component"
so this combat component would be calculating a score of points in a circle
but not much else
i did a similar thing to you @worldly pulsar i think, except with jobs. (keep in mind this is ALL ECS, i've never thought of combining it with regular code)
when the behavior tree tells "yeah pick best and move there", the movement component pathfinds there
and for the vision, i had a component doing raycast vs played continuously
so here, everything except behavior tree would be on ECS components. The MoveTo stuff a component, the visibility check a component, the zone calc a component
and jobbed
(I don't actually use this for AI, but for a "sequence of events with each taking some time" kind of thing)
yeah
i had mine (tied to a need, which is tied to the ai) but it had a couple actions, for example, hunger need.. when active.. finds the closest food, then creates a move task, pickup task, and use task.
you c an probably implement a full behavior tree as entities linked to each other
but im not sure if thats much of a good idea
hunger tracks progress, (i was trying to avoid adding/removing an active component), when move is complete, it starts pickup, after thats done it starts use.. then hunger is marked as complete
but i mean that's what? 5 entities per ai? i don't know if thats bad, or good, or what
Yeah, what I've suggested is pretty much just "execute a series of tasks" (which is what you asked for π )
If you want a full-blown behaviour tree you need a different approach
yes thats what i asked for i'm just glad i can actually see a similar approach π
Don't worry about the number of entities. Entities are basically free.
dont worry about number
nvm got out-speeded
in the unity ECS the cost of entities is literally zero unless they run in a system
so if you have 1 million entities just sitting there, waiting, thats basically zero cost
ok. so i was trying to avoid adding "active" components around, because talking before, people were saying adding/removing components fragments chunks and all that. so i have a lot of systems hitting tasks.. but they are usually just escaping early.
keep in mind an important fact on unity-style ecs, accessing components from a "random" entity is quite expensive
should i be using a tag at that point? like if i have 3 move entity tasks, should i add active to one, and thus only run that one? or should i have book "active" on the move component, and in the system it checks first thing, and exits?
on my implementation of that it is kinda slow
im doing some fancy memcaching stuff to try to make it faster
bool
the issue is that it needs to find where in the chunk exactly is that entity
i do it through a linear search for now π¦
Unless you are adding/removing the active tag within the same frame you'll probably have a performance win from having the active tasks packed in memory
so basically, for each of the components inside the archetype, i try to find the component you want to get, and get its offset within the chunk
If you want to do a more complex data structure like a BT, its much better to do that, in the best way you can - and then attach it to an entity via an BTReferenceComponent or something, instead of trying to make a BT using entities.
Unit is not building meshes out of entities, they have mesh data they attach to entities - similar idea. Everything shouldn't be an entity.
Or you can have a BT in a blob and just store the current state in a component
One thing I am curious about is will the whole DOTS tech stack change anything with how we approach serialization?
Oh, one more thing I like about the approach I suggested - you can store any task-specific additional data you want on the task you are executing (so in your case that would be e.g. a NavMesh query), without putting everything on the actor. Then you cleanup by just destroying the task entity.
yeah that's why i was using separate entities as tasks too. the useful stuff is there, and when it's done, you can remove it
@gusty comet yes it makes it a lot easier to serialize stuff
and i figured since tasks would usually be a few frames (they'd be the animations, delays, move-times, etc) adding, destroying the entities wouldn't be extreme for performance.
I figured that is the case @trail burrow given that the components themselves are completly stateless
that's what i thought, components are all neat little packages you can serialize pretty easy, and with jobs you can multithread it.
yes
i was actually using jobs to save map chunks before i knew what jobs and ECS were
I am pondering right now and maybe put this to the test in a week long or so project. Would be it be a good intermediate step to kind of apply the ECS pattern by doing the segregation into structs for the data, very atomized classes that do a single task like systems and using the game objects only for editor stuff? To kind of get used to the pattern without having to commit to it given it seems especially for my usecase which is 2d turn based games, Dots is not there yet.
@prime cipher you are probably missing a LocalToWorld component on your manually created entity.
@gusty comet you can definitely do that. I find ECS patterns are so different than how I usually think it's almost not worth it? I mean learning ECS is hard enough as it is right now, with the lack of documentation and frequent framework changes...
For me coming from langauges that are mostly purely procedural or heck even completly just state it would make more sense believe or not
take inform 7 for example the whole thing is literally just you manipulating state by manipulating relationship between data
thats why I am so pumped and want to get into it
I was never really fond of doing things the OOP way
if you really want to get into an ECS mindset however, you can use ECS for all your data as is, and gather that data for you GameObjects to use with a system
@flat talon Actually not, the component is there. One of the differences is, that my entity is a child, but the parents Translation is 0,0,0
@winter veldt I admittedly have no clue where to even start in a unity context.
@prime cipher can you post what the debugger for both entities looks like?
My experience is also, that if LocalToWorld is missing, it wonβt be rendered at all, but thatβs was in an earlier preview
@safe lintel sure, gimme some mins getting back to my pc
@gusty comet you can also run Entitas, which is easier to use than unity ECS
It would help to just have a concrete example for my usecase that I can poke my way around in. Say a simple 2d sprite box that I can move around with the arrow keys.
i am not very far ahead of you to be honest π but you can use systems to communicate back and forth between game objects. there may even be an easier way now with the newest version (see above, @vagrant surge was just talking about new possibilities with components being classes instead of structs)
Yeah I am a pure schmuck cant buy stuff from the asset store
so entitas is not an option sadly
isnt entitas free?
nope 80 bucks and chage
also did you check out the samples repo?
@gusty comet google it, the asset store version is basically a donation thing, the Github repo is MIT licensed iirc
yeah that
quicker at the draw than me π
i've yet to look at it. but i probably should.
Why use entitas. If you're just starting out you're better off learning unity's system. It's pretty good right now and it's only going to get better
ill be honest, i gave it a short try because unity ecs is frustrating, but learning its own way of doing stuff was confusing π
I have bad memories of Entitas. Their codegen is really annoying to work with in the long run.
for starters there's almost zero documentation. no tutorials that you can be sure are current, and this channel is pretty much the only place to get answers π
Yeah as said all I would need would literally a small sample of my usecase that I can poke at to understand how it works because right now its a black box for me
The ECS Samples have pretty good documentation. The cube samples are all very small and easy to digest and mess with and the readmes for each sample have a very clear explanation of what's going on
Because I have trouble conceptualizing it
I understand ECS on its own but I have no idea how it integrates if you will
welcome to the club @gusty comet
the cube samples do me no good though sark they use their internal conversion magic for 3d stuff
which is irrelevant to me
From what I gather I would be the kind of "hybrid" case if you will
It's all open source so it's not really fair to describe it as magic, but I know what you mean
Look at the spawner conversion sample. It has an authoring component for a fully custom spawner entity, and a system that operates on that.
Conversion is horribly documented right now
yeah those examples are basically for use if you know and are up to date with the current way ECS works. they explain very little. Also they are all pretty much oriented around rendering things, not something like.. ai, or more complex processes
i think only the TransformSystem has a good explanation, but using the samples repo should be a good place to start digesting it all
I dont need something complex as said. All I want to do is is move a f... sprite around
i can rotate the HELL out of entities. but that's not what i want to do.
Yuuki, from the ECS cube sample do you think you could move the cube around?
Once you can do that, all you need to do is change the cube to your own mesh (a quad for a sprite) and set your uvs and use the mesh instance renderer component to render it
I am not sure to be honest, thats why I said it would be immensly helpful to have a working example to poke at, because from that I could derive how other things work.
All I want to understand is the expected workflow
which as of right now is not the case because I have no clue what I am supposed to do in my given use case
Its a thing I could whip up in 2 minutes doing it the regular unity way
you said you're doing 2d right? does ecs conversion even do spriterenderer yet? if not all that conversion code in the examples would just be extra fluff you have to work around anyways
Yeah I am doing exclusively 2d stuff
using the sprite renderer? or tilemaps?
I have no clue yet what I am supposed to use in my use case right now that is my whole issue
what is your use case again?
2d turn based.
I am in the early stages of moving over a roguelike game to unity because f... python
There's no 2d renderer for ECS yet. If you want to do sprites in ecs you need to know how to build a mesh from code and how to set up your uvs
Otherwise just use regular unity and tilemaps until unity makes a 2d renderer
Thats why I said if there would be a way to do something similar to a MVC with the current ECS implementation I would use that
aka segregate the data and the render layer
have the model handled by dots and the view by game objects if you will
I could use the power of ECS to allow me more complex world state modelling basically
One pet peeve feature I always wanted to do was for example proper atmospherics
but that means traversing through thousands of tile instances in some cases
@gusty comet can i DM you? i'm pretty much working towards similar goals.
You should be able to model all your positions via entities in ECS then just run a ComponentSystem to map sprites to the entity positions. Seems like it would be a mess though
sure you can
I'll see if I can make a simple example showing how to convert a Unity Sprite into a rendered entity
That would be neat
There was a full sprite renderer in ecs linked here for you @gusty comet
you mean this forum post right? https://forum.unity.com/threads/200k-dynamic-animated-sprites-at-80fps.695809/
yup
Oh hey it's the thing I worked on
I am still going through that because I dont want to use something that I do not understand
But yeah I am slowly trugdging through scraps of information on how this thing actually works
Also just to clarify, I care so little about the editor end of things since most of the stuff I will do is procedual generation, meaning UI aside the vast majority of what I will be doing will not happen in the editor regardless.
I mean I did not have any editor when I was working in python, so there is that.
ok made a short example, attach script to a gameobject, plug in a mesh and material for it. when you press space in play, it moves the created entity forward. it doesnt use conversion though i suggest you look into it because its a big part of making your life easier
https://pastebin.com/q5HjTpz8
I will give this a look immediatly
tbh i found some of the samples kinda hard to understand, like spawn an entity that itself spawns prefabs that are created in conversion... ugh my brain breaks on trying recursive stuff and it reminds me of trying to understand 3d arrays, i agree that it is a little hard to decipher and also understand all the new terminology and different way of thinking
I assume since this has translation and rotation in it I have to use the legacy diffuse material as the texture?
or was this a 3d object you did move
use whatever for material or mesh
localtoworld is needed to render the entity with a scale/position/rotation
translation & rotation are optional but make it easier to modify local position/rotation without explicitly changing the localtoworld's 4x4 matrix
private IEnumerator WaitForJob( JobHandle handle, Action completeAction)
{
yield return new WaitUntil( () => handle.IsCompleted );
//This is optional
handle.Complete();
#if DEBUG
Debug.Log( "Job completed" );
#endif
completeAction();
#if DEBUG
Debug.Log( "Job Action completed" );
#endif
}
So an acquitance of mine is working on some code for doing some world baking for a mod we are working on for Risk of Rain, and he setup this coroutine to execute a batch of jobs
he contends that handle.Complete() isn't necessary, but he put it in here for "good practice"
I don't think there is any reason to have it there, and think it might be confusing/misleading
is there anything we may not be considering here to clear this up further?
Complete() is necessary if you have any NativeCollections in that job, to make the safety system happy
Yeah I just ran into that too. I was worried the job wasn't actually being run in the background or something but nah, it works the way you expect you just need to explicitly call complete once it's finished
thanks @worldly pulsar @zenith wyvern
Okay so I started working on a sprite conversion sample and I was quickly reminded how much of a nightmare it was to get instanced sprites rendering
@gusty comet are you comfortable with shaders?
@safe lintel Sry for beeing late, kids needed attention: Here is the screeny from the converted entity. The Translation 10,0,10 is from the GameObjects position
Here the manually / code generated entity. Pls don't mind some additional components, it is right out of a prototype
If you want to be able to get per instance rendering using sprites you do it using Graphics.MeshDrawInstanced and DrawMeshInstancedIndirect. If you aren't VERY familiar with those functions and how to use them, that's where you need to start. Forget about ECS altogether, just learn how to use those in normal Unity
Once you understand how to use compute buffers to push per instance data to your shader with DrawMeshInstance*, then you can start thinking about rendering sprites in ECS
Otherwise just wait for Unity to put out a 2d sprite solution for dots
@zenith wyvern I have never used shaders
When I wanted to do something equivalent to shaders I normally did effects via code
I am old.
aka per pixel manipualtion
@safe lintel and here out of game tab, to show the placement of the sphere in comparison with the line showing the real translation vector.
Then my advice is to start learning shaders or just stick with regular Unity tilemaps for now
huh?
So sphere should be at the end of the one pink line instead of in outer space
I have a hard time seeing why Sark. Given I can even right now just load a sprite of some kind in unity and manipulate it and return the result. For what I did it worked just fine.
Keep in mind my world is a world where 16x16 is high resolution for a texture
@prime cipher could the translation diff be due to something in the parenting process?
Do you require sprite sheets or animation?
Or are all your sprites just static images moving around?
There's a universe of difference between those two in terms of the complexity required to render them in ECS is what I've found
I dont necessary require them, it would be a nice to have, but not a strict necessity. I wont use the unity internal animation system for sure
because it is clunky for what I do
@safe lintel The parent has a zero Translation vector. I just add the RenderMesh to the childs and am only manipulating the Translation vectors of the childs afterwards. The diff is constant though, even if I move the entity by applying changes to the Translation, the resulting offset stays the same, a larger Translation vector.
Sark think Dwarf fortress with a tileset
thats about as visual as I would get
or top line would be cogmind
I simply don't know, where it should come from. I firsth thought, it might be the application of the scale, but that does not fit.
Yeah it sounds like you would be using sprite sheets at least then to change sprites. I'm trying to think of how to do that without having to write a custom shader
https://store.steampowered.com/app/722730/Cogmind/ for reference that would be the ideal level of fidelity I would aim for
Experience sci-fi tactical combat and exploration in a procedural world that combines traditional roguelikes with an immersive modern interface like no other. Build yourself from components found or salvaged from other robots. Attach power sources, propulsion units, utilities...
$19.99
519
@safe lintel mmhhh, Translation seems to fit LocalToParent but not LocalToWorld, still no hint, where the diff might come from
Where do I find the good documentation for Jobs?
I'm going to see what I can come up with to make something simple that fits the requirements, but it will take a bit
Any help is appreciated, I know I am probably a huge outlier compared to your average unity dev.
I don't think there is good documentation for anything dots or jobs related right now
The way I learned is by messing with ecs
yuki did you try that code?
also noomieware i assume on creation of the child entities when adding localtoworld localtoparent and translation they are blank?
I will soon(tm) right now I am on the phone with a customer so I did not have the time to.
timezones are not fun
@safe lintel yes, setting only Translation afterwards
21:20 and I am still working technically
Or do you mean, Iβd have to set LocalTo* ecplicitlY to initial values, probably zeros
no chance of any other systems interacting with it by chance after the fact?
yeah i dont think its necessary to explicitly set zero
No matter what you write to LocalToWorld, the transform system should write the (Translation+Rotation+Scale) into it every frame
what about commenting out adding any of your own components, and even removing the rendermesh from the process, see if you still get the offset issues when simplifying
@safe lintel It seems I have to adapt it to fit the new template or am I just confused?
@gusty comet what do you mean exactly?
@prime cipher wait, so you have the parent at (0,0,0) with scale = 3, and the child is at (5, 0, -8) relative to parent, so it should render at (15, 0, -24), which looks more or less like that is happening on your screenshot (assuming the pink vectors are (5, 0, -8))
also @worldly pulsar there was or still is the issue of creating an entity but the transform system doesnt kick in writing to the localtoworld so for a frame you might be seeing stuff get created at 0,0,0 or whatever the converted prefab's localtoworld is
(sry if I missed part of the conversation)
meant it as just a response to when you wrote about localtoworld being written to every frame
it complains about this part var rendermesh = new RenderMesh { castShadows = ShadowCastingMode.On, layer = 0, material = material, mesh = mesh, receiveShadows = true, subMesh = -1 }; specifically the RenderMesh
what the error?
@worldly pulsar Wait, you mean scale affects everything not just the size of my RenderMesh?
that the type or namespace does not exist
@gusty comet you need to add the hybridrenderer package
oops, will do that one sec
in particular, any child Translation will be effectively multiplied by the scale of its parents
@worldly pulsar holy moly just wanted to reuse one mesh an size it
LocalToParent is Matrix(Translation, Rotation, Scale)
then LocalToWorld is LocalToParent * Parent.LocalToWorld
so if Parent.LocalToWorld has scale in it, then local translation is effectively multiplied by it
LocalToWorld is what is then used for rendering
Totally makes sense now . Thx
while the localtoworld is modified, im pretty sure the Translation component should not be affected by the values of the parent entity
So my use case would be mesh instance manipulation? Need to look that up though
@safe lintel And what I was talking about is if you import the current version of the Entities package you can create a pre made cs with a pre defined structure that I assume is what we are supposed to use
@safe lintel it is not
But the renderer never looks at the Translation component, all it cares about is LocalToWorld
this is what you get for example if you create a new system
@gusty comet just copy paste the entire thing in and call it MoveAuthoring.cs, you dont need to adapt anything
i thought this was the whole reason of your woes @prime cipher
a translation value being added in somewhere that offset the creation of your entity?
No, Translation always reflected the expected values, just the rendered mesh was not at the Translation vector but somewhere else
Sry to habe not explained properly.
@safe lintel @worldly pulsar thx.
You not accidentally know by heart how to scale the instantiated mesh ? βΊοΈπ
you can move the scale to the child
or divide the child Translation by the parent Scale
@safe lintel what is the expected behaviour?
it creates a capsule and that capsule moves forward when you press space
without conversion
yeah nope
what I can gather is that when I hold space the z value of the entity increases that is about it
well technically not a capsule, thats the mesh i used but whatever mesh you input in the mesh field
had me worried everything i was saying in discord was inaccurate π
hmm seems materials do not like transparent pixels π¦
Okay, heres a question
more than two hours later and still no answer to twiners question π
didnt see a question only a statement π
The question is imaginary you have the find the answer within yourself
Anyone else able to run the updated physics examples?
I'm getting a package manager error
they work for me
Working in a component system, I would like a fixed-size array, I found this: https://forum.unity.com/threads/arrays-in-structs-in-c.22628/#post-2073615
However, this is all for MonoBehaviours, will all that truly work in ECS/Jobs?
What I am trying to do: Fill a 3x3 "grid" of ints. The grid size will never, ever change, and using individual int variables is just bothersome. I was wondering if there's a better way.
Huh! Thank you!
Reinstalling the engine version fixed my issue.
@zenith wyvern @left spindle You can do this also:
unsafe struct InlineArray<T> where T : unmanaged {
public readonly T* Buffer;
public readonly int Length;
public T this[int index] {
get { return Buffer[index]; }
set { Buffer[index] = value; }
}
public InlineArray(byte* buffer, int length) {
Buffer = buffer;
Length = length;
}
}
unsafe struct MyComponent : IComponentData {
// 12 = sizeof float3
// 8 = element count
fixed byte _Float3Array[12 * 8];
public InlineArray<float3> Float3Array {
get
{
fixed (byte* p = _Float3Array) {
return new InlineArray<float3>(p, 8);
}
}
}
}
If you want just a quick/short array in a component
I do want a quick/short array, thank you!
Why does Buffer have to be T when it's assigning buffer to it (and it's a byte*)?
I cast it to (T*) and the compiler stopped throwing the error so I hope that's good. I don't deal with "unsafe" stuff very much.
@left spindle i wrote this from memory in discord text window, so possible i fucked something up π
Is it possible to override the ecs delta time? i.e. the time used for animation/physics/etc ?
is it possible to dynamically create and destroy worlds? i.e. instantiate a world dynamically during runtime, attach systems to them, and then destroy it later on
Yep
@left spindle if you want a fixed size array of any primitive type (float/int/byte etc. no string tho) you can do this:
unsafe struct Comp : IComponentData {
public fixed int Arr[9];
}```
## [NetCode 0.0.3-preview.2] - 2019-12-05
### Changes
* Updated the documentation and added a section about prediction.
* Upgraded entities to 0.3.0.
### Fixes
* Fixed a crash when multiple clients disconnected on the same frame.
* Fixed read / write access specifiers in AfterSimulationInterpolationSystem.
* Fixed build errors in non-development standalone builds.
## [Transport 0.2.2-preview.2] - 2019-12-05
### Changes
* Added a stress test for parallel sending of data.
* Upgraded collections to 0.3.0.
### Fixes
* Fixed a race condition in IPCNetworkInterface.
* Changed NetworkEventQueue to use UnsafeList to get some type safety.
* Fixed an out-of-bounds access in the reliable sequenced pipeline.
* Fixed spelling and broken links in the documentation.
hmmmmm
Entity Conversion preview breaks asap when I add that NetCode package to the project
I mean, if viewed while playing in editor
@left spindle why not just use int3x3 if u need grid 3x3?
Ty for notice Olento
As much as I try the whole conversion stuff does not yet gel with me.
I don't like the conversion workflow, it feels like a half measure to me
and perhaps less forgivingly, a hack solution
-> rotated 90 degrees CCW
I'm still working a "simple" example for sprite conversion but it's slow going. The conversion is the easy part. The hard part is figuring out the flow of data from conversion to rendering
My approach to that is trying to use the hybrid renderer
Which I guess is why Unity still hasn't come up with anything better than the incredibly basic hybrid renderer
all I am trying to do is convert a gameobject with a sprite component to a entity with said sprite using the hybrid renderer package
but what bugs me is I have no clue what the hybrid renderer exactly does.
It's open source so you can always dig in to find out
@zenith wyvern after you have SpriteRect and some way to reference an atlas on each entity, what is the problem then? I thought gather all entities -> sort by atlas -> Draw would be good enough?
One thing that came up while fidding around is that according to the compiler components can only hold primitive types
which is kind of odd?
What do you mean by "atlas" in this context?
A sprite atlas, a single texture with a bunch of source textures arranged in a grid or whatever
So you need a custom shader that handles per instance uv data. You then need to collate all the separate entity uv data per sprite and push it to the shader
That's the complicated part I'm finding
I've already done all this in the 200K sprites thing I made. Now I'm trying to simplify it down as much as I can
Turns out it's not so simple, at least from what I can see
Oh, it's the simplyfying that's hard. Yeah, getting instancing to work annoying.
And unfortunately the RenderMesh system isn't much help. It offers no built in way of instancing data on the ecs side so you just have to do everything the old way by pushing all your instance data to the material in compute buffers and doing Graphics.DrawMeshInstanceIndirect per material
I think I've seen some movement in that direction (like, you can set the _Color by adding a component)
Oh really?
There was a forum post where Joachim gave an example
I'll have to dig that up, maybe I could just expand on that
Although looking through the source for the rendermesh system it's really hard to make heads or tails of it
tell me about it
Haven't looked at it any deeper or tested that
And it was Siggi that gave an example not Joachim π
speaking of conversion workflow, let's say you made your own sprite renderer
you could use conversion from unity's spriterenderer to your ecs sprite renderer, but then you're basically using something else to render in editor (non-play mode)
you could make your own ecs spriterenderer authoring but then it won't render because systems don't run out of play mode
what's the solution here if you're trying to show stuff while scene editing without making a completely seperate authoring rendering system
I think you're always just meant to use "old" stuff in editor mode, so you would use sprites in the editor
If what will eventually show up in ECS can't be sufficiently represented via gameobjects due to performance or whatever you just have to abstract it with custom editors
you can create a world for at edit-time - I'm working on using it as a solution for previewing tweens
Pretty sure you can both run systems in editor, and the (non-subscene) entities are converted into the editor world
ahh didn't know you can create edit-time worlds
Hybrid Renderer has [ExecuteAlways] and it runs in the Editor World
that's good
I finally got the simplest thing working.
Aka have a game object with a sprite that then gets converted to an entity with the proper components
@gusty comet the problem I ran unto with hybrid renderer and sprites is that alpha sorting sprites does not work. There is no way to draw them in the correct order (back to front).
rendermesh has a layer property
I freely admit I used in large parts loogies code to get a grasp on how to construct the rendermesh from the ground up to get it to work but it does work now
Oh wait derp, alpha sorting...
I should read a bit slower I guess
yeah no idea on that front I have to say
but its better then nothing I would say. For my use case transparency is not that much of an issue since there wont ever be much occupying the same tile ever
If you can guarantee that then for sure it's a non-issue.
Yeah I make a 2d Roguelike so yeah I can
I wanted to be able to use it to ECS my entire parallax system but it was a no-go
Yeah, but given they said they will add 2d support but postponed it because people cried for 3d support in project tiny
which annoys the f... out of me to be honest
I wonder how many people are even using tiny yet
Well right now you cant even because they pulled the package
so unless you scram to find it you wont even see it is available
so my guess is, not many
But given they advertised it for super short casual games and ADS
I guess its a question of "it will make us money to listen"
weren't they going to use hybrid renderer in project tiny so it was one unified thing
i think that's why they postponed 2d in tiny, they were writing their stuff completely seperate from all the other dots packages before but now they are unifying and hybrid renderer doesn't support 2d yet
Well initially we where also supposed to get a pure dots editor, and then tiny was supposed to be pure dots now its neither
this year has been confusing overall in where unity goes
bottom line, I dont know for sure
yea it's weird
i'm not against conversion workflow but the whole thing is so awkward atm
with subscenes
and if you modify your authoring component you have to manually change a version tag which literally has a string of your name on it + version, just to let subscenes know they need to update
I mean I get that, it might be a bit odd for a single seat user, but in a team that makes sense
especially with the caching
But I agree the whole conversion workflow is arkward.
Yuuki that's just rendering from a whole texture right, not from a spritesheet?
Yeah thats just a single texture
If you do anything beyond displaying it might not be worth your while it was done specifically for a usecase like loogie or I have, as said most of the code is his.
Gotcha
All it basically does is take a sprite you specify, build a rendermesh with the 2d sprite renderer material, construct a rendermesh and display the result
I don't suppose the DOTS multiplayer sample is out yet?
@trail burrow I wouldn't say hacky, just really unpolished
I agree with fholm it feels very hacky.
@worldly pulsar they're using their old system as a bootstrap to pull data from... it feels like a giant hack π¦
because they didnt wanna rebuild the editor
It works if you want to move from game objects to Entities but once you are in the entity space you loose all interlinking
because it'd be too much work
i mean it is what we got, so whatcha gonna do about it
but well
Like I have still no clue how a UI monobehaviour like a simple label would even display the contents of a component for example
Well, they could write a full new editor, have that editor edit authoring data, make you write builders that turn authoring data -> runtime data. But the result would be like 95% the same as piggybacking on existing MonoBehaviour tools
As it stands right now I fail to see how unity is a better way to do it over just firing up monogame and implement a custom ECS that I have full control over
Remember that separating authoring data from runtime data is the goal here.
It's literally in active development
It sucks right now, it's going to get better
Hopefully
As I said yesterday, for my taste they made this publicly available at least a year to early
For example once we get visual scripting, it only has a dots representation, same with the new physics stuff
which keeps the whole thing in this odd limbo state
for probably several years
I said before either they gonna pull this off properly in the end and everyone will switch, or this DOTS-switch is going to be in textbooks in 15 years as an example on how to NOT do a major technology pivot lol
Its a shame given that Dots itsself is not at fault
Preview tech is not supposed to be used in production. And developing new stuff in the open is the best thing for a devtool company to do.
its not supposed to be used yes, but evaluated as if
since that is the goal in the end
I mean however it ends up I vastly prefer this to how it used to be. Take ugui, literal years of development with almost no information coming out and when they finally drop it, well....
Let's just say it could have used more user feedback while in development
they're on their third ui lib and third networking lib
third times the charm
so
.... maybe?
π
I still use the ass old UI lib
it has the big benefit for debugging tools in that you can write a GUI which will work in both editor window and in a game build
which we do a lot
UIElements is super promising. And thankfully they are letting us mess around with it while it's still in it's infancy
I mean I am not their target audience because I hate everything webdev with a burning passion
I'm still trying to overcome my aversion to CSS π
so the whole css stuff scares the crap out of me
I'm not a fan of it either but it makes a lot of sense with how tools are developed for games
I am generally not a friend of anything that is interpreted
I like stuff that is defintive
because it is easier to reason about and you do not need to know intricacies of implementation
I wont judge it before I havent tinkered with it for a while so I wait till it drops
With the ui builder you won't even have to mess with css or anything. You build your ui visually similar to how you do with ugui then just hook it up in code
I'm trying to overcome my aversion to visual gui editors as well π
MS FrontPage anyone?
But if you want the EXTREMELY useful stuff like separating layouts and styling you can do that too
Actually since we are super off-topic anyway, @zenith wyvern do you know what is the status of the in-game UIElements and ECS-UIElements?
Last I saw they're delaying runtime UIElements until 2020.1
frontpage was my jam! dont diss it!
And they said they're working on turning it into a package on the package manager at the same time at which point they can start looking at integrating it with ECS
ok, so distant future. thanks
That thread you showed me about instancing data on entities for the Hybrid renderer is really promising
oh sark already replied, should drink more coffee
Sadly it's only for HDRP right now
But if that's how it's going to work with URP it will be fantastic
Isn't Hybrid basically HDRP only right now?
Yeah
But you can just assign arbitrary data in your component and it will automatically pass it along to the shader
Oh I don't think the hybrid renderer is hdrp only atm, you can just drop it in a normal scene and it works as far as I know
But the per-instance ecs data only works with hdrp materials right now I guess
My understanding (based on Joachims post in that very thread among other things) was that they are working on Hybrid for HDRP first and other pipelines work kindof by accident
I know the last time I tried hybrid with LWRP it was... not good
That's a bummer but I guess it makes sense. I'm not really interested in the bulky mess of HDRP for doing small scale tests with ECS
Would be nice if there was somewhere that kept an up to date matrix of all of the RP stuff. HybridRenderer works with built-in something like so long as you 1) use standard shaders if you want instancing, 2) don't need light baking, 3) ... etc - my assumption is these will be first supported on hdrp as Rett says but it's hard to keep all of this in your head.. or even know before you pick an avenue
I'd rather have the effort needed for testing/maintaining that matrix spent in getting the renderer done asap π
.. not sure there's anyone at Unity who would actually know enough to be able to make it anyway given the teams and intricacies π
what even is the hybrid renderer
ECS question: is it possible to have several instances of the same system in different worlds at once?
so i can create a world during runtime, and dynamically add systems to it? even if another world with some of those systems already exist?
World.GetOrCreateSystem<Sys>() will do that for you
Is there anything specific around multiple worlds that are broken right now?
like loading sub scenes into them, or something?
I havent tried subscenes yet but they seem to work for me so far
how would i load a subscene into a specific world?
been trying to figure that one out also
Not sure sorry - not tried something like that. However, being a bit curious I see you could take a look at AsyncLoadSceneOperations.cs e.g. using (var reader = new MemoryBinaryReader(FileContent)) { k_ProfileDeserializeWorld.Begin(); SerializeUtility.DeserializeWorld(Transaction, reader, objectReferences); k_ProfileDeserializeWorld.End(); } and other bits might be useful
would be interested to see if you get a simple example working
afaik there isn't a nice easy API call for it yet.. there's just the subscene auto load stuff
@trail burrow I may be completely wrong on this because I never tried, but from what I understand each subscene is represented by an entity with the SceneReference component (just a GUID in it), and if you attach the RequestSceneLoaded component to it then there is a system in InitializationSystemGroup that is supposed to notice that and load the subscene.
So maybe if you somehow copy the SceneReference+RequestSceneLoad to the other world it would work?
speaking of different worlds - I am currently browsing through the docs but can't seem to find a way to transfer entities between worlds. I basically just need to instantiate a entity into one world based on an entity in another world.
I am still somewhat confused. I have the following situation. I have an entity (say for example a player) that has a given component(say a transform) and I have an UI element that I want to display its x and y position in. What I am not sure of is how on the monobehaviour side of things would I query the entity and its component data?
@gusty comet are you manually creating the entity? Or is it created with the conversion workflow?
Well in my current situation I have created it in the conversion workflow but I also have instances where this is not the case.
This is the authoring I am using at the moment to do so https://pastebin.com/8Tkz37xF
Its a derivative of what loogie did to get a sprite to render on the ECS side of things baked into an authoring system basically
I plan to generalize this further by letting it grab the sprite from the gameobject it is attached to once I am a bit further into things
Its a very hacky workaround using the hybrid renderer
I mean one of the big advantages of ECS is supposedly be to easily reference data, which inside the ECS system works like a charm, but beyond that I am utterly clueless.
Aka how to "bridge the gap" if you will
You can run main thread code over mbβs that have been converted if that helps. I.e. Entities.ForEach(.. in SpriteRenderer sr) and get texture data. Apologies if you already knew that.
I honestly have no idea of what you speak. And I dont need texture data I just want to get a primitive value out of an alredy existing entity on the monobehaviour side of things so I can display them.
Iβd probably approach it as a system setting a MB rather than a MB interrogating an entity
Which way around is secondary to me as long as it works.
but how does the system even know that the monobehaviour side exists?
@gusty comet https://forum.unity.com/threads/showcase-pure-dots-ui-system-detailed-description-feedback.688531/
source code released: https://forum.unity.com/threads/source-code-dotsui-open-source-ui-project-for-dots.715880/
Motivation
The current Unity UI...
this is all totally confusing to me
I havent used myself, but you should lok into it how he does it.
Thats not helping me right now, I want to find the supposed workflow not something externally created
Right, but theres most likely an answer somewhere in there.
Look through the code, see how he does it. Recreate.
Talking to uGUI from ECS really isn't something you want to do right now. UI in general is on the "Not Ready Yet" pile.
I dont want to talk to UI specifically this was just one use case. I just want to know how the heck I am supposed to let the monobehaviour side peek into the ecs side
regardless of what it is
since right now I have no clue how that is supposed to happen
All I want is basically find an entity, find a given component of that entity, and read a value that it has on the monobehaviour side
You can query the World.DefaultReallyLongNameThing from a monobehaviour, or use a GameObject with "Convert and Inject GameObject" that is not part of the canvas to have an ecs system see that gameobject.
For non-uGUI GameObjects you can just use Convert and Inject and the systems can just query for the components on them
So what I am gathering there is its best I just ditch the Monobehaviour side completly and write my own systems in pure ECS
or use injected GameObjects
The whole conversion workflow as it exist right now is too hacky to rely on for me, too many excpetions or things not there yet.
that's true for the whole DOTS ecosystem
Yeah I mostly muck around with it to learn as of right now
One thing that seems to be the case that I am not sure of yet though. As I understand it that the world that is created is completly scene agonistic
which means at one point or another we might have to dispose of things manually again?
Or is component data deallocated immediatly after a job has run its course?
These days you can have temp allocations that get cleaned up automatically if you use Allocator.Temp in Jobs
There's also JobHandle Dispose(JobHandle) that does jobified deallocation on native jobs, which is relatively recent
Yeah wasnt that supposed to be used only for literally temporarily needed data? aka say a intermediate result of something that you then discard before a job returns its result
What I am curious about is where basically the boundaries of state are
Say I have a "map" that is a bunch of tiles that all have a position and a type like in any turn based game, then I move on to a different level and the previous tiles are basically of no use to me. In managed code I would normally deallocate those
@gusty comet late reply but from monobehaviour you just query components same as normal, and the other way around you can just add your UI elements (or whatever other monobehaviour) to an entity and iterate that from a system
i think it was 0.2 that added adding monobehaviours to entities
@gusty comet If you are looking for 'ready made solutions' that work out of the box, give up on ECS/DOTS atm.
I am not looking for ready made solutions, quite the contrary actually
and regarding deallocation, i'd prob add something like a scene/tile tag and delete every entity with that tag if the tile gets unloaded
Where I am right I am basically trying to understand the expected workflow @trail burrow
Since they released this to be tinkered around with I think its safe to assume that they had a specific workflow in mind
For both a pure and a hybrid approach
static stuff use conversion workflow, dynamic is instantiated from archetypes/prefabs, scenes are loaded/unloaded via the subscene idea
And yeah scorr that is pretty much what I was thinking. Since runtime GC can not really defer what is no longer needed due to the nature of how systems are working.
the ECS basically doesn't cause the mono gc to run because its all allocated from native mem
Ah see that helps, which gets me back to yeah we have to manage that on our end, which I am fine with, I just wanted to know if that is the case.
no need for object pooling or anything, just delete an entity and it's gone
still not sure what you mean, have to manage what on our end?
deallocation
it's basically same as with monobehaviours isn't it
except you don't have to worry about garbage and the slowness of instantiating gameobjects
@gusty comet It's possible to get and inject data into ECS from a MB, you just need the EntityManager. I store it on init in a public static and use this for UI stuff
My 3rd person camera script has only a reference to an entity, in update i get the translation comp to get the current position for example
There's actually nothing preventing you from exchanging data
It's not recommended because it's slower and runs on main thread but I don't care for that when the other solution would be to rewrite everything
Has anyone used the feature of adding managed components like GameObjects directly in component data ?
Seems like its possible in 0.2.0
One thing that confuses me when reading discussions about Unity ECS are static vs dynamic entities. What exactly is not dynamic about them?
Post for reference: https://forum.unity.com/threads/per-instance-material-params-support-in-entities-0-2.782207/#post-5206433
@deft niche I've not read anything new about it. Do you know more?
@magic frigate It's about rendering. You can optimize better for non-moving entities.
Ah. I got way too far ahead of myself assuming it was something to do with the memory layout and not just a rendering thing
@deft niche I dropped my weird string interning scheme and just attach
class Title : IComponentData { public string Value; }
to my entities now. No problems with it so far.
Ah you mean attaching MonoBehaviours. No, sorry.
did anyone tried to use UECS with IL2CPP on windows?
I am getting this, but don't how how to fix it as the disabled stripping level is not available anymore
(of course I can modify the code but don't want to do that)
Did they remove the name sorting of groups, or have I messed up a lot in my project? x)
Now my AA<systemName> ZZ<systemName> doesn't work anymore x)
@scarlet inlet you can use link.xml at the root of Assets folder (I dunno if it works elsewhere in the Assets folder too
to whitelist packages that you don't want to get stripped
example here from dots physicss samples: https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/UnityPhysicsSamples/Assets/link.xml
great thank you!
I just personally copy that file over
yes sounds good
do you know what I should do to get a package from git? I am trying to make my library package compatible
I don't understand the question
what package?
if you mean the package managers ability to use github as source, you probably need github repo/branch that's prepared for that kind of use
I dunno if they support separate package paths inside git repo yet
in past they didn't which practically destroyed the feature for most (as you can't then share the actual package and sample on the same branch)
yes I am talking about that and it seems to be a thing in unity 2019.3
but using a git url with a package.json on the root doesn't seem to work
what is a thing?
git support or paths inside the repo?
if the latter is not supported, it's not that useful
it's actually been there for a quite while, they just did a GUI for it
Here's for example Alloy shaders turned into package https://github.com/0lento/Alloy
I did that on summer 2018
but back then the package needed to at the root of the branch
Maybe this helps, too: https://docs.unity3d.com/Manual/CustomPackages.html
ok checking them thank you
that's just how to make them, I thought the idea was to use some existing package from github?
@silver dragon I checked that, I don't understand why that article assumes I know what an embedded package is
no I am making a github package
ah
then just stuff the package at the root of your github branch
and that article is the right thing to get started
just go through it (it's good they finally have docs for these)
basically you need package.json at the root.. that's the bare minimum
and you also need to have your code and shaders use package specific paths
and if there's editor and runtime scripts, you have to setup assembly definitions and organize the package folder structure so that these are separated
that's about it
PM can nowadays make the custom package shell now, there should be a wizard for it
you can also edit package.json directly with the editor now and same with asmdefs
yeah I think you are right, in fact it's telling me that my json is not valid and I am trying to figure out why π
yes a wizard would be useful
it doesn't like a dependency written in this way: "dependencies": {
"com.unity.collections": "0.3.0"
},
I think I got why
got it
a wizard would definitevly be less time consuming
well, editor has these
where? and do you know how to specify a dependency that must be at least a version and not that specific version?
thank you for your help btw
OK I managed to make it work anyway. Even if a package with previous dependencies changes the current project, one can update it again with no problems
hey, I've been battling with trying to move the pivot of an entity in order to scale respectively by it. I've seen ScalePivotTranslation and ScalePivot in the API but dont know how I should use them properly
if anyone know how or have any advice I'd be thankful
@dull copper I meant more a wizard to create the json file for me
right click on the editor's file view
there should be way to create assembly definitions
for the main json you may need to make a new package using package manager's wizard
there's some + button somewhere I think
or on the dropdown menu
once you have the json file in place
you can just select it and edit it
also, this is quite #π»βunity-talk now
ok back to dots then, do you know if SkinnedMeshRender is supported? I have seen demos with skinned mesh
in the changelog there is written: New Features
Added support for vertex skinning.
but it's not clear if it means support SkinnedMeshRenderer
pretty they need to go different route for keeping the animation cheap for large entity counts
there's a new animation package but there's not much info how to you use it atm
once dots shooter project is out, we at least have practical example how these all work together
there is samples for dots animation already on github https://github.com/Unity-Technologies/Unity.Animation.Samples
So much new terminology.. keeping my distance for now π
I'm getting increasingly annoyed by the fact "performance by default" really means "performance if you use Burst"
Todays disappointment: NativeHashMap<int, int> is a lot slower than Dictionary<int, int> on Mono, and a fair bit slower on il2cpp
(on both add and access)
The #1 disappointment: Unity.Mathematics on Mono is a sad joke in terms of performance
yea
not sure what they are doing with the math library that makes it run so poor on mono
they're aware of it too
basically said it's by design because the intended use case is "just use il2cpp/burst"
il2cpp is still slower than using Mathf/UnityEngine.Quaternion/Matrix/Vector3
(I tested that quite a while ago - a few months at least - so maybe it changed, but it was still better to stick to Mathf)
new math lib was never meant to be performant without burst
Right now I have a Mono project that I want to optimize that uses a Dictionary accessed from all over the place, and I need to add a perf-critical piece of code that touches that dictionary a lot. So either change to NativeHashMap, write the new code with Burst, and make literally everything else slower... or just write Mono code.
main reason the new math lib exists is so they can hardcode some math instructions
which does make sense in the bigger picture
if you are not going to use Burst, then you may as well try to optimize your stuff differently
but since it's central part of DOTS, you really shouldn't try to avoid it
everything is designed around it
doing just synthetic tests to prove things are shit without it makes no sense
as it's never been the goal
The thing is (with math) that I now have to use different math lib on main thread vs burst code, or accept that non-bursted code will be slower than it needs to be
why do you use different math?
because Mathf. is faster π
yea but that's his point
I have code that can't use burst
why not?
Because not all code can execute in burst? lol π
well, bugs aside
C# reference types?
I'm touching managed data structures
well, that's not performance by default then :p
...?
I mean, the grand goal is to use DOTS for everything and the goal is to get perf by default when you don't mix things with the old slow things
'old slow things' = the entire rest of the .net eco-system
they don't claim you get perf by default on hybrid setup today
That's my point, "performance by default" is "performance if you use Burst"
I just think that slogan is now totally taken out of context, that's all
burst isn't even that much faster unless you're doing something which is super easy to vectorize
it's not just burst tho
yes
sure, but it's always been tedious to do by hand
you could do SIMD operations manually too
But, that's always been a PITA in .NET before .NET Core 3.x and Burst
Yes it absolutely is.
'not there yet' = been said for 2 (?) years now, so tired of hearing it lol
well, if we are lucky
Ok, I'll rephrase: I'm annoyed by the fact that major components of the "performance by default" ecosystem (namely Unity.Mathematics and Unity.Collections) are slower on their own than the old stuff
this stuff is running by 2025 smoothly
@worldly pulsar unitys collections are REALLY bad if you're not using them concurrently
like really really slow
@worldly pulsar and that's also not what it's been designed to do well, so I dunno why one would expect it to be performant there
if you take a avg sedan to the off roading, it'll do a crap job too
@dull copper everything can not be made into a parallelization dream which scales linearly across cores, and if performance by default is the argument - then that has to hold for things which are not insanely parallel also IMHO.
You can't make half the other stuff slower, and defend yourself by that the other half is faster.
I just don't get what all this has to do with their slogan
That slogan is biting them in the ass π
Unity has never claimed their systems would work in performant ways if you take core parts out of it
A native container using burst shouldn't be much if even slower than a managed container in a single thread no?
@zenith wyvern yes
they are waaaay slower
the .NET dictionary destroys the native hashmap thing by 5-6x
on a single thread ofc, since the .net dictionary can't be used in multithreading
Oh right the parallel containers are reeeeallly bad, I guess I was only thinking of NativeArrays
I wanted to be like "Hey guys look, I did this thing we thought was going to be expensive but it uses DOTS so it's not that bad, we should use DOTS more often", but I can't do that if changing a Dictionary to a NativeHashMap makes everything slower.
i dont even think there's a difference between NativeArray and regular .NET array in terms of speed, they are both the most obvious O(1) datastructure, etc.
The only advantage of NativeArray is they use native allocators. They are actually worse on Mono because Mono has special-case optimisations for built-in arrays
You can write to them in parallel though which you can't do with a managed array
yes you can
In dots that is
you can write to the .net array in parallel also if you want
using the same tricks that they use with thread index, etc.
well, you can't write to managed arrays in dots, period. concurrent or not π
it's not something unique, we do the same thing in our own task system
oh well, sure
Sorry I'm just getting jaded from hearing 'dots is the best' ... but then you go and use it and the reality is ... 'but it's not ready and half the features are broken'
less of broken , more of non existent.
I'm fine with it not being ready
@naive parrot well, maybe dots core itself (ecs/jobs/burst) is fairly finished, but everything around it is either half broken or missing.
It's always been the case with Unity that we're waiting for the next big thing. At least this time they're being open with it and letting us mess with the source
I'm not fine with it being worse than the managed stuff, or only usable in very specific ways, by design
I'm not fine with it being worse than the managed stuff, or only usable in very specific ways, by design
There's no silver bullet... It will always have restrictions... The goal is to make it super good for 80/90% of the things, and be flexible with how teams can handle the last mile.
Jobs + Burst is quite useful as it is currently though for. i have been doing stuff with it without considering ECS at all.
pure mono + jobs (with burst)
@naive parrot yeah that's my angle for it also
there are also asset store plugin leveraging jobs quite well.
I think the only complaint is the PR stuff... Lol... I think the "not yet ready" is as good as it gets... There are its pros as well (like being more "open")
A* Project already has beta version moving parts of it core to Jobs , where possible. there Motion Matching plugin that also use Jobs as base
there one other very popular terrain engine that now does lots of computation on jobs , am forgetting name of.
Exactly, I think the point is Unity has not yet decided completely on how much Bridging there will be
that old thing is still going? A* project
They're still in between... Would we always have both things?
yeah , Aron A* Is kicking fine!
@tiny ore most certainly. when you see how literally all production ready aspects of engine are non DOTS.
and there multi billion enterprise products completely done in non DOTS code , till now.
it will have to supported for long time as it is
yep.. that's the elephant in the room IMHO.
They'll have to support 2 engines forever
That is not getting streamlined, it's getting worse...:)
i don't think DOTS was ever thought out as "Replacement"
multi threaded , parallelized code will always be a challenge , even with all the heavy handling Unity has done with DOTS developement so far. casual development , hobbyist,students user of unity will continue not bothering with it
It seems like their goal at this point is to develop the gameobject side purely for editing and the dots side purely for runtime
should be more like: "as an option, for certain things where it makes sense", instead of "by default"
But If I knew marketing, I'd not be programming, right?
i guess.
yeah really. i feel like dots workflow is so different it -really- needs a new editor. sooner the better
not gonna happen
oh i know
That's pretty much decided that it will be the hack
Conversion workflow is the wya they're going
or better, the Mule
it still should happen
Sadly
Conversion workflow = fancy name for the hacky mule
I guess I'm the only one who is actually ok with the conversion workflow being the final thing π
god it's such a hack
I mean it sucks right now. But it makes sense to continue to leverage all the work they did with gameobjects and prefabs. Maybe it will eventually get to the point where it's hardly any different than what we always envisioned the "pure entity editor" would be
pretty much. for someone like me who only got gradually exposed to DOTS stuff in only past 6 months , knowing how there were other ways other current conversion workflow , is quite jarring! all those Proxies and Injections.
From how they talked about it when they first announced it I think that's their goal at least
I know how it works, i still hate it lol.
I mean it's unpolished as hell, and the EntityDebugger sucks (that's the part I think most of the criticism of conversion comes from, we can't manipulate entities at runtime)
worst part , how some of the fundamental parts of engine are left unaddressed for so long now! RIP Navmesh!
till they are revamped for DOTS.
But the general idea, including piggybacking on MonoBehaviours I actually like
i thought i remembered them saying the idea was to replace things.. eventually.. with dots implemetations of the same? i know it'd be a long long way. but that seems it was at the beginning of ecs and things have changed
can you put breakpoints into code thats inside the new foreach lambda stuff btw?
i dont think so
The Navmesh question is interesting @naive parrot
@naive parrot some parts? the mecanim/playables thing is abandoned also apparently, etc.
Navmesh Components , the only sensible way to work with Navmeshes is not even part of core engine
I haven't seen a single post about it... Is there any (real question)?
its an abandoned repo on github
@worldly pulsar well the point is it shouldn't be required. its all just overhead.. for what? so it shows up in editor? it just just be an editor made for ecs, then there's no conversion needed
also rip , GI ( Enligthen )
oh yeah hows the new light baker coming along?
@winter veldt I have a lot of cases where data that's convenient to edit != data that's efficient/convenient to execute with. I had my own half-assed converters for a long way, but they usually worked in Awake() or required pressing a button in the editor to refresh the "baked" stuff
@worldly pulsar not that this is ultimately what we'd like but in the case of porting code / working with existing I think a pretty good pattern is to just copy the data before & after you've manipulated it. i.e. leave it as a Dictionary but for the heavy lifting, copy to a NMHM, burst job, then copy back. Depending on the size of your data, how much processing you're doing etc obviously it might not be worth it but just thought I'd mention it.
HOW is that a good pattern lol?
yes but that all sounds like you are talking about getting it to work with hybrid. if they just made a pure ecs editor, you wouldn't need to convert.
Oh I really don't want to copy that thing
That's the opposite of a good pattern lol
yeah
copying is fast.. not sure why it's a bad pattern for optimising existing code?
@winter veldt no, I mean I had that long before DOTS was a thing
certainly Unity/Joachim have suggested this is how they see it being used
@amber flicker copying say a million elements from a dict into a NMHM is not fast lol
NMHM is really really slow
like I said.. it depends
That's not how the NMHM is intended to be used though right? The boids demo uses NMHM and that's pretty impressive to be running in the editor
well yeah. there will always be a stretch of leveraging old code. but thats for people who want to use it. and will always be a stop-gap. that'd be the whole reasoning behind keeping gameobjects in the first place.. utilize all the work put into them. doesn't mean you aren't hamstringing those willing to try to fully implement things
@trail burrow seems to hit the breakpoints in new foreach as long as you use WithoutBurst()
doesn't seem like there is actually useful info in there though 
@hollow sorrel then you have to add/remove that, in the code? every time you want to debug it?
can't even read the parameters that are passed in
π¦
why do they have to do all this magic shit
all the other 'magic' shit they've added they've regretted in the past
Unet IL weaver, DOTS injection, all the null/false conversion operators, etc.
Just make a clean and obvious API
yea i actually prefer having to create a job struct than this ForEach magic that also increases compile times
Yes
btw does anyone know how the execution works for several worlds at the same time? are they executed one after the other?
or concurrently?
yeah you need to be able to learn the magic, not just believe in it without conviction.
The Foreach thing is to save you from the boilerplate, of course there's going to be a tradeoff for codegen
like if i have worlds A, B and C
I want to see where they go with this. Codegen lets them make really flexible apis, and things like the debugging problem are solvable (assuming they have a way to get debug symbols between the codegen and burst)
and they are all 100% independent
if i schedule jobs from them, can they execute at the same time? or is it somehow sequential anyway?
been trying to figure this out
What does it look like on the profiler?
I imagine they all just pull from a pool of threads right?
@worldly pulsar good question
or good answer, it it turns out to show what happens...:)
now if the project doesnt take a minute to start with the netcode package in it
god im so tired of this lol
Oh, you'll try now? Post the results here @trail burrow
update sequentially
Speaking of posting the results @trail burrow have you tried the "Copy subscene SceneReference to another world" method of instantiating subscenes we talked about yesterday?
That's a lot of fixed updates per frame O_o
What are the specs in terms of load here @trail burrow ?
no no
this is with safety checks off but in editor I guess?
ok
in editor though
Give it a proper chance...:) Add a stopwatch on a proper build...
speaking of safety checks anyone else find it annoying how every time you start the editor it enables jobsdebugger making things like physics take up twice as much ms
Or can't we measure the actual time?
so close to being annoyed enough to make an editor script that keeps it disabled
this is the netcode sample project
from github
non modified at all
bone stock
takes 30 sec to get into, runs like an old dog
heres my jobs/burst settings
if that matters
turn on synchronous compilation?
weird I saw on the forums they were aware having it off made it v slow for quite a while
also leak detection off I guess?
yes
23ms
this is the best frame i could find
every safety/debugging/etc option is disabled
got me curious.. downloading now
but considering this is the thread utilization the netcode manages
it's not weird maybe
lol
yea i'm downloading now too
is this just opening the asteroids scene and hitting play?
yes
Β―_(γ)_/Β―
maybe they have an issue with amd/many cores
yeah i have a weird CPU
am on i7 8700k
yea dunno if it's actually the cause just speculating
https://github.com/Unity-Technologies/multiplayer that's the sample right?
yes
hmm I don't see anything in the game view other than a red rectangle? that expected?
cool - where's the switch to client world?
entity debugger
ta - btw does your perf change if you close the entity debugger?
no
This is what I see.. (old i5)
about same as me then
playerloop there is 4ms tho
~30fps ?
editorloop seems to be taking the most
yea the vast majority is 'others'
editorloop is the green stuff i think
Need to test this on my machine
but yea on fholm's it's playerloop taking a lot of time so idk
Yea for me it's jumping from 2ms to 6ms per frame, and that's in editor, with safety checks+leak detection on
on a Ryzen 5 so not an AMD thing
I mean... ~4ms on mine isn't exactly great either..
for this no it's not
this is like <0.5ms amount of work
"performance" by default.
well.. it's alpha.. will check it out in a few weeks
yeah i know... just so tired of all unfinished stuff, sorry lol
I think a prototype of something that aims to show performance should, ah, perform... Fine to have a few bugs
But isn't the whole point to be efficient?
No, right now they're getting the groundwork in place and letting people see the API
They've been in the forums specifically saying performance is not good and they're working on it
Ok, fair then
yea.. plus.. I guess one feature of all this work is that it's much more optimisable than traditional oop
like the hybrid renderer.. I think a few days spent by a team will see a lot of perf improvement.. but it's not what they're focused on atm
I really wish they would focus more on the renderer, specifically for LWRP
No one wants to use HDRP for testing this stuff
I have no idea why, but it just works for me π
f1 here also
I'm on b12, this is in Development Build
@trail burrow what does the profiler say is taking the most time for that?
ah I was looking in editor
@safe lintel profiler wont connect to the build for some reason
@safe lintel here's the in-editor profiling
In editor, with all the safety stuff still on I saw ~3x the times
so may be b12 vs f1 ?
possibly
timboc said 4ms on f1
