 |
Noticed while working on occluders that a renderModel has space set aside for decals attached to animated meshes. That makes sense now I come to think of it: they need to deform with the animated mesh, so they're not treated like static decals. Evidently, they're not getting preserved through the mesh switch. |
|
|
The overlays are being removed by renderer method that clears the current model data: R_FreeEntityDefDerivedData, which is being invoked indirectly by the new idAnimated::SwapLODModel routine when it calls the renderer routine FreeModelDef. Tantalisingly, R_FreeEntityDefDerivedData has parameters that let you specify you don't want the decals and overlays removing. But it doesn't expose those to the game. So this would be fixable with a renderer tweak, but I'll look first whether it can be done in the game code by simply reapplying the blood splats. |
|
|
The blood splats and other overlays get applied by idEntity::ProjectOverlay. Not sure what the difference is between an attached decal and an overlay, but the renderer treats them separately. The missing blood splats are overlays. idEntity::ProjectOverlay uses a randomizing function when it does its stuff to avoid every blood splat looking identical. Need to see whether the game can recover the settings for the particular blood splat from the renderer so they can be re-applied, else it'll mean modifying the renderer code to let the blood splat be preserved unchanged. |
|
|
The difference: In renderer language, a decal is for a static model or worldspawn, an overlay is for animated meshes. Probably *not* fixable with a renderer tweak after all. The overlay is intimately bound to the mesh surface, both on screen and in the code. The option to keep an overlay when freeing derived data is only available if the model isn't being changed. Nor can we recover the information needed to set up the blood splat from the renderer. The setup parameters are used only to create the new surface tris. They're not remembered. Looking like the best bet is to have the entity remember the setup of the last overlay it applied, so it can be reapplied after a model switch. Lots of different animated classes use overlays slightly differently, but the pinch point that all the routes pass through is idEntity::ProjectOverlay. |
|
|
Simply storing the parameters generated by idEntity::ProjectOverlay doesn't quite do the trick. The AI will have changed position by the time the decal needs reapplying. It puts the decal back close to where it should be surprisingly often, but not often enough. Need to save the joint-related positions for the decal that're used in idAnimatedEntity::AddLocalDamageEffect, so we can recalculate where it needs to go. |
|
|
In scope: animated entities and static models. Not in scope: moveables. These don't get decals applied. |
|
|
Deleted several notes that don't apply to latest plan. Actors and their blood splats are tricky as the splats can hit both head and body, and when the splats come to be reapplied the relative positions will have changed. I see a lot of blood moving round a guard's head with LOD transitions. Heads are especially complicated as a blood splat caused by an arrow in the head is measured from the body's neck joint, not a joint in the head. The collision result specifies the head, but the result gets hacked before being passed to idAnimatedEntity::AddDamageEffect. That's because bindmasters that receive a splat also splash their bindchildren. Not easy to amend that to pass on the original joint info while preserving the bindmaster->bindchild splash relationship, and in any case storing the splat details on the head instead of neck wouldn't help with restoring blood to the neck (or wrist, if the victim happened to have his hand by his face when hit). Latest plan under test: == Overlays for animated meshes == For each entity splashed (head and body are separate), do a trace to find a local joint as a reference point, and store the detail against that. Should give much more consistent results for splats shared by head and body. == Decals on static meshes == Store details of each impact against the entity that got directly hit (if any), plus the World entity if no direct hit. Restore all from a savegame. Restore just one entity's direct hits after the entity gets unhidden or has its model switched by LOD. |
|
|
That works, with one amendment for overlays: instead of a trace, which is expensive and difficult to get right, we simply find the closest joint to the point of impact and record the position and direction of the splat relative to that joint. Plan to restore decals and overlays after: (1) LOD switches, (2) hiding (which includes shouldering), and (3) save game loading |
|
|
Update: This is working perfectly for animated meshes. One outstanding problem remains with func statics and fire arrows blasts. The reappllied decal is approx half the size of the original. Not sure yet why that should be. EDIT: Problem was caused by idGameLocal::ProjectDecal halving its "size" parameter before using it. |
|
|
Committed at rv 6106 (code), rv13999 (game dll) Actor.h Actor.cpp AFEntity.h AFEntity.cpp AI.cpp Entity.h Entity.cpp Game_local.h Game_local.cpp MeleeWeapon.cpp Misc.h Misc.cpp Projectile.cpp IdleAnimationTask.cpp (unrelated, removing a temporary comment left in by me in error.) |
|
|
Reopening for a bug fix. Dropping a body without adequate space causes a console error. That's because CGrabber::FitsInWorld tests whether the body will fit by unhiding it, triggering a decal restore, but then hides it again if it won't fit, so there's no render model to receive the decals. |
|
|
This could have been fixed by having idEntity::Hide unset the flag that says to reapply decals on the next Think(). Fixed instead by having ReapplYDecals() abort the operation if there's no current render model. That'll cover any other parts of the code that Show() then Hide() a model before it has chance to Think(). |
|
|
Committed at rv6114 Entity.cpp Misc.cpp |
|
|
Commit # 3 at rv6115 Tweak to idAnimatedEntity::SwapLODModel. Do not attempt to reapply the overlay if the joints couldn't be preserved through the LOD switch. Preventative bugfix in case we ever add LOD stages with simplified skeletons. |
|
|
Commit # 4 at rv6120. Changed a const pointer declaration to a non-const one because the pointer is used to delete the object it points to. For some reason that compiled ok on MSVC (!!!) but gcc correctly choked on it. |
|
|
Further report of ProjectOverlay causing a fatal error when dropping a body: http://forums.thedarkmod.com/topic/16706-crash-on-body-drop/page__fromsearch__1 Waiting for confirmation whether this code predates fix at rev 6114 above Edit: closing again pending further testing after the branch that gave this result gets merged back in. I've not been able to rep it in 100s of tests, and it's not clear whether the code used for the build included the fix. |
- Anonymous
