#⚛️┃physics

1 messages · Page 35 of 1

lapis plaza
#

@tropic hamlet DOTS physics api is different

#

you can swap between Unity Physics and Havok

tropic hamlet
#

i use physx in a light manner, I just need really good spherecast, raycast, convex colliders and rigidbody basically. everything else I code myself fine with the fundamental building blocks above

lapis plaza
#

but PhysX will stay on the gameobject side setup with old components

#

did you watch the keynote for physics?

tropic hamlet
#

yes but I cannot hear, so...

lapis plaza
#

oh right, I forgot

#

well, the blog post is fairly good

tropic hamlet
#

any info you can add is super welcome <3

lapis plaza
#

basically swapping between those two new alternatives is just a switch in script

#

I'd hope someone makes DOTS api compliant PhysX setup too

#

if not by Unity then by nvidia itself as they got the physx 4 plugin thing going on now

tropic hamlet
#

the physics thing cannot be coded with regular c# ?

lapis plaza
#

but in the end, I'm really hoping Unity Physics will be enough for everything on my needs 😄

#

Unity Physics is c# package, you can use it without ECS but it works on ECS

tropic hamlet
#

i would expect that to still be possible since with physics you can close the sim for most things, and only interfere when needed...

lapis plaza
#

I mean, from what I've understood, they want the new DOTS physics setup to work for traditional nonECS projects

#

despite the physics code itself runs on ECS

tropic hamlet
#

porting my game to ECS is viable but I am one man, I cannot afford to extend dev times with unknowns, and I have a strict deadline with Sony in august

#

(for an alpha playable not a final)

lapis plaza
#

well, if you are not really going for ECS, just stick with PhysX

tropic hamlet
#

so i can play a little but it needs to be quite clearly an api not changing too much

lapis plaza
#

Unity Physics will definitely not be ready by summer

tropic hamlet
#

I played hard with ECS when it came out but it changed rapidly and I couldn't afford to keep changing with

#

will havok be ready sooner?

lapis plaza
#

they launch integration on summer

tropic hamlet
#

what advantages are there for using havok over physx?

lapis plaza
#

nobody here knows 😄

#

besides Unity staff

tropic hamlet
#

well classically havok has been deterministic, the only physics engine guaranteed to be actually if you wanted it to be

lapis plaza
#

if the API is more exposed, it can be seen as advantage

#

I saw that Unity Physics samples had all kinds of modification support

tropic hamlet
#

so histortically I can see why it's been the stronger mp bet

lapis plaza
#

that looked super fancy

#

as that's what I've been asking for Unity's physx integration for ages now

tropic hamlet
#

i like contact modification.

#

i need that.

lapis plaza
#

oh, if you do MP, then the new package will be nice

#

eventually anyway :p

tropic hamlet
#

i want to just do my char controller before it moves not correct it after. i do correct it after really, really well but it would be all kinds of perfect just to mod the contacts, you know?

lapis plaza
tropic hamlet
#

oh....

#

that's interesting eh

#

has xmas come early for us ? no it hasn't since we wait for summer

lapis plaza
#

I'm super happy

#

HPC# Physics + Granite

#

didn't expect the latter

#

also, I don't really care for Havok itself

#

at least not with current info

#

they've hinted it'll be additional payment

tropic hamlet
#

I'm kind of dissapointed about the whole physics thing because yant is doing all this work and it's being replaced, basically... why is nvidia doing a plugin separately?

lapis plaza
#

but no details how much, so hard to get excited about something you don't know the details about

#

I'd guess they knew about this and wanted to cover the physx availability

tropic hamlet
#

also granite and their patents will help. amplify had to pull theirs because of granite's patents.

#

