View Issue Details

IDProjectCategoryView StatusLast Update
0004970The Dark ModDesign/Codingpublic16.02.2023 05:46
Reporterstgatilov Assigned Tostgatilov  
Status resolvedResolutionfixed 
Product VersionTDM 2.07 
Target VersionTDM 2.09Fixed in VersionTDM 2.09 
Summary0004970: Avoid problems with rotation-resized models
DescriptionIt is possible to set non-orthogonal "rotation" matrix to an entity. Then it would be resized/distorted according to the matrix. However, many subsystems (physics, shadows) don't work properly with such entities.
Mappers don't know that, because the problem are rather subtle and show up during beta testing or never at all.

It would be great to do something so that this problem doesn't appear again in future. It is one of:
1) Support bad rotation matrices properly (maybe by duplicating and physically resizing assets --- watch out for dynamical rotations).
2) Warn about such entities loud enough so that mappers know immediately that this is wrong (keep in mind that existing missions have many entities with bad rotations).

Additional InformationExtracted from issue found during 2.07 beta:
Please read the discussion in that issue: it contains a lot of valuable information.
TagsNo tags attached.


related to 0004941 closedstgatilov Odd Ragdoll behaviour 
related to 0004981 resolvedstgatilov Urn in Chalice of Kings gets wrongly pruned 
related to 0004779 resolvednbohr1more Resized models have overblown specular in GLSL enhanced ambient 
related to 0004232 resolvedSteveL skins do not change collision data 
related to 0005186 resolvedstgatilov Make prefabs with rotation hacks comply with new rules 
parent of 0005251 resolved Visual glitch - scissors? 
related to 0006258 new Proxy models (_roth_gen) are not generated on saved game load 




20.01.2019 08:14

developer   ~0011441

A big fat warning should be displayed to mappers in any case.

Another quick workaround would be to dynamically add "inline = 1" when a non-orthogonal rotation matrix has been detected. According to NBohr, this might decrease performance, though, since the entity is converted to brushes.


20.01.2019 15:34

reporter   ~0011446

Inlining affects physical properties no less than rotation hacking: Also it happens during dmap (you end up with a bloated .proc if you inline a lot), so if you wanted to apply it to existing maps you'd have to recompile them and then test for unwanted behaviour. That's not a quick workaround any more.

SteveL reported shadow errors from inlining, as well as a huge slowdown to dmap if it's used heavily within a visleaf:


26.01.2019 09:52

developer   ~0011510

IIRC the wiki already tell the mapper about the fact, that only the visual model is affected by the non-orthogonal part of the rotation matrix.

However, if the visual model can be modified like that, the more important question is why shadows and collision are not affected. Using non-orthogonal transformations to adjust a models size to the geometry in your mission is extremely useful opposed to creating a new model for each usecase, and I have used it in the past, too, although I restricted on minimal size deformations to avoid the issues with that approach becoming too noticeable to the player.

It might therefore be desireable to identify the code pieces responsible for that specific aspects and changing it so they accept such transformations.


08.12.2019 17:03

administrator   ~0011899

Started a lengthy discussion about the problem on forums:

Also, added one more issue due to this: 0004779.
It is reproduced be running Penny Dreadful 2, and teleporting: setviewpos 5300 1100 -700 (the big golden keys underground are culled away sometimes).


14.12.2019 14:05

administrator   ~0011929

Added 0004232 as related, since it explains why some models have ('\1' + skinName) appended to their name.


07.01.2020 09:41

administrator   ~0012109

Committed the change:
  svn rev 8513: fixing models of rotation-hacked func_static-s
  svn rev 8514: dmap complains about rotation-hacked entities

While there is cvar g_rotationHack which controls this new fixing, it only takes effect when the game is started.
Then the value is saved into savegame files and persisted for the whole gameplay.


08.01.2020 09:23

administrator   ~0012120

One more change in svn rev 8517.

Now if dmap detects rotation-hacked func_statics, it forces the dmapper to set g_rotationHack to 0 (turning off the implemented fix).
Without this additional annoyment, there is high chance that some future maps will contain a shitload of rotation-hacked func_statics without any testing under "g_rotationHack 0". This is very bad, because if we decide to remove the fix which I implemented here in future, such maps will become unplayable.


16.01.2020 16:19

administrator   ~0012150

One more change in svn rev 8525.

I fixed R_RadiusCullLocalBox for non-orthogonal rotations.
It was reponsible for clipping away rotation-hacked entities which were enlarged by rotation.
Seeming no more culling problems remain (for static non-shadows objects).

P.S. Ironically, there was a "FIXME" comment at this place =)


16.01.2020 17:32

administrator   ~0012152

Yet another change in svn rev 8526.

Don't do anything with with func_static-s having "bind" spawnarg. Usually the "bind" master changes location of the func_static. Thus, it is not "static" and messing with its rotation is dangerous.


02.04.2020 06:39

administrator   ~0012330

Last edited: 02.04.2020 07:02

Reverted most of the changes in svn rev 8657 on trunk.

Namely, the following commits were reverted:
  r8513 Now func_static-s with bad rotation are forked and transformed. This is done under g_rotationHack cvar. Hopefully, this will remove almost all issues that rotation-hack causes.
  r8517 Throw error during dmapping if rotation-hacked func_static is detected, unless mapper has disabled g_rotationHack. The reason for it is to ensure that mappers either keep their maps clean, or test their maps
  r8526 Don't embed rotation into func_static-s having "bind" spawnarg. Usually the entity it points to dynamically changes the location of the entity.
