Hi all,

After seeing some missing pixels along the edges of meshes 'beside each other'/ connected, I first thought it was mesh specific/related.
But after testing the following, I still see this occuring:

- create a flat grid/plane, without textures
- output only black, white background (buffer cleared)

When I draw this plane twice, e.g. 0,0 (XZ) and 4,0 (XZ), with the plane being 4x4, I still see those strange pixels 'see through' (aiming for properly connected planes).
After quite some researching and testing (disable skybox, change buffer clear color, disable depth buffer etc), I still keep getting this.

I've been reading up on 't junction' issues, but I think here this isn't the case (verts all line up nicely).

As a workaround/ solution for now, I've just made the black foundation planes (below the scene), boxes with minimal height and bottom triangles removed. This way basically these 'holes' are not visible because the boxes have sides. Here a screenshot of what I'm getting. 

I wonder if someone has thoughts on this, is this 'normal', do studios workaround this etc.
There might be some rounding issues, but I wouldn't expect that with this 'full' numbers (all ,0).

Could be related to the vertex ordering of your triangles, or too many operations on the vertices (it's normally best practice to multiply all needed matrices together before sending them to shaders) perhaps?

Thanks all.

@Zakwayda I just did some debugging in renderdoc, checking the world matrix that's used in the VS. This looks as expected, with round numbers for the XYZ position of the plane (X -56, Y 10, Z -94).

WorldViewProjection is not that easy to verify

I also tried to statically position the camera in front of a plane, with 90 deg rotation etc., to better inspect WVP, but then I don't see the issue )-;

Will try to debug further and see what I can find.

if the triangles have the same vertex position and are 32bit floating point and you arent doing anything extra other than just rendering, id look more at aliasing and multisampling than accuracy of vertice position. 

@TeaTreeTim @Zakwayda I found it  after a chat with @Hodgman. 

The solution is/ was a combination of 2 things:

- I have a fixed timestep for updating, the state of the camera's view projection matrix is not correct, as used when rendering
- the transformation of the vertex in the VS, using 2 separate world matrices (potentially, looking at possible accuracy/rounding issue. Old:

	// Transform to world space space.
	vout.PosW    = mul(float4(vin.PosL, 1.0f), gPerObject.MatWorld).xyz;
		
	// Transform to homogeneous clip space.
	vout.PosH = mul(float4(vin.PosL, 1.0f), gPerObject.MatWorldViewProj);

New:

	// Transform to world space space.
	vout.PosW    = mul(float4(vin.PosL, 1.0f), gPerObject.MatWorld).xyz;
		
	// Transform to homogeneous clip space.
	vout.PosH = mul(float4(vout.PosW, 1.0f), gPerFrame.MatViewProj);

Now the issue is gone.
Currently figuring out how to exactly approach the view/projection matrix updating, for testing I just moved updating the CB per frame to the render function

20 hours ago, cozzie said:

potentially, looking at possible accuracy/rounding issue

Glad it worked

Going from nice small, round model coordinates to nice small, round world coordinates is unlikely to encounter floating point precision issues. So, say you've got two instances, A and B, of a mesh with 2 vertices local coords 0 and 1, and their world matrices place them at position 10 and 11. Instance A ends up with verts at 10 and 11. Instance B ends up with verts at 11 and 12. Seeing as both instances agree that the edge is at 11, there's no crack. Both of those two different vertices at position 11 are transformed to the screen using the exact same projection matrix, so they'll end up with the bitwise same screen position and still have no crack. 

In your original code where you go directly from local vertex coordinates to screen coordinates (by using a world-view-projection matrix), the two instances are being transformed to the screen (which involves a lot of very precise, long, fractional numbers) using a completely different set of numbers. If you're unlucky (which it seems you were), the left vertex of one instance won't be bitwise exact with the right vertex of the other instance. Doh. 

This is kind of a funny problem though, because in general, the "fixed" version (local to world, followed by world to screen) has some bad precision implications -- because you're using world space as an intermediary, any vertices that end up being a long way from the origin can suffer quantisation problems. In a planetary scale renderer, this would absolutely destroy most of your data quality... Going directly from local coord to screen coord works well even for solar system sized scenes (assuming your code that constructed the 32bit float matrices was using 64bit double input data on the CPU).

So, use local to world, world to screen if you want edges of different models to perfectly match up. Use local to screen if you want best precision within a single model. 

There's also one other solution that's popular - use "camera relative world space" as an intermediate coordinate system, where it's world space, but [0,0] is relocated to be wherever your main camera is. This can give a blend of both of the other solution's strengths and weaknesses. 

@Hodgman thanks, the explanation is pretty clear.

I'm not planning for that large scaled scenes so far, but it's good to know.
Not sure though how the 3rd 'in the middle' option would work, would it be something like this:

- mul world with view on CPU
- mul model space vtx with worldview
- mul the result with projection?

Btw; I did notice some clipping within a mesh with the new/ fixed solution, but not 100% sure if that was caused by the change (or just coincedence). It only occured when being 'very far' away from the mesh (could also be Z fighting/ precision). Update; just did a test changing it back, the clipping issue (Faces 'through each other') does occur at closer Z with the new approach, compared to the old approach (issue occurs only when further away). But in this case I think I need a better mesh