(don't quote me ;) )

lapis plaza
#

you probably heard Unity acquired them?

tropic hamlet
#

ofc

#

but i'm talking about amplify

lapis plaza
#

I know

#

kinda sucks for amplify

#

at least Unity doesn't have to work around those patents now ;D

tropic hamlet
#

i mean, amplify couldn't go further with theirs anyway as it crossed the patent line and while graphene didn't do the nasty it wasn't worth it

lapis plaza
#

AT and Granite has really similar implementation though

#

so I'm not even surprised

#

I've tried both

#

and they work exactly alike from the surface anyway

tropic hamlet
#

well i have some inside knowledge but i think it's irrelivant now as we get the patent backed toys...

lapis plaza
#

it's like someone just copy/pasted the implementation

#

how the atlases worked etc

tropic hamlet
#

and the company that did it was basically just working as bespoke contractors so any plugins were left to rot

#

AAA was fine with it due to them having priority

#

but plugins kinda were really left behind

#

now its bought by unity we can expect some magic

lapis plaza
#

yeah

#

not expecting anything in short term tho

#

maybe for 2019.3 earliest

#

if even that

tropic hamlet
#

really tho unity just needs the right to use the tech and can easily source staff to move forward quick

#

so the real stumbling block was having them to begin with

#

its all good

#

thing is with this stuff, is... its still kinda really hard to author textures that scale

#

we have done it a lot in the past and the storage, the processing is harsh

lapis plaza
#

authoring 4k maps is fine

#

imagine you have any open world game with high resolution textures

#

VT lets you do more streamlined and naive pipeline

#

no need to fiddle with shaders to optimize the materials, just texture it on substance painter etc and deploy

#

same with scans

#

of course your installation size will be huge

tropic hamlet
#

well I still need terain texture caching and splatting a terrain is a faster workflow than texturing every part uniquely. i get the mip streaming but unity already has it

lapis plaza
tropic hamlet
#

ok

lapis plaza
#

I didn't want to report it as it's not really breaking any forum terms

#

someone just happened to make another thread before the official thread was live

tropic hamlet
#

done

lapis plaza
#

thanks

#

Still working out the details regarding the Havok Physics integration. I'll be following up with info here and in another blog post once we've locked down all the details.

Yes, so we're using the exact same data layout in the Editor which means when you author a bunch of content you're only building it once. For example, if I set up my environment with a bunch of physics components and I am using Unity Physics and then I decide to use Havok Physics, I don't have to redo every object to use a set of Havok components. Similarly, any game code or scripting logic you've written to use Unity Physics will work just the same if you swap in the Havok Physics backend.

Regarding differences, they're both intended to be high-performance physics solutions, they just solve different production needs. Unity Physics' key points are the fact that it's a C# package so you can easily get in there, look at the source code, and modify it to your heart's content. It's also stateless, so instead of using caches, we rely on brute force optimizations to make it more compatible with things like network rollback architecture. Havok Physics is integrated using the Havok engine and uses caching so you're able to squeeze more performance out of complex scenarios and get much more stable simulations for things like stacking, lots of rigid bodies, etc. Hopefully, that helps explain it a bit more but let me know if you'd like more details!
#

I do hope they fix the stacking on Unity Physics regardless 😄

tropic hamlet
#

I have decent stacking

#

but you have to still watch your masses

#

don't stack anything 2x heavier on anything else etc

#

preferbly the lower ones should have higher masses

#

classic physx nonsense :D

lapis plaza
#

oh I meant for the new package

tropic hamlet
#

well hopefully answers will come

tropic hamlet
#

for me I do want a LOT of simple physics objects bouncing around like debris etc

lapis plaza
#

yeah, I'm not in a hurry for that 😄

tropic hamlet
#

er ... that doesn't seem timestepped and interpolated at all

lapis plaza
#

yeah we covered that earlier

tropic hamlet
#

seems like its tied to framerate

lapis plaza
#

yes

#

it's a bug

tropic hamlet
#

lol.

lapis plaza
#

they run it at each update with fixedDeltaTime

tropic hamlet
#

I was just frowning then!

#

well would need substepping

lapis plaza
#

it's probably because they recently moved the ECS simulation group from fixedupdate to update

tropic hamlet
#

unless it's purely visual one cannot just run it at delta time

lapis plaza
#

if you scroll back few pages here, you'll see my rants about relying on Unity side code for fixed timesteps

#

I really really don't like it

tropic hamlet
#

I see well if we can choose when each world is stepped it should be fine i think

lapis plaza
#

but one can do their own stepping of course

tropic hamlet
#

i do prefer to run my physics in a fixed loop so my characters and everything run the same (mostly) regardless of hardware

lapis plaza
#

oh, I do like fixed timesteps for physics

tropic hamlet
#

I even have my combat logic in the same fixed update loop

#

because I like the reliability regardless of framerate for that

lapis plaza
#

I meant that I don't like that they run the ECS physics stepping code on closed source Unity side

#

as they could just do it on ECS fully

tropic hamlet
#

(anims have colliders and thus need to be stepped though at specific resolution like streetfigher etc)

lapis plaza
#

now things rely on many things: Unity Physics rely on Entities package for simulation groups I think

#

and entities relies on Unity's internal code for fixed timesteps

#

they are pointless dependencies if you do pure ECS

#

well, not the entities one but the engine side thing

tropic hamlet
#

what portion of unity's own hpc# physics are engineered by havok?

#

I ask so I can be reassured there's a pedigree behind it at least.

lapis plaza
#

no idea, they haven't really been clear on public statements on that

#

in the keynote it sounded like Havok implemented the whole thing

tropic hamlet
#

if it's just unity's own stuff, then I predict a way longer path to stability

lapis plaza
#

and in blog post it sounded like it was purely Unity's internal thing

#

I'm fairly certain that the truth is somewhere in the middle

#

and the foundation seems really solid

tropic hamlet
#

yeah I think we'll be waiting a while. whenever Unity's rolled it's own alternative to something you can get off the shelf, it's ALWAYS been one guy or two guys and it's not given the attention it needs

"it's open source" can also mean "we've only got one guy on it"

lapis plaza
#

so even if Havok is no longer involved, it's not really a huge issue

tropic hamlet
#

so open source doesn't mean shit tbh

#

not without backup

#

else you might as well invest too much work of your own in it

#

I'm not knocking unity, just saying... it's not the first time we've been shown promising things then had to wait forever then seen it depreciated in the end.

lapis plaza
#

what is REALLY cool about Unity Physics at this state is that it's really human readable and super focused thing, it implements the bare minimum

tropic hamlet
#

yeah and my game needs more than the bare minimum

lapis plaza
#

so if anyone is interested on how physics engines work, this is a great resource

tropic hamlet
#

I'm interested in shipping my game > all

lapis plaza
#

well, they do all the basic collider types, queries, narrow+broadphase, joints

tropic hamlet
#

I'm up fo havok if the price is right but haven't any interest in the unity physics UNLESS.... unless it's the fastest option in which case I will look super closely at it

lapis plaza
#

what I mean, they cover all the basics already

maiden grove
#

Havok licenses are in the O($100k) per game range - I do wonder how this will wind up being licensed

tropic hamlet
#

havok to be fair is usually licensed by AAA and comes with bespoke havok staff support

maiden grove
#

do I get to customize the staff?

tropic hamlet
#

the unity one for unwashed masses like us should probably be absorbed as pro license / affordable service

lapis plaza
#

I'm still so much against the pro deal

#

it's what I really disliked about Unity on Unity 4

#

physics isn't a service either

#

it's a core game engine feature

tropic hamlet
#

I'm actually a little unhappy with all this:

  1. unity's own physics doesn't work with gameobjects so i'd need to code my game character in dots

  2. physx seems to be heading to dll land and moved out of native unity... it will only have updates, so no guarantees on future console support etc, no guarantees anywhere

  3. havok is licensed and unity doesn't have a plan to make it's own hpc# physics as performant. likely they could, but unity staff did mention you would use havok for bigger higher performing scenarios

so this basically is a trio of not so hot scenarios

lapis plaza
#

yeah, I'm least excited about Havok option

tropic hamlet
#

the best option here, is obviously going to be using havok. this is logical from unity's partnership and the implication it would outperform the other options.

lapis plaza
#

because if that's the best option, it means the options regular users get will be way worse

#

and there will not be need to optimize the built-in package further

#

as AAA can just use Havok

tropic hamlet
#

thats precisely what is happening so I will move to havok if I can.

lapis plaza
#

I'm fairly certain that havok being there is for AAA

tropic hamlet
#

if I cannot afford it then I will have to run the physx dll guantlet in the long term

lapis plaza
#

yeah, will see how this plays out

tropic hamlet
#

I do not believe that the hpc# physics will be anything except a default option

#

I think we're 100% seeing the start of the end for physx, agreed?

#

it could take a long time

#

but i think as it'll go external (no reason why it wouldn't) then we'll have to just accept that

#

as expected

lapis plaza
#

we'll see

tropic hamlet
#

i agree with your pro statement but you aren't doing a correct comparison

#

before with indie/free you couldn't add the missing features without pro. pro was the only option

#

now u can though, take a service without taking pro

#

so it doesn't block anyone like the old days, even so I agree it would screw up my team

#

:D

lapis plaza
#

well

tropic hamlet
#

So it looks like realistically we use hpc# or physx, and both are in uncomfortable places.... looks like we better start forking gitting on with it ;)

lapis plaza
#

yeah

tropic hamlet
#

i guess we best get our hands dirty with open source

#

i can't see the other secure affordable option

lapis plaza
#

I'm fine with that

tropic hamlet
#

and we both know that's a long road

pearl warren
#

I'm affraid this is really really bad

lapis plaza
#

having Unity Physics sources available now is a blessing

pearl warren
#

Unity Physics will not be as good as either option

lapis plaza
#

this saves me a ton of time

pearl warren
#

and havoc will be big dollars

tropic hamlet
#

it means physx will become external closed box and not further developed, this is logical

lapis plaza
#

well, PhysX is open source, so is Bullet, so is Newton Dynamics, ODE etc

#

you can port things you need to Unity thing

#

if you have time and understanding 😄

tropic hamlet
#

well physx will not be a package i dont think

#

it's a dll

lapis plaza
#

physx is not really that great codebase to port tho

#

it's barely human readable

#

I mean, it's efficient, it's just not really nice to work with

tropic hamlet
#

thing is physx is actually battle tested and it does work really well

#

hpc# is one man's go at stuff

#

one guy

#

hardly billions of dollars of research

lapis plaza
#

PhysX 4 is not battle tested tho

tropic hamlet
#

it doesn't need to be

lapis plaza
#

it does

tropic hamlet
#

4 is largely 3

#

3.5x

lapis plaza
#

you clearly didn't use PhysX 3.4 when it was new

#

it was a nightmare

#

and yet it was improvement on 3.3

#

not a new thing

tropic hamlet
#

i did actually

#

I've been shipping games with physx since 2009

lapis plaza
#

I was the guinea pig for that on UE4, they got it integrated before it was publicly released

#

and physx 4.0 isn't even released yet, it's still RC

tropic hamlet
#

and mostly on mobiles or contract

#

so i know how to get them to be reasonable perf too

#

(which makes them less stable...)

lapis plaza
#

just saying it's probably mostly fine but you will hit early adopter bugs without any doubt on it

#

it just is bound to happen

tropic hamlet
#

need a fair bit of correction code and i think that... with physx moving to external it means that i lose all that engineering vs something totally brand new and barebones that requires me to code in ECS

#

I'm not actually that upset

#

