View Issue Details

IDProjectCategoryView StatusLast Update
0004941The Dark ModPhysicspublic20.01.2019 07:15
ReporterSpringheel Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityhave not tried
Status closedResolutionwon't fix 
Product VersionTDM 2.07 
Summary0004941: Odd Ragdoll behaviour
DescriptionWatch the video in the link below. You can see that the ragdoll seems to be getting some kind of impulse that causes it to regularly roll around. Could be related to the rug? Doesn't appear to happen when thrown on the bed or against other models.

May be a fluke, but something to watch out for if it gets reported by others.

This is in the basement area of Cleaning Out the Neighbourhood beta.
TagsNo tags attached.


related to 0004970 resolvedstgatilov Avoid problems with rotation-resized models 




08.01.2019 20:22

administrator   ~0011259

Last edited: 08.01.2019 20:22

I tried reproducing this in a testmap with various rug models and could not. I'll have to try isolating that part of the map in particular. I'll leave this assigned to me until I can get a decent testmap, unless someone else wants to claim it.



09.01.2019 00:57

administrator (458,791 bytes)


09.01.2019 00:58

administrator   ~0011263

Ok, I isolated that part of the map in a testmap and was able to reproduce the behaviour. Map is now attached.

Load the map; KO the AI directly in front of you and drop him on the rug in that room a few times.


10.01.2019 17:04

developer   ~0011302

I've had a quick look at this, but couldn't find anything obvious. I'll leave this task to someone experienced with the ragdoll code.


12.01.2019 11:15

administrator   ~0011326

Last edited: 12.01.2019 11:15

Found the place.

I'm pretty sure something is wrong with the rug.
I enable:
  g_showCollisionAlongView -1
Then a cube should show intersection point of a ray with anything.
It clearly shows something weird: the cube is not even in the center of the screen. So idClip works incorrectly with this rug.



12.01.2019 15:58

administrator   ~0011329

Ok, the problem is with particular entity func_static_1100.

Its "rotation" matrix is not orthogonal/orthonormal. Something like:
  -0.724 0.194 0
  -0.194 -0.724 0
    0 0 0
As you see, it multiplies the size of the rug by about 75%, efficiently changing its size.
And it is known that doing so with meshes in general and especially with collision models is a very bad idea.

I have changed the matrix to perfectly orthogonal:
  -0.965926 0.258818396803 0 -0.258818396803 -0.965926 0 0 0 1
And ragdolls behave normally afterwards.


12.01.2019 16:02

administrator   ~0011330

While this is clearly a map problem, I would like to hear from mappers what should be done to avoid such issues in future.

I see two options:
1) Write warning to game console whenever an object with clip model has non-orthogonal rotation matrix.
2) Duplicate the collision model in question, scale it physically, then attach the new collision model with normalized matrix instead.

The first one looks better to me...


12.01.2019 16:29

developer   ~0011332

As we know, warnings typically get ignored, so fixing it on our side would be best.


12.01.2019 17:08

administrator   ~0011335

Fixing it on the side of TDM engine means transparently duplicating collision models and probably even rendermodels per every such entity. Doesn't it sound like performance abuse?
One might argue that it should be fixed on DarkRadiant side. I'm pretty sure DR has some ways of scaling objects. If it generates such output, then it would be fixed or restrained. If it does not, then one should learn how these objects were placed and restrain that way.


12.01.2019 18:22

administrator   ~0011336

I suspect Bikerdude did that. He apparently wasn't aware that there was a proper method for resizing models in DR now and used an old rotation hack.


12.01.2019 20:17

reporter   ~0011338

Last edited: 12.01.2019 20:24

Rotation hacking is also used in at least one TDM prefab (furniture/tables/office_desk_witems.pfb -- the small bust and the book row: I remember tracking down a shadowing problem in a w.i.p. map to that book row).

Edit: re. the rug, it's also possible it was rotation-hacked to change its footprint without changing its height, since DR's scaling seems always to preserve proportions.



13.01.2019 05:46

administrator   ~0011340

In this case only XY dimensions are resized, Z dimension stays the same.
So yes, this is "anisotropic" scaling, which means that even normal directions change, not just lengths.
Probably talk to greebo about anisotropic scaling in DR?

