#Is Unity Physics Rebuilding Static Bodies Every Frame A Bug?
1 messages · Page 1 of 1 (latest)
Are you affecting the transforms of those static entities at runtime? An issue we had was some objects that should've been kinematic, were actually static, and as you say - it then spent every frame rebuilding the static physics BVH because their transforms had been written to.
When the entities are spawned, their transform position, scale, rotation are changed, but that is all. They are not moved at all after their placement.
Do you have any systems that have write access to the transforms of those static things? Just accidentally marking those chunks as "possibly written to" it would trigger the change filter, I think?
I do have a system that spawns the static collider entities, but no system that touches them after the fact.
{
Entity spawned = ECB.Instantiate(spawnerComponent.Prefab);
LocalTransform spawnedTransform = new LocalTransform
{
Position = Random.NextFloat3(-halfDimensions, halfDimensions),
Rotation = quaternion.RotateY(Random.NextFloat(0, 2 * math.PI)),
Scale = Random.NextFloat(spawnerComponent.Scale.x, spawnerComponent.Scale.y)
};
ECB.SetComponent(spawned, spawnedTransform);
}```
The entire system: https://pastebin.com/Wx9p9kFD
Interesting, that looks mostly fine to me (as long as the prefab in your SpawnerComponent idoes not itself contain SpawnerComponents! Since that would cause it to potentially generate new things every frame).
How are you ensuring your prefabs are static from the physics systems PoV? Also what version of entities, physics, and the engine are you using?
This is the prefab
If you create a project with no systems, and put a bunch of static physics objects in the world
Does it rebuild every frame?
I am using Entities 1.0-pre.15, Physics 1.0-pre.15
so like put them in a sub-scene at editor time instead of spawning them at run-time?
you can spawn them just don't have any systems opening transforms
so, one system that is spawning them, and no other system?
or is there some other way of spawning at runtime I am unaware of?
for a quick test, just throw 1000 objects in a subscene with no spawning
it shouldn't be updating the static bodies every frame
but you need to confirm this
ok 😅
Ok, here are my highlevel, in-editor profiler results for 204,800 entities spawned in Editor with no systems written by me in the project at all
(may need to open in browser to read, as I have an ultrawide)
and this is the frame immediately after
only seems to build once
you're right that the multiple times per frame that BuildPhysicsWorld is firing, that it appears to only be building the static tree once
but the next frame, it appears to do it again
yeah something is (probably incorrectly) triggering change filters
i wonder what
in theory only opening transform or physicscollider for write
or creating/destroying a static collider
should trigger it
I guess I can zip up this project and submit it as a bug report
i was curious about this
and the reason it updates every frame is one of the change filters is on LocalToWorld
chunk.DidChange(ref LocalToWorldType, m_LastSystemVersion) ||
which is open every frame for writing in the transform system stuff
i suspect this is just some teething issues with the V2 transform update
and when we can properly remove components again it should be fine
Do you know if you comment out that specific check, if it stops doing the update every frame?
as long as you aren't opening localtransform
however it will break if you have a localtoworld entity with no localtransform
i think the proper fix is only doing a LocalToWorld DidChange if it doesn't have a LocalTransform
(!chunk.Has(ref LocalTransformType) && chunk.DidChange(ref LocalToWorldType, m_LastSystemVersion)) ||
something like that
Hello! @wide python is correct, this was a bug in the 1.0-pre15 release, where the transform system itself was prematurely taking Read/Write access on entities whose transforms hadn't changed, which caused a bunch of ChangeFilter checks to fail and a bunch of unnecessary work to happen on otherwise-static entities. It was promptly reported and fixed in the forums; the fix is included in this week's new 1.0 preview release.
Awesome. Btw is there any plan for dots physics to implement incremental bounding volume hierarchy that only update for the dynamic physics body entity that actually changed position and/or rotation?