The following commits remain:
  r8514 Let dmap complain about rotation-hacked entities. Note that all func_static-s get only one global warning, but other entities get individual warnings. Perhaps we should refine this over time...
  r8525 Fixed R_RadiusCullLocalBox to work properly for non-orthogonal matrices. As the result, rotation-hacked entities are no longer culled away erratically.
In particular, dmap will report all rotation-hacked stuff as warnings, but will not throw errors.

There are two reasons for doing so:
1) Related issue 0005186 about rotation hack in stock prefabs.
2) A cleaner idea of proxy models was proposed:


02.04.2020 07:03

administrator   ~0012331

Committed engine support for proxy models in svn rev 8658 on trunk.
Also committed the test map with two proxy models in svn rev 15892 on trunk.


26.07.2020 12:04

administrator   ~0012679

Committed a small preliminary change in rev 8890.

In rev 8891, committed a new way of converting rotation-hacked entities on-the-fly.
Now all entities are convered without exceptions.
Conversion results in "model_*" spawnargs pointing to automatically generated proxy models in real files.

See also:


17.08.2020 12:51

administrator   ~0012739

Last edited: 17.08.2020 12:51

There is one problem with new approach, which blocks e.g. WS4 FM from loading.

The problem happens when the following conditions hold:
1) entity is moveable
2) entity is rotation-hacked
3) entity has no "clipmodel" spawnarg
4) entity's "model" has .cm-file nearby, with same name as the original model
5) the original model cannot be converted to CM e.g. because it has too many vertices

I would say the first two conditions together already make no sense, and is most likely mapper error.
I have detected about 20 FMs which have any .cm files except for the main one for the map.
Let's hope that most of them are not rotation-hacked.

The plan is to fix FMs before next release.
One reliable way to do it is to make automation start every FM (I have already done it), and look at FMs which don't boot.


25.08.2020 11:04

administrator   ~0012760

I tried to start every mission, and found four more non-booting FMs due to this.

Here is the full list:
1) Hack-rotated moveable with .cm:
    ws4_warrens --- described above, .cm in the FM
    rightful --- same, but .cm in core files
2) Hack-rotated animated model (md5):


15.01.2021 15:28

administrator   ~0013455

For the history: the loading errors have all been fixed by repacking FMs.
More details here:

Now the small fix during beta:
  svn rev 9074: now proxy models are saved to tdm-base-dir/models/_roth_gen/xxx.proxy.

Issue History

Date Modified Username Field Change
20.01.2019 07:12 stgatilov New Issue
20.01.2019 07:12 stgatilov Additional Information Updated
20.01.2019 07:13 stgatilov Relationship added related to 0004941
20.01.2019 07:13 stgatilov Additional Information Updated
20.01.2019 08:14 STiFU Note Added: 0011441
20.01.2019 15:34 VanishedOne Note Added: 0011446
26.01.2019 05:04 stgatilov Relationship added related to 0004981
26.01.2019 09:52 Obsttorte Note Added: 0011510
08.12.2019 05:11 nbohr1more Relationship added related to 0004779
08.12.2019 17:03 stgatilov Note Added: 0011899
14.12.2019 14:04 stgatilov Relationship added related to 0004232
14.12.2019 14:05 stgatilov Note Added: 0011929
07.01.2020 09:41 stgatilov Note Added: 0012109
07.01.2020 09:41 stgatilov Assigned To => stgatilov
07.01.2020 09:41 stgatilov Status new => resolved
07.01.2020 09:41 stgatilov Resolution open => fixed
07.01.2020 09:41 stgatilov Fixed in Version => TDM 2.08
08.01.2020 09:23 stgatilov Note Added: 0012120
16.01.2020 16:19 stgatilov Note Added: 0012150
16.01.2020 17:32 stgatilov Note Added: 0012152
02.04.2020 06:39 stgatilov Note Added: 0012330
02.04.2020 06:39 stgatilov Relationship added related to 0005184
02.04.2020 06:39 stgatilov Relationship deleted related to 0005184
02.04.2020 06:39 stgatilov Relationship added related to 0005184
02.04.2020 06:39 stgatilov Relationship added related to 0005186
02.04.2020 06:40 stgatilov Relationship deleted related to 0005184
02.04.2020 06:40 stgatilov Note Edited: 0012330
02.04.2020 07:02 stgatilov Note Edited: 0012330
02.04.2020 07:03 stgatilov Note Added: 0012331
02.04.2020 07:13 stgatilov Status resolved => assigned
02.04.2020 07:13 stgatilov Fixed in Version TDM 2.08 =>
02.04.2020 07:13 stgatilov Target Version TDM 2.08 => TDM 2.09
12.05.2020 16:55 stgatilov Relationship added parent of 0005251
26.07.2020 12:04 stgatilov Note Added: 0012679
26.07.2020 12:04 stgatilov Status assigned => feedback
17.08.2020 12:51 stgatilov Note Added: 0012739
17.08.2020 12:51 stgatilov Note Edited: 0012739
25.08.2020 11:04 stgatilov Note Added: 0012760
15.01.2021 15:28 stgatilov Note Added: 0013455
15.01.2021 21:55 nbohr1more Status feedback => resolved
15.01.2021 21:55 nbohr1more Fixed in Version => TDM 2.09
16.02.2023 05:46 Daft Mugi Relationship added related to 0006258