fix shader interpolation and make image comparison tests more tolerant.

[mjkkirschner]

Purpose

This PR does the following:

• in the shader - do not pass our flags from the vertex stage to the fragment stage - the data gets interpolated and no longer can be decoded - instead just get it from the common buffer - this is faster, makes more sense, and lets us get rid of our custom input struct. yay!

• It now works on

  • Parallels (forwarding calls to apple metal)
  • and using WARP -
  • and on a real machine with an Nvidia Quadro 2000m.

• adds two methods for making the image tests more tolerant

  • adds a color distance metric which calculates euclidean distance in RGB space from the actual to expected color - this is a wide tolerance, the accepted distance is 128 - thats half the color space.
  • next a percentage difference is calculated, for all pixels which failed the first assertion, those pixels are counted against the total pixel count to calculate a final percent difference between images.

This let's us spot differences like this:

but this still passes, even though there are many pixel to pixel differences, the colors are still within the same space:

to my eye these are almost the same - but of course alpha blending in different renderers will produce slightly different results, order matters etc.

These tests now pass on the dynamo performance machine.

Declarations

Check these if you believe they are true

• The codebase is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning and are documented in the API Changes document.

[aparajit-pratap]

Just some minor suggestions and some stupid questions arising out of ignorance.

[aparajit-pratap]

@mjkkirschner how do the flags get passed to the default PSInput struct?

We currently have a custom struct for the vertex shader called VSInputCustom. Did we also get rid of that in the helix-upgrade branch?

[aparajit-pratap]

What do you mean by data interpolation? How did you figure out that that was going on?

[mjkkirschner]

we no longer need any custom input structs - the data gets passed to each shader using a directX constant buffer, read about these here:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-constants

you can think of this like a uniform in opengl except per model, not shader or triangle.

So imagine we have a triangle with 3 verts - each vert has a color associated with it - to smoothly interpolate those colors for each pixel of the triangle, the renderer interpolates those values and sends those interpolated values to the pixel shader - that was being done to the flags data... it turns out that in directX apparently interpolating between the same value on each vertex does not interpolate correctly... the value should remain constant - but it obviously did not...

in parallels(metal) it did interpolate correctly, so each pixel had the correct flags set.

What we were seeing was each pixel having a random set of flags - some frozen, some selected etc.

I figured out what was going on by noting that the data was being corrupted between the vertex stage and the pixel stage, but was fine if I set it myself using some constant number.

[aparajit-pratap]

Wow, I would have expected interpolation only to be applied to vertex normals and colors, not for all data in the shader.

[mjkkirschner]

it depends on the semantic you use - check this out:
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-struct#interpolation-modifiers-introduced-in-shader-model-4

[aparajit-pratap]

Why is the alpha channel not used?

[mjkkirschner]

theres no (meaningful) alpha channel in a full color image with no transparency. These are renders not textures or masks.

[aparajit-pratap]

What about when we are comparing images in isolation mode or frozen geometry?

[mjkkirschner]

nope, even then, the final output color is just red,green,blue, the alpha channel is still 0. These are 24bit images anyway, there isn't even an alpha channel.

[aparajit-pratap]

So would the image comparison between an isolated geometry and non-isolated geometry return true (same image)?

[QilongTang]

@mjkkirschner OK, let me read your comments carefully again!

[mjkkirschner]

I know it's a bit confusing - but you can see in the shader:

//if isolated - alpha should always be low - 
//overriding other alpha values (except if selected)
if(isIsolated && !isSelected)
{
	I.a = .1f;
}

that if the isolate mode is active we set the alpha of the returned color (returned from the shader)

Because the shader is using AlphaBlending - the renderer uses this alpha to compute a final color.

It doesn't matter if each vertex had a low alpha or a high alpha, since they're not used.... atleast not unless that Model has RequiresPerVertexColor enabled.

I hope that makes sense. Please let me know if not, I can find some better written docs on the subject.

[aparajit-pratap]

thats unrelated - in your test you were not looking at the color values of an image, you were looking at the color values of individual verts which were not used for computing the final color.

Yup, sorry for confusing the two; my bad.

[aparajit-pratap]

So when we generate a bitmap the alpha channel has already been incorporated into the final RGB color - you can think of this like premultiplying or something - the color values have been modified by the alpha channel in some way to create a color blended with the other colors that were located at the same pixels.

Ah, so it's something like homogeneous coordinates :)

[QilongTang]

Make sense! @mjkkirschner