store positions relative to the mesh surface

[mrgreywater]

tl;dr: Store positions relative to the mesh surface to avoid clipping when the simulation is stopped or skipping frames.

This fixes the mesh mesh clipping through the hair as seen here:

Explanation:

Before, it worked the following way:

• GenerateTransforms: Unlimited Framerate, computes transforms from object space to each animated/skinned triangle for usage in the Simulation.
• Simulation: Has maximum framerate of 60Hz, and updates the Positions using Verlet Integration and some stiffness constraints. The positions are stored in object space.
• Render: Unlimited Framerate, draws mesh using current animation, draws hairs from Simulation. -> Problem: due to the Hairs being stored in object-space by the simulation, and the simulation potentially skipping frames, the mesh clips through the hair on fast moving objects.

With this PR, it works like this:

• GenerateTransforms: As before
• Simulation: Store the positions in a new buffer (write-only) in relation to the skinned triangles (by multiplying with the inverse transforms). A new vertex buffer is required, as the physics simulation needs vertices that share the same coordinate system.
• Render: Read the new relative positions, and transform them back using the up to date transforms from step 1

  Todo:

• Check if it makes any sense storing the inverse transforms instead of calculating them each time the output positions are updated.
• Maybe reduce the number of transforms, only one per guide hair should be needed.

Sidenote: Reducing the simulations speed makes the artifacts this PR fixes more obvious. You can now disable the simulation, while the animation still runs.

Alternatives:

1. Interpolate output-positions (not the positions used in the simulation) in GenerateTransforms. Pros: Easy to implement. Cons: Need to iterate vertices for each strand in GenerateTransforms; Vertexshader is probably faster.
2. Simulate each frame, even when over 60FPS. This requires time-corrected verlet integration, and probably some other tweaks. Pros: No additional Transforms needed. Cons: Simulation must be executed each frame and cannot be disabled. (You can try the time-corrected TressFX version here: https://github.com/mrgreywater/TressFX/tree/time-corrected-verlet). The time-corrected verlet integration should also be used anyways, since the simulation is not executed with fixed step. If you try the linked build you will see that it looks both more realistsic and needs far less length constraint iterations before it converges to a stable result. Using TCV and this PR is not mutual exclusive.

Final note: I am aware of the fact that this change was not discussed properly in the issue section as is recommended. So in case we find a better solution to this problem, i'm ok if this PR is rejected.

[mrgreywater]

ping @jstewart-amd

[jstewart-amd]

As mentioned in the corresponding issue, "I'll be in full GDC scramble mode." This is the busiest time of the year for me. I am going to have to ask for your continued patience. I do hope to talk to our TressFX simulation guru about this today, though.

[mrgreywater]

@jstewart-amd After GDC, Easter, GTC and over a month of waiting, can please somebody take a look at this (and the various issues that don't have a single reply). I find it kind of unbelievable that a big company like AMD only has one busy employee that looks over all the GPUOpen repositories. Communication and seeing active development is important for any open source project, and I believe having long delays like these will put off other developers that may have contributed otherwise.

[jstewart-amd]

Communication and seeing active development is important for any open source project, and I believe having long delays like these will put off other developers that may have contributed otherwise.

I agree with you, for what that's worth.

Your PR title says that it is work in progress and should be discussed before merging. What specifically do you want to discuss? I've tested the changes locally, and it is an obvious visual improvement for the bear model, but at the cost of some additional simulation time. Given the care you took with preparing and documenting your PR and how long you've had to wait, my inclination is just to merge your PR as is and put whatever work we feel is still needed at the top of the backlog. We already know we need to take another optimization pass over all the code, for example. The "yeah, but it makes the simulation more expensive" aspect of your PR can just be lumped under the already existing and high-priority to-do of "make everything faster".

[mrgreywater]

Thanks for the reply. Since the general direction of this PR seems to be alright, I'll go ahead and implement the first todo item:

Do the same transformations when there is only a single-head-matrix.

before the merge.

[mrgreywater]

Did the same thing for the single head transforms. When translating the head, the hair will not clip through the head as it did before. Also you can disable the simulation now and still translate the model.

The whole thing should still be optimized in the future, but it fixes the problematic clipping issues for now.

[jstewart-amd]

Thanks, @mrgreywater

Assuming no show-stopping issues, I'll get this merged today or tomorrow.

[jstewart-amd]

This is merged now. Thanks, @mrgreywater

There is now a new warning from the D3D debug runtime: D3D11 ERROR: ID3D11DeviceContext::CSSetUnorderedAccessViews: On devices created at a Feature Level D3D_FEATURE_LEVEL_11_0, the maximum Compute Shader Unordered Access View slot is 7 (Offset 0 and NumViews 9 specified). [ STATE_SETTING ERROR #2097404: DEVICE_CSSETUNORDEREDACCESSVIEWS_TOOMANYVIEWS]

In the short term, I will probably just disable the warning with code like this:

#ifndef NDEBUG
    if( SUCCEEDED( hr ) )
    {
        ID3D11Debug * d3dDebug = nullptr;
        if( SUCCEEDED( pd3d11Device->QueryInterface(IID_PPV_ARGS(&d3dDebug) ) ) )
        {
            ID3D11InfoQueue* infoQueue = nullptr;
            if( SUCCEEDED( d3dDebug->QueryInterface( IID_PPV_ARGS(&infoQueue) ) ) )
            {
                // ignore some "expected" errors
                D3D11_MESSAGE_ID denied [] =
                {
                    D3D11_MESSAGE_ID_DEVICE_CSSETUNORDEREDACCESSVIEWS_TOOMANYVIEWS,
                };

                D3D11_INFO_QUEUE_FILTER filter;
                memset( &filter, 0, sizeof(filter) );
                filter.DenyList.NumIDs = _countof(denied);
                filter.DenyList.pIDList = denied;
                infoQueue->AddStorageFilterEntries( &filter );
                infoQueue->Release();
            }
            d3dDebug->Release();
        }
    }
#endif

In the longer term, I'm assuming the number of UAVs will drop when we do our optimization pass.

[mrgreywater]

tbh we don't need the ninth uav slot anyways, I just checked. I will send a small fix tomorrow. Thanks for the heads-up.