View Issue Details

IDProjectCategoryView StatusLast Update
0003871The Dark ModPhysicspublic06.05.2021 12:16
Reportertels Assigned Tonbohr1more  
Status resolvedResolutionfixed 
Product VersionSVN 
Target VersionTDM 2.06Fixed in VersionTDM 2.06 
Summary0003871: Number of ActivateContacs is hard-coded to 10
DescriptionHard-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 ReproduceLook at the source code.
Additional Information/*
void idEntity::ActivateContacts()
    idList<contactInfo_t> contacts;
    contacts.SetNum( 10, false ); // HERE

    idVec6 dir;
    int num;

    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[0], 10, GetPhysics()->GetOrigin(),dir, CONTACT_EPSILON, clipModel, mat3_identity, CONTENTS_SOLID, this );
TagsNo tags attached.




08.10.2014 19:35

viewer   ~0007065

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.


01.11.2014 12:59

reporter   ~0007108

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.


01.11.2014 13:07

administrator   ~0007109

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.


01.11.2014 13:34

viewer   ~0007110

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.


16.11.2014 14:07

reporter   ~0007136

@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.


14.09.2017 02:37

developer   ~0009219

Revision 7136

Increased limit to 128


06.05.2021 12:16

administrator   ~0013967

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.

Issue History

Date Modified Username Field Change
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