 |
Version 1 of the new LOD code is ready for committing. Enables LOD for three types of animated entity: idAFAttachment (heads, helmets), idAI (AI), and idAnimated (animated props). Dev forum discussion here: http://forums.thedarkmod.com/topic/16424-animated-lod-design-proposal/ I've attached a open office drawing with the new architecture. Green boxes are functions. Downwards arrows mean it's a virtual function. Red X's above a function means it overrides its superclass function without calling the superclass function. A red border means changes have been made with the upcoming commit. The new addition is a new virtual function idEntity::SwapLODModel. That function holds all the class-specific logic and methodology. The model switch is handled by an existing facility in the engine: idAnimator::SetModel What that does is: • Clear down all existing animation and joint data • Set the new model, whether static or animated • If the new model is an animated one, then it sets up the new joints and animation data (but it doesn’t start any anims playing). The new LOD classes will all use that method, and then do a bit more setup afterwards. The (spawn) classes supported in this instalment: === idAnimatedEntity === Not used as a direct spawn class, but it’s the parent class of the other three. It currently handles the model setting for all the other types, and so it’ll handle the new LOD switches too. What the new code will do: • Make a note of any current animations and what state they are in • Tell the animator code to switch the model • Check its notes to see if any of the anims can be continued on the new model • If so, restart them at the right frame === idAFAttachment === • Spawnclass for heads and helmets etc • No need for anything special: it’ll just make use of the idAnimatedEntity method above === idAnimated === This is the spawnclass for animated models like grass and banners. The animation(s) that it uses are specified in its spawnargs. It supports a special dummy model name: "be_still". Setting model_lod_N to "be_still" for a LOD level means: stop the animation but don't switch model. It also supports switching to and from a static FS model. When actually switching models, it makes use of the idAnimatedEntity method too. After the model switch, it’ll check whether its new model has its start anim available. If so, and it's not currently moving, and if the start anim hadn't been stopped at some point in favour of a different one, then it’ll start itself moving using its start anim. That’ll let it support switching to and from a non-moving model. === idAI === Spawnclass for AI It’ll use the idAnimatedEntity method too, but it’ll have an extra condition: Ongoing animations on legs and torso must have same-named replacements available on the new model, else we’d risk screwing up the AI scripts So it’ll check first, and block the LOD switch with a console warning if the new model doesn’t support those animations. |
|
|
Committed: Code at rev 6075, binary at rev 13928 |
|
|
Three problems found with LOD transitions for AI meshes: 1) AI head snaps to face forward briefly when LOD transition happens on body (including skin-only changes). 2) AI head appears to vanish and scroll upwards back into correct position when LOD transition happens on head. This is independent of the head's origin, which remains stable. 3) AI shoulders shrug briefly when LOD transition happens on body. Obvious only when AI is standing still and at slowed timescales. |
|
|
Problems above were caused by idAnimator::SetModel() destroying and reallocating the joint data, then resetting the mesh to the default pose from the md5mesh file. Animations were being restored, but sometimes a frame or two later even when attempting to force updates same frame. The 2-frame delays were the visible jerks. Confirmed by logging joint positions and orientations. There's no real need to reset the joint data when switching to a model with the same joint setup, so fixed by addition of a new animator function idAnimator::SwapLODModel which does a thorough check on joint compatibility (number, names, order, and hierarchy) before swapping the model without destroying the joint data. If joints are not fully compatible, the previous method is used. Confirmed in the log that joints now stable. |
|
|
Committed at rev 6082 (code) |
|
|
All child reports now closed. |
- Anonymous
