 |
|
 |
I'm happy to hear this may be solved at least for 2.12. Wanted to confirm here as well that "r_useEntityScissors 1" is an improvement worth fixing: I get at least +10 FPS with it in many areas. However I had to disable it due to the problems with bounds detection described here. Currently it can cause entities to appear cut off across portals and in other areas, such as the top of a guard's helmets disappearing. Also any part of a mesh that protrudes through a portal_sky boundary appears black. I attached two screenshots from a map I'm working on showing what happens to a volume light touching a portal surface as this is probably a less noticed case. olam (2022-12-08 22-59-54) (396.32 -1095.95 116.25).jpg (214,752 bytes) olam (2022-12-08 22-59-59) (396.32 -1095.95 116.25).jpg (217,148 bytes) |
|
|
The bounds are computed in idAnimator::GetBounds. They are computed as a union of two adjacent keyframes stored in idMD5Anim::bounds array, with some kind of "origin" subtracted depending on translation flags (animBits). These bounds however, are stored in md5anim file (section "bounds"), and this is stupid. I don't know much about MD5, but I think in general animations are expected to apply to any rigged mesh that uses compatible skeleton. Thus, animation cannot be held responsible for knowing the bounds of any model it's going to animate! I'm pretty sure it is possible to do some interval math in order to precompute guaranteed bounds in load time. It can be obtained from bounding boxes of mesh pieces that are affected by each joint + joint animation data. |
|
|
The same issue with neck happens when I knockout the woman. In ragdoll/AF mode, bounds for rendermodel are taken from idAF::AFPoseBounds. They get into there in idAnimator::FinishAFPose, where they are computed as: GetBounds().Expand( POSE_BOUNDS_EXPANSION = 5.0f ) Here GetBounds is idAF::GetBounds --- a different method. It works by taking orientation of body clipmodels, and applying it to bounding boxes of clipmodels. |
|
|
Here is how clipmodels look like for the problematic woman. I think the problem here is caused by replaced head: entityDef atdm:ai_townsfolk_female { "inherit" "atdm:ai_humanoid_newskel" "ragdoll" "guard_base_newskel" "model" "tdm_ai_townsfolk_female" "def_head" "atdm:ai_head_female02_base_brunette" "offsetHeadModel" "1.7 0 -1.2" The head gets a bit detached from the body, which results in inconsistency between clipmodels and rendered model, and between animation-precomputed bounds and rendered model... bakery_job (2023-02-12 09-22-24) (1687.21 27.51 34.25).jpg (127,745 bytes) |
|
|
Also, the only cases of idAFAttachment seem to be heads and helmets. I suppose helmets are attached to heads which are attached to the rest of the body =) And the only cases of wrong scissoring that I remember are only heads and helmets. |
|
|
Joint transforms are copied from body to head in CopyJointsFromBodyToHead method. Local transforms of two non-root joints are copied there... I guess it can also cause wrong bounds. I see two ways to proceed: 1) Set bounds or bounds increase manually in .def file. Like we say guard is (60 60 150) size and hope that regarding of all the animation flexibility, everything will fit these bounds. 2) Always compute all joints transforms, even for far off-screen animated models. Then we can combine bounding boxes of individual bodies to be good and conservative bounds. It looks that original Doom 3 tried optimized away these computations. However, we always compute joint transforms in case something is attached (weapon, head or cap) to AI, so this optimizations is partly not working already. It seems that doing all computations increases CPU percentage of idAnimator::CreateFrame from 1.4% to 2.4%... this can probably be reduced by restoring SIMD optimizations. |
|
|
I decided to follow approach 2: r10269. Use per-joint bounds and fully evaluated skeleton to compute bounds of animated model. So now when we load MD5 mesh, we compute per-joint bounds. For every joint, we take all vertices/weights that are affected by it, and store bounding box of them all. Then in order to compute bounds of the whole model, we transform these bounds according to joint locations, and compute total bounding box. A few points to consider: 1) This computation method is correct (i.e. surely contains the mesh) only when vertex weights are nonnegative and sum of weights is 1.0 for every vertex. It seems to be true, but who knows... 2) In order to compute bounds, we always compute location of all joints (i.e. call CreateFrame), which takes some time. So this solution is a bit slower than the old one. The old behavior can be enabled by setting cvar "r_animatedBounds 0". At the start of AT1:Lucy map (which has a lot of AIs), I see 3.9% spent in idAnimator::GetBounds, out of 34% of game modelling time. This is not totally negligible, but not a major thing either. I think I can reduce this time by implementing SIMD versions of skeleton processing. |
|
|
Let's recall the "r_checkBounds" debug cvar. When I enabled it, I noticed that particle systems often don't pass the check. That's usually the viewer-oriented billboard particles of rather large size. So I slightly increased the bounds of particles to make them conservative: r10270. Enlarge particle bounds by 40% larger margin due to size. Now when I enable r_checkBounds, I see not errors (at least on several large maps). |
 |
Thus far, with these changes I have not found any AI with cutoff rendering or missing areas. That said, there are some pretty serious hall-of-mirrors artifacts in the skybox. Sometimes just moving around will cause them to cure themselves shortly after but other times they persist no matter what. Perhaps a hack to exclude skybox or portalsky entities from the optimization? |
|
|
Yeah, I noticed that. I'll look into MirceaKitsune's issue next, then into skybox issue. |
|
|
The skybox is broken by some wrong scissoring code in this specific case. I simply deleted it: r10271 Deleted R_PortalRender case with r_useEntityScissors. Then enabled scissors by default: r10272. r_useEntityScissors is now enabled by default. I think new backend uses the scissors in depth prepass, but does not use them for interactions rendering. Maybe the old backend benefits from it more for that reason. P.S. As for MirceaKitsune's case, there is no way to reproduce it for me. So I guess I'll wait for feedback on future dev builds. --------------------- |
|
|
Everything works as expected. I vaguely recall enabling r_useEntityScissors and seeing some performance gains "somewhere" before this change. I am struggling to find a mission where performance improves or changes but that is probably because the benefits are GPU fillrate related and my GPU is overpowered at 1080P ? ( Just tested for 2x FBO size and no difference in performance found for r_useEntityScissors thus far... ) I'll keep looking for a good example scenario for the sake of documenting the change for 2.12 Thus far, I am also unable to re-locate any missions where r_useEntityScissors improves 2.11 vanilla. |
|
|
Yes, I did not see any performance improvements either. Maybe there is something on old backend and/or on AMD... |
|
|
Added ForceUpdate to idAnimator::CycleAnim in svn rev 10354. Otherwise particle entities bounds to joint of animated entity were broken with "r_animationBounds 1": https://forums.thedarkmod.com/index.php?/topic/21818-animated-view-oriented-particles-broken This can be reproduced e.g. on Alberic's Curse: just look at green fireflies near player start. |
- Anonymous
