#archived-dots

1 messages ยท Page 69 of 1

dull copper
#

there is physx.net but it's kinda mess, would love official plugin version

lime dome
#

makes me feel like that guy never came back to the discord to see my bug report there

light sage
#

wrong image. blender plus HDRP, plus ECS is a headache, but I like how the tutorial ship is shaping up

urban rivet
#

it's fine we talk about ecs in physics and here we talk about HDRP :)

foggy chasm
#

So - I, like a lot of Unity developers haven't really had a lot of hands-on experience working on a data oriented code base. But I was interested in folks perceptions for an average game that consumes ECS, how much of a code base do you think would be fully entity/systemified. I've got a few folks on my team with AAA experience and have worked on these sort of data oriented code base and swagged it as 20% max (AI, physics, pathfinding) and the rest is more traditional "procedural" code

#

Basically as we start to have folks kick off projects on 2019+ - understanding "how much" and "when" to employ ECS seems like some good general advice to have at hand

urban rivet
#

I would suggest dabbling with samples, I mean it's going to help you if you like it or not anyway (since Unity's moving it's own stuff to DOTS)

but the samples (if they're visible) should help, did you try one?

foggy chasm
#

Naw - not yet. I'm on a project mid production on 2017.x - you're right though I should probably poke at it directly to speak a little less ignorantly

lime dome
#

why I don't say much here. While I have a general understanding of ECS concepts, I have no idea how Unity has implemented it and for now don't want to break my brain on it since I doubt i''m going to use it any time soon.

foggy chasm
#

haha

urban rivet
#

the layman's explanation is: you make a little class of the smallest and only data you need, for example just a position (the component), and then you have a system (the code to move it)

that's all. It will be automatically performance by default and fully threaded.

#

its a lot easier but there's a lot more files and a total change in thinking (no inheritence) so thats the difficult part for people unwilling to change

foggy chasm
#

yup - that part I get my head around. It's just for your "average" shipped game code base, how much of your code is written in this style vs run-of-the-mill procedural

#

like doing the behavior for a settings dialog in your game is (I think) almost positively not going to be written in a data oriented style?

urban rivet
#

you would use it for a thousand attack ships, or an army or an rts, or really, anywhere there's far too many of them for poor ol' mono to handle.

and when you get close to those in the army, there's nothing stopping you making the closest ones be monobehaviours

foggy chasm
#

Seems most suited for anywhere you have N mostly independent operations

urban rivet
#

given that you can have a thousand attack ships for basically the cost of a single monobehaviour, there's a good reason to look into it for anything like what you suggest

foggy chasm
#

yeah

#

I wonder if it's better suited as an optimization that you retrofit later vs grounds up

#

or if that refactor (and I realize this is all hand wavey) is more expensive

urban rivet
#

its recommended as an optimisation atm because it's not really finished and there are not yet enough unity equivalents, so they have hybrid for that

#

it's not actually possible to make a full ECS only game right now anyway

foggy chasm
#

totally

urban rivet
#

the intention is you use it where you are slow

foggy chasm
#

but, when you look forward to when ECS is a completed system - it's still only appropriate for a certain class of problems - and most games (short of AAA that know what they're doing) can probably think of it as an optimization

#

anyways - appreciate the thoughts. I suspect there's going to be a fair number of "how do u ECS" people rolling into here as the system starts to get stable (and increasingly hyped) and the answer is "you probably shouldn't"

urban rivet
#

Yeah it's fine, I was shipping mobile games based off monobehaviour a decade ago so it's not one size fits all

foggy chasm
#

๐Ÿ‘

lime dome
#

yes well the way everyone talks it sounds like the new hammer to hit every nail with

foggy chasm
#

^^

lime dome
#

even unity making a 100% ECS demo seems to indicate that

#

"you should make your game 100% ECS"

foggy chasm
#

It leads otherwise intelligent and handsome engineers like myself to ask the dumb questions

urban rivet
#

lol

lime dome
#

I too know your pain, as a fellow handsome and intelligent engineer. ;p

safe lintel
#

theres a good gdc talk on the architecture of overwatch using ecs, theres no mention of specific % but i just get the feeling its more than 20% of their codebase(but thats just my totally unscientific and luddite impression)

urban rivet
#

yeah lets use ECS there too.

#

let's not forget ecs is not just a thing for perf but also for saving money

#

for example with ECS you have a closed enough system that the mathematics library and burst can support with determinism, resulting in substantially less bandwidth spent on network costs

#

though you can do that without ecs

safe lintel
#

I just like it that its way more modular, i can screw up systems galore and it only sorta breaks my game unlike my old monobehaviour chain of dependencies with the whole thing imploding

slow wasp
#

ECS is great for anything that runs in a loop, so it's great for gameplay. It's harder to use for one-off events, like interacting with UI. For gameplay though, it really simplifies the code architecture, and I love it. I think going forward the default choice should be to use ECS, so instead of asking should I use ECS for this, it should be why shouldn't I; and if you have a good reason, don't use it.

analog tangle
#

Btw -- is Unity going to maintain a list of canonical components for eventual Asset Store creations to target? If so, is there a list? (like Heading, Position, etc.)

#

Or are we supposed to make our own of everything?

lime dome
#

wait, unity doesn't even give you a way to find an object's position in ECS?

#

O.o

analog tangle
#

I'm probably just confused lol.

tawdry tree
#

There is position and rotation components of some sorts, but... I don't think they're listed anywhere. They're used by the render system(s), so if you can find the source for that you might be able to fish it out.
A proper list of 'this is included in the package' would be nice, tho

lime dome
#

yeah i'd think the basics should be there, position, rotation, scale, material

analog tangle
#

Was hoping for a list to kinda know what's already there... get some ideas and not re-invent the wheel if I can fit into something existing.

#

Especially if that means that my work can be compatible with future stuff.

lime dome
#

yeah, i'm sure documentation will be coming

solar ridge
#

There will likely be a "list" in the future, but there shouldn't be one now. Main reason for NOT listing them: they have changed the transform system at least 4 times. The first iteration had a transform value and a local transform value (Ie position, localPosition) now we are on translation and localToWorld utilizations for position

#

I'd love a list, but it needs to be less volatile first

#

Easiest thing to do now: Open up the package, and look through the Tests folders to just get an idea

knotty radish
#

Need some hype ? Take this cool package

final fox
#

@knotty radish OM.... Thank you !

#

Just found two packages I waited soooo badly ^^

knotty radish
#

It seems like it's not a wrapper around PhysX

visual dock
#

I think they use Havok for this.

final fox
#

public struct PhysicsCollider : IComponentData โค

visual dock
#

Well, now we know what to expect from the keynote in 90 Minutes ๐Ÿ˜ƒ

final fox
#

I'll be programming ๐Ÿ˜›

visual dock
#

Unity Physics is a deterministic rigid body dynamics system and spatial query system written from the ground up using the Unity data oriented tech stack. Unity Physics originates from a close collaboration between Unity and the Havok Physics team at Microsoft.

solar spire
#

C# stateless physics library

#

sounds pretty cool

toxic walrus
#

Please announce deterministic lockstep sample bongo

urban rivet
#

subscene action

dull copper
#

nice ๐Ÿ˜ƒ

#

they got brief docs on the package itself

#
======

