SkeletalMesh animation fades out inconsistently with attached items

When the camera’s not near my cars, bits attached to the cars animate normally but the cars don’t. (See gifs below).

I have vehicles created so the base car body is separate from some attachment pieces. The roof, doors, and other misc. attachments are staticmesh components attached to the skeletalmesh root of my blueprint.

These parts are attached to bones on the skeleton that animate such that when I animate the car body, the parts will animate along with it.

When I play my animations and the camera is up close, everything looks great - the body and attachments bounce up and down in sync:

When I move the camera further away, the animation sort of fades out in amplitude on the car body, but the attached parts continue to animate to their full extent:

Because I want the game’s camera to be far overhead, I want the full scale animation to always play. But at the very least I expect the attached components to be in sync. Is this a bug? Is there a setting I’m missing that can affect this?

edit: I’m using 4.6

Hey Kurtrussellfanclub -

I want to say that this might be related to a Level of Detail, but without seeing your actual skeletal mesh setup for the car it is hard to say. Do you happen to have LODs setup and if so what is your skeleton setup? It would be helpful if you could set up a sample project with one of your cars for me to debug, if you need as well you can send the sample project via the private message to me.

Thank You

Eric Ketchum

Hey Eric,

I don’t have any LODs set up (as far as I can tell anyway – I’ve based the blueprint off the Sedan demo, so if any of its settings carry over then I could have something set up that I’m unaware of).

I’ve attached an image of the skeleton setup –

Vehicle_Base is the root node, with wheels attached to it. The Vehicle_Body bone is also parented to it, and this is what I’m animating. I’m just moving it up and down. It has some bones attached for controlling the hood/trunk and doors.

I’ll send you a cut down project via the as well so you can debug it if there’s nothing really clearly wrong with the above :slight_smile: Thank you so much.

(Oh, and my name is!)

Hey -

I cannot find a direct apparent cause for why this would be happening. I’ve asked one of our Animation people to take a look at the asset setup to see if they see anything I might have missed. We will keep you informed.

Thank You

Eric Ketchum

Hi Mike,

Can you send a picture like the one above showing the bones but with the attached roof, doors, etc. Also, what program are you using to create your vehicles and skin them to the base skeleton? Let me know when you can.

Thanks

Hi ,

Sure thing!

I’m using 3DS Max 2015.

Other important things:

  • This never happens when viewing the mesh inside the animation asset viewer or the anim blueprint window. The attachments are always attached perfectly and no matter what distance the camera is, it always looks in sync.
  • This doesn’t happen all the time even in game game window. Sometimes I can open the editor and the car’s animation plays fine at any camera distance. I don’t know what causes it, but it does seem either a bug or there’s some sort of scalability going on because when I set it up the first time it works okay – it’s only after I’ve quit the engine and reloaded a few times that it can start happening (possibly when my PC is taxed?)

If you need to see the assets yourself, I sent Eric a link to a project with the cars and a basic scene (called Demo_Scene, I think) via PM on the .

Thanks for looking at this

EDIT:

I’ve just found the repro steps – it’s only occurring for me when I have temporal AA on and when the camera is moving. So it’s not camera distance at all! When I hold alt and left-click while simulating, it’ll suddenly get out of sync – and it appears to happen regardless of camera distance.

I imagine that’s why it happens when my PC is taxed - lower frame rate probably hits temporal AA quality?

Thanks Eric,

I’ve just noticed that:

  • the desync between car and attachments happens when I’m simuating as soon as I start controlling the camera (alt+left click) and
  • It only happens with temporal AA on.

Since the camera is always moving and I’ve been noticing it most during gameplay, I never made the connection.

There’s a little more info above in my reply to .

Thanks a lot.

Hi Mike,

Sorry it’s taken so long to respond. I’ve spoken to one developer about this issue and they offered a couple of hypothesis but nothing definite. If you are still experiencing this issue, please try Launching to windows and see if it occurs in that window.

28284-launch.png

Thanks so much - no worries, and I can imagine it’s not a P1 or even P3.

It happens in Windows builds as well. It only happens when the Temporal AA is on, and then it’s generally fairly pronounced.

I don’t really understand how the temporal AA would cause a different amount of smoothing on two meshes with the same motion since I assumed temporal AA was in screen space only…?

I wish I could help more!

Hi kurtrusselfanclub,

I finally spoke to a developer who could should some light on this issue. He said the animation is fine, the problem lies in the use of Temporal AA and the post process rendering of the different pieces. The Temporal AA takes longer to render the larger pieces and makes the motion less apparent while the smaller pieces take less time to render and show a fuller range of motion. (Kind of like when you make a pencil appear to be rubber when you hold it between your thumb and forefinger and shake it -the motion away from the finger appears faster than the motion where the pencil is being held.)

