#⚛️┃physics
1 messages · Page 35 of 1
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
but PhysX will stay on the gameobject side setup with old components
did you watch the keynote for physics?
yes but I cannot hear, so...
any info you can add is super welcome <3
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
the physics thing cannot be coded with regular c# ?
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
i would expect that to still be possible since with physics you can close the sim for most things, and only interfere when needed...
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
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)
well, if you are not really going for ECS, just stick with PhysX
so i can play a little but it needs to be quite clearly an api not changing too much
Unity Physics will definitely not be ready by summer
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?
they launch integration on summer
what advantages are there for using havok over physx?
well classically havok has been deterministic, the only physics engine guaranteed to be actually if you wanted it to be
if the API is more exposed, it can be seen as advantage
I saw that Unity Physics samples had all kinds of modification support
so histortically I can see why it's been the stronger mp bet
that looked super fancy
as that's what I've been asking for Unity's physx integration for ages now
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?
for the modification samples:
oh....
that's interesting eh
has xmas come early for us ? no it hasn't since we wait for summer
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
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?
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
also granite and their patents will help. amplify had to pull theirs because of granite's patents.
(don't quote me ;) )
you probably heard Unity acquired them?
I know
kinda sucks for amplify
at least Unity doesn't have to work around those patents now ;D
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
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
well i have some inside knowledge but i think it's irrelivant now as we get the patent backed toys...
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
yeah
not expecting anything in short term tho
maybe for 2019.3 earliest
if even that
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
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
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
@tropic hamlet since you are around, could you go close this thread? 😄 https://forum.unity.com/threads/dots-based-physics.646840/#post-4335802
ok
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
done
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 😄
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
oh I meant for the new package
well hopefully answers will come
for me I do want a LOT of simple physics objects bouncing around like debris etc
yeah, I'm not in a hurry for that 😄
er ... that doesn't seem timestepped and interpolated at all
yeah we covered that earlier
seems like its tied to framerate
lol.
they run it at each update with fixedDeltaTime
it's probably because they recently moved the ECS simulation group from fixedupdate to update
unless it's purely visual one cannot just run it at delta time
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
I see well if we can choose when each world is stepped it should be fine i think
but one can do their own stepping of course
i do prefer to run my physics in a fixed loop so my characters and everything run the same (mostly) regardless of hardware
oh, I do like fixed timesteps for physics
I even have my combat logic in the same fixed update loop
because I like the reliability regardless of framerate for that
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
(anims have colliders and thus need to be stepped though at specific resolution like streetfigher etc)
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
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.
no idea, they haven't really been clear on public statements on that
in the keynote it sounded like Havok implemented the whole thing
if it's just unity's own stuff, then I predict a way longer path to stability
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
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"
so even if Havok is no longer involved, it's not really a huge issue
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.
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
yeah and my game needs more than the bare minimum
so if anyone is interested on how physics engines work, this is a great resource
I'm interested in shipping my game > all
well, they do all the basic collider types, queries, narrow+broadphase, joints
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
what I mean, they cover all the basics already
Havok licenses are in the O($100k) per game range - I do wonder how this will wind up being licensed
havok to be fair is usually licensed by AAA and comes with bespoke havok staff support
do I get to customize the staff?
the unity one for unwashed masses like us should probably be absorbed as pro license / affordable service
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
I'm actually a little unhappy with all this:
-
unity's own physics doesn't work with gameobjects so i'd need to code my game character in dots
-
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
-
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
yeah, I'm least excited about Havok option
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.
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
thats precisely what is happening so I will move to havok if I can.
I'm fairly certain that havok being there is for AAA
if I cannot afford it then I will have to run the physx dll guantlet in the long term
yeah, will see how this plays out
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
we'll see
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
well
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 ;)
yeah
i guess we best get our hands dirty with open source
i can't see the other secure affordable option
I'm fine with that
and we both know that's a long road
I'm affraid this is really really bad
having Unity Physics sources available now is a blessing
Unity Physics will not be as good as either option
this saves me a ton of time
and havoc will be big dollars
it means physx will become external closed box and not further developed, this is logical
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 😄
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
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
PhysX 4 is not battle tested tho
it doesn't need to be
it does
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
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
and mostly on mobiles or contract
so i know how to get them to be reasonable perf too
(which makes them less stable...)
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
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
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
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
oh man
it's flooded with separate threads for the same thing now
and the official thread isn't even in that forum section
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 )
never believe this hive of scum and villiany
I've learned that wishes aren't reality
we got Havok guy on the physics thread now
huge lack of information and docs atm
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
for md, I went through that looking for a markdown processor but only found crappy ones
in the past
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
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
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)
or Unity just had better connections to microsoft than nvidia
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...
physx would need a complete rewrite and a rethink, while havok already did the thinking ecs style
I think it's fault of Ugo Foscolo, but idk...
havok already works like unity dots does
I dunno about that
so it was a very good plan to strike a deal
it's all about how you do the integration
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
so it would be slower
sure
all I'm saying, that it could work for the DOTS api
they clearly made some deal with Havok, hence the integration
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)
I think you've misinterpreted the physx part
physx will stay for gameobject physics
unity physics and havok will be swappable with minimal work
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
it's not necessarily even slower with unity physics
it would still depend on the gameplay
Well the blog literally states it would be unfair on unity to compare atm = it's slower
comparing any wip thing is unfair IMO 😄
"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.
it's marketing speech
you can't really put clear answer on the perf now vs future perf without doing extensive testing
premature is probably a better word than "unfair" (sounds defensive)
unfair = it's slower, not really expected to get much faster
premature = we plan faster
and even if you do extensive testing, it really matters who prepares the tests
well lets try the classic boxes test :P
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 😄
hehe yes
he didn't really setup it like bullet should have been setup for the test
becuse of the "differences" but in reality all projects are slower on bullet.
and despite asking the source code, I don't think bullet dev got it so he could have fixed it
it bullshit, mostly stuff is gonna be faster or slower and you do see immediate gains or not
yeah, I don't really doubt that, but the test wasn't really fair either
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
if it's a big deal, people will make cache system for the Unity Physics
just wish they'd put it on github
unity claims a cache for it would be bad for rollback
it would encourage custom forks
yeah, that's kinda the reason they don't have it
but not all games need the rollback
quite true
I'm just wondering what kind of difference it would make, and why unity would avoid adding it
avoid adding what
yeah I looked on github and didn't find dots physics
(@ol)
@jagged shale avoiding adding a cache for their stateless physics engine
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
if it had a cache, it wouldn't be stateless 😛
cache is separate though
yep and unity don't plan on adding a separate cache
I mean there's nothing to prevent you from doing your own caching
probably best anyway
I'm pretty certain that the cache is what breaks the rollback determinism on physx
you can make sure it's done how you want
on the same computer that is
nothing preventing me writing my own game engine but i do need to draw the line somewhere....
lol
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
it's not about needing it, it's about saying you have it 😛
"our game has cached determinism (but shhhh we dont' use it)
it's like doing damage in games, its always more if you look good doing it
yes, need to do fancy gun spins and backflips
and have a completely different gender with a really nice butt or something... will sell more than cache will :P
this looks kinda fancy https://forum.unity.com/attachments/bounce-gif.391057/
"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
I like how in the docs it's referred to as damping (which is correct) and not drag...
what is
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
true
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
I'd hope not
I had an amazing idea of making an ECS hour glass, but.... that needs stability
hello
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 ?
I imagine we'll see systems released on github by anyone with an interest in it
and that'll be cool
hey?
yes people can read your messages
yay!
I can't
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
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.
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
having one item on top of another is a pretty common thing!?
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
bring out your notebook
there's really no good reason why Unity Physics couldn't have caching as option if full Havok can with the same API
20k per component licence 😃
probably the deal they made so they can use havoc stuff for free Olento
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
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
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/
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
yeah, that would fail on this new package 😃
and mind you this is a very basic thing a lot of people are doing.
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 😃
i care for determinism :p
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
for anything that has even the slightest impact on the simulation
for multiplayer, it makes sense
also for physics puzzle games
after that, I don't really see use cases that would require it
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
basically it's only build for DOTS style playback and rewinding network state of players?
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
but PhysX isn't in ECS
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.
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
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
well the only reason they haven't is that Microsoft bought them
true
Havok has been passed around so many times
but you cannot stay unprofitable department forever
when people keep buying and selling a company you know it's a dog
Havok is one of those pieces of middleware that everyone wants and needs but no one wants to pay what it costs to maintain
nice soundbite but really, it's fine
it wouldn't be industry leader otherwise
I mean, AAA isn't stupid.
it used to be the only game in town
OLD havok was a chore to work with but they have polished in the last 20 years
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
so use physx since it's legacy and works for you
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
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'
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
changing physics engines rarely increases productivity
quite the opposite heh
since it touches just about everything
i'm betting havok is just more stable under load. Physx has always been fast but unstable
look at Bethesda
physx's job is also to do whatever nvidia says is best for their gpus
there's a reason they stil use the old, moldy Gamebryo engine with Havok
for 15 years now
because changing = pain
of course it's changed
useless piece of shit havok! we hate you which is why we use you in all sony first party games
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)
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
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
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
true but that doesn't mean it's not better
doesn't mean it is either ;p
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
physics will always be a hard problem to solve
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
funny enough the tools I've worked with for the last 10 years have been havok based
so I know it's quirks
physx is super temporal really
i just want something in ECS that works reasonably well
and doesn't cost an arm and a leg
we dont have to rush
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
unity's havok integration is likely to be as pain free as physx, all nice ui etc
fancy slider bar
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
i dont know but i do know I have something I can use today: physx
but not in ECS 😛
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 :)
Whats the rationale for providing Unity Physics (and not just Physx OR Havok) to begin with?
like why 3 lanes?
because ceebee hogs the middle lane, I get caught in the bus lane and those in the fast lane do not see the cliff
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
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
I guess Unity Physics is a wrapper and a hedge against Havok? Like eventually they see themselves replacing some of those bits?
it's the weak alternative so people can't say they have no alternatives lol
yeah
my hot take on it:
-
physx cannot be made into ECS, it's just too different for dots
-
unity looked around for something deterministic with same dots style code, only havok had that
-
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
-
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.
i'll even bet that's part of their agreement with Microsoft: "You can't make a competing physics alternative"
yes correct
because the techniques used in unity physics are the same ones as in havok
read the docs it even SAYS so
well all physics engines mostly use the same techniques
not patented ones
there's only so many ways to skin a cat
havok has a battery of patents.
its just maths in the end
sure and physx resists determinism and bullet is dog slow
hehe
if unity want hardcore ecs physics over the network it doesn't make sense to fail for 10 years to follow physx and bullet
nobody is perfect 😛
i hate to say it but imho unity made the right call
yes unity isn't in the physics engine business
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)
finally something we can agree on 😛
stranger things happen :P
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?
not sure what you mean
just that it'll never been as clean as "just switch out the backend" :p
you mean have allocations? unity is removing all that over time
sorry, leak as in - https://en.wikipedia.org/wiki/Leaky_abstraction
In software development, a leaky abstraction is an abstraction that leaks details that it is supposed to abstract away.
ah I see
just snark
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
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
and then removed it
it's not like Unity set out from the start to offer something PhysX didn't
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
well i just care about it being basically functional
whole point of ECS was "it's earth shatteringly great and bestest of all perf" so why is it not?
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
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
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)
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)
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
sounds like they don't know themselves either what is going to happen
also the latest here
his saying how "wonderful" DOTS physis is aggravated me
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+
honestly I don't even know that "Unity Physics" supports determinisim and rollbacks.
it seems so super basic
it says it on the box
ok if it says so...
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
I can confirm the bad perf myself
hard to compare with build in physx but it looks like 100x times as slow.
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
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
heck many programs are only now adding SSE2
since people have stuff older than that
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
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?
UE4's new physics engine got caching 😄
I know, lame joke
their fracturing stuff = nvidia blast
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
yeah sounds like how Blender does dynamics
you bake the sim and then can replay it from the cache
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? 😄
The question is why
it's a good question
all game engines will inevitably have their own physics and math libraries
this is inevitable
now that PhysX is open source they can steal all it's secrets 😛
oh i mean, 'learn from it and make their own'
well, UE already had custom physics engine
around the UE2 days
but they moved to third party offerings
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.
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^^
@pastel dawn that's cool, did it take long to port?
it almost took the entire day x)
now only need to port the new char controller to ECS too 😄
@lapis plaza isn't the OCC the new char controller?
but, I've (almost) made it to work with ECS 🤔
the character component is a struct component
oh, I thought you did gameobject port
ah no^^
way ahead of my thinking then 😄
well, I'll put the code tomorrow on github if you are interested! (well... I originally planned to put it...)
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
The revolution in multiplayer games development! Create MOBAs, brawler, RTS, fighting and sports games with the blazing fast deterministic networking engine: QUANTUM.
combining physics and networking is mandatory tbh
or at least have them play together
physx plays with no-one
yes this is known
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
but for those of us who wouldn't touch networking with a 20 foot pole, it doesn't matter 😛
and latency is still not fixed.
yeah but
this also makes networking a u t o
you send inputs
done
my unity friend whined about having the ability to rewind daiily
its perfect for unwashed masses like me.
i am very much an unwashed mass.
nothing prevents me keeping physx around for some effects work
downsides:
Stacking doesn't work yet, maybe we get an in-house solution
upsides:
Time travel possible without 1.21 Jigawatts
heart for ref
And regarding stacking, I guess I would find ways around it to make it work, I would have to.
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
destruction has never been hard
so part of the main problem is authoring
it's just making it performant
the physics side not an issue
no, just the opposite
authoring is easy
it's the physics that make it laggy to do
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?
i'll say yes though I don't know what "DCC tools" is
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.
I'd use blender's fracture
Maya, blender etc are DCC tools
digital content creation
I call them Ceebee objections (CBO)
but anyway, sure you use your favorite tool
but then you instantiate several hundred items, all physical
and your game tanks
not to mention all the particles etc
yes so that means really, runtime authoring of the destruction is needed in part at least
I mean the storage becomes insane
there's systems to do the 'cutting up' at runtime as well
I have a pretty good one
but it's the same thing
otherwise i guess you will always split the cube into 100 pieces even though only half was broken off.
now you're doing that work AND the physics at runtime
so really it's worse
there's a really aweome talk by Ubisoft
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.
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
Introducing a game-changing technology in a AAA game comes with its own set of challenges. It's not enough to develop a new technology, you need to make it play nicely with other systems in the game. This session is about developing and...
I would probably let particles do most of the job
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
wtf
I do that too! i though it was just me being a primitive twit
i guess one needs to be a primitive twit for perf
using mesh particle systems is ideal for this
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
HLOD?
(if it's not become apparent, I really hate abbreviations and those lettery things people use instead of whole names)
hierarchical lod, where the bits are separate close up but swapped for combined lower poly ver
Acronym
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.
oh I know about it, I just don't know the short name
HLOD could be literally anything
Happy Logs Out Drinking
a few open world games use it, I noticed it was in the gta 5 breakdown
Half-time Longcat Overdosing on Drugs
it's in the megacity demo project in the toolbar as well
under HLOD
brb shouting at unity's staff for daring to abbreviate
hehe
nah I get ya
these acronyms are all easily googlable though 🤷
no it's not
I think they mean lots of separate bits become fewer but lower poly bits in this case
that's not used as a hierarchy though
and they display one at a time based on distances you set
and not what the word hierarchical means
sure if you want to be oblivious
Look I know you have some kind of problem with me
i don't know exactly what, maybe I threaten you
(fyi I like you ceebee, I have never had a problem with you if you mean me)
But the snarky bullshit is getting old
what?
we're both on the discord all day man
and I really don't appreciate it
slowly backs out of the room
I don't play that game but I can start
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.
I've got no beef either O.o
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
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)
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
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
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
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?
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
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?
but it's' probably best to use it if you'll get huge triangle count savings
but not if it's minor
true
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
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?
i don't know, i have a feeling they won't be doing anything to improve the legacy pipeline
I do wonder about the future of it
and whether they'll depreciate it entirely
at least in the nearish term
years not decades 😛
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
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...)
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
I assume it's an ECS only thing
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
they're controlled via the HLOD component that forces a certain lod
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...
popping is mainly bad because the small objects get too early out
larger shapes lod properly
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
pretty sure the conversion tool handles those to hybrid renderer
well that's what i was wondering
0lento do you know much about subscenes?
what about subscenes?
it converts components too?
certain components, yeah
i can at least work with the editor now that it's on my SSD
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 😛
yes the way they are used here, they just seem to be a fancy prefab
there's the whole ECS conversion process - and I've heard it's related to that
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
ah
instead of loading gameobject scene and converting it in place
I think MegaCity has additional streaming system that takes advantage of this data
was the giant chain in Megacity or a different demo
yeah it's on the side of the pagoda
but would need to see this gdc's talks to know exactly what the current setup is
ah yeah there it is