Unity Physics is a deterministic rigid body dynamics system and spatial query system written from the ground up using the Unity data oriented tech stack. Unity Physics originates from a close collaboration between Unity and the Havok Physics team at Microsoft.  ```
solar spire
#

Yeah, Archy posted it above

dull copper
#

The most up to date use of Unity Physics is the Samples for it in the main DOTs sample repository and they cover a wide range of use cases not yet covered in these documents, such as character controllers, ray cast driven cars, and examples of all the joints.

#

so.. repo?

solar spire
#

It'll be interesting to see what you think of it when you get to have a play ๐Ÿ˜›

dull copper
#

yeah me too ๐Ÿ˜„

knotty radish
#

Watching the GDC direct at Unity's office with other people of the game industry. Lot of hype /o/

dull copper
#

I checked the samples repo but they haven't updated it yet for the physics package ๐Ÿ˜ƒ

soft nova
#

All I want is native MateiralProperty mesh drawing

elder wharf
#

I think it will be directly on dots (not ecs sample one) repository which is rn private

dull copper
#

"in the main DOTs sample repository"

#

that sounds like the samples we got already

#

unless they do another

untold night
#

oh there's documentation

dull copper
#

yeah, I was surprised they did docs

untold night
#

here's the Transform docs:

#

this seems to be the cannonical set of Transform components for the time being

elder wharf
#

ye, I found the address to dots repository (from entity package comments) but it's still private...

dull copper
untold night
#

yessssss, thanks @dull copper

safe lintel
dull copper
#

heh

solar spire
#

hahahaha

untold night
#

there's a lot of yellow in these samples

dull copper
#

I'm still solving the errors ๐Ÿ˜„

#

ah, restart helped

#

DOTS now on keynote

tawdry lotus
#

wiiii

dull copper
#

download link at the bottom ๐Ÿ˜ƒ

lilac ermine
#

"trivial to implement havok physics"

knotty radish
#

Not sure what's the difference between Havok and Unity new physics

dull copper
#

seems like the physics package is more limited, DOTS friendly thing

#

that you can use on netcode etc as it's stateless and utilizing Burst (so we'll get determinism once it's implemented)

knotty radish
#

Yeah not very clear on that point

#

Still amazing

manic aurora
#

hmm there's no real way to simulate having a dynamic buffer full of interfaces, is there? i have a situation in-job where i have a lot of methods with the same signature that do almost-but-not-quite-the-same math as each other. i need to re-run some of these methods several times with tweaked parameters based on their original results, and i'd like to be able to cache the large amount of reusable math done in each one. the types of the reusable math are common to all methods. this means each cache/buffer element must be able to descibe 1) the cached values and 2) which specific method implementation was used. seeing as i cannot have an interface as an IBufferElement member, i find myself reaching for undesirable constructs like the following:

public struct ThingSolver : IBufferElementData {
    public float someReusableMathResult;
    public ThingSolverKind solveType;

    bool Solve() {
        switch (solveType) {
            // execute some specific Solve() implementation based on solveType
        }
    }
}

any ideas on a way around adding this crapton of branching to my jobs? i assume there isn't a practical way to get a map of <ThingSolverKind, Func<bool>> in job. i could give up caching the math if i had to, but i still need to store a collection of ThingSolver to indicate which ones need rerun. the alternative of course being bool rerunSolver1; bool rerunSolver2;...

untold night
#

You could write separate jobs for each thing type and use a static class function library

it's perfectly fine to call code outside of the job structure as long is it's functional (no side effects)

manic aurora
#

well the results of the various methods depend on one another, useless to do them separately

untold night
#

point being, you could pull the critical fuctions out of the job to make it easier to compose the logic you need per solver type

manic aurora
#

oh that's kind of interesting, i didn't realize i could, say, maintain a static dictionary in a job-external static class, call into a function of that class that reads the dictionary, and burst wouldn't complain

solar spire
#

I thought burst only liked its own collection types and it would hate that

manic aurora
#

guessing the point is that in the situation i described the dictionary itself isn't burst compiled

#

can you even burst compile something that isn't a job? this job is where all my big math is, so moving the math out if i can't burst compile it is also useless

solar spire
#

I also thought jobs only liked their own collection types - sorry

#

I haven't explored all this enough ๐Ÿ˜›

manic aurora
#

frankly i am not clear on why that even works either, i just assume the job can't "see" the dictionary because it's private to the external static class, so it doesn't care

dull copper
#

so wait

#

Unity acquired Graphine?

#

I had to google after watching that keynote part again

solar spire
#

yes that's what they said in the keynote

dull copper
#

yes

#

that's great

#

maybe we'll now get first class integration ๐Ÿ˜„

solar spire
#

hopefully ๐Ÿ˜ƒ

dull copper
#

so far they've not supported SRPs, their plugins have often dragged months behind Unity releases and they haven't supported height map streaming for vertex shaders

#

so, if they really get it integrated, it will be awesome

untold night
manic aurora
#

i saw that, but it reads like it's only for arrays?

dull copper
knotty radish
#

It will be on YT soon enough I guess

dull copper
#

yeah, few weeks probably

#

I'm hoping to we could get at least slides for DOTS roadmap + regular unity roadmap sessions

#

as those are the most interesting bits at this point

untold night
#

@manic aurora - yeah, you could bake the lookup if the key can be converted to a unique integer, but for most datasets that aren't massive, a for loop equality lookup is pretty fast

solar ridge
#

So quick question: Anyone who has used the new physics package, are you happening have a problem with having dynamic physic bodies settle?

urban rivet
#

the thing about graphene

#

they have patents

#

i think

untold night
#

that would make sense

solar ridge
sharp nacelle
#

stable stacking is an old problem of physics engines (remember tables exploding, once you touched an apple in oblivion?). I'm sure they are still very much working on this, though.

full stirrup
#

ECS only being done in a short hour window (45 minutes) tomorrow?

solar ridge
#

30 mins on wednesday it seems

gusty comet
#

So Nvidia is working on a package replacing Unity's PhysX with PhysX 4, Unity is also working on their own PhysX upgrade separately, there's also Unity Physics and then there'll be Havok support.
That's a hell of a split personality syndrom ๐Ÿค”

lilac ermine
#

@gusty comet in a dots / ecs world this kind of thing feels very natural and i hope we see more of it ๐Ÿ˜ƒ

gusty comet
#

@lilac ermine Ehh, you mean spreading resources around unstead of focusing on one thing?

solar spire
#

Unity won't work on the Havok support in the long term and PhysX is a dinosaur, so this is very sensible - what would you want instead? A pure focus on PhysX and a poor interface with ECS?

gusty comet
#

@solar spire if there won't be long term Havok support, does that mean they'll add Havok just to deprecate it later? ๐Ÿค”

solar spire
#

Havok will support it

#

They're working together to get the details down but in the long run Havok does all the work on their end and they request a few features in the protocol layer that likely benefit Unity.Physics anyway

gusty comet
#

I see.

solar ridge
#

There is a dropdown for simulation type in one of thephysic components in the examples. You can just switch to Havok so that might be interesting to test later when it is available

solar spire
#

If they provide a test that doesn't require you to license!

lilac ermine
#

They're working together to get the details down but in the long run Havok does all the work on their end and they request a few features in the protocol layer that likely benefit Unity.Physics anyway this ๐Ÿ˜ƒ

#

so you'll be able to swap implementations "trivially"

#

i lol-ed pretty hard at that part

dull copper
#

it's important to note that full Havok is most likely to cost you a lot of extra $$$

#

so it's not really direct replacement of anything in the big picture here

#

it's like external FMOD or WWise integration is to Unity now, additional extension (despite the built-in Unity audio runs on FMOD)

#

and you license it separately

#

I'm mainly wondering what Unity is doing with PhysX now as it can't be coincidence that nvidia just came up with their own PhysX plugin for Unity yesterday

safe lintel
#

well microsoft own havok and they touted it as part of their gamestack platform, im assuming a license agreement but i doubt a hefty cost

dull copper
#

considering they've said there will be cost, it's going to cost something

#

and if they would bundle it with Unity Pro, that would be a huge mistake

#

as it would drive unity back to the old model that made people leave unity in the past

#

kinda sucks that we have to wait to the summer to find out

knotty radish
#

I don't really agree, Havok is a third party, if it's bundled with Unity Pro that would makes sense just like Unity Services is for Unity Pro only. It's not an essential part of the engine, it's something someone else did and, while there may not be a free alternative, it's still outside of the basic features of Unity

dull copper
#

that's a dangerous path

#

Unity 4 had essentials on the free side

#

and fancy stuff on pro side

#

this didn't really work well for Unity

#

if anything, if it's not available to all Unity tiers, I hope it's a thing they license separately

#

and I don't really agree on it not being essential part if that's the only full blown out DOTS physics offering Unity will have

#

where Unity Physics package goes will determine how essential it'll be

#

of course I'd hope DOTS physics could cover all use cases

#

Unity is already playing catching up on providing the source code access

#

competition gives full engine and editor sources

#

and then moving more closed source stuff behind paywall?

#

I dunno, that's just not great option

knotty radish
#

From the blog we can see that it will not have caching while Havok will and that would be the main difference

mint iron
#

after looking through the new code and demos for Unity Physics it seems that all the fundamentals all there, and then some, and i'm sure they'll build upon it. Are there many things that aren't there yet, which the legacy system can do and should be supported? It seems to me the havok option will be for very advanced use-cases or extreme performance situations, which seems reasonable for the 0.01% that will need it.

urban rivet
#

what is more performant, C# physics in Unity or Physx right now?

dull copper
#

in that case, you shouldn't bundle a thing that 0.01% benefits of into Unity Pro license

#

it should be a separate thing

#

also the performance thing is not really something you should be worried about today ๐Ÿ˜„

#

it's first public preview

#

it's buggy, it gets more stable after they iterate on it

urban rivet
#

if havok is bundled with pro or I get a free license then all is well, and I become a havok fanboy, promoting it endlessly. if not then booo sucks

#

:D

dull copper
#

I don't really mind that they give option to use full Havok, having options is great

#

just afraid they ruin the tiering system again when they just got it fixed

#

they haven't said they do that tho

#

and I'm fairly confident that it'll be an additional offer

mint iron
#

yeah i'm sure i've heard Unity in the past talking about how important it was to them to get the structure right so that all developers would have the same tools out of the gate, it would be surprising to move away from that ideal.

#

but on the other hand they do offer lots of services at additional costs.

dull copper
#

services are different tho

#

this is key element in the game engine

#

but that being said, I really want DOTS thing to cover most use cases

#

it's kinda weird to see that they even offer c++ Havok

#

must have been some deal they made with the DOTS package developement

#

as Havok team was involved

mint iron
#

yeah, to me it sounds like havok probably heavily collaborated on the development, so Unity gets a quality lightweight engine quickly, and havok gets some marketing and an access point to the Unity developer marketplace.

dull copper
#

yeah, that's how it sounds like

#

and that's fine

#

now only need to wait for nvidia to step up and implement the DOTS api for their physx 4 plugin ๐Ÿ˜„

mint iron
#

i really appreciate that its open source, and i've heard from many unreal engine folks that say its been one of the biggest limiting factors with Unity, that they can't see or extend all the parts that have been closed. So its a huge step in the right direction in that regard.

dull copper
#

yes, as guy who's heavily modified UE4, I fully agree ๐Ÿ˜„

#

or even CE

urban rivet
#

well unity partnerships have add value and ralph (the guy behind partnerships) is a very smart guy just not as big as lucas is

dull copper
#

I upgraded CE's CryPhysX from 3.3 to 3.4 in few days

#

I implemented PhysX contact modifications in ~week for UE4

#

I've asked for contact modifications for Unity for years now I think, it's not there

#

but at least the new Unity Physics package has something like it now

#

not having the code access limits these things a lot

#

when you get the sources, you just can do it yourself

#

and not wait for years and pray if something happens or not

urban rivet
#

I don't appreciate unsuppoted open source

#

because ultimately I do use unity because it's saving me time, so there is that.

#

so i like open source that's bankrolled

dull copper
#

yeah, I mean source code availability now for a commercial tool

#

not some side project from one person ๐Ÿ˜ƒ

#

having the sources available helps to minimize the risks

#

if you don't have it and get a game breaking bug on the engine side, you can't do much

#

just wait and hope Unity will fix it asap

#

but we have a lot of examples from commercial projects that went sideways because those fixes took so much time

safe lintel
#

hmm is there some tweaking you have to do for some of the physics demos? seems like the character controller and vehicle demos play way too fast

dull copper
#

it's a bug

foggy chasm
#

strong early showing

dull copper
#

they simulate physics at fixed delta time

#

but run them once per update

#

it probably happened because entities package recently moved temporarily simulation group from fixedupdate to update

#

but they forgot to change it on the physics package with this tight schedule

#

I'd guess the easiest fix is to just modify the physics package to use regular deltatime for the time being

#

it will not do fixed timesteps for physics but at least physics would simulate at right speed for now

safe lintel
#

oh right

#

so many things to unpack and digest

full stirrup
#

Is the megacity out now or after gdc?

safe lintel
#

at the bottom is a download link

full stirrup
#

7.1gb nice

lime dome
#

@urban rivet Graphine may have patents, but now Unity owns those patents... so they can do whatever they want with them ๐Ÿ˜›

#

@solar spire if PhysX is a dinosaur, then Havok is the primordial ooze all life came from, because it's way, way older ๐Ÿ˜›

tawdry tree
#

Dem Havok barrel stress tests though. 1k, 2k, 15k...
If we can do that kinda physics in unity...

dull copper
#

@lime dome yeah, he was really talking about Amplify's end now

#

but yeah, Unity is safe

full stirrup
#

Would whatever dissecting the megacity give, still be a standard tech?
Like they started it last year, and ECS has had quite a few changes since then; and hopefully more... although the 30 minute keynote tomorrow is a little disappointing

dull copper
#

yes

#

well, they have their custom tech in it

#

but it runs on stock packages

#

there's zero modified packages included

#

it's probably the first tech demo Unity has released that didn't do that since the package system came here

lime dome
#

I don't see Amplify in the conversation but whatever ๐Ÿ˜›

dull copper
#

@lime dome ah, it was on another channel

#

though it was here since you replied here

#
[5:31 PM] hippocoder: (don't quote me ;) )```
#

totally respecting his request here ๐Ÿ˜„

urban rivet
#

@lime dome that is why they bought graphine, is my point.

#

otherwise you cannot have best in class streaming

#

but anyway that could've been unrelated, just shrug! but looks like I will have to port to ECS to take advantage of perf

lime dome
#

yeah I saw you mentioning moving your char controller to ECS

#

honestly I think that's seeing everything as a nail

#

but I could be wrong

#

