View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006483 | The Dark Mod | Physics | public | 10.02.2024 11:11 | 09.11.2024 17:48 |
Reporter | stgatilov | Assigned To | |||
Priority | normal | Severity | normal | Reproducibility | sometimes |
Status | new | Resolution | open | ||
Target Version | TDM 2.13 | ||||
Summary | 0006483: Stacked moveables drop into each other after you touch them | ||||
Description | The 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 Reproduce | Start 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. | ||||
Tags | collision, Physics, realism | ||||
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. |
|
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. Sigh... |
|
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. |
|
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. |
|
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 | |
09.11.2024 17:48 | Fiver | Tag Attached: collision | |
09.11.2024 17:48 | Fiver | Relationship added | related to 0006541 |