Benefits from LOD AI?

[SteveL]

Joint names are listed in both md5.mesh and md5.anim. They need to match exactly, otherwise you'll get an error message during map load.

Thanks. Are joint name and number they the only things that needs to match? What about size?

 

The code already has some of these safeguards built in. It falls back on more primitive methods of switching the model if the animator fails to set up the new model.

[Arcturus]

I did a quick test. I scaled upper part of proguard and exported it and it worked. Just looked bad.

[SteveL]

Cheers again.

I'm making my head hurt trying to work out the effect of switching to a model def with different animations part-way through an animation without cancelling the animation. Skeletons do modify the proguard animations a bit. In the demo vid above, I didn't reset the animation channels at all so they still pointed to the guard model def throughout, even when the render model and main animator pointed to the skeleton model. So it's perfectly smooth, but it's not a good fix because it leaves the game in an inconsistent state: different parts of the animation code pointing to different defs for the same entity.

 

If I update the model pointed to by the anim channels too, it works quite well. The guards stoop and start to shuffle whenever they become skeletons, and the walk animations seem to be compatible, so it's not too jarring. That's almost certainly the right thing to do. The only stuff that gets carried over through the model switch is simple data -- which animation is playing, which frame is it on, what speed, is it cycling, and so forth.

 

One thing that would wreck it is to swap in a new model that declares a different number of animations or does them in a different order. The animation data is picked up by the code that blends the frames together using a number -- for example, "get the 32nd frame for the 4th animation defined for this model". If we swap model defs and the 4th animation is something completely different for the new model, the result could be ugly.

 

None of this probably matters, given that we'd be using identical animation definitions for LOD models. If an adventurous mapper wanted to try swapping animations, they'd just have to respect the same-number and same-order rules to get it to work. Or -- if really needed -- we could decide to patch in an extra spawnarg or something that says "anim 4 on this entity is the same as anim 16 on this other".

 

Switching to a static model is pretty easy too by the way (one of your questions above). The existing code lets you do that, so I just need to plug it in in the right place.

[SteveL]

One thing you can do is disable lod entirely on your entity by adding spawnargs dist_check_period 0 and hide_distance 0. With both those at 0, the entity will never get touched by LOD, no matter what gets added to a inherited def later.

This is a method left in the code by Tels, but he meant it to be a code optimization, not necessarily an easy method for mappers.

 

Given that we're planning to add LOD to many entities by default -- entity lights and hopefully AI -- should we add a simple "no_lod" spawnarg to make it easy for mappers who are doing something special?

[SteveL]

Hmm, is it normal that the "channel" settings in Model Defs do not get inherited?

 

I'm trying out my ai with new lod model defs as planned above, but I find I have to repeat the following lines in each model def or the anims play but the ai doesn't move: he walks on the spot:

  channel torso   ( *Spine_Dummy)
  channel legs    ( origin Pelvis Pelvis2 *Hips)

[Springheel]

The animation data is picked up by the code that blends the frames together using a number -- for example, "get the 32nd frame for the 4th animation defined for this model".

 

I don't quite understand this. Where does the number 4 come from in this example? The 4th animation defined in the modelDef? The 4th animation the AI has played since map start?

 

should we add a simple "no_lod" spawnarg to make it easy for mappers who are doing something special?

 

I think that would be useful.

 

 

Hmm, is it normal that the "channel" settings in Model Defs do not get inherited?

 

I found that they were not inherited, but don't know if that's "normal" or not.

[SteveL]

I don't quite understand this. Where does the number 4 come from in this example? The 4th animation defined in the modelDef? The 4th animation the AI has played since map start?

The order that they're declared in, from the model def. I haven't looked into how inheritance from one model to another affects the ordering, but I expect it always works the same way.

 

We have more options here if we need them... Animations do have names in the code too of course, so we could swap the simple rule "anim #4 must match anim #4" with one that matches up animation names, for example. When I started messing with this I had no intention of finding out how animations worked under the hood. I was thinking we'd have to prevent the animator code wiping out the animation data during the switch, and rely on identical setups between the two models so that the animations just carry over as if by magic. But I can see now that it wouldn't be too hard to let the existing code wipe out all the animations, then just start them up again at the right point. That feels like a better / less brittle way to do it. I'll stop testing alternative solutions and come up with a proper proposal some time this week, promise

 

I think that would be useful.

Consider it done.

 

I found that they were not inherited, but don't know if that's "normal" or not.

Good to know it's not just me getting confused about it. I'll take a look at some point to see why this is.

[Springheel]

We have more options here if we need them... Animations do have names in the code too of course, so we could swap the simple rule "anim #4 must match anim #4" with one that matches up animation names, for example.

 

