View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004970||The Dark Mod||Design/Coding||public||20.01.2019 07:12||16.01.2020 17:32|
|Product Version||TDM 2.07|
|Target Version||TDM 2.08||Fixed in Version||TDM 2.08|
|Summary||0004970: Avoid problems with rotation-resized models|
|Description||It 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 Information||Extracted from issue found during 2.07 beta:|
Please read the discussion in that issue: it contains a lot of valuable information.
|Tags||No tags attached.|
|related to||0004941||closed||stgatilov||Odd Ragdoll behaviour|
|related to||0004981||resolved||stgatilov||Urn in Chalice of Kings gets wrongly pruned|
|related to||0004779||resolved||nbohr1more||Resized models have overblown specular in GLSL enhanced ambient|
|related to||0004232||resolved||SteveL||skins do not change collision data|
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.
Inlining affects physical properties no less than rotation hacking: http://forums.thedarkmod.com/topic/18242-model-import-help-crystals/#entry392812 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: http://forums.thedarkmod.com/topic/16678-what-are-current-max-limits-for-the-following/page-3#entry359239
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.
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).
|Added 0004232 as related, since it explains why some models have ('\1' + skinName) appended to their name.|
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.
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.
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 =)
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.
|20.01.2019 07:12||stgatilov||New Issue|
|20.01.2019 07:12||stgatilov||Additional Information Updated||View Revisions|
|20.01.2019 07:13||stgatilov||Relationship added||related to 0004941|
|20.01.2019 07:13||stgatilov||Additional Information Updated||View Revisions|
|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||Obstler||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|