View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003871||The Dark Mod||Physics||public||08.10.2014 12:26||06.05.2021 12:16|
|Target Version||TDM 2.06||Fixed in Version||TDM 2.06|
|Summary||0003871: Number of ActivateContacs is hard-coded to 10|
|Description||Hard-coded limits are bad. ActivateContacts() has such a hard-coded limit, it always fetches at most 10 contacts from the physics objects and call activate on them.|
If the entity has contact to 11 or more other entities, only a random subset of entities will be activated.
While a hard limit might be unavoidable (the function "::Contacts()" takes a maxContacts param), 10 is definitely too low.
|Steps To Reproduce||Look at the source code.|
contacts.SetNum( 10, false ); // HERE
dir.SubVec3(0) = -GetPhysics()->GetGravityNormal(); // look up
dir.SubVec3(1) = vec3_origin; // ignore angular velocity
idClipModel *clipModel = GetPhysics()->GetClipModel();
if ( clipModel->IsTraceModel() )
// HERE again
num = gameLocal.clip.Contacts( &contacts, 10, GetPhysics()->GetOrigin(),dir, CONTACT_EPSILON, clipModel, mat3_identity, CONTENTS_SOLID, this );
|Tags||No tags attached.|
Are we going to notice a difference between 10 contacts and 11? 12? 13?
Why do you think 10 is "definitely too low"?
I can see where there'd be a difference between 2 contacts and 10, but I suspect id set a cutoff at 10 because it was enough to calculate a reasonable estimate for the physics, and counts larger than that wouldn't change much.
id categorized their physics as "good enough". Unless there are specific situations that are absolutely wonky, I wouldn't spend any time on a general fix; I'd just focus on the wonkiness.
Because if the player stacks 11 items on a moveable plate in my map, only 10 items get activated if the plate/blocks moves.
If the player stacks (or there are) more than 11 items, even more are left floating.
The same would probably be true for elevators in normal TDM FMs. Anywhere a mover has more than 10 contacts and starts to move, some of them will not get activated.
|Has anyone ever reported an actual example of this causing a problem? I'm not aware of any. And we've seen videos of massive stacks of crates all falling properly when the bottom one is removed--I can't recall ever seeing anything just left floating.|
Okay, I read this report the wrong way. I assumed it had something to do with friction.
Now that I'm seeing it for what it really is, I agree that the limit should be removed.
@Springheel: It only occurs with movers + their contacts. A crate sitting on a crate is a "moveable touching a moveable", not a "moveable touching a mover". This is a small, but important distinction, as the code handles both cases in different places and differently.
The limit of 10 only occurs in the latter case.
Increased limit to 128
The limit was only increased in idEntity::ActivateContacts.
However, there are other calls of gameLocal.clip.Contacts, which still use limit = 10:
And this limit is not enough sometimes, leading to unknown consequences....
I have changed it in the following series of commits:
r9343. Increased maximum number of contacts in physics from 10 to 32.
r9344. Maximum supported number of contacts in idEntity::ActivateContacts reduced back from 128 to 32.
r9345. Now size of contacts array in all gameLocal.clip.Contacts calls is set to CONTACTS_MAX_NUMBER = 32. The behavior does not change, it is only minor refactoring.
So now the limit is 32 for all calls.
My commits also rely on idRaw hack to avoid zeroing these arrays without need:
r9341. Added idRaw<T> hack which can be used to avoid idVec3 filling for large local variables.
These changes will take effect in TDM 2.10.
|08.10.2014 12:26||tels||New Issue|
|08.10.2014 19:35||grayman||Note Added: 0007065|
|01.11.2014 12:59||tels||Note Added: 0007108|
|01.11.2014 13:07||Springheel||Note Added: 0007109|
|01.11.2014 13:34||grayman||Note Added: 0007110|
|16.11.2014 14:07||tels||Note Added: 0007136|
|13.09.2017 20:49||nbohr1more||Assigned To||=> nbohr1more|
|13.09.2017 20:49||nbohr1more||Status||new => assigned|
|13.09.2017 20:49||nbohr1more||Product Version||=> SVN|
|13.09.2017 20:49||nbohr1more||Target Version||=> TDM 2.06|
|14.09.2017 02:37||nbohr1more||Note Added: 0009219|
|14.09.2017 02:38||nbohr1more||Status||assigned => resolved|
|14.09.2017 02:38||nbohr1more||Resolution||open => fixed|
|14.09.2017 02:38||nbohr1more||Fixed in Version||=> TDM 2.06|
|06.05.2021 12:16||stgatilov||Note Added: 0013967|