the only problem is my character code (not controller, which is simple) is really quite heavily monobehaviour

lapis plaza
#

if nvidia ships the physx plugin sources, like even the native dll side

#

then I can see that as on option

#

as it does bring more to the table as the built-in Unity physx integration then

tropic hamlet
#

its a proper full-featured thing, wall jumping, combat, ai, dodging, etc, everything for a real complete character (and this is not the physics) but i would have to port to ecs or be given whatever physx has

#

I get we can bridge it but... why would i bridge it

#

unity's stated we can swap the backend

lapis plaza
#

oh man

#

it's flooded with separate threads for the same thing now

#

and the official thread isn't even in that forum section

tropic hamlet
#

what about cloth?

#

I guess physx and havok will be in the lead feature wise for a long time

#

the hpc# one is deterministic

#

so that's a big deal

#

@olento joe has replied

#

it does see promising that Unity maybe taking their own physics engine seriously

#

So far I saw an exploding deltatime demo so my concerns were a bit...

#

+no clotho or spring stuff?

#

( dont need )

lapis plaza
#

yeah, I noticed 😃

#

I tried to get a straight answer, wasn't dissappointed

tropic hamlet
#

I'm happy he is on the ball (bad pun?)

jagged shale
#

we already confirmed that

#

but I guess Hippo didn't believe us 😛

tropic hamlet
#

never believe this hive of scum and villiany

#

I've learned that wishes aren't reality

lapis plaza
#

we got Havok guy on the physics thread now

tropic hamlet
#

huge lack of information and docs atm

lapis plaza
#

they actually have some docs on the package

#

talking of which, what tools there are for windows to read markdown documents?

#

would be nice to get proper formatting and navigation instead of just opening the files one by one in text editor

tropic hamlet
#

for md, I went through that looking for a markdown processor but only found crappy ones

#

in the past

lapis plaza
#

yeah, I tried to find some myself before but didn't find anything good either

#

So far we have used Box and Sphere for the collision types. Currently six distinct shapes are supported (and then *compound*, so multiple of these in one body, to allow more complex arrangements). Here they are in rough order of how expensive they are to use, from fastest to slowest:

