 |
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. |
|
|
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. |
 |
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. |
 |
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. |
|
|
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. |
|
|
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... |
|
|
As we know, warnings typically get ignored, so fixing it on our side would be best. |
|
|
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. |
|
|
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. |
 |
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. |
|
|
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. |
|
|
I have added a script check_entity_rotation.py 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. |
|
|
Reminder sent to: greebo Greebo, do you have some advice for us? |
 |
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... http://wiki.thedarkmod.com/index.php?title=Rescaling,_Resizing,_Models_in_Dark_Radiant |
|
|
Moving to 2.08 as discussed in the forum. |
|
|
I have extracted the core problem into 0004970. Closing this issue as "not-an-issue" or "by design". |
- Anonymous
