Physics applied on a skeletal mesh renders differently between movie render queue and viewport preview

Physics applied on a skeletal mesh renders differently between movie render queue and viewport preview

I am having a problem rendering physics on a skeletal mesh within movie render queue, which produces distinct results compared to viewport preview. For your information, physics is added to the skeletal mesh to counter intersection issues, because I am retargetting mocap animation to a customized character.

Throughout testing and the help of Problem rendering physics simulated objects, I was able to get a basic idea of the key influential parts, but the outcome is still imperfect. To summarize, Anti-Aliazing plays an significant role throughout the process.

To start the discussion, here is a screen record directly from the viewport. I’ve applied physics only to the arms of the character. The simulation performs regularly with no errors.

Here is the blueprint to set up the physics of the arms:

The problem occurred as follows:

  1. When Temporal Sample Count is set to any number except 1, the skeletal mesh initiates a tremendous flickering in the render:


    Users from the forum Problem rendering physics simulated objects have already provided valuable solutions to this problem, involving tuning up motion blur or keeping Temporal Sample Count as 1. The accepted answer of that forum suggests that tweaking engine frame rate and physics sub-stepping will enhance the matter, but unfortunately I do not found that effective on my project. Nevertheless, I found that keeping Temporal Sample Count at 1 will omit the flickering, but there is still another problem.

  2. Arms are locked to a certain level as if they are constrained in the render.


    In the video above, it’s obvious to see that the arms are stuck at a certain angle (around the section of a T-pose). For this render, temperal sample count is at 1 so it dissolved the flickering; however you can still see this problem occurs in the previous video when TSC is not set to 1. I later discovered that this is connected to the blueprint where I set the physics to initiate starting from the upper-arm joints, a combination of apply physical animation settings below and set all bodies below simulate physics. I learned this setup in Epic’s Physical Animations | Live Training video. If I disconnect the nodes that initiates the physical animation, and only fire the part that runs the physical constraint, the renders works out pretty fine, though of course no collision will happen but only physical constraints.

    I tried diving into the elements of the nodes that construct the physical animation part, but did not found any of them to have a direct connection with this issue. It is as if the whole node set up works as a filter that forced the arm to perform this way in the render.

A few things I would look into:

  1. Check to make sure it is not LODding down. You can either force LOD0 or delete other LODs in the skeletal mesh asset details. When things go to higher LODs, bones can get merged and create strange things in animation. This may only happy when playing due to camera distance.

  2. Check your physics assets. If you physics capsules can overlap it can cause jittering like this (most commonly in ragdoll mode). It will only happen during playing or when simulation is turned on. Physics won’t run in the viewport under normal situations. To fix, go and reduce the size of your capsules in the physics assets.

I’ve seen both of these cause a similar problem for me and these are the fixes. Note that the LOD/Animation is driven by the server in a multiplayer listen server so that’s something to keep in mind (not applicable here).

Sadly it does not work out. I made sure the LODs are on 0 only and the physics bodies are not colliding (if they are then neighboring bodies are not set to collided), but the render results are still the same.

So I finally figured this out. Apparently, the reason why the physics is behaving weird is because of there is by default a sphere in the center of the world, which represent player start.

More about the sphere on this post:

Why is there a random sphere in the middle of my scene when rendering a video through Matinee?

Since my character just so happens to be in the center of the world, apprently the sphere is colliding with my characters. I do not have the “player start” in that level (since I am not making a game), I assume the sphere does not know where to go and so idles at the center by default.

With that being said, to fix this, just create a “player start” actor and move it away from the character.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.