View Issue Details

IDProjectCategoryView StatusLast Update
0006483The Dark ModPhysicspublic22.06.2024 16:00
Reporterstgatilov Assigned To 
Status newResolutionopen 
Target VersionTDM 2.13 
Summary0006483: Stacked moveables drop into each other after you touch them
DescriptionThe physics code requires about 0.25-1.0 distance between object in order to handle collisions between them properly.

Normally, mapper is expected to put moveables some distance above the object below them.
Then the special "DropToFloor" code moves them down as much as collision code allows at map start (see idPhysics_RigidBody::DropToFloorAndRest).
However, sometimes mapper puts a moveable exactly on top of the object below it, and this problem currently is not resolved.

As the result, the moveable falls into the object below it as soon as you touch it.
Note that if you don't touch it, then the object stays in place because it is put to "rest" at spawn a time.
So it is very difficult for a mapper to detect this issue.
Steps To ReproduceStart Inn Business mission, go to the locations with many moveables.
For instance: "setviewpos 600 -80 70 0 180 0", grab one jar and collide it with other objects.
Another good location is "setviewpos 850 1050 210 0 -90 0": the object here would benefit from better initial placement.

You can also get this issue in Saint Lucia mission.
"setviewpos 1300 3400 -380 0 180 0" and jump on top of the barrel: the barrel falls into the ground.
TagsPhysics, realism


related to 0000665 new Moveables stacked on top of eachother begin to levitate up 
related to 0001073 new Butcher Knife & Kitchen Knife Levitating 
related to 0003543 new Bad physics for small moveables 




10.02.2024 11:22

administrator   ~0016494

The function idPhysics_RigidBody::DropToFloorAndRest traces a ray down and uses the position of first collision to decide where to put object.
The core idea is to start tracing from a bit higher position (by 1.0 at least) so that object can also geet a bit higher if necessary.

It seems that DropToFloor is only used on game start.
In original Doom 3 it was also applied to reaspawned powerups, but we don't use this feature.
Perhaps we can remove the code from runtime, and instead run it globally on map start.
It is much easier to handle all the entities in one piece of code than to run separate code chunks for each moveable and fight e.g. with gravity already turned on.

Speaking of a single function, we can probably do e.g. 10 passes over all moveables performing the adjustment for them.
The exact number of passes necessary depends on how deeply the moveables are stacked.

Another problem is when the moveables are inside each other (e.g. the pillows near the floor at "setviewpos 850 1050 210 0 -90 0" of Inn Business).
Just pushing each entity up will cause all of them to raise simultaneously, thus not resolving the collision.
Perhaps sort moveables by lowest Z and apply the tweak in this order, each time resolving the collision completely.
In this case there is no limit how high an object can raise if it collides something.

Finally, the function "idPhysics_RigidBody::DropToFloorAndRest" has a lot of useful warning, but they are disabled and nobody knows about them.
I guess we should post warnings if entity ends up outside playable area, or we failed to resolve collisions, or if an entity was moved too far either direction.


15.06.2024 12:29

administrator   ~0016740

We cannot lift moveable high.
Almost all existing missions have a bunch of moveables which are "stuck" in something.
Sometimes it is stuck in such a way that if we "unstick" it it will fall away.

For instance, there is a pot with key on a balcony immediately in front of player start.
If I lift object to fully resolve collision, then the pot immediately falls down to the player.

And if we don't lift objects high enough, then some collisions can't be resolved.
For instance, the barrel in Saint Lucia (1300 3400 -380 0 180 0) is half inside ground: that's too much to be lifted.

It is also rather hard to deal with "physics teams", like e.g. typical "holder with candle".
A lot of warnings are probable false alarms.



20.06.2024 10:04

reporter   ~0016762

Is it possible to add warnings to dmaps? So mappers at least see this happening?

Maybe it's possible to alter DR to make this less likelly? Maybe a script that checks for distance of movable entities in relation to each other?

Just some ideas. I mean fixing the current missions might be too much, but including ways to make it less likely that this happens in future missions could be useful.


22.06.2024 16:00

administrator   ~0016767

It is possible to add dmap warnings in general, but it is hard for this case.

Because dmap does not initialize game, entities, physics --- non of this exists.
It can only do very basic checks, which won't be enough.
Same for DarkRadiant, I suppose.

I guess there was a reason why ID introduced "developer" spawnarg and put such warnings under it.

Issue History

Date Modified Username Field Change
10.02.2024 11:11 stgatilov New Issue
10.02.2024 11:22 stgatilov Note Added: 0016494
10.02.2024 14:13 nbohr1more Relationship added related to 0000665
10.02.2024 14:13 nbohr1more Relationship added related to 0001073
10.02.2024 14:15 nbohr1more Relationship added related to 0003543
10.02.2024 21:37 Fiver Tag Attached: realism
10.02.2024 21:37 Fiver Tag Attached: Physics
15.06.2024 12:29 stgatilov Note Added: 0016740
20.06.2024 10:04 datiswous Note Added: 0016762
22.06.2024 16:00 stgatilov Note Added: 0016767