Long story short, this is expected behavior. The resolution to your issue is to use FXAA instead of Temporal AA.

Thanks for speaking with the developer, .

I tried attaching the roof of a building to a car and the roof was about 8 times larger on screen and it moved while the car didn’t. I would have thought if it was screen-space algorithm that it would take much longer to process the motion of the roof than the smaller car body. Is it screen-space? Or does it have access to the render time for the actual mesh? (So is it not the pixel coverage but the render time?) That means that skeletal meshes will always move less regardless of screen coverage because it takes longer to perform all the bone transforms etc.?

Sorry, just trying to wrap my head around how this is expected and whether you mean expected-but-not-desired (as in, this is a side effect of how the algorithm has to work) or expected-and-desired, in which case I think it’s not desired because it leads to really odd-looking side effects like the original

I understand the pencil analogy but because I’m not rotating in my animations and I’m translating, I don’t think this should be the resulting effect.

Yes, I should have been more clear, this is expected-but-not-desired and was described as a “side-effect” to the post-process rendering. If your car was all one mesh, it would not be an issue.

“So is it not the pixel coverage but the render time?” -It is related to the render time. The actual translations in the animations are fine, it’s simply rendering the AA at different speeds causing the “illusion” of the separate pieces bouncing out of sync.

To be honest, as it was described to me, I understood it to be pixel based so I cannot explain why the roof you made 8 times larger would move while the base car didn’t. I suspect it has something to do with it being attached to the skeleton and not part of the base skeletal mesh.

Please try it with FXAA and let us know if that resolves the issue.

Thanks - I already have tried with FXAA and it’s fine. Unfortunately I’ve got my heart set on the temporal AA so I’ll just find a workaround. Given that attachments of any size work fine, I think I’ll just make the whole car body an attachment and so it’ll work absolutely fine from here.

I suspect you’re right with the attachments. I do have concerns for other devs who are making games like UT / Gears / Mass Effect and want characters who have staticmesh guns attached to the skeletal characters. I’d hate to see the same dancing attachments with static characters.

If it comes up for my characters I might jump into the source and see if I can come up with an update, but for hard attachments like vehicles I can work around this.

LONG TIME NO BUMP!!

I’ve pinpointed the issue!!

There’s an issue* with physics object skeletal meshes – my non-moving vehicles don’t write their velocity to the velocity buffer. So the animations only appear to play (if temporal AA is on) for the skeletalmesh part of the car while the car drives. When the car is still, only the attachments will write to the velocity buffer.

So the vehicle animating on the spot will appear static while the moving attachments will animate up and down. If I move the vehicle then the vehicle skeletal mesh starts writing correctly to the velocity buffer and then the vehicle animates and the attachments animate as well.

The fix would be for animated skeletal meshes to always write to the velocity buffer. I’m not sure why mine isn’t doing that. Regular pawns do this, but vehicles (possibly because they’re physics bodies?) only write to the velocity buffer when the car moves.

I implemented my own rendering mode to visualize the velocity buffer and this is how it looks:

*Issue is possibly a bug, or perhaps I’m looking for an option to turn on??

Hi Eric, I posted a reply to down the bottom that explains what the issue is (I finally found it!)

Cars (and possibly other physics objects, but I haven’t tested it yet) don’t write their velocity to the velocity buffer when the car has stopped physics-simulating (when it comes to rest). They stop rendering velocity even if their skeletal mesh is playing an animation. So the temporal AA is getting bad velocity info in the v buffer, and therefore the car body will look static even when the animation is being played, so long as the car and camera are both stationary.

The fix would be, I imagine, for car (and possibly other physics cases) skelmesh objects to write their velocity to the velocity buffer when animations are playing. I’ll look at my source to get a fix on this quickly, but I wanted to share :slight_smile:

If you’re using a vehicle with animations, or any other skeletal mesh with animations, and you’re also using temporal AA, you need to enable “per bone motion blur” in the skeletalmesh settings.

This setting allows your mesh to have its animation velocity rendered to the velocity buffer, and the velocity will be correct throughout animations. If you don’t do this, your animations will only be correctly played when your skeletal mesh actor is moving, or when the camera is moving.

It turned out to be an extremely easy fix, but hard for me to understand.

I can’t find this option anywhere in 4.15.1. Has it been removed?

I’m running an older version, so I don’t know if it’s been removed. I did notice, though, that it might have no longer worked a few versions back. I’ve removed temporal AA from my project, though, because of other graphical issues it was causing