* **Sphere** : a point with radius, so the simplest form of collision shape.
* **Capsule** : a line with radius, so a little bit more expensive than a sphere.
* **Plane** : a plane bounded four sides, so like a quad in graphics, but all 4 corner vertices are coplanar.
* **Box** : an oriented box. 
* **Cylinder** : currently this is actually a convex hull so will have the same cost as a similar complexity hull, so see next.
* **Convex Hull** : a 'convex hull' is as if you wrapped the object in paper, all the holes and concave parts will not be represented, just the outer most features. Collision detection algorithms for something you know is convex is much faster than concave.```
#

so they might make proper cylinder primitive

#

* **Mesh** : a arbitrary triangle soup. The most expensive and is assumed to be concave. All the convex shapes above all can collide with each other, and they can collide with Mesh, but Mesh can't collide with other Mesh in Unity Physics. So best used for static objects, but if you know your dynamic object Mesh will not need to collide with other Mesh it can be dynamic, but make sure to setup your collision filtering appropriately.

#

it's nice that they allow that latter case

#

in Unity 5+ they just hardcoded non-convex mesh collisions to static only

tropic hamlet
#

well unity's dots physics will basically use the same formulas as havok

#

so it will just lack some of the more hardcore things havok can achieve

jagged shale
#

I wonder why they chose Havok over PhysX

#

is it because of the networking aspect?

tropic hamlet
#

yeah likely

#

but also havok had a lot of math and tech that's also under patents

#

this industry is really big on having the right to use a technique

#

so it's probably partially related

#

only guessing ofc

#

remember havok is only deterministic across the same CPU while dots physics aims to be deterministic no matter what CPU you are using. So unity's will end up better than havok for networking.

#

(once burst updates to it)

lapis plaza
#

or Unity just had better connections to microsoft than nvidia

tropic hamlet
#

nah

#

unity knows EVERYONE

#

physx offers nothing unity hasn't already got

lapis plaza
#

it doesn't mean they didn't ask nvidia

#

we wouldn't know

tropic hamlet
#

but nvidia hasn't got anything they need or can use

#

unity already clearly said that havok is like dots internally

#

so the code techniques aligned

#

the hpc# IS using havok

#

same formulas and techniques, and it's dots friendly...

lapis plaza
#

well, it's not Havok still

#

and obviously they've adopted things to unity dots thing

tropic hamlet
#

physx would need a complete rewrite and a rethink, while havok already did the thinking ecs style

royal hearth
#

I think it's fault of Ugo Foscolo, but idk...

tropic hamlet
#

havok already works like unity dots does

lapis plaza
#

I dunno about that

tropic hamlet
#

so it was a very good plan to strike a deal

lapis plaza
#

it's all about how you do the integration

tropic hamlet
#

unity said this olento.

#

its what unity said not me

lapis plaza
#

you can make physx work for the dots api for most parts

#

and since havok was involved in development, of course the dots physics api favors havok's design now

#

physx has stateless solvers too despite what Joe wrote

#

it's just most don't use the immediate mode on it

#

it doesn't have any scene or cache

tropic hamlet
#

so it would be slower

lapis plaza
#

sure

#

all I'm saying, that it could work for the DOTS api

#

they clearly made some deal with Havok, hence the integration

tropic hamlet
#

unity said that you could just swap between physx/dots/havok and it would just work. but this implies they will make the new api work the same as physx for monobehaviour platform. probably using abstracted wrapper

#

i think physx was a mistake in that forum post and they meant only dots or havok being interchangable

#

having no cache does mean it's deterministic, right?

#

I mean stateless lets you go back and (forth a bit)

#

but the havok one seems to have a cache somehow

#

(there's always a catch)

lapis plaza
#

I think you've misinterpreted the physx part

#

physx will stay for gameobject physics

#

unity physics and havok will be swappable with minimal work

tropic hamlet
#

yeah definately makes sense like that

#

i'm very concerned though that there is already a pain point:

go with dots physics for determinism with any cpu but slower
go with havok for determinism with same cpu but faster

#

Unity is understandably keen to avoid benchmark discussions

lapis plaza
#

it's not necessarily even slower with unity physics

#

it would still depend on the gameplay

tropic hamlet
#

Well the blog literally states it would be unfair on unity to compare atm = it's slower

lapis plaza
#

comparing any wip thing is unfair IMO 😄

tropic hamlet
#

"if you have a team that has experience with Havok Physics or your use-cases are pushing on complex and high-fidelity physics requirements, the caching system of Havok Physics can offer better stability and performance," according to Bowell.

#

both better stability and performance.

lapis plaza
#

it's marketing speech

tropic hamlet
#

they also dodged my request in forum posts

#

they really dont want comparisons

lapis plaza
#

you can't really put clear answer on the perf now vs future perf without doing extensive testing

maiden grove
#

premature is probably a better word than "unfair" (sounds defensive)

lapis plaza
#

yeah

#

exactly

tropic hamlet
#

unfair = it's slower, not really expected to get much faster
premature = we plan faster

lapis plaza
#

and even if you do extensive testing, it really matters who prepares the tests

tropic hamlet
#

well lets try the classic boxes test :P

lapis plaza
#

if you've followed the industry discussion around physics engines, things got bit heated between physx and bullet devs when physx dev made their own benchmarking tool 😄

tropic hamlet
#

hehe yes

lapis plaza
#

he didn't really setup it like bullet should have been setup for the test

tropic hamlet
#

becuse of the "differences" but in reality all projects are slower on bullet.

lapis plaza
#

and despite asking the source code, I don't think bullet dev got it so he could have fixed it

tropic hamlet
#

it bullshit, mostly stuff is gonna be faster or slower and you do see immediate gains or not

lapis plaza
#

yeah, I don't really doubt that, but the test wasn't really fair either

tropic hamlet
#

when I used tokamak and ODE, I could see tokamak was way faster, right from the outset, but ODE was more capable

#

here, we have same capability

#

so i expect pretty much a win or not

#

seems this cache thing might be a big deal

lapis plaza
#

if it's a big deal, people will make cache system for the Unity Physics

#

just wish they'd put it on github

tropic hamlet
#

unity claims a cache for it would be bad for rollback

lapis plaza
#

it would encourage custom forks

#

yeah, that's kinda the reason they don't have it

#

but not all games need the rollback

tropic hamlet
#

quite true

#

I'm just wondering what kind of difference it would make, and why unity would avoid adding it

jagged shale
#

avoid adding what

tropic hamlet
#

yeah I looked on github and didn't find dots physics

#

(@ol)

#

@jagged shale avoiding adding a cache for their stateless physics engine

lapis plaza
#

heh

#

this workaround

#

Hmm, I know we've turned on vsync in the project Quality settings as a quick workaround

#

for the too fast physics

tropic hamlet
#

loooooooool

#

oh dear, some red faces there!

jagged shale
#

if it had a cache, it wouldn't be stateless 😛

tropic hamlet
#

havok is stateless + cache

#

probably like you can have a cake and eat it

jagged shale
#

cache is separate though

tropic hamlet
#

yep and unity don't plan on adding a separate cache

jagged shale
#

I mean there's nothing to prevent you from doing your own caching

#

probably best anyway

lapis plaza
#

I'm pretty certain that the cache is what breaks the rollback determinism on physx

jagged shale
#

you can make sure it's done how you want

lapis plaza
#

on the same computer that is

tropic hamlet
#

nothing preventing me writing my own game engine but i do need to draw the line somewhere....

jagged shale
#

lol

lapis plaza
#

well, don't worry about things you don't necessarily need

#

if you don't do huge worlds or mass simulations, almost any physics engine will do

tropic hamlet
#

turns his nose up

#

only the best for my shovelware

jagged shale
#

it's not about needing it, it's about saying you have it 😛

#

"our game has cached determinism (but shhhh we dont' use it)

tropic hamlet
#

it's like doing damage in games, its always more if you look good doing it

jagged shale
#

yes, need to do fancy gun spins and backflips

tropic hamlet
#

and have a completely different gender with a really nice butt or something... will sell more than cache will :P

lapis plaza
tropic hamlet
#

see the one on the side?

#

he said "fk this, i'm gone"

#

and jumped

tropic hamlet
#

"Also, performance seems suspicious (stack of 300 cubes brings my framerate to its knees, even when not using FixedUpdate), but I'll blame the early experimental status of the package for that"

#

seems super early then :P

tropic hamlet
#

I like how in the docs it's referred to as damping (which is correct) and not drag...

jagged shale
#

what is

tropic hamlet
#

rigidbody drag / damping

#

it's really just a damping formula over time, while drag would need air resistence and all that jazz

#

or water etc, you know

jagged shale
#

true

odd bough
#

Lool @lapis plaza the funny thing is, I noticed the movement after spawning cubes and noticing the pile was.... alive somehow 😂

#

It is amazing how stable the objects are when they meet a static object

#

Then on the flipside how volatile they are when just barely touching a dynamic body

jagged shale
#

yeah it looks to be a bug

#

shouldn't behave that way

odd bough
#

I'd hope not

#

I had an amazing idea of making an ECS hour glass, but.... that needs stability

mild oriole
#

hello

tropic hamlet
#

Honestly, if it doesn't perform the same as physx does throughout I'm not sure there is enough reason to use it - period.

#

Since mostly, I use physx cosmetically, I expect the sim to be different on different machines, so I really only need to sync the player stuff

#

i could use both shugs ?

hollow echo
#

I imagine we'll see systems released on github by anyone with an interest in it

#

and that'll be cool

mild oriole
#

hey?

hollow echo
#

yes people can read your messages

mild oriole
#

yay!

tropic hamlet
#

I can't

tropic hamlet
#

huh

#

I probably have zero choice but to use Unity's if I have any interest in origin shifting, and I kind of do because why not :P

viral solstice
#

I am mostly using physics for cosmetic (unless you count general collision-detection), but if it were deterministic I would totally open that up to using it left, right and center and everywhere inbetween. And then network it to many players too.

So I hope they get the new Unity Physics performing well soon-ish, because that's nifty.

lapis plaza
#

    The Havok Physics variant will certainly support stable stacking out of the box, however....
    A major part of the design philosophy of Unity Physics is to provide a simple core, while ensuring open access to the data following through the system. So while at present the stateless nature of the Unity Physics preview doesn't support the likes of stable stacking, welding or deactivation, there should be nothing in the way of users adding and sharing the likes of contact caching themselves.
#

well, that's alarming

#

having stable dynamic vs dynamic contacts is an essential thing

hollow echo
#

having one item on top of another is a pretty common thing!?

pearl warren
#

Please

#

Physics engines don't need dynamic interactions

#

🙄

lapis plaza
#

I wonder if the original plan was to make Unity Physics a multiplayer solution only and then hope people who need more would just agree to pay to MS for Havok

pearl warren
#

bring out your notebook

lapis plaza
#

there's really no good reason why Unity Physics couldn't have caching as option if full Havok can with the same API

pearl warren
#

20k per component licence 😃

#

probably the deal they made so they can use havoc stuff for free Olento

lapis plaza
#

the stateless thing has been mentioned quite few times but full havok isn't stateless and they can use the same API

#

so, that does bring up a lot of questions

#

it does sound like there's some bigger plan in works that they don't want to tell us about

#

I wouldn't be surprised if the full Havok integration will be only there for AAA customers

#

as Unity clearly tries to go into that market segment

pearl warren
#

yep

#

feels like that to me too

lapis plaza
#

as long as stacking is not happening, we can forget any kind of destruction using this setup

#

as that will result in a lot of dynamic objects on top of other dynamic objects

#

and in addition, I don't really see why they couldn't handle like some time limited buffer for some states, it wouldn't prevent rollbacks or ruin determinism

pearl warren
#

physics in our game for a lot of cases is destroying something

#

and its a bunch of parts for visuals only client side

#

without collision on players

#

that will be a mess/

lapis plaza
#

technically, we could still deal destruction on different physics engine as it's usually only visual

#

but it's still annoying to have multiple physics implementations

pearl warren
#

as example in our game

lapis plaza
#

yeah, that would fail on this new package 😃

pearl warren
#

and mind you this is a very basic thing a lot of people are doing.

lapis plaza
#

yeah

#

also people don't care for determinism on such thing

#

would be nice to have some option "keep cache for these objects only"

#

altho I dunno if that's really feasible to implement

#

I do get where they are going with the stateless thing, they are trying to solve one hard problem in networking with it

#

that's really cool thing about it

#

anyway, it does seem like they just threw it out looking at the response, Unity has taken community feedback into account on DOTS stuff before too, so there's always hope they'll listen this time around as well 😃

celest widget
#

i care for determinism :p

lapis plaza
#

on destruction?

#

even if it's only your client that sees it?

#

technically the determinism should still be there for first trigger, it's the rewind and resimulation that gets messed up if you can't reset the cache to the earlier state

celest widget
#

for anything that has even the slightest impact on the simulation

lapis plaza
#

for multiplayer, it makes sense

#

also for physics puzzle games

#

after that, I don't really see use cases that would require it

tropic hamlet
#

unity's physics are for not physics basically

#

basically perfect for games which don't have regular physics but need fantastic query performance

#

like colliders, character controllers, etc

#

don't expect it for simulation

#

it does come unde physics of course but I'm just saying for intensive sims its not the thing

#

if their ragdoll demo is unity physics then I would be brave enough to say unity physics are very usable

#

rememeber it's deterministic

#

that's a big plus

pearl warren
#

basically it's only build for DOTS style playback and rewinding network state of players?

tropic hamlet
#

no it's just super light exactly what they're saying. it's the sort of thing I use physx for

#

I use physx mostly for strong queries, colliders etc, and handle the movement myself

#

it can do great ragdools, char controllers etc, anything

#

it does seem though they've deliberately avoided implementing anything that would bring it near havok

#

in any case we have physx still

jagged shale
#

but PhysX isn't in ECS

pearl warren
#

It seems to me just that Every time Unity is promising amazing things in presentations and when they actually deliver it, it can only be described as "meh" at best.

jagged shale
#

i don't agree with the guy that 'settling is easy'

#

do you know how long it took Havok to get it right lol

#

wasn't until Havok 4 or 5

#

so i guess what they are really saying is "just use Havok"

#

since it seems it will be the only really viable physics

#

somehow i don't think it will be free though

pearl warren
#

They stay very silent about that

#

I suppose it's going to be expensive

#

Very

#

Expensive

#

I noticed that Google was also pushing Havoc in the presentation

#

Something is telling me that Havoc is about to go bankrupt and they made big deals around the industry to stay relevant

#

since we have Physx going open source

#

Bullet is there for a while and many other options

#

The chance that a game developer buys a Havoc licence is turning to be 0 lately

jagged shale
#

well the only reason they haven't is that Microsoft bought them

pearl warren
#

true

jagged shale
#

Havok has been passed around so many times

pearl warren
#

but you cannot stay unprofitable department forever

maiden grove
#

the business unit still needs to turn a profit

#

yeah

jagged shale
#

when people keep buying and selling a company you know it's a dog

pearl warren
#

Havoc was very relevant

#

but still today?

maiden grove
#

Havok is one of those pieces of middleware that everyone wants and needs but no one wants to pay what it costs to maintain

tropic hamlet
#

nice soundbite but really, it's fine

#

it wouldn't be industry leader otherwise

#

I mean, AAA isn't stupid.

jagged shale
#

it used to be the only game in town

tropic hamlet
#

OLD havok was a chore to work with but they have polished in the last 20 years

jagged shale
#

now companies use it because they already own it

#

not because it's the best

#

don't discount the profit motive

#

why spend money on a new solution when you already own something else hehe

#

so yeah lot of AAAs continue to use it because ti's legacy within their company

#

not because it's the best

tropic hamlet
#

so use physx since it's legacy and works for you

jagged shale
#

😛

#

if it was in ECS i would!

tropic hamlet
#

you realise when games earn billions and cost 200m to make that the license cost of havok is the least of anyone's problems

#

its lint to them

jagged shale
#

it's about productivity

#

their people already know it

#

their tool chain is already set up to use it

#

their pool of assets and animations were already made for it

#

it's more than just 'license fee'

tropic hamlet
#

yes and if something improves productivty, AAA do all that on the side risk free. It's why AAA all have huge unity licenses but don't necessarily use them for production

jagged shale
#

changing physics engines rarely increases productivity

#

quite the opposite heh

#

since it touches just about everything

tropic hamlet
#

i'm betting havok is just more stable under load. Physx has always been fast but unstable

jagged shale
#

look at Bethesda

tropic hamlet
#

physx's job is also to do whatever nvidia says is best for their gpus

jagged shale
#

there's a reason they stil use the old, moldy Gamebryo engine with Havok

#

for 15 years now

#

because changing = pain

tropic hamlet
#

so havok has never changed since?

#

never improved?

#

sat still inside microsoft

jagged shale
#

of course it's changed

tropic hamlet
#

useless piece of shit havok! we hate you which is why we use you in all sony first party games

jagged shale
#

but not to the extent rewriting all your tools for a new engine would entail

#

not to mention invalidating your asset library

#

also you assume every studio jumps on every upgrade

#

(spoiler: they don't)

tropic hamlet
#

but the thing is here is that Sony does rewrite for first party games, it has to squeeze the most bang for buck because first party games are responsible for selling the console

jagged shale
#

same way people will stick with Unity 5.6

#

when we have 2019 out

#

once their game is on a version, they aren't changing

tropic hamlet
#

then we have a brand new engine by ubisoft for nintendo (the mario/rabbids crossover) which for switch, used havok. That's telling

#

I'm sure it's going to be on par with physx and all that but I doubt, strongly doubt its bad

jagged shale
#

it's what their people like

#

people really hate change

tropic hamlet
#

true but that doesn't mean it's not better

jagged shale
#

doesn't mean it is either ;p

tropic hamlet
#

I do think unity's builtin physics will not come close to physx though for non networked scenarios

#

rigidbodies etc

#

sim stuff

#

they said in docs for unity physics, they expect the perf to be same as leading physics engines for queries but not for sim

jagged shale
#

physics will always be a hard problem to solve

tropic hamlet
#

so your raycasts, shape casts, etc all should be top as expected... but not the simulation or stacking

#

physx probably remains fastest if you want it for visuals

#

i'm used to physx's quirks

jagged shale
#

funny enough the tools I've worked with for the last 10 years have been havok based

#

so I know it's quirks

tropic hamlet
#

physx is super temporal really

jagged shale
#

i just want something in ECS that works reasonably well

#

and doesn't cost an arm and a leg

tropic hamlet
#

we dont have to rush

jagged shale
#

and so far neither option meets those criteria

#

now they could surprise me and say havok is free

#

but it's Microsoft

#

so I don't se that happening

#

but stranger things have happened i guess

tropic hamlet
#

unity's havok integration is likely to be as pain free as physx, all nice ui etc

#

fancy slider bar

jagged shale
#

yes I have all the Havok SDKs from when Intel used to offer them for free 😛

#

(which Microsoft put a swift end to)

#

I've lived long enough to know a good thing is temporary so archived them all heh

#

so I've got a lot of experience with how it works

#

honestly their tools were poor

#

coder art

#

but they got the job done

#

i wonder how much M$ has cleaned them up

tropic hamlet
#

i dont know but i do know I have something I can use today: physx

jagged shale
#

but not in ECS 😛

tropic hamlet
#

very true

#

but I dont yet see a compelling reason to use ECS when:

  • unity will still render my world with ECS even if I don't use it
  • unity will still accelerate all their systems with ECS even if I don't use it

... so I might not use it :)

maiden grove
#

Whats the rationale for providing Unity Physics (and not just Physx OR Havok) to begin with?

#

like why 3 lanes?

tropic hamlet
#

because ceebee hogs the middle lane, I get caught in the bus lane and those in the fast lane do not see the cliff

maiden grove
#

haha

#

The type of game to lean into DOTS and want a deterministic high perf physics engine is likely to be the game of game to pay the licensing fee

jagged shale
#

i think they got tired of people asking for deterministic physics for networking

#

and it's true Havok is probably one of the few players who has that

#

as in, the ability to rewind for syncing clients

#

and by tying that to ECS they can push people to use ECS

maiden grove
#

I guess Unity Physics is a wrapper and a hedge against Havok? Like eventually they see themselves replacing some of those bits?

jagged shale
#

it's the weak alternative so people can't say they have no alternatives lol

maiden grove
#

yeah

tropic hamlet
#

my hot take on it:

  1. physx cannot be made into ECS, it's just too different for dots

  2. unity looked around for something deterministic with same dots style code, only havok had that

  3. unity's own efforts fell so far short that they quickly realised that all the physics coders they wanted were hired, and all the techniques they wanted were patented

  4. so they struck a deal: they get the core patented algos for the basics from havok for the new Unity Physics (dots physics) and in return, havok gets partner intergration

that's my hot take on it, not what Unity has said happened.

jagged shale
#

i'll even bet that's part of their agreement with Microsoft: "You can't make a competing physics alternative"

tropic hamlet
#

yes correct

#

because the techniques used in unity physics are the same ones as in havok

#

read the docs it even SAYS so

jagged shale
#

well all physics engines mostly use the same techniques

tropic hamlet
#

not patented ones

jagged shale
#

there's only so many ways to skin a cat

tropic hamlet
#

havok has a battery of patents.

jagged shale
#

sure, i know

#

but clearly there are other ways, or bullet and PhysX wouldn't exist

tropic hamlet
#

its just maths in the end

#

sure and physx resists determinism and bullet is dog slow

jagged shale
#

hehe

tropic hamlet
#

if unity want hardcore ecs physics over the network it doesn't make sense to fail for 10 years to follow physx and bullet

jagged shale
#

nobody is perfect 😛

tropic hamlet
#

i hate to say it but imho unity made the right call

jagged shale
#

yes unity isn't in the physics engine business

tropic hamlet
#

you only make what you can't buy

#

i don't believe I need to care about the physics engine in use if unity will wrap it up nice

#

i just care about what i can do

#

i am not even slightly pleased with dots physics performance at the moment

#

so unity will still have to try much harder

#

(don't think because I think unity did the right thing, that I like what they did)

jagged shale
#

finally something we can agree on 😛

tropic hamlet
#

stranger things happen :P

maiden grove
#

i don't believe I need to care about the physics engine in use if unity will wrap it up nice
Unity abstractions never leak, right?

tropic hamlet
#

not sure what you mean

maiden grove
#

just that it'll never been as clean as "just switch out the backend" :p

tropic hamlet
#

you mean have allocations? unity is removing all that over time

maiden grove
tropic hamlet
#

ah I see

maiden grove
#

just snark

tropic hamlet
#

yes yant has been talking about that

#

he's been talking about how the physics engine shouldn't really offer anything it doesn't do itself in the unity front end

#

trigger to trigger stuff is one thing like that

#

i agree with you :D

jagged shale
#

well that's a PhysX problem

#

they USED to support it

tropic hamlet
#

i guess thats telling through, they can switch between dots physics and havok without leaky abstraction but physx will never be part of that party

jagged shale
#

and then removed it

#

it's not like Unity set out from the start to offer something PhysX didn't

tropic hamlet
#

I do think the unity builtin (free) new option needs stronger perf though. hope it's coming.

#

i love that it's open and i can make it my own

#

dont love it not as fast :P

jagged shale
#

well i just care about it being basically functional

tropic hamlet
#

whole point of ECS was "it's earth shatteringly great and bestest of all perf" so why is it not?

jagged shale
#

and if you can't rest one dynamic object on another, it's not functional

#

try having your character stand on a moving platform LOL

#

or anything else basic

tropic hamlet
#

for me its broken for as long as I can't stack 3 cubes. Really the minimum stacking is 3, wouldn't you agree?

#

2 is a fluke

#

3 is... hardcore

jagged shale
#

havok just basically checks for movement for a period you set

#

once that threshold is reached it 'sleeps' the physics on the object

#

(not patentable :P)

tropic hamlet
#

not an acceptable feature.

jagged shale
#

yeah i already saw that

#

and dubbed it 'bullcrap'

tropic hamlet
#

stacking is required, but we don't need to go nuts, just enough to put books on a bookshelf, surely? for common game scenarios

#

my hateful reply at the bottom

#

(it's constructive but hate sounds better)

jagged shale
#

Edy - the builtin integration of PhysX isn't going to disappear any time soon, we will maintain, support and improve it for a while. That said, we still target at shipping PhysX 4.x upgrades once they're ready.

#

wonder how long 'for awhile' is

lapis plaza
#

sounds like they don't know themselves either what is going to happen

jagged shale
#

also the latest here

#

his saying how "wonderful" DOTS physis is aggravated me

maiden grove
#

haha

#

Can I parrot your guys analysis back to you so I can bring it back to my team and sound smart?

1.) Physx - This is for games that are not using ECS and don’t require a deterministic physics simulation. Generally Physx will be faster with simulation than other options
2.) Unity Physics - This is for games that are leveraging ECS and require determinism and rollbacks. Aim here is for queries to be on par with Physx, but no guarantees on simulation speed.
3.) Havok Physics - This is for games that are leveraging ECS and require determinism and rollbacks and performance (as well as the stability and maturity of Havok). Both queries and simulation will likely be on par with Physx.

#

These are the 3 lanes that are going to be available starting 2019+

jagged shale
#

honestly I don't even know that "Unity Physics" supports determinisim and rollbacks.

#

it seems so super basic

maiden grove
#

it says it on the box

jagged shale
#

ok if it says so...

maiden grove
#

😄

#

of these, #2 seems like it may just become "the wrapper" over #3

jagged shale
#

also i read the performance isn't on par with PhysX

#

someone said they tried having 300 boxes moving and it brought editor to a crawl

#

which is BAD peformance

#

but it is basically alpha

#

so hopefully that aspect improves

#

yeah was hippo that linked to that post

#

Also, performance seems suspicious (stack of 300 cubes brings my framerate to its knees, even when not using FixedUpdate), but I'll blame the early experimental status of the package for that

pearl warren
#

I can confirm the bad perf myself

#

hard to compare with build in physx but it looks like 100x times as slow.

tropic hamlet
#

well built in physx in my scenes has 0.5ms or so for a huge pile of cubes

#

(with stable stacking)

#

another bonus dots physics has:

#

free origin shifting since it's stateless

#

its 100% free to just shift

#

whikle there is a huge cost with cached systems

#

with stateless you just move it, like it's being moved anyway per frame, so the movement is free

lapis plaza
#

you could handle the large world support many ways on ECS

#

like, keep the main transforms in doubles but shift them for both rendering and physics solving so those would get to use faster floats

#

unless you really need to solve the physics on the whole world at once

#

but I'm now thinking some open world/universe thing where player is only at the one part of the world at once

#

I'd love to get proper AVX support for doubles on Burst

#

but I doubt it's happening, unless LLVM somehow does that automatically under the hood

#

right now Burst is hardcoded to SSE4 on windows anyway

#

that's also something I'd want Unity to improve with

#

like, detect the clients CPU and pick the extension for it accordingly

#

today we still have people running those ancient phenoms etc that don't have SSE4 even

#

and AVX is still only like 85% of the computers

jagged shale
#

heck many programs are only now adding SSE2

#

since people have stuff older than that

lapis plaza
#

tbh, I don't really care that much for those phenom owners today

#

those cpu's are so old they could barely run games launched today anyway

#

and that's like 4% of the playerbase according to steam stats that don't have SSE4.1

#

AVX is different tho

#

Intel still makes CPUs that don't have AVX support

#

it's kinda stupid thing

#

I mean, most chips have the support

#

but they still do the budget things that don't

jagged shale
#

yeah it's true

#

my processor has all the candy

pearl warren
#

I am out of my topic here but does it sound very stupid to suggest shoulden't a runtime use certain instruction sets dynamically on platform?

lapis plaza
#

UE4's new physics engine got caching 😄

#

I know, lame joke

#

their fracturing stuff = nvidia blast

jagged shale
#

neato

#

but Unreal stuff probably belongs in off-topic 😛

lapis plaza
#

unreal is streaming this live now

#

they have option to pre-bake the simulation but then let dynamic things activate their dynamic sim for the parts they hit

#

it's pretty cool setup

jagged shale
#

yeah sounds like how Blender does dynamics

#

you bake the sim and then can replay it from the cache

lapis plaza
#

yeah, but this lets you interact with the cache

#

it becomes live at that point

#

but yeah, this is so far for demolition, while cool, I'm not that impressed unless they can use this stuff to improve actual physics sim in ue4

#

ue4 hasn't really been great on that front

#

so....

#

everyone is dumping physx? 😄

pearl warren
#

The question is why

lapis plaza
#

it's a good question

blissful shore
#

all game engines will inevitably have their own physics and math libraries

this is inevitable

jagged shale
#

now that PhysX is open source they can steal all it's secrets 😛

#

oh i mean, 'learn from it and make their own'

lapis plaza
#

well, UE already had custom physics engine

#

around the UE2 days

#

but they moved to third party offerings

jagged shale
#

yeah back then it was the wild west

#

there were no 3rd party anything, everyone rolled their own everything

#

middleware was something that came out of maturation of the industry

#

but as things have consolidated, it does make more sense for things to coalesce into monolithic systems once again.

pastel dawn
#

So, I've remade the Open Character Controller script for fun (https://github.com/Unity-Technologies/Standard-Assets-Characters/blob/master/Assets/_Standard Assets/Characters/Scripts/Physics/OpenCharacterController.cs) into the new unity physics! (and that can be jobified!).
Right now, there are some issues that are still need to be fixed that are visible on the video (as it was just a fast 1:1 conversion for fun) and I didn't added the sliding on slopes (the one that is called at update)
https://streamable.com/r2ij6

I'll upload the script once I'll clean it a bit^^

lapis plaza
#

@pastel dawn that's cool, did it take long to port?

pastel dawn
#

it almost took the entire day x)

covert vale
#

gosh damn thats awesome

#

like 1000x better then what I can create

lapis plaza
#

now only need to port the new char controller to ECS too 😄

pastel dawn
#

@lapis plaza isn't the OCC the new char controller?

lapis plaza
#

it is

#

I'm talking about the same thing

#

it's not using ECS

pastel dawn
#

but, I've (almost) made it to work with ECS 🤔

#

the character component is a struct component

lapis plaza
#

oh, I thought you did gameobject port

pastel dawn
#

ah no^^

lapis plaza
#

way ahead of my thinking then 😄

pastel dawn
#

well, I'll put the code tomorrow on github if you are interested! (well... I originally planned to put it...)

tropic hamlet
#

it's necessary for gaming world of multiplayer and content streaming that has lightweight origin shifting to exist, and this has never been AAA's problem, but for the masses, you can't use physx and keep costs down. you just can't do it.

#

without determinism it'll cost you too much money

#

and you'll be priced out like you've always been

#

which is why you've never had it before

#

combining physics and networking is mandatory tbh

#

or at least have them play together

#

physx plays with no-one

jagged shale
#

yes this is known

tropic hamlet
#

its good in single player and you can get it to do mp no problem

#

but it will cost you much more money than deterministic ones would

jagged shale
#

but for those of us who wouldn't touch networking with a 20 foot pole, it doesn't matter 😛

tropic hamlet
#

and latency is still not fixed.

#

yeah but

#

this also makes networking a u t o

#

you send inputs

#

done

jagged shale
#

my unity friend whined about having the ability to rewind daiily

tropic hamlet
#

its perfect for unwashed masses like me.

#

i am very much an unwashed mass.

#

nothing prevents me keeping physx around for some effects work

blissful shore
#

downsides:
Stacking doesn't work yet, maybe we get an in-house solution

upsides:
Time travel possible without 1.21 Jigawatts

tropic hamlet
#

heart for ref

#

And regarding stacking, I guess I would find ways around it to make it work, I would have to.

tropic hamlet
#

so

#

looks like there will never be a builtin destruction library in unity so we shoud look at maybe how that would work

#

I mean, it's 100% clear now where Unity's spending the time and it will not be for destruction physics. Not a big deal but the competition has gone there

jagged shale
#

destruction has never been hard

tropic hamlet
#

so part of the main problem is authoring

jagged shale
#

it's just making it performant

tropic hamlet
#

the physics side not an issue

jagged shale
#

no, just the opposite

#

authoring is easy

#

it's the physics that make it laggy to do

tropic hamlet
#

at runtime in unity, say you want to destroy a cube? this is simple, you break it using DCC tools, import the broken version and instantiate it, right?

jagged shale
#

i'll say yes though I don't know what "DCC tools" is

tropic hamlet
#

the instantiation cost can be easily absorbed with ECS - with ecs, creating 100 objects in 1 frame is in fact as close to "free" as you can get.

jagged shale
#

I'd use blender's fracture

blissful shore
#

Maya, blender etc are DCC tools

hollow echo
#

digital content creation

jagged shale
#

I call them Mesh Editors

#

MEs 😛

tropic hamlet
#

I call them Ceebee objections (CBO)

jagged shale
#

but anyway, sure you use your favorite tool

tropic hamlet
#

I am using myself

#

being a tool and all

#

but lets continue

jagged shale
#

but then you instantiate several hundred items, all physical

#

and your game tanks

#

not to mention all the particles etc

tropic hamlet
#

yes so that means really, runtime authoring of the destruction is needed in part at least

#

I mean the storage becomes insane

jagged shale
#

there's systems to do the 'cutting up' at runtime as well

#

I have a pretty good one

#

but it's the same thing

tropic hamlet
#

otherwise i guess you will always split the cube into 100 pieces even though only half was broken off.

jagged shale
#

now you're doing that work AND the physics at runtime

#

so really it's worse

#

there's a really aweome talk by Ubisoft

tropic hamlet
#

we've got destruction in our game, but it's really primitive, for example an urn will use the same broken bits as anything similar to it, the broken bits are more generic than it seems. that was my solution at least, so no bespoke creation or partial destruction: it's either broken bits or it's not.

jagged shale
#

about their procedural destruction system for Rainbow 6 Siege

#

and they have all the same issues, but They literally did something kind of like ECS

#

also they make debris vanish very fast

#

kind of cartoony

tropic hamlet
#

I would probably let particles do most of the job

jagged shale
#

here it is

#

it's an interesting read

#

they customize the physics to make their style of destruction more robust

#

but this here is the key thing about debris

#

they do not just cut things up

tropic hamlet
#

wtf

jagged shale
#

they make replacement chaff

#

and just throw it around

tropic hamlet
#

I do that too! i though it was just me being a primitive twit

jagged shale
#

and it disappears fairly quickly

#

nah it's really the best thing to do

tropic hamlet
#

i guess one needs to be a primitive twit for perf

jagged shale
#

using mesh particle systems is ideal for this

tropic hamlet
#

although the authoring here is still done art side, no special tooling,. i just find the nearest matching debris and use it

#

so partial destruction has same cost as full unfortunately in my case

#

its fixable with a trick - sorta

#

using static batching

#

because with static batching, you can hide elements of your choice but the rest will still be robustly batched

#

this is one of the reasons why static batching is a mem hog

#

but then doing this, we find it's really a local HLOD

#

too much work for me i think

jagged shale
#

HLOD?

#

(if it's not become apparent, I really hate abbreviations and those lettery things people use instead of whole names)

tropic hamlet
#

hierarchical lod, where the bits are separate close up but swapped for combined lower poly ver

jagged shale
#

Acronym

tropic hamlet
#

HLOD is something everyone is expected to know about because it's a big thing with DOTS based rendering.

Hierarchical Level of Detail is something everyone is expected to know about because it's a big thing with Data Oriented Tech Stack based rendering, and now my hands are tired.

jagged shale
#

oh I know about it, I just don't know the short name

#

HLOD could be literally anything

#

Happy Logs Out Drinking

tropic hamlet
#

a few open world games use it, I noticed it was in the gta 5 breakdown

jagged shale
#

Half-time Longcat Overdosing on Drugs

tropic hamlet
#

it's in the megacity demo project in the toolbar as well

#

under HLOD

#

brb shouting at unity's staff for daring to abbreviate

jagged shale
#

hehe

tropic hamlet
#

nah I get ya

hollow echo
#

these acronyms are all easily googlable though 🤷

jagged shale
#

all LOD is hierarchial.

#

so it's kind of redundant

hollow echo
#

no it's not

jagged shale
#

yes it is

#

check out the LOD component sometime

tropic hamlet
#

I think they mean lots of separate bits become fewer but lower poly bits in this case

jagged shale
#

there's a hierarchy from LOD 0 to LOD 3

#

or however many LOD levels you make

hollow echo
#

that's not used as a hierarchy though

jagged shale
#

and they display one at a time based on distances you set

hollow echo
#

and not what the word hierarchical means

jagged shale
#

if they were flat, they would all display at once

#

so they are Hierarchial

hollow echo
#

sure if you want to be oblivious

jagged shale
#

Look I know you have some kind of problem with me

#

i don't know exactly what, maybe I threaten you

tropic hamlet
#

(fyi I like you ceebee, I have never had a problem with you if you mean me)

jagged shale
#

But the snarky bullshit is getting old

hollow echo
#

what?

jagged shale
#

you hover around everything I say

#

trying to find some tiny thing to harp on

hollow echo
#

we're both on the discord all day man

jagged shale
#

and I really don't appreciate it

tropic hamlet
#

slowly backs out of the room

jagged shale
#

I don't play that game but I can start

tropic hamlet
#

I'll say this tho ceebee, I like you and if my occasional teasing is too much then np I will stop

#

clearly you've got the wrong end of the stick.

hollow echo
#

I've got no beef either O.o

jagged shale
#

hi·er·ar·chy
/ˈhī(ə)ˌrärkē/
noun
noun: hierarchy; plural noun: hierarchies
a system or organization in which people or groups are ranked one above the other according to status or authority.

#

LOD 0 is above LOD 1

#

LOD 1 is above LOD 2

#

it's a Hierarchy

tropic hamlet
#

True yeah I agree, anyway I think in the case of the HLOD I guess they mean an additional hierarchy to that, sort of like an octree of lods?

#

(you are 100% correct ofc)

hollow echo
#

I agree, I'm sorry - I mean to say that a linear hierarchy is already defined in the word LOD, I assumed you were talking about their existence in the Hierarchy

tropic hamlet
#

the hierarchy of classic lod is 3..2..1...0 but here we have 0..1..2.. gone! (and spawn a fused lower poly bigger one)

#

saves draw calls i guess

jagged shale
#

yes I get the new LOD stuff is further branched out

#

but simply from their descriptions

#

I really haven't had time to examine it in depth

tropic hamlet
#

I actually thought it was bad in classic unity to have a lot of lods because each lod in the classic way, meant a different unbatchable object if that makes sense?

#

so 5 lods in an open world for a lot of things would reduce poly count a lot but it would be way higher potential setpass

#

the SRP batcher arnaud did at unity aims to fix all that too!

#

you heard of it?

jagged shale
#

yes i heard about the batcher

#

and I agree, LODs can sometimes be more harm than good

#

I've actually heard the LOD system is not very performant in Unity

tropic hamlet
#

tbh when I heard of it... I thought it was absolute magic, i mean ACTUAL magic... because you no longer care about if one material is different to another...it batches by SHADER instead! mad right?

jagged shale
#

but it's' probably best to use it if you'll get huge triangle count savings

#

but not if it's minor

tropic hamlet
#

true

jagged shale
#

and you should definitely author so every LOD uses the same textures

#

i.e. material so you don't run into issues with having a lot of extra materials

#

sometimes you can't do that

#

but a lot of times you can

tropic hamlet
#

SRP batcher means I suppose, less worry about if the lod needed a different material, so long as its the regular shader

#

is it something working on builtin?

#

i mean could they port it?

#

seems to me it would solve a huge part of buitin's problems and ... why not?

jagged shale
#

i don't know, i have a feeling they won't be doing anything to improve the legacy pipeline

hollow echo
#

I do wonder about the future of it

#

and whether they'll depreciate it entirely

#

at least in the nearish term

#

years not decades 😛

jagged shale
#

it may not be for a few years, but i'm sure once the SRPs are stable, they will

#

i'd love to get a look at Call of Duty's Custom SRP

#

i wonder how different it is from LWRP/HDRP

hollow echo
#

is HLOD in megacity implicitly built into the structure of the prefab hierarchy?

#

Or is there manual setup somewhere

#

Ah there's an HLOD component (monobehaviour...)

jagged shale
#

i'll have to sit down with it and the manual or something because apparently 2019 added some crazy new features i don't even get

#

like 'subscenes'

#

whatever happened to just layering scenes

hollow echo
#

I assume it's an ECS only thing

jagged shale
#

maybe. they seem to be valid scenes

#

you can open them individually

#

but contents is definitely ECS

#

everything inside is still using standard LOD groups

#

but then those LOD groups are grouped as entries in an outer LOD group

hollow echo
#

they're controlled via the HLOD component that forces a certain lod

jagged shale
#

yes and then those are further still in groups that are controlled by the HLOD component

#

it's basically just enabling/disabling large groups of items

#

it's confusing though they gave two different groups the same name lol

#

pretty sure one of those should be Medium or something

#

maybe that's why the popping is so bad...

lapis plaza
#

popping is mainly bad because the small objects get too early out

jagged shale
#

both medium and low are low

#

they didn't make a medium

lapis plaza
#

larger shapes lod properly

jagged shale
#

but i'm surprised they are just using the standard LOD component

#

I've always heard it's horribly bad at performance

#

maybe that's not true

#

because here they are using it thousands of times over

#

real stress test

lapis plaza
#

pretty sure the conversion tool handles those to hybrid renderer

jagged shale
#

well that's what i was wondering

hollow echo
#

0lento do you know much about subscenes?

lapis plaza
#

they are there just for waiting conversion

#

like meshrenderers

jagged shale
#

if ECS had a replacement for those

#

so the converter handles more than just objects

lapis plaza
#

what about subscenes?

jagged shale
#

it converts components too?

lapis plaza
#

certain components, yeah

jagged shale
#

i can at least work with the editor now that it's on my SSD

hollow echo
#

Just anything, are they entirely a tool to enable streaming? I'm unsure why they exist, in a sense a prefab could be utilised in their place now you can nest them. Why do they seem to be ECS only, is whatever benefit they bring just not relevant elsewhere?

#

Is there a resource somewhere that I can't find 😛

jagged shale
#

yes the way they are used here, they just seem to be a fancy prefab

hollow echo
#

there's the whole ECS conversion process - and I've heard it's related to that

lapis plaza
#

they exist because they they also contain serialized entity presentation of that subscene

#

so if you load subscene with ecs, you actually load ecs serialized version

#

and that's fast

jagged shale
#

ah

lapis plaza
#

instead of loading gameobject scene and converting it in place

#

I think MegaCity has additional streaming system that takes advantage of this data

jagged shale
#

was the giant chain in Megacity or a different demo

hollow echo
#

yeah it's on the side of the pagoda

lapis plaza
#

but would need to see this gdc's talks to know exactly what the current setup is

jagged shale
#

ah yeah there it is