That seems much more robust to me. Although there are some cases where different AI have animation names pointing to different md5anim files...like the "walk" animation for skeletons and citywatch. Don't know if that throws a wrench into it.

 

When I started messing with this I had no intention of finding out how animations worked under the hood.

 

Well, while you're poking around in there, let me know if you find anything that might answer two issue I've had for years--I can't get AI to play animations on the head channel: http://bugs.thedarkm...iew.php?id=2247, and the issue where AI do not blend animations when using a path_anim.

 

Thanks for taking this project on, btw...sounds like it's a lot of work.

[SteveL]

Although there are some cases where different AI have animation names pointing to different md5anim files...like the "walk" animation for skeletons and citywatch. Don't know if that throws a wrench into it.

That causes no probs for the animator. If you choose two incompatible "walk" animations, the transition is going to look odd, that's all. I already have skeletons and city watch doing this in my test map. Right now two of my skellies are using their own walk animation, and the other two are using the same one as the citywatch. The same-animation switch is seamless of course. The skellie-walk transition doesn't look too bad either although I haven't attempted to blend them so the change in posture is abrupt.

 

Well, while you're poking around in there, let me know if you find anything that might answer two issue I've had for years--I can't get AI to play animations on the head channel: http://bugs.thedarkm...iew.php?id=2247, and the issue where AI do not blend animations when using a path_anim.

Ok I'll keep an eye out!

[Springheel]

That causes no probs for the animator. If you choose two incompatible "walk" animations, the transition is going to look odd, that's all

 

Great!

[Tels]

That would be good I guess. You want full res during cutscenes.

 

I can confirm the spyglass doesn't move the player closer for LOD purposes. My skellies in that test map are still skellies when zoomed in.

 

That the spyglass does not modify the LOD distance is a bug, it actually should do this. However, it is also a feature (you can use it to check the LOD) and it has also the benefit that during spyglass zoom things don't get suddenly laggy and stages POP during zoom, because you are looking at a far-away forest and all the trees suddenly switch to high-res.

 

So, in a nutshell, I always wanted to "fix" the spyglas, but it was useful and I couldn't think of a good way to fix the lag issue. So it got left in it's current state.

 

And Cheers! for Steve to tackle this issue

Edited August 15, 2014 by Tels

[Tels]

I just came across this while googling for something GPU related:

 

http://www.simplygon.com/

 

Might be worth a look to get some ideas.

[SteveL]

Nearly there with the decal fixes. I have killed more AI each hour in the last 3 days than I ever have in my entire TDM career. I must have cut quite a ghoulish figure to the other AI in the map, seeing me shoot people in the face and stoop to look closely at their wounds then wandering off and back again repeatedly for another close inspection.

 

AI have a smallish flaw: blood on the face can move around a bit. Specifically, if an AI is killed by an arrow to one side of the face, sometimes the blood will move to the other side of the face of the ragdoll after the first LOD switch, mirror-image-like. Most mysterious, because it doesn't always happen. And if an AI has his head turned during the LOD switch, the blood can shift a small amount too. I don't think that one will be noticed in non-testing situations, but see what you think.

 

I've not spotted any problems with blood on the body. The head thing is just because it's a separate entity, and because of a quirk in the AI setup: blood on the face is applied by the body using the neck as a reference joint, not by the head entity. If you think it's too disturbing I'll change that and make sure that both the original splash and the LOD replacement use some convenient joint in the head instead.

 

Func statics work fine, but I've only tested with fire arrows. I wasn't sure what else to use to stain a func static. I looked for all the places in the code that could apply a decal to an FS and there are quite a few but most of them look like doom3 leftovers: exploding barrels and the like. I put in support for arrows, and marks left by melee weapons.

 

In both cases I've made a function that'll make it easy to add support for more entities later if needed. One that closely matches the existing functions that they use to apply a decal.

 

I never spotted this before, but the engine doesn't seem to offer a facility for applying a decal to a movable: it only does it for md5 meshes and func statics and worldspawn. If you place a working entity door in your map and place an inert door model next to it using the exact same model, you can blacken the inert model but not the real door.

 

One more thing I hadn't noticed (probably because I never kill AI) is that blood vanishes when you shoulder a corpse. I'm going to go looking for that one before I commit it because with the new LOD setup, those blood splashes are remembered and get reapplied with the next LOD switch. So not only is the loss more noticeable when it suddenly reappears, but it should now be easy to put the blood back again for a dropped ragdoll.

[Springheel]

Cool!

 

http://bugs.thedarkmod.com/view.php?id=1512

[SteveL]

Cool!

 

http://bugs.thedarkm...iew.php?id=1512

 

Hmm I started a new tracker issue that duplicates that one. But only because I couldn't find one. I exported the bugtracker to csv to search but that issue isn't in the export. I just double-checked. Something up with the export feature I wonder?