Anyway, something must be done to prevent such situations on TDM side. Right now mapper can live for months with such entities, having all sort of weird bugs.


13.01.2019 07:31

administrator   ~0011341

I have added a script to /devel/

Running it on "Cleaning Out the Neighbourhood" gives 172 entities with bad rotations, half of them has anisotropic scaling.
It may be that most of them won't cause any issues. But given that issues are possible both with physics and with shadows, I have no idea how to filter them out.

The official maps are much better.
"New Job" has no problematic entities, "Saint Lucia" has only 8.

"Accountant 1" gives 73 entities, only one is scaled anisotropically.
"Accountant 2" gives 81 entities, four of them have anisotropic scaling.
"William Steel 4" gives 129 entities, most of them are scaled anisotropically, five even have skewed transformation (i.e. not being rotation + scale).
"Cauldron" gives only 4 entities.
NHAT: politics has 26 entities, anoott has 32 entities, forest has 22 entities. Some are anisotropic, one entity is skewed.

I'm at a loss if forbiding such entities or producing a warning is feasible.


13.01.2019 07:43

developer   ~0011342

Reminder sent to: greebo

Greebo, do you have some advice for us?


15.01.2019 02:47

developer   ~0011358

Historically, big problems with the rotation hack were cured via
the "inline" "1" arg which would revert the model to worldspawn
and force the map process to re-triangulate based on vert positions.

Are affected models using this arg?

If not, that may limit the scope of the problem.

The source of this pain...,_Resizing,_Models_in_Dark_Radiant


17.01.2019 11:05

developer   ~0011381

Moving to 2.08 as discussed in the forum.


20.01.2019 07:15

administrator   ~0011439

I have extracted the core problem into 0004970.
Closing this issue as "not-an-issue" or "by design".

Issue History

Date Modified Username Field Change
01.01.2019 17:00 Springheel New Issue
01.01.2019 17:01 Springheel Status new => feedback
01.01.2019 17:01 Springheel Target Version => TDM 2.07
08.01.2019 20:22 Springheel Note Added: 0011259
08.01.2019 20:22 Springheel Status feedback => new
08.01.2019 20:22 Springheel Note Edited: 0011259
08.01.2019 20:22 Springheel Assigned To => Springheel
08.01.2019 20:22 Springheel Status new => assigned
09.01.2019 00:57 Springheel File Added:
09.01.2019 00:58 Springheel Note Added: 0011263
09.01.2019 01:02 Springheel Assigned To Springheel =>
10.01.2019 17:04 STiFU Note Added: 0011302
11.01.2019 07:05 STiFU Assigned To => STiFU
11.01.2019 07:05 STiFU Status assigned => confirmed
11.01.2019 07:06 STiFU Assigned To STiFU =>
12.01.2019 11:15 stgatilov Note Added: 0011326
12.01.2019 11:15 stgatilov Note Edited: 0011326
12.01.2019 15:58 stgatilov Note Added: 0011329
12.01.2019 16:02 stgatilov Note Added: 0011330
12.01.2019 16:10 stgatilov Assigned To => stgatilov
12.01.2019 16:10 stgatilov Status confirmed => assigned
12.01.2019 16:29 STiFU Note Added: 0011332
12.01.2019 17:08 stgatilov Note Added: 0011335
12.01.2019 18:22 Springheel Note Added: 0011336
12.01.2019 20:17 VanishedOne Note Added: 0011338
12.01.2019 20:22 VanishedOne Note Edited: 0011338
12.01.2019 20:24 VanishedOne Note Edited: 0011338
13.01.2019 05:46 stgatilov Note Added: 0011340
13.01.2019 07:31 stgatilov Note Added: 0011341
13.01.2019 07:43 STiFU Note Added: 0011342
15.01.2019 02:47 nbohr1more Note Added: 0011358
17.01.2019 11:05 STiFU Note Added: 0011381
17.01.2019 11:05 STiFU Target Version TDM 2.07 => TDM 2.08
20.01.2019 07:13 stgatilov Relationship added related to 0004970
20.01.2019 07:15 stgatilov Note Added: 0011439
20.01.2019 07:15 stgatilov Status assigned => closed
20.01.2019 07:15 stgatilov Resolution open => won't fix
20.01.2019 07:15 stgatilov Target Version TDM 2.08 =>