#Physics Enableable Components..

1 messages · Page 1 of 1 (latest)

brave roost
#

I realise this is probably a long shot but is making Physics components Enableable something that's been considered?

#

The use-case for me is that recently i've been implementing something like a re-usable object-pool but for entities that have physics mass/velocity/colliders..
So i think it might be possible to change the PhysicsWorldIndex to a non-existant world index, but haven't tested this. Currently i'm just moving these objects out of view as a temporary solution but it would be useful to simply disable the Physics components and have them not included in the Physics world build, then re-enable when they're needed again.

#

I think it would be useful for a number of other scenarios also, avoiding structural changes, but do understand it might be a whole can of worms in terms of changes to the Unity physics codebase.

#

Disabling the Simulation component does make physics objects effectively static, but they are still included in the world and colliders active etc.

vapid wyvern
#

Hi! Yes, you can change the PhysicsWorldIndex to effectively disable the entire rigid body, and sort of park it.

#

There are a bunch of different use cases here which are related, such as changing disabling a rigid body fully, changing a body's control type between kinematic and dynamic. Depending on the use case there are a few ways in which this could be done efficiently. Enableable components can definitely be part of the solution.

brave roost
vapid wyvern
#

For disabling a rigid body fully, I would suggest you use the physics world index. If that doesn't work, let us know. It should.
We could add some convenience API here to make this feature more obvious, but under the hood that is probably the optimal solution anyways.

brave roost
vapid wyvern
#

For switching control type without structural changes, we don't have any plans for it at the moment. This being a feature requested by users will though definitely help us in establishing the right level of priority.

winter forum
brave roost
vapid wyvern
#

We would need to see in practice depending on how many bodies you need to park whether using enableblable components over shared components would be worthwhile.
The advantage with shared components is that the entities with different shared component values are placed apart from each other, since they will all appear contiguously and in the same chunks. This will speed up processing of the entities which we are interested in, i.e., the ones that are NOT disabled and are in the default physics world.

#

So you are trading off the time spent for a structural change for time gained during processing of the data.

#

It depends entirely on how much work is required during the structural change whether the trade off produces a net positive effect when using one data type over another (shared components instead of enablable components).

#

In your specific use cases, you could do some profiling and see the effect.
Note that for structural changes it is best to do these using the built-in entity command buffers which will all be played back at specific moments in the corresponding entity command buffer systems. This is to avoid unnecessarily having to wait on job completion of the job that uses the command buffer to do the changes you need to do.

#

This can be done via, e.g., SystemAPI.GetSingleton<EndSimulationEntityCommandBufferSystem.Singleton>(), from which you then obtain a command buffer using the CreateCommandBuffer() function.

#

You can use that command buffer in a job through a parallel writer (entityCommandBuffer.AsParallelWriter()), and you don't need to wait on the job completion and manually play back that command buffer using entityCommandBuffer.Playback(), since the system you created it from will do that for you.

#

But you might know that already. I just thoght I'd share this here for completeness' sake.

winter forum
brave roost
vapid wyvern
#

Like I mentioned above, you would not want to have the memory all mixed up through something like this, which will likely slow down the physics world build phase as it needs to filter out all the entities with that enableable component and we will have gaps in the memory access patterns, reducing cache coherence.

#

So, it's not as easy as it sounds.

#

I mean, not "easy", but potentially not as "good"

brave roost
#

Would just adding removing velocity and collider components in an ecb be more or less of a structural change hit than changing shared world index, either way its a structural change.

vapid wyvern
#

If you have small numbers of bodies you need to disable per frame, the structural change cost through the shared component modification might be smaller than the cache miss cost you pay when using enableable components and filtering out while walking through the chunks.

#

I think using the shared component instead of removing velocity and collider components should be faster, but that's just a hunch. We would need to measure that.

brave roost
winter forum
vapid wyvern
#

@winter forum : Precisely

#

@brave roost : Yes

brave roost
#

Okay yep just reread your reply.. damn 😛

vapid wyvern
#

If you use EnablableComponents, when going over the chunk through a query, the ones that are excluded need to be filtered out.

#

Creating gaps in the memory access pattern

brave roost
#

Yeahhh

vapid wyvern
#

With shared components you don't have that problem since the chunks are entirely clean of these gaps

#

See above for an explanation of the pitfalls with shared components in that regard. With different usage patterns you can really shoot yourself in the foot.

#

But if you use it differently, it can be very beneficial.
In the last chapter on this page it's said that if you have many unique shared component values with a low number of entities holding these values, that causes issues since you will have a lot of chunks that are "clean" but almost empty.

#

In our case here, that wouldn't be the case, since we would have exactly two world indices, one for enabled and one for disabled bodies.

#

So there is a very high chance that the entities we are actually interested in during physics processing (physics world build), the ones with the "enabled" value, are in nicely packed and full chunks, while the "disabled" ones are in chunks which we will never even access.

#

If these are empty or not doesn't matter.

brave roost
vapid wyvern
#

Sounds good. You are welcome!

pale dirge
brave roost
sharp helm
#

I can give you a use case for the need for a structural free way to disable physics
Netcode prediction
When a predicted object is destroyed you want to stop simulating it in physics for future frames however changing the physics index breaks and constantly have to roll this back is pretty costly (I really dislike structural changes inside fixed update group as it ruins perf)

#

I actually have a way in core to make any existing component enableable and noticed physics was setup to already support this so I tested it a while ago.
#1064581837055348857 message
You might find it interesting @vapid wyvern

#

I don't suggest that this is default behaviour but a secondary optional tag component might be nice

#

Iterating enableable is fine if 99% of the time they're all enabled or disabled so if it's just used in normal circumstances it should be fine...

#

(basically the stimulate tag except physics specific because netcode hijacks this)

vapid wyvern
#

Thanks! I took note of all that and filed a ticket internally.

fringe compass
#

Disabling physics update for an object is going to be cheaper with enableable component is done quite often and if the disabling is sparse.
Otherwise, a structural change for parking an entire chunk of data by changing the WorldIndex is going to work faster.
For Netcode specifically, we are already using the Simulate tag (enableable) to switch the object we dont won't to simulate to kinematic.
Can be further extended with a couple of other options that specify the behaviour in that case, and you probably don't need to add any further enableable component.

sharp helm
#

Switching to kinematic isn't good enough though

#

We want to be able to remove objects from the physics world to avoid spatial queries on them (and other objects interacting)

#

Also simulate is a bit of an all or nothing solution, can't selectively say don't be enabled in physics but be enabled in other predictive systems without having to slice multiple systems throughout to toggle states

fringe compass
#

I agree, that was the simpleset solution at almost 0 cost implementable in 3 minute.

winter forum
dusty nova
#

Does anyone use the Simulate component for anything?

#

It sounds like it's for netcode, but I'm not sure why it's in the core Unity.Entities if so.

#

Should I use that component if I want to classify my entities as static world vs. dynamic objects?