#⚛️┃physics
1 messages · Page 37 of 1
I just want to use unity's physics but lack of primitive stacking (note: don't need to stack across the network, just for local) would be just right for me
seems backwards not to have something which seems so basic for a modern physics engine, really hoping they reconsider or that the havok part is affordable
I wish they'd put the Unity Physics on github
users could then add caching easier if Unity wont
as great as user stuff is, id feel better about the long term availability if unity themselves implemented that
of course, but when it comes to physics, I dunno if it's worth waiting for years to maybe get the functionality you need
well yeah id use it and be thankful. But I'd forever be left wondering about what exciting frontiers an official solution could lift me towards, not to mention the vast multitude of possibilities for user solutions built on top of that!
I don't actually know how you are supposed to find the latter link by site navigation, I just know it exists :p
Thanks Olento
Hey so I'm looking to create a 2D character controller and I'm really at a loss as to which method to go with.
idk if I should use transform.Translate or Rigidbody.movePosition or Rigidbody.velocity or which way I should be detecting collision.
any suggestions?
@peak panther Probably need to start with this one:
https://docs.unity3d.com/ScriptReference/Rigidbody2D.Cast.html
@sly violet Is this the standard thing to use with a kinematic rigidbody?
also thanks for responding
I think the standard thing to use is the existing character controller, but if you're dead set on making your own, you'll need to know what you're going to hit before you hit it so you can adjust the movement appropriately, and that requires a "cast" before you move.
I made my own rigidbody based one but I think people will need actual years of experience in doing that to do it well. Raycast based ones are far safer
Hmm is that so?
Is there any good character controller then (rigidbody preferably, but I'll look at some raycast based ones) that I can look at?
I'm experimenting with using the Physics system to avoid doing between 1 to 10 million distance checks in code to check if objects are within range of each other
for now I've implemented a system that uses box colliders as triggers, but I've been reading and people say using sphere colliders is better for performance than box colliders
is that correct? and if so, why?
do box colliders check per vertex and sphere colliders check based on a radius?
@stuck bay it's not just the vertical stacking, I mean, it's issue in all directions
and yeah, I have situations where that can happen
sleep would require caching
you can't just sleep with stateless thing
because you can't just put things to sleep if the velocity is 0
it needs to be close to 0 for multiple physics steps
you don't need tons of past states tho
even having previous frame can help a lot on the stability in these kinds of scenarios
this is why verlet integration is more stable vs naive euler solver
as it uses previous steps data as well
the final example on that isn't super stable looking either but it does eventually stabilize 😄
I do plan to investigate the options to fix that kind of jittering on Unity Physics if Unity doesn't beat me to it, it's not a priority but it's very solvable issue
Unity Physics in general?
I really wish they'd put it on github
but I'm afraid they don't as they don't put any ECS packages there
mathematics is exception
but it's not only for ECS either
nah
it's proprietary
I mean you get the c# scripts on the package but it's mostly native code there
it's also one of the few packages Unity actually ships with native binaries in it
usually they tend to put native code in engine side
but this lets them upgrade Burst without it being tied to engine releases
and by the native part, I mean the actual Burst compiler
@sleek prairie : Yeah, sphere-to-sphere collisions are cheap to calculate because all you need to know is the distance squared.
No geometry, no rotation...
@stuck bay tbh, that's something I have no idea about, better ask in #archived-dots 😃
@sly violet I see, thanks! I'll probably try OverlapSphere on the 1st set of objects and a sphere collider on the 2nd set. Right now I'm doing box collider on both the 1st set and 2nd set and seeing some performance spikes sometimes with more than 10k objects
Hmm, you'll probably see a small across-the-board improvement but the spikes will probably still happen. Spheres are quick to check but doesn't help with the, what's it called, sorting out which checks can be automatically culled and not even checked.
Just guessing/theorizing, though, I'd be interested in hearing how it works for you.
I will run some tests tomorrow to see how it turns out. I can post the results here along with my previous tests. The good thing about OverlapSphere is that I think I can "space out" the calls since I only need to do that once per object and I have a time window of about 1 second from the time the objects are created to the time that I actually need the results of the distance checks
I have a set of 10k objects that are not moving and another set of around 1000 objects that are activated at runtime and then moved
I think some of the Physics performance spikes come from moving those 1000 objects that have colliders, but I might be wrong on that one
@sly violet I'll tag you here once I post the results 🙃
I'd love to see different broadphases as option, like physics engines tend to have
yeah but Unity Physics is stateless, so they kinda want everything to be generated from scratch each time
I don't know what's involved on on SAP algo tho
like, could you make it deterministic by storing the previous state as cache
yeah, it does limit things
yeah but I mean now if you need to roll back to previous state
you have to have the cache rolled back in similar state for determinism to work
should read how it's implemented to really understand this 😃
well, wikipedia can do that too ;D
In physical simulations, sweep and prune is a broad phase algorithm used during collision detection to limit the number of pairs of solids that need to be checked for collision, i.e. intersection. This is achieved by sorting the starts (lower bound) and ends (upper bound) of ...
but I'm terrible at understanding text in this form, I understand equations, formulas and code way better 😃
describe algo in text = takes 100x more effort to understand that to examine it in snippet with description
don't they do that already for Hybrid Renderers lod system?
I think they have some basic AABB setup there
or "basic" they did exploit a lot of things for it, Mike Acton did a talk about it on Unite LA
they pretty much relied on every building being static there tho
How we used ECS to display a large environment in the Unite LA MegaCity streaming demo. Slides: https://www.slideshare.net/unity3d/lod-and-culling-systems-th...
well, they used that for culling
well, I don't really know what the whole thing would be called
it's not SAP
it's custom setup
the talk does describe it 😄
I totally expected them to come up with something like that in the Unity Physics, was pretty surprising to see BVH instead
but it could have been some thing from Havok devs, if they wanted to make it that way
now that I watch that LOD talk again, I totally understand why they couldn't use this 😄
they could have used this for static colliders
but that's about it, the chucks are hardcoded for the bounds
so you can't do that for anything dynamic
wonder if the static BVH is still expensive
as this talks setup would be super cheap
I'll worry about the broadphase if it turns out to be too high cost in the final setup
in my case, it's mostly about static colliders
I tried to get some answer but less surprisingly that got ignored
have asked for that physics repo on every possible thread, it's not even possible they haven't seen it
they just ignore it 😄
the havok guy even follows me on the forum but it's not his call either 😄
I'm guessing they want to keep the DOTS code out of github on purpose
like, they don't hide it from Unity users as it's on the packages but they don't want to share it openly to the whole world
now basically they can limit the users to ones who use it through Unity editor
well, technically you can download the packge from the bintray directly too but it's not something most people would do
well, UE4 source code requires github linking too
IMO they could do same for Unity repo
if that game more access to the actual devs, that would be fine
May be too soon
So I've been doing experiments to determine what is the most efficient way to check game objects within a certain range in my game
Tests Conditions: 2 sets of objects (A and B) with 1000 objects each
Tests Objectives: Check what objects of set A are in range with objects of set B
Test1
Test2
Test3
@sly violet you were right, box colliders and sphere colliders don't make a significant difference
sphere colliders are slightly more performant. Edit* on the Test3 I forgot to change the last line, it's actually SphereCollider --- OverlapSphere: 7ms
missing Test4 where you use the new math lib, burst compiler and job system for the Test1 😃
but brute force isn't good
@lapis plaza hehe I still haven't used yet any of the new features with ECS, Burst, Job System or any of that
would it make a significant difference for my intended use?
well, test1's case would get way better results but it's still kinda wrong way to do it
I should point that my my tests don't actually test against ALL 1000 objects on each set, they are not all positioned at the same point, instead they are spread out to simulate the actual implementation that I need for my game
the overlap sphere is best pick IMO
and then run the burst job for it 😄
you don't need to do ECS for this
just do regular job and use new mathematical and burst
it'll give you speedup for that part for sure
it'll multithread and SIMD optimize the math
you can also read the transforms in job systems worker threads
so it's not all tied to main thread
@lapis plaza what about test1 is wrong? I thought of implementing some kind of spatial segmenting so I wouldn't need to test all objects, but I didn't think it was worth it because it would overcomplicate the system and I still need to add more things on top of it
your test3 already does that
physics engines do this already for you, so why not take advantage of it
how costly is the overlapsphere itself?
exactly, that's what I got from reading around the forum and the recommendations of some peeps 😃
one sec I'll test the overlapSphere without populating the arrays
it would tell if there's room for optimization on the array processing
this is what I get on the profiler
so the OverlapSphere itself is 2.39 and the method that calls it 4.32ms
so 2.4ms?
yeah I guess so
what the method does?
on that profiler screenshot is empty
just the Physics.OverlapSphere
Physics.OverlapSphere(transform.position, 2.5f);
weird that it's almost double cost than the actual check
I call it on the Update method with if (Input.GetKeyDown(KeyCode.S))
maybe it's that?
ah
you should measure the cost in some isolated function
you will not get right results if you have extras there
so should I isolate the OverlapSphere in it's own method?
and then call that from the update with that input check?
for benchmarking, it does make it easier, yes
ok, now that I'm at it I'll sample the method for the profiler too
I'd recommend keeping Update slim anyway
there's also jobified spherecast but it might be overkill if you only need one overlap check (there's no jobifed overlap checks)
what's nice about the jobified thing is that it returns the results in native array that can then be easily processed with another job
but I guess the overlapsphere's array works too for that purpose
anyway, this should get you started on jobs if you want to try it out: https://docs.unity3d.com/Manual/JobSystem.html
(for processing the overlap results)
with deep profiling shows different results but more consistent
seems the other cost comes from getting the transform and position
I don't think I'm populating the array too inefficiently
triggeredObjects = new GameObject[triggeredColliders.Length];
for (int i = 0; i < triggeredColliders.Length; i++)
{
triggeredObjects[i] = triggeredColliders[i].gameObject;
}```
the difference between calling only OverlapSphere and calling OverlapSphere + populating the array doesn't seem to significant
it's pretty much 1 or 2ms in difference with 1000 objects calling the method
I must mention that the arrays themselves aren't too big, 100 items at most
I'll be sure to check out that link, it's been on my list for a while to learn about ECS, Job System and the Burst Compiler
oh, so you don't even batch process the objects in range there? yeah, burst wouldn't help you there 😃
also the spherecastcommand (jobified spherecast) will not help here either as spherecasts don't get the initial overlap apparently
@sleek prairie
@lapis plaza sorry but what do you mean by "batch process" ?
I'm an artist reconverted to programmer, some concepts are still foreign to me 😅
I just mean processing all the elements through one by one and doing some math on them
what do you do with those gameobjects you get in the array?
like, why do you even need this?
I need to know what objects are in range to apply other systems on top of them. For example a procedural generation system that needs to act on arrays of points that are contained inside those objects
also do some shader stuff with the objects in range
I give a unique identifier (an int) to each of the objects and then I need the other systems to do stuff with them
sounds like you'd love the ECS 😄
probably, I've heard good things about it! 🙃
but for now it's not a priority since I haven't hit any roadblocks with the "regular" Unity way of doing code
it's just, if you process a ton of data, it makes that kinda of tasks a lot of faster
If it offers a considerable improvement in performance and I can combine it with the Monobehaviour way of coding..
I will probably use ECS for my procedural points system
@lapis plaza I am just reading through the conversation to learn, but pardon me, isnt batch processing essentially processing elements into batches of similar attributes to be stored to then be processed in one go? What's this about processing one by one?
Just a curious question because I am still learning, I dont meant to challenge. Does batch processing mean something else in unity or am I just wrong?
@sharp sentinel same here! heh 😅 all I know about "batches" is related to Unity's rendering pipeline.
@sharp sentinel I was referring to https://docs.unity3d.com/2018.3/Documentation/ScriptReference/SpherecastCommand.html and Unity's Job System for processing transforms if needed
I dunno if the batch processing is somehow right or wrong term, I just use it for processing a lot of data in similar fashion
right. I see. All good. Batch processing meant something different from what I learnt, so I was curious. Thanks 👌
afaik, it's pretty common term tho, like if you process similar inputs, with same operations, many softwares call it batch operation
imagine like image editor that runs series of operations in script for each file you enter for the batch processing
I kind of get the gist of what you are getting at. Right. Makes sense for the name. It's almost the same as what I know except for the organizing the data into separate scheduled payloads a step prior, what you are saying is the entire input is already in a "batch."
I'm trying to improve performance on a system for my game that is based on OverlapSphere()
so I have 500 objects, each one with a child that has a trigger collider and a rigidbody
both parent and child are on different physics layers set to not interact with each other
I call the OverlapSphere on all 500 parent objects in 1 frame
with the child's colliders active, the OverlapSphere calls take around 40ms
but with the child's collliders NOT active, it takes around 1ms to 2 ms
what's the explanation for that?
I even call the method to only act on a specific layer and with QueryTriggerInteraction set to ignore
Physics.OverlapSphere(transform.position, overlapRadius, LayerMask.GetMask("OriginalObject"), QueryTriggerInteraction.Ignore)
the OverlapSphere is working as intended and it's only getting colliders on the layer I provide
Profiling with child collider active
Profiling with child collider NOT active
...I've always wondered if the collision matrix is resolved before or after the principle calculations for casts and such. Kind of looks like after, doesn't it?
Still seems too big.
Like, even if they share the same underlying matrix, the increase should be proportional, and that seems geometric.
My knowledge of how the Physics engine works is quite limited so most of this stuff just flies over my head
I would assume the collision matrix is doing what I want it to do
because the OverlapSpheres don't return the colliders of the child objects
Hmm, sorry, mine too, in this case. I don't really know how it's optimized under the hood except in the most general sense.
Yeah, thing is, there's two ways to not return it, right? They could not find it in the first place, or they could find it but discard it.
even with both those ways I still get a massive cost in performance
the workaround I have now is just keep the child collider inactive until the OverlapSpheres have finished doing their thing
Heh. Is it cheap to activate them all?
I'm wondering if you can put them in a separate physics instance instead of a separate Layer. Might help.
...But right now I can't even find that option.
I'd've sworn that was something in beta at least.
Oh, they call it "Multi-scene physics"
activating the child's colliders is not costing any time at all, it's so fast that I can't even find it in the profiler based on the graph because I don't activate them all at once
I progressively activate them based on other conditions
which are procedural and can be the case that most of them activate at the same time, but highly unlikely
Hmm. Sounds good, then.
That stuff about "physics instances" sounds interesting
is that a 2019-only feature?
Unfortunately it's tied to scenes, which means you can't use it for child objects.
thanks for the link, I'm gonna take a quick read
Batched queries might help you, too, although they don't include Overlap so maybe not. I think we discussed that earlier in this thread.
ah! Seems this is somewhat related to what I'm experiencing
By default, all the changes to Unity transforms were synced to the physics engine right before they might be needed. That is, every time a raycast is run, every time a simulation is run and so on. says that blog page
on the screenshot I posted for the profiler that shows 40ms
the bigger performance costs come from: Physics.SyncRigidbodyTransform and Physics.SyncColliderTransform
Huhhh. Yeah, that's a huge improvement, although it doesn't explain the discrepancy.
I wonder if this ever made it out of beta?
I have 2018.3
maybe it didn't
My (extremely uneducated) guess as to what is happening with my OverlapSphere is that the Physics engine is somehow feeding and syncing the child's colliders and rigidbodies data into the physics calculations even tho I have the collision matrix set to ignore it
but it is weird since I am not getting any performance cost increase from moving the objects when the child colliders are not active
I clearly see a performance cost on the profiler graph as soon as the child colliders are getting activated
If someone more experienced with Unity Physics can shed some light on the situation so I can understand better what is happening I would greatly appreciate it 😊
on the meantime I'm gonna do some reading on transform syncing with the Physics engine
@sleek prairie Simply turn off "AutoSyncTransforms" in physics settings. This should be off by default on new projects.
The collision matrix is used early, not as a filter after the query has run i.e. it's used during the broadphase detection, not narrowphase.
@ocean horizon oh thanks! Now the OverlapSphere takes the same amount of time
I still end up needing to keep the objects inactive while their movement starts
otherwise I get a huge spike in Physics.Processing of about 100ms with 500 moving objects
If I activate the child objects in the middle of the movement Physics.Processing doesn't even reach 5ms at worst
You should not be activating/deactivating objects. Make sure you're not moving physics objects by modifying the Transform. Use Rigidbody.MovePosition/MoveRotation.
@ocean horizon I would, the thing is I am moving the parent object and it doesn't have a collider or rigidbody
I need the child object to detect whenever it collides with a surface
I move the parent with this ```while (elapse_time < duration)
{
discoverer.transform.Translate(0, (Vy - (gravity * elapse_time)) * Time.deltaTime, Vx * Time.deltaTime);
}
So why not place the body on the parent?
Then you can drive the body which will modify the transform thus avoiding any transform-sync prior to the simulation stepping.
that's a good question 🤔
I organized it this way for ease of use
since the parent does something completely different to what the child does
but I might aswell follow your advice
and put all together
also my previous setup used a collider on the parent for distance checks so that was one of the reasons
Prior to the simulation stepping, we have to perform a check to see if any transforms with RB or colliders changed. If so, we update the appropriate RB/colliders. The best case is where there are no transform changes and it's actually far quicker for this case than a single transform change. So for best performance, let the RB drive the transform, it's what it's there for.
oooohhh
For ad-hoc cases where you don't do this then it won't matter. But if you're doing hundreds/thousands then it becomes important.
so by moving the object through the RB it doens't need to sync transforms and colliders at all?
No. Transform sync is Transform -> RB/Collider.
i.e. an indirect way to modify the RB or collider. Doing it directly avoids that completely.
oh! I'm really thankful for the advice 😊
You're most welcome. Rule is, don't modify transform with a RB/collider on it if you can help it.
will do! 😃
The only reason it's supported is because we cannot ignore it.
As much as we'd like to sound loud sirens when it happens. 😃
question about Syncing if I disable "Auto Sync Transform" is there any undesired behavior I might encounter when leaving it disabled?
or any stuff that I should be mindful of?
Prior to that option, when you modified the transform we immediately updated any RB/collider. The transform system changed a while back and we no longer got notifications of transform changes. This meant that to keep backwards compatibility with "changing RB/collider when a Transform changes" we had to implement the "AutoSyncTransform" stuff. This means that anything that can read a RB/collider state that depended on knowing about the transform has to perform a transform-sync first to ensure it's up to date. So with it on, it changed very little. With it off however, the RB/collider are only updated once prior to the simulation step (or if you call "Physics.SyncTransforms" yourself).
So with it off, the behaviour change is that the RB/collider are still where they were prior to the Transform change. Spatial queries "see" them at the old position.
The advantage is that the transform change is decoupled from physics and you don't pay a physics cost, even if you change it thousands of times per frame.
we only sync-up when it matters to the simulation.
hmmm, I think I get the gist of it. So if I want to do it "the wrong way" and move by transform even when I have a RB I need that on
does it apply to moving by transform when only having a collider and not an RB?
We automatically sync transforms prior to the simulation so no, you don't need it on.
so I don't really need Auto Sync on in any case?
doesn't matter what I do and how I fudge the physics and transforms
You should avoid having it on if performance is important. Knowing that when you change a transform, it does not immediately update the rb/collider is important.
If you change transform then perform a query, it won't see it at the new position.
but that is potentially a bad way to do things anyway
I got it now, thanks for bearing with me 🙃
often it's query then adjust things for next simulation step.
sets a reminder to himself: DO NOT MOVE PHYSICS-DEPENDENT OBJECTS VIA TRANSFORM
Not a problem. It's all hidden stuff so confusing. Mainly this "feature" was a backwards compatibility thing. Moving forward it should be off.
what makes this twice the fun is that you need to relearn all the fancy tricks when you move to ECS physics as old rules don't apply 😄
I mean, for the transform update magic etc
(it's fine though)
OH GOD
I kinda never got the transform autoupdate benefit unless you made a game that didn't utilize physics sims more
for example, if you make a custom vehicle, you need the updated transforms each fixedupdate anyway
so that ruins the optimization afaik?
or can you somehow fetch only one transform?
transform autoupdate benefit
It was a backwards compatibility option.
The transform system changed and it was "imposed" on all teams in Unity.
yeah, but I mean the benefit of that optimization now
Which optimisation?
for not updating all gameobject transforms on fixedupdates
We do update them then and only then. We always do that once.
Actually when you perform a simulation step. Whether in fixed-update (auto) or manual
I thought the idea was to update the transforms only for next update unless the user needs the data on fixed?
The idea is to simply not update physics when the transform changes. Only update it when it's required which is prior to the simulation stepping.
The transform system itself changed to not produce callbacks. This was done due to its integration into the Job system
there was some handy snippet that made this all obvious how you should take it into account
So the trusted callback we had just went away. 😃
In-fact, the amount of projects I saw where the transform was changed many, many times between a simulation step was scary. Even doing position, rotation and scale changes separately and multiple times.
Each one caused a physics update for that GO.
No longer with the option off obvs.
Only thing to remember is that changing a transform does not affect physics.
fast but potentially inconvenient if you expect all state to be in-sync all the time.
For new projects, this is off so fast but can catch you out if you expect to always be in sync.
There's a "Physics.SyncTransform" call which is what we call prior to a simulation step. This is also called (if you have "Physics.AutoSyncTransforms" on) prior to any query.
2D/3D are identical in this regard.
<message ends> 😉
heh, thanks for the insight 😃
I hope I don't have to use the built-in physics anymore though, I really enjoy the freedom with source code access on ECS Unity Physics 😃
finally get those contact callbacks exposed I've asked access for years on stock physics integration
Yep and we'd expose them if we could but there's no way to stop things happening during such a callback that could cause serious problems.
We've asked for a "sandboxed" callback on our side too.
this isn't saying the built-in integration wouldn't be good, it's mainly about the access and enabling more things
Yep. It's good for you and us too.
not having access to physics code has always been driving me to custom physics solutions on unity
used to use bullet at some point
yeah, I imagine it'll be easier to maintain in the long run
Being able to point to source code in a chat like this is far easier.
I can do that to some degree with Box2D but there's still a large "hidden" layer to contend with.
So yeah, more stuff on Github the better.
btw, talking about github
you know is Unity Physics is going to be in Github?
right now it's only distributed via Package Manager / bintray
would be fancy to get it on github so would be easier to fork and share modifications to it
right now, there's no DOTS packages on the github at all, so wondering if this is some policy?
well, there's mathematics package there, but that's about it
Unfortunately it's a separate team that deals with that so I have no idea what the plans are there. I don't think there's a specific policy though. The physics stuff is so new that I think it's just "how it is" for now.
yeah, I hope there's not 😃
but in case it's Unity not wanting to share the packages fully open, I'd be fine even with private repos with requirement to link your github account like many companies do
main thing would be to get access to the repos, not the visibility
so yeah, will wait and see what happens
Exposing a thread-safe Physics.BakePhysicsMesh(meshInstanceId, isConvex) function to bake the data for MeshCollider on-demand from any thread. Usage example with C# job system (generate N meshes and bake off the main thread): https://t.co/vWIQ64yVqG
What's the typical use cases? Dynamic destruction?
Perhaps - I was hoping someone would tell me 😛
I know someone working on a skinned mesh slicer and it'd be handy for that I imagine
yeah just seems odd Unity would want to focus time on this thing especially
order probably came from zeus
It may not have taken much work, as it could have been written for internal systems and is now just being exposed
I don't have any blocking issues with physx, but the new unity physics lack of even 1 stacked object means I pretty much need to keeo both physx and new physics running in the same project - which is bad since I need to double colliders up on everything...
why you need the new physics?
for networking it will be a no-brainer
but I can cope just using it for character-to-character collision and char to env plus hitscan stuff
stacking and more is for player side dynamics mostly, that is it won't break the game being slightly inaccurate
just doubling up on colliders seems a bit off.
@tropic hamlet So you know, Anthony isn't working on the DOTS physics system at all.
I suspected as much
A feature such as mesh baking isn't prioritised again DOTS physics. It's completely separate.
What's it for?
Better wait for Anthony to turn up. I'll ping him.
Thanks! I don't anticipate giving up Physx any time soon given the limitations of dots-physics
I wouldn't expect anyone to. It's so hot-off-the-press and still in an early release state.
I think really the adjustment to make is that "Unity is sharing things that are only a month or two old" vs before
Yep. They are drinking in all the feedback though and are eager to improve. High velocity on it from what I can see.
Nice energy but can also lead to pressure for things that are basically bad to ask for because most of your customers (me included) will not be specialised like you are
I just hope "no" is a valid choice on Unity's side :D
I don't see that, seems a little pessimistic if you don't mind me saying sir. There's a lot of smart and open minds on it from what I can see.
Not saying I'm correct. Just that it's early days, they are logging all the feedback from what I can see.
Taking forums posts and making notes of them etc. Certainly not ignoring stuff. The drive seems to be coming directly from that feedback.
I think you misunderstood me: I mean it's easy for someone like me to demand and ask for things (or many like me) but Unity should feel OK about saying no to that and explaining why if it's a common request because it's easy to chase customer demands down dead ends.
Oh sorry, I misinterpreted. No offense.
course not, I can't be offended by text :P
Glad to hear it, some are though. 😃
I know, sadly. despite it being characters on a hard drive and not really there in the room :P
Was it your work that enabled GC free collision events like OnCollisionStay?
Yes.
Thanks a lot. Made my codebase so much cleaner and allowed me to make a better game.
Awesome. It's sad that it was like that in the first place.
Technical debt :) btw I did a ball-popping game in Torque2D once but sold it so I had to delete all my torque posts :( but thanks for back then too :D
Hey hey. T2D was fun to work on although I never liked TorqueScript.
The engine was a real mess too.
But the GG guys were top-notch.
Yeah... and if you dared ask for documentation then you'd be told to read a mess, basically.
I did have fun with it back then, for me cool to use a fully-fledged commercial engine
T2D was your pet project before them wasn't it?
T2D was my pet project. I started on it just as my first daughter was born. Spent late nights coding with a baby on my lap. I have no idea how the hell I managed to do that.
:D
T2D wasn't the best thing in the world but it was fun to do. I learned a lot of things, mostly of what not to do.
but isn't the way of programming? 😉
I enjoyed it immensely but also the legacy of that project is kind of living on right here isnt it?
@tropic hamlet baking/cooking physx colliders is way to turn your collision data into more optimized physx structure, you need to bake the data if you do procedurally generated meshes runtime for example
this is traditionally slow and lagging part of the proc gen stuff as it usually happens in the main thread in game engines
being able to offload it to threads is a big help if you do this kind of stuff
you have to bake the data too, it's not optional afaik
Haha I'll never be able to read your posts again Melv, without imagining you with a nappy in one hand, a laptop in another and a bit of chaos at 4am!
It was pretty much that right there sir.
I think that sounds familiar to be honest.
I have an object that can snap into place on another object. I use a fixed joint to connect them, but because one has gravity enabled it hangs a bit lower than the other one. Is there a better way to connect two rigidbodies?
I'm surprised it's noticeable. Does it need to be a dynamically breakable joint (i.e. does it have a break force/torque that isn't infinite)? If not, you could just make them one rigidbody while snapped together...
i decided to manually set the position and rotation to the same as that made it look right
I have a ship where i have objects i can move around. When i accelerate the ship, the objects fly around. Is there a way to prevent this without manually setting the position every frame?
common trick would be to simulate the ship inside parts on separate static location and just mirror the physics into visual target
im not quite sure what you mean, but using multiple cameras?
by putting physics part of the ship interior into different location, you simulate it normally there, then just send the transform changes to the moving ship for visual representation which can tilt however it wants
basically there's two places then where you sim physics: at the static location that has the inside parts and the ship itself that is moved by physics
i see, but wouldnt it be a lot of work?
depends how you view it
and having double of everything wouldnt be that efficient i suppose
you don't really double everything but gameobjects, but even still the gameobjects on the other part has meshes and other part has the colliders and rigidbodies
so it's not really duplicate, just split visual/simulation
there's one simpler trick that many fps game have done for a moving train but it's bit harder for a boat that rocks
on train, they just move the world around the train, train stays static so you'll not have issues moving around it
i thought a bit about that, but it seems like a not so good workaround for unity physics
what if i add another ship cause of coop or something like that
for the first example, that would work, you'd just have to swap the chars between physics spaces on fly
like if players jumps from ship to another, it would temporarily be in world space then again in ship space
i have a vr game and the user has to move stuff around when the ship gets hit, but when i accelerate everything goes nuts
it's not super hard to do but it's hacky alright
so i was thinking that using multiple cameras could work
how the cameras help there?
also, game physics are hacked together a lot
you just need to know how the physics engine work to bend their rules to your will
you have one camera at where the player would be in the real physics ship
and another one in the "fake" ship with all the movable objects
draw the first one and then on top draw the second one
if there are holes in the 2. one it will be filled by the 1. one
wow it seems very easy in unity
its working now :-)
that works with built-in renderer now, LWRP and HDRP doesn't support that anymore
but there's some camera stacking coming to LWRP at some point
Whats that?
Just in case anyone wants to try some new stuff, here is an update to the experimental physics branch: https://forum.unity.com/threads/physx-4-0-in-unity-experimental-builds.634960/page-2#post-4439872
(physx 4.1, articulations, Physics.BakePhysicsMesh)
so, physx 4 is currently coming to 2019.3?
well, if I manage to get it stable enough for production - yes
I guess 2019.3 alphas will then be first ones that can build the player?
so any feedback helps really
if it makes it that is
players - yes
is it really worth making 2019.1 version since 2019.3 alphas are this close?
or do you need it for testing?
I hope to attract more people. It's always a balance. I could have published builds off trunk on day 1, but then many complain nothing works there, so no reason to care.
That's been my experience with alphas over the years. "Oh, a new alpha? Nice. I'll check when it's stable in a year" At which point the feedback is too late
So this time around I'll spend more time testing in older versions rather than in the newer ones. I tried that when updating to PhysX 3.4 in Unity 2018.3 and was happy with the results.
yeah, I guess 2019.1 makes sense then 😃
what about you? do you personally need 19.3 alpha to try out the new stuff?
I'm pretty much on the bleeding edge due to HDRP
2019.1 is first I could use in production but there are constantly updates that make it better on upcoming versions, and considering Unity's current TECH / LTS plan, IMO it makes sense to work toward the LTS if you can't stick to previous years LTS
on HDRP, it's targeted to get out of preview at the 2019.3 so I don't really see issues on using bleeding edge until Unity reaches that version (and 2019 LTS later on)
@tardy spear awesome thanks for your work!
btw, is there any sample / programmer doc for the articulations?
or does it work similarly to existing joints ?
I've never setup these on physx despite them being around
yeah, if you check the post I mentioned above there is some programmer-quality doc there
thanks. let me know what you think.
there will be proper docs just a bit later. for now I wrote a few pages of ideas dump + physx links to get ppl started
Interesting to see if anyone's opinionated about the mesh cooking stuff.
yeah, that's fine at this point IMO 😃
people who use this kind of preview probably know a bit better what to expect from physics in general
I'd want to try something like this
it's using reduced coordinate articulations, but since these can't make loops, how did they implement the dual wishbone suspension?
here's another sample which I believe is using same setup: https://www.youtube.com/watch?v=6dATi4-wb3o&feature=youtu.be&t=278
A live-demo (not edited!) of PhysX 4.0 in PEEL 2.0. This is CPU PhysX. The GPU version would be faster but it currently has a big lag at startup time which...
in my experience the regular joints just don't cut it if you need a stable vehicle in such setup, but articulations could work
wonder if that first one is on some physx sample
I asked nvidia and the reply is basically they combined articulations and usual joints
(this is not yet supported in my custom build I shared earlier today)
I kinda suspected that as you need to have link
thanks for asking 😃
I just tried making something with this but the articulation joint setup is pretty unintuitive now without any visual cue where the anchors are and how they align
I haven't tried connecting pvd but you really should be able to conf the anchors without connecting a debugger 😃
in my test project there is a Readback script that shows the anchors
ah, I'll check it out, I haven't really used regular joints in ages with Unity physics even, maybe it's always been like this 😃
I did check the sample, just didn't realize there were a script for this
ah, found it
you may have to enable the gizmo drawing stuff in the gizmo settings box
but you're right, I'll add some anchor points editor niceness in the upcoming builds
Just noticed some misunderstanding happening around Physics.BakePhysicsMesh above in the thread. I wanted to clarify that it's been on the todo list for ages, and let me assure there are plenty of people wondering about the options to have mesh baking off the main thread.
You can pre-bake meshes and then instantiate objects faster
hmmmm, scaling transforms is also not supported atm, not sure if you mentioned it on the doc
after scaling my cubes, my visuals and physics don't match anymore 😃
It was a day of work, and I hope for some great impact actually on everyone who deals with MeshCollider really.
yeah, the off main thread baking sounds like a nice thing, especially for proc gen
For those who don't know, I've been on a mission to improve mesh cooking time: https://twitter.com/AnthonyYakovlev/status/1031940663447900161, because I care, and plenty of devs care too.
So for that reason, it's weird for me to read something like "why would you prioritise this vs object stacking in Unity.Physics". You have to know it's happening in different galaxies really.
people don't necessary know it's different team as it would be logical assumption it's the same people (if you don't know better)
I agree about "people", but I'm not sure why would that be coming from hippocoder, that leaves me puzzled.
tbh, the stacking isn't the most critical issue on Unity Physics atm even
to get back to the wishbone suspension thing, you said nvidia used combination of regular joints.. you can do that with articulations?
I guess it's just part of the outside physics from the articulation system then
yes you can. An articulation is a type of rigidbody so one can attach the joints to it. However that's not yet possible with the build on forums
"You can add normal pxjoints connecting links in an articulation. Just be aware that those joints are solved by the pgs/tgs solver so, unlike the rest of the articulation's mounts, they can exhibit error. Also be cautious about over-constraining the system because articulations don't like it when joints try to constrain already constrained axes. If the joint axes drift due to normal fp rounding errors, the solver can calculate enormous impulses to correct tiny drifts due to articulations being infinitely stiff. We are pretty good at catching/removing these degenerate constraints in the solver, but it's still something to bear in mind. (edited) "
ah, so much to learn
In addition to applying impulses and setting joint positions and velocities, it is possible to interact with the articulation links through the application of joint forces/torques, which behave like an actuator. forces are not implemented at this point?
I did see the comment about drive parameters but it's different I think
joints will come in the next builds
I'm mainly thinking how to apply custom forces to the articulated bodies now
that will also come.
for now you have drives
maybe I can add forces if you need them and rebuild tomorrow 😃
forces would let me bypass the physx friction mainly, but it's not really urgent for testing this
also, even with forces and regular joints allowed with articulations, I don't think it would be feasible to build anything but slow moving vehicles with this setup anyway as we can't filter the collisions on the wheels (they would still explode on some collision seams for sure)
but I'm genuinely interested on making a proto like on those physx videos on articulations as I think it's still cool demo
btw, did physx let you update those drive values after the thing was created?
like, could you update the drive params at runtime?
I didn't see a way to set those from code on current build
there's nothing on the current builds metadata for that drive
I mean, I can access that drive object but can't do anything with it
or I'm just missing something 😃
damn! you're right.
I copied code from C where fields are public by default in structs. Well, shit happens, sorry
np, that's what the test builds are for, right? 😄
what does the ? signify with
RigidBody? hitBody = null;
sorry in conjunction with the new physics package
in the ecs physics samples MousePickBehaviour.cs, theres a query for a rigidbody, doing RigidBody hitBody = null isnt the same as adding the ?(nor does it work)
but I don't get it
returns null if the left-hand operand evaluates to null
that returns null either way, so what's the point?
oh, it's probably used later on
ah I see, thanks @lapis plaza
I think that makes it nullable? Except Rigidbody should already be nullable so I dunno?
It's technically a ternary operator. The normal usage is -> (if a) ? (do b) : (if not a, do c)
In this case the ternary (?) is acting as a null check. so -> (if a == null) ? (then b)
The other end of that would have been the else case of the ternary the x ? a : b.. but if it's null then you just don't do anything soo x ? a
commonly its just referred to as a null check
so in this instance, RigidBody? hitBody = null; is the same as if(Rigidbody != null) { hitbody = null}
The thing that doesn't make sense in that code sample is that they are checking against the class, not an instance of that class
ternary operator would require that : to be there
the ms doc page I linked seems to fit into this case way better
A '?' after a Type makes it a nullable type.
seems so
Not unusual for say "int?", but doesn't seem meaningful for a Class?
could be just some logic error
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/nullable-types/using-nullable-types
It says you can't create a nullable Reference type, so it should error, I think?
ah, it's actually not the Unity's old rigidbody class, it's Unity.Physics.Rigidbody struct
the old class based RB would have been Rigidbody, not RigidBody 😃
wait - is that a convention?
@sly violet so this explains why they do that (as structs are value type)
almost everything in Unity's ECS side are done in structs afaik
It's perhaps worth noting that in C#8 update enables you to use nullable reference types, and that nothing is nullable unless you specify it to be. Which is going to be strange to see how Unity deals with that change when we get that update. (Probably should discuss further in #💻┃code-beginner if interested)
You have to turn that on explicitly, so I guess Unity is going to handle it just as it does with unsafe code
it's not coming from me. I know already you have nothing to do with unity physics so I assume you mis-read me.
@tardy spear
likely I was replying to something else offtopic
AND! I really love your work man. I'm using Physx (your work) in my game that will ship. I can't do it without your work so far, thank you.
heh, I was just going to post that 😄
Specific issues to be addressed in the near term include:
A solution for stable stacking that does not require adding extra state
- We are currently seeing reasonable stacking on pyramids up to 5 blocks high and across a range of scales.
- The seesaw sample is now stable and can be more complex.
- Work is still ongoing, balancing stack stability with behavioural anomalies.
A faster and more robust convex hull generator
- The convex hull generator has been improved, though work is still progressing on removing unnecessary coplanar triangles.
- A faster hull generator will also allow visualisation in the editor and potential runtime usecases.
- More use case examples are being worked on across the board (e.g. trigger volumes)
In the medium term:
- We continue to work on getting the Havok Physics integration ready for its first release in summer.
- Performance improvements in Unity Physics are being investigated, in many of the areas raised here in the forum (e.g. removing Complete calls to scheduled Jobs were possible)
- APIs are planned to allow a full simulation step within a single job (e.g. for predictions / mini simulations)
I hope the perf part will still happen sooner than later as current perf isn't all that great 😃
but the plan is looking good
Breakable or deformable joints are not directly on the roadmap, as such. That said, we do need to add joint impulse reporting so your own systems can check for violations and remove the associated Joint entity (breaking the Joint), or change the Joint parameters (deforming the Joint). Expect a new Joint demo when reporting is added (though I don't have an ETA just yet). Articulations are not planned.
what did articulations refer to in your question?
this definitely means there will be community extensions: Sleeping is currently out of scope for Unity physics. The design pillars for Unity Physics are for it to be stateless and also simple enough for users to confidently modify to their unique needs. Sleeping is something that feels simple on the surface but actually adds lots of complexity to a physics engine implementation, so does not fit the design goals. A primary goal of the Havok Physics integration will exist to address the use cases where a stateful engine really does becomes necessary - such as scenes that have enough settled rigid bodies, such that sleeping the inactive ones becomes important.
I will allow Unity to continue without punishment for a bit longer.
I expect you to crack the whip if the havok license cost is outrageous 😄
I have no plans to use Havok atm 😄
it's yet another closed source thing
even PhysX is more open now 😄
and for articulations, I mean algos that can solve a chain of joints at once
like https://en.wikipedia.org/wiki/Featherstone's_algorithm for example
PhysX and Bullet both implement this
but yeah, I didn't expect them to support it as Unity Physics will be bare bones setup
so far perf seems good enough for me but the lure of cached performance sounds too good for me to resist if havok is affordable(for me)
my maths is too terrible to make compelling use of the source 😦
you can do naive sleeping and caching on your own
Well I would be aggressively sleeping most things anyway so being able to rewind and resim, it's too powerful to ignore really.
like, if you do large world, you can just opt out simulation for parts that are not nearby for example
Yeah it's ECS so your entire planet will probably cost no more than a couple of memcpy since most of it would be sleeping, right?
also, trivial sleeping would just keep track of physics steps the rigidbody is below the set velocity threshold and then have total amount after it would sleep, this would add only like one byte of data for each stored state so you can just rewind and set this counter yourself along with the other values when you rewind and resim
it would still be fully deterministic
of course everything could be made more optimized and complicated but I would expect one to get pretty far with simple and naive optimizations like that
you can't disable the collisions
as it would never wake up then
but when it's sleeping, you just ignore it
i guess i dont know how you would wake it up via physics if you were to sleep a rigidbody, like if its removed from the sim how do you use the sim to wake it up?
you could use a component to tag the live ones
and use that for the simulation
it would never run the sim on the sleeping ones then
well, you do need to make collision checks for the sleeping bodies
but you don't have to run simulation on them
like, you know sleeping ones are like static collisions while not active
so put it on that pile while sleeping
I think Unity Physics treats these separately already
dynamic vs static
@tropic hamlet I feel that's some politics involved here, it's not what is feasible or in scope, they just want to keep Unity Physics simple to maintain and have a reason for people to pay for Havok
if they made Unity Physics better than Havok, nobody would get Havok
it's probably also question of resources Unity is willing to put in maintaining the physics module
definitely sounds like politics for the github/source answer
yeah, I really wonder if we'll ever see this on github
I sure hope it happens
also wonder if they do things like OverlapSphere
now they only support overlap check for AABB box
collider casts work with different physics shapes so that's not an issue
posted a reply
regarding sleeping
I think we can ask them to provide the neccessary groundwork to cover most of our optimisation requirements without sleeping
just provide the management for it so we can decide on simulation state for groups or individuals
its good enough
"if they made Unity Physics better than Havok, nobody would get Havok" I don't want f-ing havok :)
yeah, I agree
some stacking was necessary and its enough. but now the sleeping issue... so i need to do it myself, but require public api, then i do not need to hack source.
just need the repo on github
there's no real reason for each implement this separately :p
yes but ... why if a simple api of management is public, it's enoiugh by default for most people
most people (all) will want some form of sim on/off public yes
going to source for that is ridiculous
and we dont need sleep api then
it's a workaround so the havok guy can satisfy the business end, u see?
I'll do some testing on this at some point, but it's not a priority atm
yeah, I saw what you were going for there on the post
sleeping is not allowed, for business purposes
really even physx has overkill for sleeping. most of us would be more than happy just turning on things locally :D
otherwise it beomes not very useful for local non mp games without source
and people may want to simulate some locally and some in mp
New demo to be added to the list then ;-) ```
i was actually just trying this and removing the velocity component constantly crashes the editor
you probably have Burst enabled
try without
I mean, I think I saw mention that Burst doesn't support adding or removing components on fly yet
no it was a componentsystem using postupdatecommands
the thing that didn't work?
yeah, super simple mainthread
it could require other changes too
public class ToggleSystem : ComponentSystem
{
private EntityQuery hasvel;
private EntityQuery novel;
protected override void OnCreateManager()
{
base.OnCreateManager();
hasvel = GetEntityQuery(new EntityQueryDesc
{
All = new ComponentType[] { typeof(PhysicsVelocity) }
});
novel = GetEntityQuery(new EntityQueryDesc
{
All = new ComponentType[] { },
None = new ComponentType[] { typeof(PhysicsVelocity) }
});
}
protected override void OnUpdate()
{
Entities.With(hasvel).ForEach((Entity entity) =>
{
if (Input.GetKey(KeyCode.Space))
{
PostUpdateCommands.RemoveComponent<PhysicsVelocity>(entity);
}
});
Entities.With(novel).ForEach((Entity entity) =>
{
if (Input.GetKey(KeyCode.Delete))
{
PostUpdateCommands.AddComponent(entity, new PhysicsVelocity());
}
});
}
}
shouldnt be anything wrong with that right?
this sounds like it's crashing if you do the add/remove in a job tho
but worth checking still
I mean, it's just toggling the setting on/off from the main menu
well i suppose its not crashing when I use this in the physics samples github project
but it spits out a ton of errors and the world goes wonky
did try without burst and also adding
[UpdateAfter(typeof(BuildPhysicsWorld))] to the top
postupdatecommands should be the same as using a command buffer with the EndSimulationEntityCommandBufferSystem right?
I wouldn't know 😃
could you link xoofx' post thread?
thanks
ah finally got it working with a jobcomponent system with a proper job handle dependency to the physics world. now I cant remember what I planned on doing with it
I'm getting some oddities with Rigidbody.MovePosition
this is the code
and even with no y, the rigidbody is moving down slightly when rubbing against a perfectly perpendicular wall
this is the scene
any reason as to why this is happening?
is that gravity acting on it? im not familiar with 2d physics(is gravity at 0?)
ya gravity scale is at 0
oh nvm then
I freezed rotation and all of the sudden no variation
coolio
With the new ECS/DOTS and the new Unity Physics, how can I lock the rotation? Do I need to write a system for that? No simple checkboxes anymore? Same thing to lock position in Z for example.
@sullen saddle see this post https://forum.unity.com/threads/unity-physics-discussion.646486/page-6#post-4445458
comparing new ue4 physics to new unity physics is quite interesting, they seem to be on the opposite ends of the spectrum, new unity physics is specifically stateless, while new ue4 physics seem to extremely depend on states to keep things performant
full featured vs barebones, hoping the full havok integration competes with chaos
Hi guys. Does anyone know of problems with Physics.OverlapSphere at the moment? I've seen a few reports of unexpected behaviour, and I've just wasted an afternoon trying to implement something only to conclude it just doesn't seem to be working, at all?
For example, I place a primitive sphere of radius 0.5 with 0.5 radius sphere colliders at x, y, z, and perform OverlapSphere at x, y, z with a reasonable radius, and get nothing. With a very large radius, I detect the sphere.
Performing an OverlapSphere at 0,0,0 with seemingly any radius at all (including 0!) is detecting ALL colliders in the scene.
After a little more looking around it appears that Overlap is only working if the object has been created in a previous Physics tick/frame...?
I mean it makes sense
I just can't find any documentation of this.
I've just set up a simple script to create a gameobject with collider on start, and then do a sphere and boxoverlap test on it then, at the first FixedUpdate, and the second FixedUpdate.
And I only start getting the results from the second.
The first 2 calls return nothing. 🤔
Closest I can see is If you move colliders from scripting or by animation, there needs to be at least one FixedUpdate executed so that the physics library can update it's data structures, before a SphereCast will hit the collider at it's new position.
Unfortunately this includes creating them.
@frail warren Have you tried Physics.SyncTransforms ? Not sure it works with collider creation... But I think it should.
@sly violet Yeah that seems to be working. Significantly faster I'd expect. Thanks.
Hello every body good morning. Can I ask a question abaut gravity in 2D games here?
sure, what do you want to ask? @rare cedar
Okay thanks @stuck bay . Can i send you a private message in order to not disturb here?
okay, i'm not good with gravity(especally with 2d) but i can try and help
its too quiet, you wont be disturbing anything @rare cedar
in general it's recommended to ask help here, you get more eyes on your problem + you don't take individual peoples time who may or may not be able to help you
most efficient way to get help is just to post the full question here
mind if someone give me some help with steering a car with unity?, i ask in a different server but the response i got was someone start going on about drifting and linked to advance math stuff for realistic drifting
anyone?
anyone know what's wrong with terrian tree leaf that dont move at all after save and close
ahhh, is that even about physics? @latent spoke
@stuck bay your question is super vague
you could get anything as answer with that base info
well i haven't even ask the question yet
ah, it's usually best just to ask the actual question
okay
here's a couple of my questions
or some problems i need help with, the first problem with my car is that when i steer and let go of the W key the forward momentum moves in the original direction of when the W key was pressed, so basically when i turn with some momentum the car moves sideways, another problem is that there's too much sideway momentum, like the car is on ice, those are the main two i am having trouble about
you use wheelcolliders?
well, then you have to describe how your vehicle physics is assembled for anyone to have even slightest idea on what's going on there 😃
here's my code
{
Gear1,
Gear2,
Reverse
};
public GameObject FrontLeftWheel;
public GameObject FrontRightWheel;
public float Acceleration;
public float Steering;
public float TurnSpeed;
public float RearWheelKick;
public float MaxSpeed;
public float CurSpeed;
public Gears Gear;
public Rigidbody m_rigidbody;
float V;
float H;
void GetInput()
{
H = Input.GetAxis("Horizontal");
V = Input.GetAxis("Vertical");
}
void GearChange()
{
if (CurSpeed <= 0)
{
Gear = Gears.Reverse;
}
if (CurSpeed <= 5 && CurSpeed > 0)
{
Gear = Gears.Gear1;
}else if (CurSpeed <= 8 && CurSpeed >= 5)
{
Gear = Gears.Gear2;
}
}
void Steer()
{
float Yangle = -Input.GetAxis("Horizontal");
transform.Rotate(0, -Yangle * Steering * Time.fixedDeltaTime, 0);
m_rigidbody.AddRelativeForce(-Vector3.right * CurSpeed * Yangle / 1);
}
private void FixedUpdate()
{
GetInput();
GearChange();
Steer();
CurSpeed = transform.InverseTransformDirection(m_rigidbody.velocity).z;
if (CurSpeed < MaxSpeed)
{
m_rigidbody.AddRelativeForce(Vector3.forward * V * Acceleration * Time.fixedDeltaTime);
}
} ```
btw i know some variables aren't use for anything, they where just for testing
also i want to know a good way of making steering effected by speed, i can't for the life of me find a tutorial on how to do this without making turning feel weird
if you make physics based vehicle, you don't do things like transform.Rotate 😃
you do everything with physics forces
i did, but it was too slippery
what kind of handling is your target?
handling?
what you need your vehicles for?
for a game?
ok, so something very basic then
you know this tutorial? https://www.youtube.com/watch?v=LG1CtlFRmpU
A rundown of the general principles used for arcade-style vehicle physics using Unreal Engine 4 for the upcoming party combat racer Space Dust Racing. Dev bl...
(it has nothing ue4 specific in it)
nope
that explains super bare bones arcade handling raycast vehicle
i am trying to get a feel more with something like the Dust storm from burnout paradise
that's a lot harder then 😃
okay, but can you help me with my code?, like how to make the turn effected by speed?, or the physics problems i listed? because so far none of this answers my problems that i been trying to solve for a while?
well i fixed the sliding problem by lowering the X velocity when H is not held down
well, you can look at the video I linked and see how they did the turning there
it's basically similar solution to yours but they do turning via torque
How i can change position using RigidBody2D? I don't remember. AddForce?
but they also add extra force there based on velocity too
@wary geode you can use alot of solutions like MovePosition(i dunno if it's in Unity 2d tho) but yeah AddForce can help make your character move
can someone at least help me with making turning effected by Speed?, because that's one thing the tutorial didn't answer and i can't find a solution too
@stuck bay
for rotating via torque: https://youtu.be/LG1CtlFRmpU?t=248
for keeping traction while turning (even without pressing throttle: https://youtu.be/LG1CtlFRmpU?t=285
.......
you said your vehicle keeps moving in old direction if you stop hitting W
this is what fixes that
NO
IT DOESN'T EVEN ANWSER MY QUESTION, I AM TURNING BY TORQUE
m_rigidbody.AddTorque(Vector3.up * H * Steering * Time.fixedDeltaTime, ForceMode.Acceleration);
typing on caps will not make people help you more
well i am barely getting any help anyways so what's the point?
good luck 😃
ugh, fking hell
@JellyBelly#5965 I think i am in wrong place? I dont even know which will help with terrian tree issue?
can I somehow find out in the collision even what kind of type the other collider has?
like if(collision.type == Circlecollider)?
and then just cast it as CircleCollider
You can cast it with
CircleCollider circleC = collision as CircleCollider;
if(circleC != null){
//is CircleCollider
}```
@median frost if that's what you mean
Hmm. Usually you check, then cast:
if (other.collider is CircleCollider) {
CircleCollider otherCircle = other.collider as CircleCollider;
...
}
That's more expensive
Also you're casting safely after a check that tells you that you can cast unsafely
With the newer C# you can do the is check with a pattern match
@hollow echo @sly violet thanks
I am doing a top down 2d rpg
do you guys know a simple way to make me "not able to walk through walls"?
this is my code: https://pastebin.com/Ww9ESXM0
I have a small circle collider on the feet of my player and on the "foot" of a tree
I want that on collision just to set the player a bit back s.t. he doesn't move through
You cannot use transform.Translate, you need to use a Rigidbody2D and apply forces
this kind of works but it is a bit bumpy, sometimes jumps into a bit of the wrong direction
but I wanted to do the movement without forces since it seemed easier to me
but probably the reimplementation of exactly these issues makes it hard again, right?
without forces you're not interacting with physics and hence walls are meaningless
I mean I have no problem with forces or the physics behind it, just that if I then stop, I have to set forces to 0 etc instead of just not moving
yeah that is why I tried to reimplement the functionality myself but probably a bad idea
You can do it manually with casts, and it might work better for you. There's an example here https://unity3d.com/learn/tutorials/topics/2d-game-creation/player-controller-script
@hollow echo thanks! I'll take a look 😃
yup that was exactly what I needed
calculating the velocity yourself is a much more clever way than what I did
anyone had a chance to mess with the new unity physics?
anyone got five minutes to talk through an idea?
I have a project which is set in space, and involves very fast movement at times, and i am looking for a cast iron way to calculate collisions.
At times, it is clearly possible for an object to move far enough during a frames processing that the physics system is not going to calculate a collision because the objects dont technically move simultaneously. If the bullet moves say 5 units in one frame, and the ship also moves five units, but is three units long... theyll pass through the same space but wont collide.
I am thinking of a method using ecs.
Due to the nature of my game, a large portion of other aspects of the physics are unnecesary, i can then code my own as seems necesary really with ecs anyways.
So, i am thinking of a method where as the ship moves, during the frame, it leaves like a trail of bounding boxes of broad simplistic composition, which the bullets then calculate their own contacts with.
Whilst this does not provide an ideally accurate solution with regards to accuracy... if they are moving at the kind of speed it possibly would miss... but frankly its probably better to encourage more incorrect hits than allow too many incorrect misses. That is, assuming the gun is at least pointed at the right angle hehe
How does it sound?
I'd just use sweeps/raycasts
Two sweepcasts won't catch each other.
Will two rigidbodies with continuous dynamic collision detection catch each other in that scenario?
was more of thinking to sweep in front, like most character controllers do to detect if they are about to hit a wall
CCD helps but it's not always catching everything
CharacterControllers/sweeps are great for fast colliders hitting slow or stationary colliders. It seems inapplicable to the problem described, which is detecting multiple fast bodies on an intercepting course.
@zinc furnace : Can you live with them all being spheres? It's not too hard to calculate the closest approach of two velocity vectors.
ah, if you mean like two objects moving in completely different directions then sure
that kind of setup would catch head-on collisions tho
if you don't have a ton of objects, you could sort nearby ships that could potentially collide and the the point of collision from their trajectories, then calculate the moment both ships would be at that point and check if the time the overlap that point is within some threshold
Im using ecs ... no access to the usual physics, if i use movement systems, they'll just overwrite the physics every frame. The movement system would move the object then the physics would try to apply drag and such... All to no avail as the movement overrides the physics next frame.
Im also fairly sure that if i do sweeps then its a) not gonna catch each other, and b) gonna basically force me to use a hybrid system
@Olento, its a wide empty gulf of space, most of it.
I can, for instance, only calculate the physics to such detail when bullets are nearby...
Or reduce calculations to nil when nothing is close.
Excluding momentum and drag based stuff of course.
I have interest to use ecs as it will allow a lot of other important behaviours on the backend server, so makes sens on the client too.
Im thinking, after more consideration, that the ship will take its bounding box, and place it in interpolated positions. The result being the simplest collider shape would be used to cover its trail, and it would use a number of copies equal to how many needed to make the length continuos.
Also... The speeds required to meet the criteria of the issue im trying to avoid are such that the player's chance of really seeing if the hit was a hit are very low.
In my experience tho, if you fired bullets at more than 300 units per second, then theyd easily skip the target on a slow frame. If you try 600 they'd skip most frames, and if you tried 1000, you'll never hit. Altho, of course, i expect this to scale with your cpu/gpu power, which makes the whole scenario even less acceptable.
If you process on a fixed time step like most physics, then the skippage shouldn't be affected by the frame time, so that's one thing. 😉
I would again recommend finding the closest approach. It's not too difficult and will give you a very good answer.
First, you set one object as the reference point (probably the ship) and treat the other (bullet) as its position and velocity relative to the ship.
Then you solve for the closest approach, which tells you where and when that is:
https://en.wikipedia.org/wiki/Distance_from_a_point_to_a_line
From that you can determine whether two spheres collide in the given frame without using external physics at all.
The distance (or perpendicular distance) from a point to a line is the shortest distance from a fixed point to any point on a fixed infinite line in Euclidean geometry. It is the length of the line segment which joins the point to the line and is perpendicular to the line. Th...
Finally, if there's a lot of bullets, you'll probably want some way to only check the ones that are reasonably nearby.
Would this be a good spot for physics related code issues of a very basic level, or would that be better for #💻┃code-beginner
Right now I'm working on building out a basic movement player controller, back to basics here. The end case I am wanting to have is directional input system that generates relative force as a constant on the player.
this.GetComponent<Rigidbody>().AddRelativeForce(new Vector3(0, 0, verticalSpeed));
The issue at this current moment is that by accelerating the player in a direction I seem to be negating my downward/gravity based velocity, essentially causing a gliding behavior.
Odd. AddForce shouldn't have that sort of effect.
It's very odd, this is on FixedUpdate and I am only inputting velocity in the chosen forward or horizontal axes relative to the player
Other than a simple Jump AddRelativeForce I'm not touching my vertical velocity
Is your gravity the built-in gravity?
At this point in time I believe so, the gravity is currently set to Y -9.81
It's the default gravity
Would the solution here be to just keep radically increasing my mass and the force I'm applying to get the downward velocity I want?
No. Gravity is mass-independent, anyway.
Well, the velocity imparted by it is mass independent, I mean.
Really, what you've told me doesn't make sense. Something else is up.
Right, my tired brain should have told me that
That's really the entirety of my movement code itself. My jump is essentially the same line but with the velocity applied in the up direction
Changing the drag also isn't changing my behavior here
Add relative will be relative the the current orientation. Practically any kind of relative force will alter orientation.
Weird problem...
I have this ship deck.
Has a Convex, Non-Trigger Mesh Collider.
Has a Non-Kinematic Rigid Body.
I have a Character Controller attached to my object.
My Character Controller can stand above the deck (falls off when the deck is made a Trigger)
But, I can't fire the OnCollision/OnTrigger events on my script (Ship Floor)
Am I missing something here?
Make your Convex, Non-Trigger Mesh Collider a kinematic rigidbody
Or a static rigidbody
Are the layers correct?
should be, my character controller can sit on top of it. and if i disable the deck it falls through
(normal Player/Floor layer interaction for my game)
hmm.. ok. so i just reversed the mechanic by checking for the floor manually by raycasting from the character controller
OnTrigger takes Collider as a parameter, not Collision
And yeah, CharacterController is not a rigidbody. Usually it'
it's better to use a controller with rigidbody than character controller
...I'm genuinely curious what would happen to your CharacterController if that ship starts rocking. My gut instinct is that it won't work well, but I'm not sure.
Is there a way to make an object recognize a collision on the same frame it's activated?
on frame 500 the collider of my object is enabled like this someObject.GetComponent<Collider>().enabled = true;
but until frame 501 the OnTriggerEnter is not called
No. It won't get triggered until the next physics step. You might be able to use an Overlap function to detect the situation.
Unfortunately, Unity 3d physics only has Overlap functions for primitive shapes, and not a generic Collider version.
@sly violet I see, thanks anyways!
Unless theres a way to force a physics step manually I think I'm out of luck on this one 😅
Well... There is:
https://docs.unity3d.com/ScriptReference/Physics.Simulate.html
Note that this will move everything with a velocity and all that an extra frame.
yeah I tried that one today, didn't seem to work
unless I did something wrong, which is entirely possible
oh wait
I had to turn off Physics.autosimulation
It seems to work now
Physics.autoSimulation = false;
//Enable colliders
if (//OnTriggerEnters have been called)
{
//My code
}
Physics.Simulate(Time.fixedDeltaTime);```
so how does Physics.Simulate(float step); work?
the bigger the step the further the calculations are made?
It's the equivalent of the physics Fixed Timestep project setting in Time.
oh I see, I think I get it now
I'm trying to detect if an object with a Sphere Collider is inside of a Mesh Collider but they don't detect each other
OnTriggerStay only fires when the sphere collider is intersecting with the "surface" of the mesh collider
but if it's completely inside, nothing happens
Any idea about how to solve this? I need my mesh collider to be non-convex
A non-convex mesh collider cannot be volumetric (filled in) so you're basically out of luck. Can you put some sphere colliders in it such that your triggerer won't be able to avoid them all?
I have a job that produces a NativeArrray<RaycastCommands> for batching later
NativeArray<RaycastHit> rayHits = new NativeArray<RaycastHit>(commands.Length, Allocator.TempJob);
JobHandle batchJob = RaycastCommand.ScheduleBatch(commands, rayHits, 1, setupJob);
batchJob.Complete();
for(int i = 0; i < rayHits.Length; i++)
{
if (rayHits[i].collider)
{
Debug.LogWarning("Hit " + rayHits[i].collider.name);
continue;
}
break;
}
but the batched ray never hits anything despite that I have checked the values with a normal ray
RaycastHit hit;
if(Physics.Raycast(commands[0].from, commands[0].direction, out hit, commands[0].distance))
{
if(hit.collider)
{
Debug.Log(hit.collider.name);
}
}
which does hit.
So I have no idea if I am doing something wrong
@timid pebble hard to tell from that snippet
you didn't show your setupjob
I mean, you clearly have commands[0] setup if the latter code runs
but there could be something that would explain this on the setup stage
batched raycasts do work for me and I don't immediately spot anything wrong on the part you shared here
[BurstCompile]
public struct SetupCommandsJob : IJobParallelFor
{
[DeallocateOnJobCompletion]
[ReadOnly] public NativeArray<PreviousTranslation> prevPositions;
[DeallocateOnJobCompletion]
[ReadOnly] public NativeArray<Translation> curPositions;
[DeallocateOnJobCompletion]
[ReadOnly] public NativeArray<Rotation> rotations;
[WriteOnly] public NativeArray<RaycastCommand> cmds;
public void Execute(int index)
{
cmds[index] = new RaycastCommand
{
from = prevPositions[index].Value,
direction = math.forward(rotations[index].Value),
distance = math.distance(prevPositions[index].Value, curPositions[index].Value)
};
}
}
I did it with IJobForEach<T> originally but in a scramble to resolve the issues its now using IJobParallelFor. All I know is that I have some refactoring to do
But for now I just left it to a forloop with Physic.Raycast until I figure out what the issue was
why does ecs physics not have a ColliderOverlap (other than aabb) but it does have a ColliderCast?
and ColliderCast with 0 length gives an assertion failure
those questions might be better asked in the forum thread so the havok guy could answer
is there any information on when unity will put out physics2d for ecs?
I wanted to rewrite the system with slightly different data types, but not sure yet if it is worth it,
if anyone has looked through the new unity physics code, would it be difficult to replace the solvers and raycasting solution with 2d shapes? I think it would be?
I haven't seen a whole lot of related to 2D anything for ECS
Maybe this will yield some results:
https://forum.unity.com/threads/ecs-physics-2d-collisions.661411/
thanks!
okay, so for anyone following this topic and having similar questions,
in another thread there was an official statement by an unity employee, was from april,
- Unity Tiny is being ported to c# as you might know, it already has some 2d systems in place,
- those systems are expected to arrive somewhere with 2019.2, prediction was Q2 2019, 2d physics should be included
in case I misinterpreted something, here is a link
https://forum.unity.com/threads/c-update-for-project-tiny.643000/
new experimental 2019.1 / PhysX 4.1 build: https://forum.unity.com/threads/physx-4-1-in-unity-experimental-builds.634960/page-2#post-4512052
heh, Unity Hub 1.6.2 can't deal with custom editor if there's same number engine version installed already 😄
luckily there's been an update to 2019.1 so I can differentiate these again
it's still an oversight as there will always be experimental editor versions and 2019.1+ doesn't even come with it's own launcher anymore
thought that was ecs for a second 😦
oh snap, I got a use case where I would have needed those trigger vs trigger collisions on that that physx 4 build
I know I can workaround it by duplicating each trigger with kinematic collider of the same shape but it's pretty ugly setup
Why not just do overlap check?
because I'd need kinematic bodies then still
plus I'd expect you lose some of the optimization if you do manual overlap checks vs use built-in triggers, especially since you have to go through interop layer with physx for each poll
manual overlap checks should be pretty expensive in comparison,
the regular physics update should do broadphase in one iteration and has probably some other optimizations, instead of checking each body individually against the whole world
Whats the proper way to move a physics body in its forward direction? I have tried physicsVelocity.Linear = math.forward(rotation.Value) * (speed *deltaTime). It ends up just pushing itself through other physics bodies or falling through the floor. Using the preview Unity.Physics and this is phone coding so it may be slightly off
@timid pebble well, you are hardcoding it's velocity so that's kinda expected, it can't slow down as you reset it each update back to full speed
use forces to move it if you want it to interact
if you hard code everything or do everything manually, you also have to react to the collision resolution manually - so for example when a penetration happens you probably want to change the speed + change the forward rotation for example to the hit normal or sometihng
not the best idea to do it like I described, but generally that could be to keep in mind I guess
Well the reason I did that is because I could only find ApplyImpulse nothing for consistently applying a force
Ah, I see now. Unity.Physics.Extensions is where I should be looking
the manual overlap is indeed more expensive but how many of those are you doing? 1 query vs world is nothing.
for example you might do it for weapons, and so how many weapoms are requiring collision at a given moment? it usually boils down to a handful in most games
so what does it mean when an impulse is applied to a contact pair? Looking at https://docs.unity3d.com/ScriptReference/Collision-impulse.html whats the best way to get the impulse applied directly to my object?
Theoretically it should be just half the impulse, AFAIK. Every action has an equal and opposite, conservation of momentum, and all that. I'm not sure if that's correct if one of the colliders is kinematic or static, though.
thats not my problem. i understand what impulse is and the math behind this stuff. I cannot understand what body this impulse is supposed to be applied to. while debugging the direction of the impulse using Debug.DrawRay it doesnt seem to be the impulse of either bodies. The magnitude seems to be fine but is the direction just completely useless? I launched two balls coming in from opposing sides and each give me an impulse in a nearly same direction... I cannot imagine how this could be useful to me.
...What are you trying to do?
real time mesh deformation on impact
Ah. You might try getting the magnitude from the impulse (the direction of the impulse won't help for that I don't think) and using the contact normals for direction.
the normal is just the normal of the vertex collided, not the direction in which force will be applied. a good example of when this will give me inaccurate results would be a ball sort of skimming on top of a sphere
i do use contact point and have successfully gotten mesh deformation on impact but only coming from a specific direction, this is because of the results that i dont understand from the impulse and lack of other things to use. i dont really understand why unity hides so many details about these collisions
Well, one last thing you can do is just track the change in velocity. Keep in mind IIRC you'll need to compare with not the immediately previous FixedUpdate, but the one before.
adding relative velocity and the normal might actually work. debugging the rays it seems perfect but i wanna do more research and check to see if this is what would actually be used because at this point i just need to know
maybe im just completely thinking about this wrong
impulse is definitely a wacky value im pretty confident in that at this point
ima do some research and update here once i figure it all out
in ecs physics, if I use a colliders CollisionFilter for a raycast, it should ignore that particular collider right?
hmm maybe I was wrong with this assumption? is there a way to ignore a specific collider with raycasting(like so a character doesnt raycast itself)?
You have to use DOTS physics shape
found the answer to my question, its currently unsupported https://forum.unity.com/threads/unity-physics-discussion.646486/page-7#post-4473808
are you sure? I've got raycasts ignoring specific bodies in my scene
// Now cast the ray and see if the it hits any colliders.
var rayCastInput = new RaycastInput
{
Ray = ray, Filter = new CollisionFilter
{
CategoryBits = ~0u << 2, // Belongs to group Raycasts
MaskBits = ~0u << 2 // Only collides with Raycasts group
}
};
are the ray casters sharing the same filters as what is being raycast against? that forum post says this currently doesnt exist?
Hmm. Mine is casting the ray from the camera, so its probably not the same case, sorry.
np my situation is collider to collider that share the same filter(but I want to ignore the originating collider)
@fallow gorge you probably saw my question on this topic here https://forum.unity.com/threads/unity-physics-discussion.646486/page-6#post-4457455 (and the answer two posts below)
yeah I did 😃 just gonna offset the raycast position for now
@lapis plaza did you ever explore GroupIndex on collision filters over the category/mask bits?
I didn't have time to try it out yet
it's not a huge issue right now, can workaround it by abusing the categories
CollisionFilter filter = new CollisionFilter
{
CategoryBits = 1u << (int)PhysicsLayer.RayCast, // (int)PhysicsLayer.RayCast == 0
MaskBits = 1u << (int)PhysicsLayer.Ships, // (int)PhysicsLayer.RayCast == 1
GroupIndex = col.ColliderPtr->Filter.GroupIndex // entities (ships and bullets) on the same team share the same negative int
};
this is what Unity does on the vehicle sample scene atm
per an example from that thread
(they just put each vehicle to their own category)
I mean, it does work when you have only few vehicles 😄
not that great if you have like open world with hundreds of them
could still pool and reuse the categories for visible objects only that need it but it gets really hacky quickly
Not sure if this is the best place to ask - but a question about quaternions...
Been trying to understand whats going on, and, so far, it would appear that the xyz component is a unit vector, defining an axis for the magnitude to work around. The rotation quaternion used to describe the current rotation of an object could be said to be the result of taking quaternion.identity and rotating it around the axis defined by its xyz, an amount equivalent to say 360 degrees divided by the magnitude? A magnitude of 0.5 around an axis would provide then 180 degree rotation around said axis?
please @me if anyone can confirm (or deny) my understanding.
They're complex numbers so your intuitions may be a little incorrect - it's hard to tell based on your description
Basically they're unit-length axis-angle rotations.
For rotations the quaternion is a unit quaternion, and that's what you're dealing with in Unity
To use them you don't need to understand their makeup practically. Just use the API, AngleAxis is an extremely helpful one.
Using quaternion multiplication is also a good thing to understand. A * B => A "rotates" B
Im currently needing to hardcode the transfers for ecs...
Trying to code in rotational inertia, and rotational thrust.
Not sure I understand, there should be good maths functions in the Mathematics library, they have AxisAngle, LookRotation...
You construct the rotation using a function like that and then apply it with multiplication 🤷
If you for some reason want to construct them via Euler angles you can also use the Euler functions
@zinc furnace to attempt to clarify what your original explanation could have meant, a quaternion is not: axis, angle, it's magnitude is always 1. That way any resultant multiplication also has the magnitude of 1.
A quaternion is instead structured like: (axis * sin(angle * 0.5), cos(angle * 0.5))
seeing as the axis is always a unit length, this equation means that the axis and angle are scaled inversely and contribute as such to the magnitude.
Because of this though it's difficult to intuitively look at a unit quaternion's values and understand what the resultant rotation may be, only that if there is a magnitude in the xyz component, or xyz and w, then there is a rotation; and if w is 1 then there is zero rotation (ie. it is the identity).
Thanks for the answer @hollow echo
(axis * sin(angle * 0.5), cos(angle * 0.5)) would only give two values tho?
axis is a 3 component vector
oh i see
so its kinda backwards when the w comes at the end in the quat objects then?
no ... at the beginning...
im very tired hehe
Well, from what I wrote it aligns fine with unity's makeup, but it's actually not a standard and you often find them as:
w, x, y, z
would i be right in thinking that when you try to apply a quaternion with a magnitude != 1, is when your mesh will disappear?
Uh, I'm honestly not sure what happens, with the standard transform Unity complains loudly
ok, in ecs which is what im using atm, it makes the meshes disappear i think... not 100 % sure, but it definitely happens if a NaN creeps in
Would you be up for a quick discussion, a bit more of an indepth topic, very much physics tho.
?
(I tend to ask a lot of questions 😉 )
Nah, I'm not really much of a physics person 😛 I just know a little about quaternions 🤷
ah, ok fair enough 😃
Anyone free to give any comments on modelling the torque and rotational drag in a physics system, pure newtonian physics, without gravity. Quite arcady, i think, but full 3d, its spaceships!
Its for ecs, and i can have my rotations accessable as Eulers, so i think i will try to use those, and then it should be easy to keep a set of speeds for each axis, and modify them with acceleration rather than directly controlling the rotation...?
latest (second) Unity Physics package doesn't seem very happy when building with IL2CPP 😃 ```Temp\StagingArea\Data\il2cppOutput\Il2CppAttributes.cpp(58784): error C2039: 'numeric_limits': is not a member of 'std'
it's coming from [SoftRange(0f, 1f, TextFieldMax = float.MaxValue)] tag on PhysicsMaterialCoefficient struct
if I remove it, it does build without errors
but it also crashes on standalone immediately now 😄
crash is access violation on cpp // System.Void Unity.Collections.LowLevel.Unsafe.UnsafeUtility::InternalCopyPtrToStructure<Unity.Transforms.Translation>(System.Void*,T&)
oh well... I'll try on 2019.1 next, this was on 2019.3 😃
2019.3 also creates wrongly named data directory for IL2CPP when you use SLN creation option (it's proper if you build it fully on editor)
will see what all is 2019.3 issues and what not and try to file issues for these
How do raycasts and other queries work with rigidbody interpolation enabled? Our projectile system works with small linecasts each frame, but our fixedupdate is significantly slower (20fps). Do queries check against the interpolated collider or against the uninterpolated?
The npcs are vehicles that can go quite fast, more than 100 m/s
So there is a big jump from fixedupdate to fixedupdate
I haven't tested this but I've implemented this on other game engines. Normally you wouldn't actually alter the collider locations to the interpolated locations as it changes the physics engine state
in some games you do need to trace in regular Update tho and then you kinda have to do this
I haven't tested how this works in Unity, but I'd be surprised if they didn't just keep the latest physics state on Update() instead of feeding the interpolated state back to PhysX during update
@tardy spear could probably confirm this if he's around
but you can also easily test it yourself
just put big deltatime for fixed update, put some debug draw to your physics simulated objects and ray hit points
I think physics debugger on unity would be fine for visualizing where the colliders go
Yes, interpolation for 2D/3D physics is done by keeping the last physics body pose then interpolating to the current physics body pose. Extrapolation is done by interpolating from the current physics body pose to a pose based upon the last lin/and vel at that pose. It drives the Transform not physics state per frame update in between simulation steps.
So interpolation is always behind, moving to the current pose. Extrapolation is always ahead moving from the current pose to some potential future pose.
Queries always check the current physics state as it's not related to transforms. Interpolation/Extrapolation is a rendering thing, not physics.