[Tels]

Nearly there with the decal fixes. I have killed more AI each hour in the last 3 days than I ever have in my entire TDM career. I must have cut quite a ghoulish figure to the other AI in the map, seeing me shoot people in the face and stoop to look closely at their wounds then wandering off and back again repeatedly for another close inspection.

 

Killing Ai for the greater good

 

I've not spotted any problems with blood on the body. The head thing is just because it's a separate entity, and because of a quirk in the AI setup: blood on the face is applied by the body using the neck as a reference joint, not by the head entity. If you think it's too disturbing I'll change that and make sure that both the original splash and the LOD replacement use some convenient joint in the head instead.

 

I'd prefer to fix it for real and good, instead of postponing it. If you can spare the time, of course. If we postpone it (again), in 2 years somebody else will have to figure it out again.

 

I never spotted this before, but the engine doesn't seem to offer a facility for applying a decal to a movable: it only does it for md5 meshes and func statics and worldspawn. If you place a working entity door in your map and place an inert door model next to it using the exact same model, you can blacken the inert model but not the real door.

 

Would that be fixable? If so, I'd like to see that getting fixed. Because decals are unerused in TDM, for istance we could really have more wepon scratches. I made an extension called "Black light", which applied a small "hole" for each arrow hit. IMO it greatly enhanced the mood, but it only worked for worldspawn, which makes it less cool

 

Thank you for the work so far

[Tels]

Afterthought: When you say you have added support for a few specific cases, does that mean other ways to apply decals (f.i. from scripting) will not work? Would it be possible to make the decals "stick" regardless on how or by what they get applied? Otherwise scripting new decal-spatting entities will miss the feature again, which would be really sad if all our AI suddenly use LOD and it doesn't work with that.

 

What I'm trying to say is that neither the decal nor the method of how it is generated should dictate how it stays, but the receiving entity (in this case worldspawn, func static or AI). Or maybe I misunderstood your post?

[SteveL]

I'm thinking along similar lines. The code would need a bit of refactoring to provide a "single" solution to all methods, which is why I didn't immediately reach for that solution in order to fix these 2 tracker issues.

 

There are only 3 places right now where the game decides to create an overlay on an animated mesh, but the necessary info for recreating them never comes together in one place. 2 of the 3 go through idEntity::ProjectOverlay, but it receives only the World coordinates that tell it where to splat the decal in that frame. It doesn't receive any info about which joint of which animated mesh got hit and therefore "owns" the splash (and you need to know that in order to put it back in the right place once the pose has changed).

 

However, ProjectOverlay is used *only* for attaching decals to animated meshes, and they all have joints, so those 3 spots in the code *could* all pass the joint info to ProjectOverlay, leaving it to work out what world coords to pass to the renderer. That'd mean no need for different places in the code to save the info, but it'd make ProjectOverlay a bit less flexible: What if you want to place an overlay without doing a trace to find out what joint's been hit? Hmmm. All the existing places do have access to the joint, because they use a standard trace to find out what entity to splash, and traces tell you the joint if they hit an animated entity.

 

Perhaps we can make the joint parameter optional, and give ProjectOverlay the ability to do its own trace, only when needed to "anchor" the decal for later use. That'll cost nothing performance wise (because all existing code does already know the joint) but preserve the flexibility.

 

NB even this wouldn't be the *perfect* fix, it'd be another compromise. No single entity or mesh owns an overlay. With blood splats on AI for example, they might hit both the face and the wrist, if the AI has his arm raised when he gets hit in the eye. When the decal comes to be reapplied later, it'll hit only the face if he no longer has his arm raised. The only way to fix it fully would be for the renderer to remember the relative position of each bit of mesh that got hit (not the vertices, because they get changed by LOD). But that would be way too much extra work for too little gain imo.

 

Decals on worldspawn and static models are different, and simpler. You don't need an owning joint and the things that they hit never move. For models, they'll want restoring after LOD switches. For worldspawn, it'd only be when loading a save game (another situation where decals vanish). But it's trivially easy to set up.

 

I have no idea how much work it would be to enable overlays for movers. I've not looked at that. They have no md5mesh to pin it to, but they do have some kind of mesh of course.

 

Right now I'm still finishing off the method of restoring overlays. I've just fixed yesterday's code so it can be used in places where the model isn't currently in a fit state to have the overlay reapplied -- like when it's just been unhidden and the joints and mesh aren't in place yet. So it now works for unshouldering a corpse.

[SteveL]

Let's continue this latest topic (persistant decals) in another thread, and I'll do the same with the tracker issues, detaching them from the LOD tracker. There's more could and would be done with overlays and decals I'm certain, if there were an easy way for mappers and designers to apply them and if they were persistent.