(don't quote me ๐Ÿ˜› )

urban rivet
#

well I'm usually good at nailing it

lime dome
#

owe, touche

urban rivet
#

I think it's likely for simpler scenarios that the hpc# physics will be faster, a lot of my physics time is spent on OnCollisionStay and it's friends

#

I dont have a choice really because I need the reliable per frame contact info

lime dome
#

because of VR?

urban rivet
#

because my game relies on reliable contact information to make a rigidbody character, a vehicle, and several other things function well, including audio contact for dragging, rolling and more across a surface, including pushing objects with different masses in playable way without impeding character movement without resorting to kinematics, and so on (there's a more reasons but it will bore you)

#

in short, I really have good reasons for it. I used to approximate and avoid, and have done years of research avoiding stay, but stay has the best data.

#

I just can't get to it in physx due to closed box. Also the new physx are in dots so also a closed box

#

i might as well become schrodinger's cat, and you never know if I'm alive or not because of how long it takes for my reply here.

lime dome
#

I can see you typing ;p

urban rivet
#

:P

#

but is it now or am I typing after?

lime dome
#

there's always observable phenomenon ;p

safe lintel
#

wait im unclear on the unity dots physics

lime dome
#

but regular physics works well enough for hundreds of items moving around as it is

safe lintel
#

they mention its a collab between havok and unity so its a totally new thing not physx right?

urban rivet
#

its new

lime dome
#

so i'm unconvinced needing 1 character and 1 car justifies jumping to ECS

foggy chasm
#

probably spiked from an existing havok code base

urban rivet
#

yes thats the use case but

#

do you want me to get into it?

#

I'll have a ton of characters and thousands of rigidbodies

#

which I do in physx right now

#

I'm just telling you what the requirements are on a technical level for one of those characters

lime dome
#

yes tell me of these thousands of rigidbodies, you're burying the lead ๐Ÿ˜›

urban rivet
#

lol

#

but yes ... I would need to port all of my code in my game (I think most of it) to dots

#

and if i want networking without hassle, I should do it

lime dome
#

if multiplayer, probably

urban rivet
#

it's not atm

#

but i plan it for the period when I port it

#

so i release single player -> take some sales -> invest in mp same time as ports

#

if the pain is less sooner, it's better than a bigger pain later

#

but the timing is bad

lime dome
#

yeah things are in big flux atm

safe lintel
#

"Our goal which may or may not change is to be out of preview around Q3. " thats unusually fast

#

(regarding physics)

urban rivet
#

with what featues tho?

#

anyone can be out of preview with a few boxes

#

if its feature equivalent to physx, thats insane

dull copper
#

I'm expecting the featureset to remain what it is

#

it's covering all the basics already

urban rivet
#

cloth included?

dull copper
#

it needs polish

#

well, not cloth

#

but cloth is special case in physics anyway

lime dome
#

cloth is a separate thing, even in PhysX

#

but making your own cloth is easy

urban rivet
#

it will likely have way less control really

lime dome
#

verlet integration

dull copper
#

they are doing nvcloth in 2019.2

urban rivet
#

for physx tho

dull copper
#

but it sounds like it's going to the old side of the engine, yeah

#

mainly to replace the PxCloth implementation

lime dome
#

just make your own cloth in ECS using the new ESC physics

dull copper
#

I wouldn't be surprised if the cloth change was transparent to users

lime dome
#

if it's really faster, should work fine

dull copper
#

cloth intersections are the tricky parts

urban rivet
#

high performance cloth is really hard though and would require extensive experience in dots to achieve

dull copper
#

the actual integration is trivial

lime dome
#

yeah that's where the no-scene physics comes in ๐Ÿ˜ƒ

#

can use it to calculate the intersection collisions

dull copper
#

but most engine users don't want to implement their own cloth solvers

#

they want something out of the box

lime dome
#

just need one smart guy to do it and put it on the store ๐Ÿ˜›

#

gets ideas

dull copper
#

yeah and then pray it stays up-to-date

#

or doesn't get deprecated

lime dome
#

๐Ÿ˜›

dull copper
#

like half of the things I've bought from asset store

urban rivet
#

currently one can paint on the same skinned mesh and have instant flappy bits, it's really great and powerful and does not need intersection or self collision because the skinned mesh by large avoids that taking place...

lime dome
#

I've bought quite a few things, and I've only had maybe 2 items depreciate

urban rivet
#

by having verlet, you would have "cloth on it's own" which I find utterly useless tbh

dull copper
#

last thing I bought that got deprecated was Granite :p

lime dome
#

so from my experience it's more like a 5% attrition rate

#

this google announcement is making me vomit, I can't argue while i'm queasy

#

lol

dull copper
#

the more expensive and specific the asset, the higher risk it has to get dropped

urban rivet
#

the picture is coming clearer that unity's HPC# physics use the same math as havok, but the implementation is up to unity staff, and that they're taking the hpc# physics seriously

dull copper
#

art etc packs tend to stay there forever but I don't really buy that stuff

urban rivet
#

but it will not work with gameobjects, so....

lime dome
#

ECS physics is the future

urban rivet
#

FOOTURE

#

IS NOW

lime dome
#

so I wouldn't call it specific or risky

#

it would be like the next Gaia, or FinalIK

urban rivet
#

I remain open to being impressed and persuaded that Unity isn't going to be making a HLAPI depreciated pigs ear of it

#

And Gaia is redundant and FinalIK is redundant

#

well I'll be patient

#

so they will do cloth eventually but cloth is not joints

#

perhaps if I read it right

#

so...

#

it's time for me to port to ECS isnt it?

#

struggles and cries

#

@lime dome make it hurt less

dull copper
#

just try the samples, play around with it

#

then make prototype with it

#

see if it even works for you

#

also, fix the bugs from current version ๐Ÿ˜„

safe lintel
#

no jump right into a 100% conversion!

#

sink or swim!

#

๐Ÿฆˆ

urban rivet
#

well given the physics and networking only actually have improved performance if you put your gameplay in the same memory location with no barrier, there's not much of a choice, you will have to port most of yout game unless it's purely cosmetic

#

hmmm

dull copper
full stirrup
#

Gonna read through it when I get home

lime dome
#

@urban rivet I really don't believe that is true

manic aurora
#

they would release a physics preview when im halfway through writing this ecs SAT solver ~_~

lime dome
#

networking only need send your position and rotation, and other status of your character

#

it's not like it's a ton of data

#

if ECS cant handle moving a few kilobytes between ECS land and Mono land, it's DOA before it starts

urban rivet
#

I do - I think for gameplay you either go through the physx bottleneck (as yant has described) or you go through the ecs bottleneck (hybrid). This means that since you're pissing away performance by converting data back and forth from monobehaviour and dots worlds, you might as well either:

  • remain with physx
  • bite the bullet and go for dots physics
#

for the latter it makes sense you fail to reap the benefits without your code in ecs too

lime dome
#

well if push comes to shove i'll stay with non-ECS because it's proven and works

urban rivet
#

same

#

it's great and it works. but then I think... . I'm missing out

lime dome
#

FOMO :p

#

but I still have to even get into ECS

#

I haven't worked with it so I can't really say what it can't or can do

urban rivet
#

if you are old school chances are you will rapidly fall in love OR hate it

lime dome
#

well I've worked with ECS before

#

just on a different platform

#

and I found it very elegant once I got into it

#

but it is a whole other way of thinking than traditional coding structures

urban rivet
#

I guess my hesitation with ECS actually was the lack of physics and networking without going through hybrid

lime dome
#

yeah I can get that hesitation

urban rivet
#

I just cannot stand doing something half arsed. It's like putting the tip in and not going all the way (of a drill bit of course, you know)

lime dome
#

i'm really waiting for ECS to mature before I dive into it because I hate learning one thing then having to change midstream

urban rivet
#

amen to that

lime dome
#

not that it's ever 100% avoidable

#

but right now things are clearly in big flux

urban rivet
#

2019.3 seems to be when everyone thinks either star wars will un-suck or unity will be ready for dots in general

dull copper
#

wonder when they get AI for DOTS

urban rivet
#

problem for me is, I'm at the crossroads where if I go dots now I can still be on track for a demo in august....

#

and the thought of having a ton of ai running around, a little army, is fantastic..

dull copper
#

man, I'd love to see the GDC sessions on dots now

urban rivet
#

:(

dull copper
#

especially the one we are missing right now ๐Ÿ˜„

urban rivet
#

:(

#

unity invited me to come but i can't afford jack

dull copper
#

but it's a relevant question

urban rivet
#

why if it isn't another arowx thread.

lime dome
#

big 7?

#

what is that

urban rivet
#

it's arowx, so he will clickbait you into being intrigued

#

(and succeed)

lime dome
#

his graph doesn't even make sense

#

what does red/green mean

#

there's no legend

urban rivet
#

I'm just glad he's not babbling about memristors or such

lime dome
#

also how can hybrid be green

#

and pure is orange lol

#

if hybrid is GOOD

#

then pure should be GOODER

urban rivet
#

I think he means what can be used for best perf

#

maybe

lime dome
#

pure will always be better than hybrid

urban rivet
#

actually his graph is defeating me

#

right so the colour is the state and the column is the api

lime dome
#

also how is he citing versions that don't even exist yet

#

2018.4 isn't a thing yet

mint iron
#

yeah this visual confuses me greatly

urban rivet
#

and input being green in 19.2 is going to be news to @midnight sonnet

#

it's as if arowx achieved determinism and knows when things will be stable and finished

dull copper
#

I don't think that's his graph

#

but something Unity showed earlier

urban rivet
#

is it unity's?

#

bad unity

#

makes a cup of tea

lime dome
#

well then he took credit for it

#

"this is what I want to see from unity" lol

#

makes it sound like he made it

urban rivet
#

he thinks ecs is a separate thing, ecs is just a descriptive name for how the program is put together

safe lintel
#

that unity logo ๐Ÿ˜„

dull copper
#

oh nevermind

#

it's his ๐Ÿ˜„

urban rivet
#

ofc illegal to do it but good enough

dull copper
#

forget I even mentioned

#

well that makes more sense now

full stirrup
#

I saw arowx mentioned

#

โ†” ๐Ÿ‡ฝ

#

๐Ÿ‘ user review

#

I remember following some descent into madness with his whole making ECS query like SQL

#

Just for the morning banter

urban rivet
#

you never go full arowx

untold night
#

that 3d stacking DRAM thread was a ride

safe lintel
#

if I am converting and injecting a gameObject to Entity how do I find the representative entity without GameObjectEntity?

soft nova
#

"you never go full arowx" -hippo

That right there is the quote of the year

prisma elk
#

is Arrowx here though?

#

Don't give him that much shit, please

urban rivet
#

you don't need to worry, discord is fully monitored, no abuse will occur

#

teasing IS another story though :P

manic aurora
#

o man entity debugger finally showing systems in my non-default worlds, i love this

urban rivet
#

the physics has me diving back into the world of ECS - I wondered "what if I could make megacity destructable...?"

#

except I can't compile megacity right now for some reason :/

full stirrup
#

Hmm how much does the physics cover or is only basic rigidbody stuff at the moment?

solar ridge
#

Most of the case right now is rigid body

untold night
#

RB + Queries + some Joint stuff

dull copper
#

It has all the core elements of a physics engine: rigidbody integrator, narrowphase, broadphase, collision solving, tons of different joints, collision primitives, convex + mesh collision, queries

#

It is more complete package than most here think it is

#

It just needs a lot of polish

#

It is mainly missing caching when comparing to other physics engines

tardy reef
#

Hello! Is there an alternative link to the megacity demo? Can't download it from the google drive link on the site. Thanks!

solar spire
tardy reef
#

Its downloading thanks!

analog tangle
#

Hmm... what's the "correct" way to program an ECS system when you have interactions between entities? Ex: Let's say I have non-uniform time of day around a scene... for whatever reason. My thought would be to make a series of time of day entities. My expected approach would be to make a System that operates on pairs of entities that contains specific components... but that's probably wrong. (The obvious way is to have Time be hybrid or some other object that injects into a system but let's pretend it needs to be an entity.) How would you do it?

#

I'm pretty sure you cannot create a system that operates on two entities, one that contains (series of time of day components) and another that contains (clock hand rotation components)... correct?

#

(And I know that it's not "contains" it's "has index of" but grammar is hard lol.)

tawdry tree
#

I'm pretty sure that is the correct way, to grab two separate sets of entities. Not sure how you would get that without some black magic tho, which would probably lead to a 'bad' way of doing it

mint iron
#

@analog tangle I think the most modern examples of how to approach these sorts of things that you'll find right now is from the new physics demos. eg. https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/UnityPhysicsExamples/Assets/Demos/6.%20Use%20Cases/CharacterController/Scripts/CharacterControllerComponent.cs

analog tangle
#

Oh wait a minute... component dependencies are per-job, right?

#

Right so I just need a system with multiple jobs. One that operates on the "time of day" components. Gets the info I need. Passes it to the "clock hands" job.

#

The system doesn't care all the combinations of components that its jobs operates on, correct? Or is there any exception?

#

(thanks @tawdry tree and @mint iron btw)

#

But yeah, is there any exception?

manic aurora
#

just trying to see what i can get away with in ecs physics using multiple physics worlds. here i have "ghosts" that follow the player by some millisecond interval, each simulated in their own behind-the-scenes physics world, but the obstacles get copied into the each delayed ghost world at their true positions. so the effect is you see player inputs as if they started N milliseconds later, but the collisions are accurate for the ghosts despite not being in the "primary" physics world. i'm aware you can achieve the same effect easily with one physics world, haha.

edit: notably, 4/6 of the simulation jobs are parallelized here. finding pairs requires a complete(), but the rest of each simulation can be scheduled after that!

double edit: this scales bad. too much waiting on main thread in every physics world. lots of idle time
https://gfycat.com/tameunripecornsnake

lime dome
#

that very last guy seems to be very confused lol

visual dock
#

@analog tangle the system uses all component types accessed anywhere to calculate dependencies. Which data is accessed in which job and in which combination isn't important. You can just do what you want but may not schedule two jobs without a manual dependency between them if they access the same data and one has write access. The method you describe is perfectly fine: Job A reads data into native collections which are passed to Job B which runs over some group and uses the data from Job A.

analog tangle
#

thanks @visual dock

dull copper
#

got a response for why experimental audio api isn't in 2019.2 (needed for megacity audio package): The Audio System in Megacity is built on top of DSPGraph (which is available in 2019.1 as an internal API and inside Unity.Experimental.Audio namespace). We are working at moving this into a package and hoping to make it available in preview to the users as part of 2019.2. In order to do this we had to remove it from Unity's code base in 2019.2.

mint iron
#

@manic aurora thats really cool. Do you know if it has a linear increase in performance cost when adding worlds or are they sharing resources?

#

I noticed that they're rebuilding the bvh's from scratch constantly which is probably taking up a huge amount of time, if they can get an existing one optimizing/rebuilding only what is necessary for moving objects it would be a big improvement.

manic aurora
#

seems linear (actually worse, because every additional world adds more sync points / completes during processing) to me. in the case of my example can apparently skip updating the dynamics world, which is a nice boost, but the feeling i get from experimenting is that it simply wasn't designed to run LOTS of worlds at once

queen belfry
#

Is there documentation included with the new Physics package that I'm missing somehow, or is it an "explore and figure it out yourself" sort of thing?

manic aurora
#

seems like the demos are all we've got right now. i kinda got the basics worked out, but stuff like modifying contacts still mystifies me. although i enjoy that you can hook custom jobs into the physics world chain

dull copper
#

oh nice

#

t's the same docs as with the package

#

but I still don't know how to read md files nicely locally

solar spire
dull copper
#

I know, I just keep forgetting that option ๐Ÿ˜„

#

when I try new things from staging, that link goes nowhere

#

so I don't usually click it

solar spire
#

just letting everyone know seeing as there's apparently 3 of you ๐Ÿ˜›

manic aurora
#

oh man that is nice, good find โค

dull copper
#

For any physics features that do not cache state, e.g. raw collision queries, we expect Unity Physics performance to be on par with, or outperform, similar functionality from commercially available physics engines.```
dull copper
#

ummmm

#

Core algorithms are deliberately decoupled from jobs and ECS to encourage their reuse and to free you from the underlying framework and stepping strategy. As an example of this see the immediate mode sample which steps a physical simulation multiple times in a single frame, independent of the job system or ECS, to show future predictions.```
#

doesn't this mean that part will be a) single threaded b) non-deterministic as it can't use burst?

solar spire
#

there's a tidbit at the end of collision queries that talks about how it uses burst if you're calling it inside of a burst job yourself

#

so I wonder if that can apply to the whole thing

manic aurora
#

well i think the physics simulation applies burst regardless (i.e. their internal jobs), just the collision queries are defined outside of jobs so wont be burst compiled unless they're called from one.

but, yes, the "immediate mode" pool sample DOES run multiple simulation ticks "single threaded" - the physics simulation will leverage multiple threads, but each "tick" requires a .Complete(). you CAN simulate multiple worlds somewhat in parallel, but in the pool case it needs the result from the previous step to calculate the new one

gusty comet
#

I have playback UI that send events to an audio loader that decompresses audio from disk and sends completion result to an ecs playback system(it will track the progress and sync notes from a chart). What I currently wrote works, but it's awkward cause UI and loader post both to a global event bus and to an ECS one(by creating entities with an event component).

#

How would you ECS-ify all this?

tawdry tree
#

Not sure about UI, but the goal is to get rid of the global event bus and basically replace it with an ECS event bus instead?
It's not entirely clear to me, from what you wrote.

analog tangle
#

@dull copper It... depends. They might mean "decoupled from jobs and ECS" in the way that Unity.Mathematics is.

gusty comet
#

@tawdry tree well I'd like to do everything inside systems. But I have async code that has to be run from System.Task and I'm kinda lost with designing around it. I guess I should maybe spawn event entitities for Mono communication as well ๐Ÿค”

tawdry tree
#

You can fire off a job and save its job handle instead of completing it the same frame for a similar effect, I believe

gusty comet
#

Nah, it'managed code.

#

I'm using NLayer in one case and UnityWebRequest in other cases for loading audio from disk so.

tawdry tree
#

That'd make things more complicated, yeah. Not sure if there is an actual way to fully ECS it.

gusty comet
#

I just wonder how to design communication between all this. Like the playback system needs to check if loading failed, if track was paused, if it was resumed, control the AudioSource etc. Maybe I should just make everything poop out event entities and be done with it. Sorry for asking such an abstract question, the paralysis of choice is just killing me.

tawdry tree
#

I think the best thing to do in such cases is to just make something, and then when you (hopefully) got something working, note down both pros and cons(like pain points, perf, etc) of whatever solution you came up with. Hopefully you at least learned something, and got _something_working, and if you're actually working in ECS it should be relatively simple to refactor later, if you ever decide to.
Such is life with preview packages.

safe lintel
#

anyone know if raycasting can be jobified for the new physics? not really sure how you call the BuildPhysicsWorld system from a job

#

nevermind started reading the documents

toxic walrus
#

there is a demo with raycast inside job

safe lintel
#

which example was that? I only saw monobehaviour stuff but i couldve overlooked it

toxic walrus
#

script MousePickBehaviour

#

it calls CollisionWorld.CastRay(rayCastInput, out var hit) inside a job

knotty radish
#

Hi people, quick question we still don't have a way to find the origin of JobTempAlloc leaks right ?

knotty radish
#

Answering myself: always try to restart Unity because it will self repair

safe lintel
#

ah thanks, didnt think to look there!

safe lintel
#

eh so I can query a hit in the same job that I schedule the raycast? that seems too easy after all this time of doing two jobs for raycasting with the physx job

mint iron
#

@dull copper it means they want you to be able to use it without ECS. So you have the flexibility to use it for performance with custom burst jobs. Like just spawn some colliders and start ray-casting them in a normal non-ECS project.

All the queries are pretty much using burst jobs, so being burst compatable is not an issue - its designed to be (ConvexHull and BlobArray are blittable and could be shoved into NativeArray). I would expect them to be making it parallel compatible if its not already. Most of the jobs are IJob but BlockStream.Writer is used in a IJobParallelFor.

amber flicker
#

Hi all. Iterating over some entities in a chunk I can access related entity data using ComponentDataFromEntity e.g.


 public void Execute(ArchetypeChunk chunk, int chunkIndex, int firstEntityIndex)
 {
      NativeArray<SomeEntityData> relatedSequenceEntities = chunk.GetNativeArray(SomeEntityDataType);

      for (int i = 0; i < chunk.Count; ++i)
      {
    //relatedSequenceEntities[i].Value points to another entity
    //sequenceSettings[relatedSequenceEntities[i].Value] contains 'SequenceSettings' data for said entity
      }
 }```
My question is, how do I do a similar thing to check if a related entity (`SequenceSettings` entity in this case) has a particular tag/component?
#

sorry that was a dumb question - I can just use another CDFE with .Exists I think

tawdry tree
#

Reminder that you can put 'csharp' after the first triple backticks to get code highlighting. Note that you need a new line after that, so:
```csharp
//code here
```

earnest raptor
#

You can also do ```cs ```

safe lintel
#

anyone know how triggers work in the new physics? dont think I saw an example for it in the samples

analog tangle
#

So what's the style opinion on helper methods in IComponentData? Ex: Converting the value to other units. I think it's a definite win but \_(ใƒ„)_/

knotty radish
#

The real question is : does it bring you joy ? If not, discard it!
#EntityMarieKondoSystem

#

(I personally don't have use case for them)

shut python
#

this might be a weird question but is the Unity ECS a "native thing" now? I paused GameDev for some months and wanted to know if there are enough ressources to get into it (beginner friendly). Maybe Entitas is still an alternative? I didn't find many resources out there and when I got one the tutorial looked very "experimental" .. ๐Ÿค” thanks for help! ๐Ÿ˜ƒ

analog tangle
#

@knotty radish It does bring me joy. :p I like having one place (that's unit tested) to see how many game time ticks are in an in-game hour, etc. :p

analog tangle
#

(Not time as in Simulation Time. Time as in time of day, which in-universe day, etc.)

gusty comet
#

A note for other crazies like me that need to mix async Tasks with ECS systems: PostUpdateCommands is not captured inside async methods the way you expect it to and by the end of the task you'll have a reference to a disposed postupdate. I have to run an async IO task from a mono and from there it posts event entities to EntityManager without any problems.

analog tangle
#

Ah cool. Thanks @gusty comet

gusty comet
#

Probably not relevant to most people but I don't want to write my own jobified mp3 decoding so stepping on a rake it is ๐Ÿ˜ฐ

dull copper
#
Very much so, MegaCity for us was a stress test of:
...
Ensuring simulation & rendering and soon integrated Unity.Physics hold up in a world with massive amount of entities```
#

well, I'm not going to try integrating the physics package to megacity then ๐Ÿ˜„

gusty comet
#

Is it possible to iterate components from a Mono? I need to get all AudioLoading events from ECS inside my UI controller.

gusty comet
#

Okay, nvm. It's possible with .CreateComponentGroup. Weird that it requires a temp job allocator though with ToComponentDataArray. Ah well, components are 0-sized anyway so I can just calll group.CalculateLength().

knotty radish
#

Yeah I was wondering the same thing

#

And actually ToComponentDataArray is populating a NativeArray with a Job so TempJob make sense

#

Just weird that you need to pass an allocator but only one value works

urban rivet
#

why are people surprised it's a stress test? the moment there is a way to do the same task much more efficiently, is the moment you must assume smart people are doing the demo for another purpose like stress testing :P

#

in real world scenarios, I don't expect more than 10-20k of live objects in an optimised open world game - and this is on the highest worst case scenario, so imagine the performance of 200k, applied to 20k, and we have a winning AAA streaming and rendering system

#

you'd be applying all the classic partitioning concepts so it would be a lot less than 200k

#

brilliant for mobile too

gusty comet
#

Another dumb thing, why is any info about system update so hidden wtf. Now I have to figure out how to use ComponentSystemGroup since you can't use [UpdateBefore(typeof(EarlyUpdate)] anymore.

twin raven
#

Is there .apk of the megacity demo for android?

urban rivet
#

not that I know of

solar spire
#

Is there even a build released? You have to do it all yourself from what I've seen

urban rivet
#

Just download it, open the project and build

solar spire
#

yeah exactly

gusty comet
#

Just go to GDC and play the demo there.

urban rivet
#

I have a build if anyone wants a look, will delete from google groups in a few mins

#

I mean google drive

gusty comet
#

That's the worst emoji reaction I could get ๐Ÿ˜ข

twin raven
#

I don't have a computer available at the moment so cannot build myself :)

gusty comet
#

Anyway, pls help, how do you make a custom update order now? Where one system must be ahead of everything for example.

urban rivet
#

Well, megacity isn't just about rendering all that stuff and in fact it's ugly, it's unpolished,.... but it's also streaming it all from disc, which is a nice thing

knotty radish
#

I think you need to wait for the next update to handle update loop order correctly

gusty comet
#

But how? How do you specify that you want this system to be ran last without getting a warning about non matching simulation groups?

toxic walrus
#

put them in the same simulation group

knotty radish
#

You could also manage your systems manually but yeah it would work with putting that system in the specific group you want

gusty comet
#

Okay, I think managed to make this work. I just put the old event removal system in a custom group EarlySystemUpdate that runs before SystemUpdate and destroys all entities with Event component.
The rest of the systems belong in SystemUpdate group.
Can't post events from Monos this way, but I circumvent this by creating unmarked events from monos that are destroyed by relevant systems and then forwarded but this time marked with Event component.

minor sluice
#

Hi!
Since ecs physics are now released, I wonder if it is time to continue my ecs bullet hell game,
but I am not sure if I should go with the new physics system or make my own 2d system and orient myself on the 3d solvers Unity included for the new physics system.
(I would only need circle and line shapes at first, maybe lines with a certain line strengh, so that would be 3 solvers. circle-circle, line-line and line-circle).

Any tips/suggestions?

dull copper
#

@minor sluice Unity is working on 2D ECS Physics atm afaik

#

so if you only need 2D physics, might be good to wait a bit

minor sluice
#

nice to know, thanks! I might just wait a bit more then.
I would assume that it will eventually come, but I am not sure when the time is, since the ecs samples are updated though, I might take a look at their physics samples

dull copper
#

(melv = unity's 2D physics dev, in case it isn't known)

minor sluice
#

oh, I didn''t know. awesome

dull copper
#

we got anthony on this group too (yant on the forums), he's doing the physx stuff for unity

minor sluice
#

maybe I should visit here more often, the other discord servers are general game dev and brackeys, which are somewhat focused on unity of course, but this might feel like the go to place for new unity developments and people working at/for unity

dull copper
#

I love dedicated groups like this

#

those generic groups attract more "tire kickers", people who love the idea of doing gamedev and spend their time mostly talking about it ๐Ÿ˜„

#

that's my impression from the generic groups I've been at

#

I don't usually stay long

minor sluice
#

the issue is that I am pretty much procrastinating in the other groups ^^
oh yeah, you are right. In fact, I got more done before I joined discord

dull copper
#

this group is really nice and clean, a lot of less trash talking than on the unofficial groups

#

plus I love the presence of Unity staff here

minor sluice
#

and recently it is more like I start some prototypes and drop it again, but since ecs is now further developed, I might want to revisit what I started back in may 2018.
Aside from that, I will probably try myself at a rollback networking implementation in the next weeks, (similar to what Photon TrueSync was before they shut it down, but p2p)

dull copper
#

right now, I'm really waiting to see the DOTS roadmap talk

#

it could answer so many questions on the immediate future of Unity's ECS

#

mainly curious where they are going with the AI + when we get the full editor (but I don't really expect Unity to give ETA)

#

for example, they just got this out https://forum.unity.com/threads/ai-planner.649246/ and since it's been cooking for years, it's not for DOTS

#

there's been no discussion on navigation either

mint iron
#

What is encouraging for me is seeing in the physics examples how they've implemented inspectors for setting it all up, and the examples are easier to consume for a non-technical person in the sense that you can drop in a cube, add some monobehaviors and have it work. That easy interaction is the cornerstone of the application and the speed behind Unity Physics under the hood is still there.

So hopefully that spreads out to all other aspects of the tool eventually. The same sort of workflow that draws people into the software and why they like to use it, just much faster. Sure you will have people that want to spend the time messing around with the low level stuff and its important to have that option, but yeah, momentum will come from the higher level use cases.

final fox
#

@dull copper AI Planner seems DOTS based. BaseAgent inherits from MonoBehaviour but it works with Entities

minor sluice
#

it is a rather big shift of rethinking to go from the traditional system to their new ECS one,
I wonder if they included all main features you have with the regular approach into the DOTS, if it will also be equally as easy to use it as it is in the current system

#

accessibility is a big plus of unity, but imo, to utilize jobs and profit from data locality, you have to make some specific preparations.

But, you could still use the ECS system in a sync way without having to use jobs

dull copper
#

@final fox really? I only opened otto project I didn't examine the code itself ๐Ÿ˜ƒ

#

I'll do some digging, thanks for the heads-up

final fox
#

Yes, I'm fighting against the code generation (the otto project works but I can't do anything from scratch).

mint iron
#

Frankly i don't see much of a difference if you're working with it at a higher level. You still have a bunch of objects, its just that your work happens in a separate manager instead of on each object. Conceptually its the same as having a bunch of enemies spawned, and a separate singleton or whatever goes through and moves them all.

final fox
#

public sealed class PlannerSystem : ComponentSystem

๐Ÿ˜‰

minor sluice
#

what I also don't get.
you can put functions/methods inside your structs, but I guess because you want to benefit of the architectural separation between logic and data, people don't do it?
even though you can be sure that the method only affects data that is component internal

final fox
#

It's considered as "bad design choice", but sometimes "bad design choices" are "good hours preserved" ^^

solar ridge
#

I too wanted to see the talks from Wednesday GDC but I have yet to see any videos from those talks

dull copper
#

it's going to take ~week to see the videos I predict

#

at least that's how long it took last year for first videos to arrive

#

hmmm, that AI Planner and latest Entities package don't go along

#

had to update the AI Planner for some things

gusty comet
#

hmmm...just opened the ECS Space Shooter project and updated everything - PositionComponent and RotationComponent are gone?

toxic walrus
#

position is now translation

gusty comet
#

is it TranslationProxy?

#

I see, so PositionComponent renamed to TranslationProxy and RotationComponent renamed to RotationProxy

dull copper
#

@gusty comet where did you get the space shooter project? ๐Ÿ˜ƒ

#

I mean, wasn't that in the ancient ECS samples?

#

current repo doesn't have it anymore

#

or is that some different thing? either way, a lot of things have changed since

gusty comet
#

I got it working, idr exactly where I got it let me check

dull copper
#

ah, they still have it up

#

yeah, updated 3.5 months ago which sounds like it would be recent but at the pace ECS is evolving, that's lightyears ago ๐Ÿ˜„

#

nice that you got it going tho ๐Ÿ˜„

safe lintel
#

should a ConvertToEntity script always convert the hierarchy? getting a situation where a child isnt being converted not really sure how to debug it

dull copper
#

should

#

that's how the HelloECS samples showcase it

#

I dunno if it works if you have multiple ConvertToEntity scripts in the hierarchy itself tho

#

@safe lintel

#

or the hybrid GameObjectEntity thing

safe lintel
#

well: the child object doesnt get converted unless I add the old GameObjectEntity

#

but with or withiout extra convertToEntity on the child objects nothing happens

dull copper
safe lintel
#

yeah ive seen that demo, thing is I have a monobehaviour (on the child) that implements IConvertGameObjectToEntity and in Convert just logs a message but the message never gets logged

#

also technically should work with multiple ConvertToEntity scripts in hierarchy as the physics CharacterController setup features this(but it also features GameObjectEntity scripts on the child objects for some reason)

safe lintel
#

hmm appears if you do inject on the root the child objects dont get injected, but having ConvertToEntity on the child doesnt appear to do anything with either inject or destroy

safe lintel
dull copper
#

oooooh

#

how did you find that?

safe lintel
dull copper
#

that's a weird share ๐Ÿ˜„

#

anyway, thanks for the link ๐Ÿ˜ƒ

safe lintel
#

yeah dropbox link use is strange but the guy seems to have a pretty strong unity news game so i figured its real

dull copper
#

been waiting this for days now

#

yeah, it looks like a real deal

solar spire
#

of course it's real, Will Goldstone posted it

safe lintel
#

well thank god for reposts because using twitter is just ๐Ÿ’ฉ

lime dome
#

yeah

safe lintel
#

the amount of times ive clicked a twitter link and it fails to load is just mind boggling

lime dome
#

this is what people were fretting over in that email

safe lintel
#

wish i could make software that awful and get rich off of it

lime dome
#

floating licenses are coming, they were just getting feedback from clients

#

yes please

#

looks exactly like how Blender ended up doing it

solar spire
#

it's been in 2019 for a while, you can try it out ๐Ÿ˜›

safe lintel
#

i hope that window ends up being dockable

#

feel like an entitled brat but it just irks me the way it isnt currently

dull copper
#

@safe lintel you didn't spot DOTS talk slides there, did you? ๐Ÿ˜„

lime dome
#

prob should take this to general

dull copper
#

I mean Unity did a separate DOTS roadmap talk

safe lintel
#

i perused the dots section while i was outside, might have been blinded by the sun if i missed a dots animation segment

dull copper
#

@solar spire and lol, I have been polling Will's forum profile in case he'd post that

#

he shared the previous events roadmap slides on dropbox too

dull copper
#

well

#

yeah, I'll stop spamming now

#

that DOTS-only standalone sounds cool, also what I estimated

untold night
#

I think visual scripting reminds me more of scratch and friends than kismeer, blueprints

dull copper
#

huh

#

to me it's super messy

#

the thing they showed before, the leaked 2019.2 package for visual scripting was nicer

#

it still used the same style stacking

#

but that for each node....

#

lets just hope they'll keep iterating on the UX

urban rivet
#

I think the stringent limits allow for strong optimisation

#

we're talking about something artists can slap together that outperforms anything youi're doing in non dots c# land

#

and artists are everywhere

#

its if as performant as it should be...

#

might be cool!

dull copper
#

yeah but if you look at that node, does it look easy to use for you?

#

there's just too much going on in single place

#

it looks like someone stuffed the whole function inside single node

#

when the idea on visual scripting is usually to assemble the function logic with the nodes instead

#

oh

#

hmmm, that seems like some wip thing, wonder if they meant to set it to public yet

#

commits made by Joachim

analog tangle
#

So... for my personal sanity... if I have a JobComponentSystem and I want to early-exit in the situation that I don't need to do any work in that system (ex: timeScale is 0'd during a pause) could I just return inputDeps?

#

Or does that have any weird consequences?

#

I'd figure that'd be exactly what I want -- return the previous head of the list of jobs to do without adding my job to it.

untold night
#

that is the intended way to early out if you're manually setting up the data to process in the system

if you use component groups you can mark them as RequireForUpdate(_group); and it won't execute if there are no chunks that match.

If your systems is simple and uses IJobProcessComponent* I believe this is done under the covers.

#

also, RequireForUpdate works for multiple groups, so if you have group A and group B, but both to do work, it won't run if both are marked as required and no chunks match

#

if you need to deal with optional groups then you have to do it manually with _group.CalculateLength()

analog tangle
#

Cool. Thanks @untold night

#

... >.> I keep forgetting if this Discord has a karma system lol

untold night
#

I don't think it does

#

I do wish there was "RequireAny" variant if you had a bunch of optional groups but thats something you should generally avoid

lilac ermine
#

@dull copper i actually rather like the direction of the visual scripting look - though of course it will need ux improvements. always preferred more of a blockly or gameflow design than bolt / blueprints

urban rivet
#

its more familiar to people who are already working with shader and vfx graph

#

same sort of thing, same ui as well

#

still a bit concerned what perf would be like. Should I hang up my keyboard?

untold night
#

I greatly suspect that there may be many cases where hand-rolled HPC# code will beat out Viz scripting, since it can't make the same kind of micro-domain assumptions a programmer can. There's a good chance it'll enforce safety where one could conceivably bypass it and that might be the case where you'd want to refactor into hand-rolled code.

Although being able to hand something to a designer and have the system generate thread-safe code kind of beats out any complaints I would have.

#

Also, when has a Viz scripting system EVER eliminated text-based programming?

Somebody's got to rewrite an entire graph inside a single Blueprint node and it sure isn't the art director

urban rivet
#

that's just it, the overall contribution of scriptable content pouring out of the art dept would be safe and only require me to basically act like glorfied QA

#

albiet experienced :P

#

I'm moe concerned about the networking and how much work all that would be. How much can they automate if we stay inside dots?

#

it's kind of crazy, think about it. It's like 3drad or limited torque script all over again...

untold night
#

yeah but how many artists are writing collision systems, whole voxel engines, etc. Unless they're that one person who did and the perf is terrible because the node system is still an abstraction over hand-written code, and has a lot of temp vars and such.

urban rivet
#

hahaha

#

true

untold night
#

t..ttorque sCript trauma flashbacks start playing in background

#

WHY WAS IT ALL STRINGS?
WHY

urban rivet
#

but it's also quite safe and that's very compelling for any studio big or small:

  • safe
  • threaded
  • low barrier to entry
  • freely edit while playing
untold night
#

THERE WERE MEMORY LEAAKS EVERYWHER

#

you make salient points

#

back on topic fine now

urban rivet
#

good ol torque script. it eventually gave birth to torque2d and the same melv may now handles unity's box2D integration

untold night
#

HOLY CRAP HE DID WORK ON THAT DIDN'T HE

urban rivet
#

he invented it

untold night
#

something about his name seemed familiar but I couldn't put my finger on it

urban rivet
#

small world isnt it?

#

lol

untold night
#

I suppose you know you've made it big when a large game engine company hires/acquires you for the thing what you made

urban rivet
#

....twice

#

since torque2d was his own thing with torquescript and garage bought it, hired him and...

#

so he gets bought a lot and just goes with the flow

untold night
#

ah, I now remember seeing his name on the torsion splash, holy crap

lilac ermine
#

Should I hang up my keyboard? personally, i long for this day

solar ridge
#

But... hot keys? ๐Ÿ˜ข

#

The keyboard wishes to be loved!

urban rivet
#

the keyboard doesn't love you

#

all you do all day is poke it spitefully

#

you barely clean it

#

sometimes you blow on it as if it's a bad smell

solar ridge
#

Nooooo. I gently pet it... and at times use a highly pressurized air can to help clean it....

One of those 2 things at least seems kind ๐Ÿ˜‚

scarlet inlet
#

hello there is this a good place to talk about burst?

#

also I know this is supposed to be UnityECS, but if I want to share some Svelto.ECS articles, should I do it here?

scarlet inlet
dull copper
dull copper
#

oh nice

#

where did that come from?

solar spire
dull copper
#

thanks

sonic gull
#

We are engaging ECS on our project to a small degree and to that degree it is helpful. There are certain restrictions, and the parts that we would like help the most are not suitable for ECS workflow. i.e. they contain sub-meshes or have certain types of animation on them. Having these in mind we would consider using a different workflow in the future. It is definitely worth it, and hopefully ,as it is still a work in progress, ECS will expand to become more inclusive regarding the types of assets it can work with.

toxic walrus
#

if there are two JobComponentSystems A and B, B has [UpdateAfter(A)]... when OnUpdate in B is called, can I be sure that the jobs from system A are completed?
or do they come in as the "JobHandle inputDeps"?

tawdry tree
#

Pretty sure UpdateAfter is specifically meant to make them... update after the other one.
It was either that one or another attribute that was used to create synchronization points

dry nymph
#

In your example,

  • OnUpdate (main thread) of "System B " is called after OnUpdate of "System A"
  • There is no guarantee that the jobs scheduled in "System A" are completed, when OnUpdate of "System B" is called
  • If "System A" and "System B" share component types, the dependencies " come in as the "JobHandle inputDeps" "
tawdry tree
#

Oh yeah, the inputdeps themselves are the sync points, herp derp. I really should get around to tinkering more with ECS, right now most of what I know is from like 4 hours of playing around in preview 17 or something plus a bunch of videos and articles of varying freshness

clear bluff
#

Hey everyone, I'm looking to catch up on some of the latest Unity tech, and I was wondering the best way to get started with ECS. I've seen a few of the high-level keynotes and tech talks, but would love something a bit more focused on actually building with it. Are there any up-to-date tutorials, or sample projects to learn from?

untold night
#

So, they updated the old samples:

https://github.com/Unity-Technologies/EntityComponentSystemSamples

The HelloECS samples show different workflow setups.

The Physics stuff is brand new.

They've updated the Boids samples and added some new feature tests to work off of.

If you have the bandwidth on your machine to handle them, the https://unity.com/fps-sample and https://unity.com/megacity have actual working ECS projects. The Megacity is as close to "Pure" ECS you're going to get outside of UTiny, the FPS Sample will be updated and converted as more ECS features get built, it's already move more things into ECS recently.

Unity

Use it to learn about the latest features in Unity, extract and use the parts you need or use the full project as a starting point for your own games.

Unity

Megacity

#

I haven't messed with any of the UTiny stuff, so I can't tell you if there's good samples or not but it forces a kind of ECS that will be merged with the main ECS stuff (namely, it's workflow will merge with the main ECS and UTiny will eventually use the same C# stack as main ECS)

clear bluff
#

Great, thanks for taking the time to share all that @untold night

#

I'll check out the ECS Samples repo, and maybe give UTiny a look. I'm primarily interested in ECS for improving performance on old and weak hardware, so that could be a good fit too.

#

can UTiny build to Android?

untold night
#

I Know that UTiny is targeting web/messenger games/instant games as it's "priority zero", I don't think it currently supports anything other than that right now. Once they start merging to the C# codebase then they can probably target everything else.

the normal ECS should work on Android devices now if you make an IL2CPP build.

clear bluff
#

Cool, thanks again!

analog tangle
#

@untold night A lot of that is because a lot of the Project Tiny team are ex-Mozilla's gaming division.

#

(ex: Vlad, Martin)

untold night
#

That makes so much sense

full stirrup
#

Ah, nice links

urban rivet
#

Regarding Tiny, does this content just work on mobile browsers as well?

full stirrup
#

Was there a release for the C++ variation on unity? I remember seeing a plugin once upon a time... The DOTS slides are in C++ so just wondering if it was a common ground to work on

dull copper
#

@full stirrup there's no official c++ thing

#

Unity's closed source engine side code is done in c/c++

#

but the scripting is on c#

#

you probably mean HPC#

#

which is unity's c# subset for DOTS

untold night
dull copper
#

I've used it

#

but it's not really like c++ support

#

it's similar to native dll's with the exception that with that you can build your c++ files on the same dll with IL2CPP build

#

you still need to write same c# interop stuff for it

untold night
#

that would have made many past project significantly more convenient though. I am both pleased it exists and upset that it wasn't in place sooner.

analog tangle
#

So yeah... it can be either native or web on mobile.

urban rivet
#

Yeah, and obviously - builds

blazing mural
#

Does anyone know if the 2D stuff in Tiny is intended to become the 2D stuff for ECS in general?

#

I think they've already implemented sprites and simple collision among other things.

analog tangle
#

I was wondering if anyone can give me a little insight into how to make this code more efficient... I'm guessing the biggest problem is that I don't know how to efficiently schedule ECS work.

System that updates time of day entities. https://pastebin.com/FNSuVVta
System that rotates the hour and minutes hand of a clock: https://pastebin.com/ya2My9ND
Tag Components for Time of Day and Clock Hands: https://pastebin.com/Ax0d4pDr
ComponentSystemGroups and Barriers for Time of Day and Clock Hands: https://pastebin.com/PnftdUPC

Not listed:
GameTimeOfDay -> Component that contains an int corresponding to tenths of a millisecond in game time.
GameDeltaTimeOfDay -> Component that contains an in corresponding to the amount of GameTimeOfDay that has been added since the last frame
GameTimeOfDaySpeed -> Component that contains a float, which is the multiple over Time.deltaTime that the game speed runs at. (Ex: 4 = 4 in-game seconds per Time.deltaTime second)

Initial values are set in the spawners.

Some things to look out for:

  1. RotateMinuteHandsJob and RotateHourHandsJob seem to require a dependency between them... shouldn't I be able to just have them depend on getTimeOfDayJobHandle and combine their dependencies on return?
  2. I shouldn't need to create my own barrier for UpdateTimeSystem... should I? (It's there in case I wrap over midnight and need to assign that tag to it. I could ignore it until one of Unity's barriers. It'd leave a few systems with an out-of-date date, though.)
  3. I shouldn't need to .Complete() getTimeOfDayJobHandle... but Unity throws a fit if I don't. Is there another way?
  4. Anything else that you see inefficient.

It's kinda silly to do these onsie-twosie things on a one-off system, but it's good practice. It's knocking quite a bit off my framerate, though. (Down from ~250FPS to ~190FPS... which is a larger impact than just using monobehaviours.)

#

I'll be getting food so @ me if you want to reply. I'll respond ASAP.

untold night
#

@analog tangle - looks fine to me.

2 points about perf:

  1. The editor adds a bunch of safety checks to ECS and debugging GC allocs that can affect performance. You can disable this along with certain levels of logging from the Job Menu. You should always profile in a build to get accurate numbers for pef tho.
  2. EntityCommandBuffers aren't fully optimized even excluding Burst limitations. They've mentioned somewhere on the forums they'll look at that later. However, since you're using IJObProcess with the command buffer, you can use EntityCommandBuffer.Concurrent structure and schedule the job as .Schedule(this, inputDeps) instead of running it on one core. That can help comp until Ecbs have a perf/burst compatibility pass. You can use the index parameter as the jobIndex parameter for the concurrent ECB calls.
analog tangle
#

I was talking about performance in a build.

untold night
#

ah

#

then the only thing I can thing of is to parallelize the ECB calls.

analog tangle
#

Thanks for the ECB call... I used ScheduleSingle because I was getting errors lol. Makes sense there'd be a Concurrent version.

#

Although the test world only has one DateTime state so there's not much to multithread :p

untold night
#

Ah if you have a low set of elements the scheduling overhead may not be worth it. You can call Run instead of Schedule and it'll execute immediately on the main thread which for smaller loads may be more beneficial

analog tangle
#

Curious if it'd give a boost anyway, though... like if the way it's scheduled would be significantly different.

#

Oh really?

#

Good to know, thanks! @untold night

#

Yeah... I should definitely look into Run()

#

Was wondering how "the ECS pattern" would apply for small numbers of elements.

analog tangle
#

Yeah... while I haven't fully tested it, switching the one-off systems to "Run()" made things much faster.

untold night
#

yeah, I believe Joachim mentioned in a forum thread somewhere that if your code takes less than ~.15 ms to execute or some such number, that's when it's not worth multithreading it.

#

I couldn't find the exact number, but Run() does basically exist to run jobs and bursted Job code on the main thread if needed for low data loads.

analog tangle
#

Yeah. It still seems a bit heavyweight... wondering how much of that is something Unity will iron out... and how much of that is just "meh".

#

"It" being a bunch of one-off systems that act on single items.

#

Unless it's a one-time cost for just having anything ECS in the system at all... I'll need to test with that.

untold night
#

I mean, you can't really burst the code right now. Might try it as a componentSystem and see if that's a bit better? You won't have any job overhead at least

#

Like if your code is simple enough, JobComponentSystem may be overkill

#

especially if you only expect to have the main one time of day entity

analog tangle
#

Yeah. It's just toy code at the moment.

#

I'm not expecting to make an Alice in Wonderland world with varying time of days lol

#

It's actually a very simple game in terms of time of day.

untold night
#

and digging through the forums, it looks like the range for job scheduling is somewhere on the order of "if it's less than about ~.5 ms, the scheduling overhead beats the job savings"

analog tangle
#

Yeah... and these guys are 0.05ms under run. I don't think they'd even be picked up on the profiler if they were a Monobehaviour.

untold night
#

I'd definitely convert the main Time of day update to ComponentSystem and see how that fares. If you have a lot of things that rely on that time of day change later in your system chain, that's probably the thing to multithread

analog tangle
#

Yeah this test is interesting that's for sure lol.

#

It works right now so I'll leave it like that for the demo, but it'll be something I look into when it's time for retakes.

#

Thanks again @untold night

crystal zephyr
#

Hey guys,
I am just in the beginning for ECS usage but one thing I didn't get in my mind how to do. My plan was to have most of my game logic in ECS and the data stored already in the ECS layout. But how I would create a bridge to get ECS data out of the ECS world into the old Unity eco system? For example I would have the whole movement of my character in ECS but when it actually moves I want to trigger the correct character animation which I sill have to do with animator on a GameObject. Can I somehow easily link my entity to a gameobject in the scene and use that in a ComponentDataSystem?
How you would approach this?

gusty comet
#

I have an entity bridge script but I'm not at home rn :/ There are many ways. ISharedComponent, keeping a map of entity to mono, posting event entities and queryeing from a mono through a compoment group... Hacky shit.

#

You can actually ForEach monos from ComponentSystem so that'd be the least hacky.

#

In your ConvertToEntity inspector disable destroyal and then your entity will have a mono attached.

#

Then you can just Entities.ForEach((Entity entity, ref DumbComponent MyDumbComponent, MyMono mono) => {});

oblique fractal
#

Hi Guys :D I'm into some trouble right now. I'd like (inside a job) access to some chunks using a entity reference (that I just get from another chunk). How would you do that? I mean, sometimes ago there was something like ComponentDataFromEntity, but with the chunks I don't have a clue of how to proceed.

amber flicker
#

@oblique fractal it's still CDFE's - assuming you know how to do a normal job/chunk iteration, you're basically already there - something like this I think:

[ReadOnly] internal ComponentDataFromEntity<OtherEntityData> otherData;

 public void Execute(ArchetypeChunk chunk, int chunkIndex, int firstEntityIndex)
 {
      NativeArray<SomeEntityData> entitiesForLookup = chunk.GetNativeArray(SomeEntityDataType);

      for (int i = 0; i < chunk.Count; ++i)
      {
    //entitiesForLookup [i].Value points to another entity
    //otherData[entitiesForLookup [i].Value] contains 'OtherEntityData' data for said entity
      }
 }```
and when you create the job, something like: `otherData = GetComponentDataFromEntity<OtherEntityData>()`
oblique fractal
#

Thanks @amber flicker I give it a try !

gusty comet
#

Hey guys ๐Ÿ˜„ I'm starting to implement a custom rendering system for non instanced meshes. I was wondering about the Blob functionality that was implemented in 2019. Should I use that stuff to handle my meshes? seems like it can be serialized with the world. That could be useful. But there is not a lot of information about what is the goal of Unity with this blob stuff.

untold night
#

the most I've seen of it is in the physics samples for building collider / joint data and passing it around.

I'm looking to use it to migrate scriptable Object data

#

I do think the design intent for it is "immutable after creation" but don't quote me on that until we have clearer documentation

#

so it may not be the best choice if you're doing a dynamic mesh, then again, we don't know enough yet

fringe sinew
#

I think that this was answered 100 times in the past, but I can't turn my head around on how to dispatch jobs from a system and use the results of it in another system

#

So, for example, you have a system broken up in two, first one dispatches jobs and the second one, after who knows how much time, force the jobs to finish and do the rest

#

Switching from OOP is a bit of a challenge

manic aurora
#

i mean, there are a bunch of ways. kind of depends on the nature of your data. if a dynamic buffer suits it, sometimes it's easiest just to cram the data on an entity in a buffer. if you have some more complex type like a native hash map, you could stash it on a shared component or as a public member on a system that you inject into the next system.

depending on what other work you need to do, you might have better luck declaring a single system that contains a persistent container for your data. then declare two other systems/classes that expose a public method like JobHandle ScheduleWorkForThisSystem(NativeArray<Thing> myDataContainer, JobHandle inputDeps). then in your system that owns the container, you just call both ScheduleWorkForThisSystem, pass the container as an argument, and force the returned JobHandles to depend on one another. i see (approximately) this pattern a lot in the new Unity.Physics - you have some container class that both manages collections and schedules parameterized jobs that use those collections.

fringe sinew
#

I don't think I really get it. Don't you need to inherit from JobComponentSystem to operate on entities in jobs?

#

If that's the case, returning the job handle from the main thread is required and after that I don't think you have the ability to control it.

#

Like... The basics. A rotating object that consist of 3 systems. One holds general data, one dispatches jobs to operate on that data, the final one which requests the job to finish and then operate on that data.

#

I mean, there's a lot of magic going in the background. Like, I don't get it, how do I get archetype chunks then? How do I fill it and pass them to an IJobChunk struct for it to be called from a usual ComponentSystem?

#

Gah! This is pretty confusing

tawdry tree
#

A system which takes inputDeps as usual, but instead of using it in any way, it just creates the jobs to be queued and store their handles somehow, and returns inputDeps unmodified?

fringe sinew
#

I guess, yeah

#

I mean, you can probably do it like that, but what is unity doing behind the black box? Maybe it's calling Complete right after scheduling, which fully throws my needs in the trash

#

I mean, this is pure magic. Where does the ArhetypeChunk come from? How do I get it myself to use in vanilla ComponentSystem? What about the indexes?

manic aurora
#

Do you specifically need chunk iteration for something? If you just want to rotate an object, you could just define and schedule an IJobProcessComponentData<Rotation> and modify it there.

fringe sinew
#

I suppose yeah, but I would've preferred chunk iteration. Now then, for the sample scripts again. Where do Rotation and RotationSpeed components come from? Aren't they from JobComponentSystem?

manic aurora
#

Well they're from all the entities that have both a Rotation and RotationSpeed component. My understanding is that IJPCD is basically doing chunk iteration under the hood to gather the data and calling Execute() once for each Entity.

#

The entities themselves are your data store

fringe sinew
#

I've been thinking. How bad is ScheduleBatchedJobs?

#

It says that it can hurt the performance, but what if I need to schedule a job at the beginning of a frame and have it done by the end of that same frame? How does unity even decide when it's appropriate to kick-off jobs? Unity is a bit vague on it

manic aurora
#

iirc the recommended use case for that is like when you're scheduling lots of jobs in a for loop, you should call it every so many schedules. you can pretty much assume that when you leave a component system update, if you scheduled a job, it will be scheduled in a reasonable time. wouldn't stress about it if you aren't scheduling LOTS of jobs

#

also i've never tested this, but i'm pretty sure any job you return from as a dependency from a system has to complete that frame

fringe sinew
#

But, I mean, what if I schedule a job, come back to it in a bit, call Complete and it didn't even start? That's a magnificent waste of processing.

#

I could force the scheduling, but then again, Unity says that it's bad for performance.

manic aurora
#

just unlikely, like, id be interested if you could even make that happen on purpose. by the time something else runs where you can check the job status, it's very likely to be scheduled

mystic mountain
#

I didn't get any answer in the Physics channel, but its related to ECS so; In the doc for the new physics it is said
You can choose to create you own collision worlds which are entirely independent of the physics world. However, if you are performing queries against the same physics world you are simulating, which is common, then you can take advantage of the fact that the broad phase had already been built.
Does this mean you can only simulate one world at a time? And as someone who haven't used this concept before, in comparison of using layers between two types of collision objects to never collide in what circumstances would one be better then the other?

manic aurora
#

You can simulate multiple physics worlds at a time. Dunno about the rest

urban rivet
#

Yeah I think there's problems running worlds at fixed rates so that's something Unity is looking at now, if I am not mistaken.

solar hill
#

hey does anyone have any suggestion on how to get this "on" To Debug, enable the define: TLA_DEBUG_STACK_LEAK in ThreadsafeLinearAllocator.cpp. This will output the callstacks of the leaked allocations

#

i am trying to find an undisposed allocation

#

as in Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak

#

i assume it is related to this but none of the settings seem to do anything

knotty radish
#

Before trying anything else, try to restart Unity (had the same issue and it went away with a restart)

#

There is no way to debug that so I suggest you comment out one by one all of your components queries / injections

junior fjord
#

if I want to create a few entities at the beginning of my game how would I do that?

#

I'd need something that runs only when the game is started

untold night
#

you could have a system that disables itself after running. Or an entity conversion that creates other entities and then destroys itself

#

or have a MonoBehaviour that adds entities via EntityManager during Awake() or Start() and then doesn't do anything else

junior fjord
#

ok thank you

#

what is an entity conversion?

untold night
junior fjord
#

ah very nice, there are new samples?

#

thanks very much ๐Ÿ˜ƒ

#

I have been inactive for about a month and did not know

untold night
junior fjord
#

woah, when I was here like a month ago ppl said that production ready will take a few years more

#

but they probably haven't integrated physics yet?

dull copper
#

there's new physics package

#

still super early

untold night
#

fully integrated into everything? Nah, several years.

Production ready as in all the basics are covered and the foundation is done? several months

dull copper
#

I'd say several years off still for fully production ready ๐Ÿ˜„

#

but you can expect something usable at the end of the year

junior fjord
#

still very excited

#

I mean as long as I can use it and then get the benefits one by one I am fine

#

thanks for the informations

dull copper
#

@junior fjord did you see the GDC roadmap slides for this?

#

ECS core is targeted to reach 1.0 by this summer

junior fjord
#

no not yet

dull copper
#

that's pretty ambitious

junior fjord
#

can I find the talk?

dull copper
#

unity will upload it to the youtube eventually

#

right now we only got slides

junior fjord
#

can you share the link?

dull copper
#

sure

junior fjord
#

sounds interesting

dull copper
junior fjord
#

how is that pdf 200 mb size ๐Ÿ˜„

dull copper
#

but there's no publicly shared slides or video for that

#

those should appear soon in gdc vault tho

junior fjord
#

I do not have access to gdc vault unfortunately

dull copper
#

everyone get access to these sponsored talks

#

also in past years, all slides have been free for all regardless

junior fjord
#

ah I thought gdc vault is the stuff you have to pay for

dull copper
#

in the end, it's like half of the actual videos go to behind paywall, all slides are free for all

#

and after 2 years, they release the rest for all

#

but if you got sponsored sessions, they usually are freely available to all

#

so if you see Unity presenting things there, if they are about Unity itself, you will most likely see them on the free side from day one they upload them to the vault

#

but Unity also did sessions on their booth in addition

#

apparently they recorded them as well so those should appear on the Unity youtube channel within few weeks

latent walrus
#

@untold night How do I see you everywhere? You're on the forums too all the time lol

untold night
#

This week I just happen to have a lot of light work tasks

#

so I'm doing R&D and on the forums a lot

latent walrus
#

nice, I don't know if I should feel honored or jealous : P

ember ruin
#

Hey, I would be happy if someone has time to look at my problem.

I currently make a voxel game for training with unity and I am currently on a "major" performance issue:
https://puu.sh/D6eEE.mp4

Whenever I move to generate more chunks my FPS go down horribly until the chunks are finished and combined into one mesh, if I generate them inactive and then activate the combined mesh I get a laggspike once I set all the combined meshes active.

Changing from one 1x1x256(height) to 16x1x256 makes it faster but the fps are dragged down far worse.

I use hybrid ECS.

This would be my code: https://github.com/SidiaDevelopment/VoxelWorld/blob/master/Assets/Scripts/Terrain/VolumeChunk.cs

foggy chasm
#

wonder if you should be GPU instancing each block

ember ruin
#

Just fyi, this is my first project, I do this to make myself known with the engine, ill need to look up gpu instancing at first ๐Ÿ˜„

foggy chasm
#

Unity makes it generally easy if you're using mesh renderer

#

just tick da box

#

mesh combining in C# is ๐ŸŒ

ember ruin
#

Ok, i will try if gpu instancing helps in a few mins

Any other idea better than mesh combining?

#

without it my batch count goes through the roof

foggy chasm
#

yup

#

if they're voxels - you might be able to dynamically batch them

#

which effectively just shifts the workload down to the native layer

ember ruin
#

can you elaborate on that?

foggy chasm
#

if your meshes share the same material and are less than 900 vert attributes (and no more than 300 verts) - unity should be able to batch them for you (with some minor caveats)

#

it does so in engine code, every frame

#

so there's some CPU overhead

#

something like voxels seems pretttty ripe for gpu instancing though

ember ruin
#

so with instancing theres no need for combining/dynamic batch?

foggy chasm
#

correct, instancing basically tells unity to tell the GPU to draw the same mesh X times at appropriate places

#

it shifts some of the burden to the GPU to handle the instancing - but I've got a hunch you'll be fine

ember ruin
#

sounds nice, thanks for the help, ill update you on the results, may i ping you if i have further issues?

foggy chasm
#

sure thing

#

fwiw - handling the mesh baking yourself is frequently the right answer for things like mobile where instancing isn't available on all devices yet

ember ruin
#

would lag out in the current stance on any mobile device, even my 1080 / 6700k build collapses under the current chunk generation ๐Ÿ˜„

#

but i guess for mobile i could just crank down the view range ๐Ÿ˜„

foggy chasm
#

yeah or just min-spec on GL3.1 (iPhone 5s and above, galaxy S6 and above)

ember ruin
#

oh i come from webdevelopment, dont remind me of supporting old devices (browsers) ๐Ÿ˜„

ember ruin
#

@foggy chasm unfortunately GPU instancing didnt change anything apart from my fps when i leave them all uncombined

#

my fps still drops to below 20 when generating new terrain

vale gorge
#

Are there some things you shouldn't do when using Hybrid ECS to make sure to get the most out of it?

dull copper
mint iron
#

entityManager.Instantiate() cant be called within a job? exception is saying something about must be on main thread

gusty comet
#

Hi guys ๐Ÿ˜ƒ I'm asking here but it's not ECS related, just it does use the Entities package:
I want to serailize/deserialize meshes the fastest possible so I just started to do this:

StreamBinaryWriter writer = new StreamBinaryWriter("File.bin");
var vertices = mesh.GetNativeVertexBufferPtr(0);
var indices = mesh.GetNativeIndexBufferPtr();
writer.WriteBytes(vertices.ToPointer(), mesh.vertexCount);
writer.WriteBytes(indices.ToPointer(), (int)mesh.GetIndexCount(0));
writer.Dispose();

Sometimes it works (well it did happen only when I was debugging), most of the time it crash because Memcpy can't access the adress. I tried to use MarkDynamic() but same thing. Someone have an idea about what's happenning?

gusty comet
#

Oh I think i'm stupid and I just don't give the right size. But I don't know how to find it ^^

junior fjord
#

the new samples are great

mint iron
#

they really are

mint iron
#

is there a way to SetComponent or update a component value within a burst job? seems that TypeManager prevents it

safe lintel
#

my sieve brain cant remember the code syntax for discord but the examples show a good amount of changing component values in burst jobs

#

what does your current job look like?

mint iron
#

i started making an imposter to fix the issues with TypeManager having managed arrays etc so that SetComponent would work. Figured i could extract the Type Index ahead of time and pass it into the jobs, but ended up having to replace pretty much every connected piece, there are so many issues in there.

#

so that works fine in burst, as the "Instantiate" method has no down line burst incompatible code.

#

and i figure i'll make another job/system to update the entity positions/properties on the components in a later step.

safe lintel
#

oh SetComponent by a EntityCommandBuffer isnt yet burstable

#

Could try ijobparallelfor and EntityCommandBuffer.Concurrent

untold night
#

"Destroy, Create, Instantiate" on ECB are all burstable. I believe Add/Remove should be burstable if you use ComponentType instead of the generics version, but that may have changed since I checked last year.

Right now the best you can do is use ECB.Concurrent to speed up most ECB usage.

mint iron
#

looks like in preview27 there's an overload for RemoveComponent that takes a ComponentType but none for Add, only T

dull copper
#

Burst got few updates today:```

Changelog

[1.0.0-preview.8] - 2019-03-28

  • Fix for iOS symbol names growing too long, reduced footprint of function names via pretty printer and a hash

[1.0.0-preview.7] - 2019-03-28

  • Burst will now only generate debug information for AOT when targeting a Development Build.
  • Added support for locating the build tools (standalone) for generating AOT builds on windows, without having to install Visual Studio complete
  • Fix Log Timings was incorrectly being passed along to AOT builds, causing them to fail.
  • Fix editor crash if burst aborted compilation half way through (because editor was being closed)
  • Fix issue with job compilation that could be disabled when using the burst inspector
  • Fix issue with spaces in certain paths (e.g. ANDROID_NDK_ROOT) when building for AOT
  • Restore behavior of compiling ios projects from windows with burst, (burst does not support cross compiling for ios) - we still generate a valid output project, but with no burst code.
  • Add support for Android embedded NDK.
  • Fix issue where certain control flow involving object construction would crash the compiler in release mode```
chrome pawn
#

could someone explain why the burst compiler generates this error when trying to access a static readonly int[,]? error: Unexpected error while processing function MarchingTetrahedra.MarchTetrahedraJob.Execute(MarchingTetrahedra.MarchTetrahedraJob* this, int jobIndex). Reason: Object reference not set to an instance of an object

#

something to do with multidimensional arrays?

#
            {0, 0, 0},{1, 0, 0},{1, 1, 0},{0, 1, 0},
            {0, 0, 1},{1, 0, 1},{1, 1, 1},{0, 1, 1}
    };```
#

ix = cubeIndex3D.x + VertexOffset[i, 0]; is the line that throws the error, I've verified that the null reference it's complaining about is VertexOffset

#

I don't understand how this could ever evaluate as null

#

tried instantiating the class that VertexOffset belongs to before scheduling the job to see if the static constructor wasn't being called or something but it didn't help

#

and it runs fine when not [BurstCompile]'d ofc

#

I'm assuming this made it in already considering I don't seem to have this problem when accessing 1d managed static readonly arrays

untold night
#

I'm going to go on the assumption they only support 1D arrays for static readonly data that can be converted

chrome pawn
#

yeah I started writing this before testing 1D arrays, it does seem to only be an issue with multidimensional arrays atm

untold night
#

you could replace it with a 1d array of int3 from the math package

#

the multi-dim primitive types all have indexers for their components

mint iron
#

int[,] is a managed array no? it cant be used in burst then

untold night
#

they have support for copying static readonly managed arrays of primitives and supported types

it seems to be 1D arrays only however

mint iron
#

huh, interesting

untold night
#

and bye that I mean, if your bursted job accesses a static readonly int[], it will actually be copied into the job itself when the job is compiled.