Your matrices looks fine enough. But how big is this model that you need the camera to be 250 units back from it, and 10,000 units sideways? Especially since the world matrix seems to place this model at the origin...

The model was exported from a CAD program with metric units. Would it help to normalize the model? I do need a preserved coordinate system since I need to highlight certain points which I only have in the original scale.

You are using a float4 as Position in VertexShaderInput. Are you sure your vertex buffer contains vertices with 4 coordinates?
In most cases only vector3 (x,y,z) are stored and you use float4(input.Position,1.0f) as input at the matrix multiplication.
Just guessing, but the vertexshader output in your debug view looks good at first sight.

One more note:

float4 AmbientColor = float4(1, 1, 1, 1);
float AmbientIntensity = 0.1;
return mul(input.Color, AmbientColor * AmbientIntensity);

this will result in a barely visible output because you basically doing input.Color.rgba*0.1 and this will also effect the alpha channel (transparency)

I set the FieldOffset in my vertex-struct explicitly so it should actually map the Vector3 into a float4 without misaligning the following ones. Nonetheless the VS stage output does look correct and meanwhile me and our mathematician checked the matrices. It does seem to be correct. Weird thing though is that I can't move further away than ~1000f from the car. It just clamps to that.

Yeah I already figured so. But as long as the PS won't even run it doesn't matter anyway ...

EDIT: I changed it to Vector3 but it doesn't change anything at all. Moreover ever since I placed the camera behind the car model looking at it, I don't get any values anymore. EVERYTHING output by the VS is now 0 (except passed through values for color and texture). Debugging it I only see that it completely skips the matrix multiplication. Allocates the output structure and jumps right down to where I pass through the PS-required values and that's it... Seriously. Whats wrong with it all?! That's beyond weird behavior...

Mmh that's really strange. I would try to replace this complex model to a simple cube, so it's easier to see and debug. Than maybe try to switch from RH to LH, because default on DirectX is the left handed coordinate system. I can't see how you update the matrices but are you transposing them first or have you loaded the shaders with the row/column-major flag (can't remember exactly right now).

Well, I initially tried to render a quad which resulted in the same behavior: No PS ran but I could see the result in the IA and VS stages when debugging.

25 minutes ago, Auskennfuchs said:

are you transposing them first or have you loaded the shaders with the row/column-major flag (can't remember exactly right now).

Nope I forgot about that initially but did randomly try it with transposed matrices. I've read only recently that HLSL uses a different alignment by default - so now I do use "SetMatrixTranspose()" on the effect parameters. But it does not change anything.

I still don't understand why the vertex shader now skips the transformations ... I run over it with a debugger and it exactly skips the three transformations. This since I changed the input layout from float4 to float3.

My guess now is that this is some strange issue with Intel Integrated Graphics. I'm currently installing VS 17 and NVidia NSight on our CAD laptop which has a Nvidia Quadro in it. Maybe I'll find out more with that. Moreover I'm not sure what could possibly be the source of the issue since the Visual Studio Graphics Debugger is so incredibly instable. Exceptions and crashes on and on.

Alternatively it might be a problem with SharpDX and UWP. It's rather unusual since the codebase should be the same, but that's my only guess so far... UWP support in SharpDX seems to be rather untested and might have some issues nonetheless. Probably my last resort to contact xoofx directly ...

EDIT: Major break-through! The non-existing output was my own fault. I set local variables for each transformation step as test yesterday. I forgot to set the last position value into the output, though. And now I even see the PS running!

PixelShaderInput VS_Ambient(VertexShaderInput input)
{
	PixelShaderInput i;
	
	// Normalize first
	float4 world = mul(input.Position, World);
	float4 worldView = mul(world, View);
	float4 worldViewProj = mul(worldView, Projection);

	i.Position = worldViewProj;
	i.Texture = input.Texture;
	i.Color = input.Color;

	return i;
}

Can it be that HLSL does not support writing into the input struct's fields? Since I explicitly set world, worldView and worldViewProj it works ...

The result is still some weird mix of random lines but it's something.

EDIT2: Nope. Works, too. Okay. I'm highly confused... that's something im my 13 years of programming: Randomly fixing an issue that took me days and then trying to revert it to find out what the problem was...

EDIT3: I think I know the issue. It was some mapping issue from the vertex struct to the actual buffer. It's obviously not enough to have a Vector3 field and explicitly setting a offset. My guess is that the graphics card does not set the w-coordinate to 0 by default but uses the value that is currently at that memory location. Thus the w-value was invalid and the whole thing broke. Now I do set a Vector3 by constructor and create a Vector4 out of it with w set to 1.

18 minutes ago, IonThrust said:

Can it be that HLSL does not support writing into the input struct's fields? Since I explicitly set world, worldView and worldViewProj it works ...

No way, I use that all the time. Very strange that this would fix it for you...

26 minutes ago, IonThrust said:

float4 world = mul(input.Position, World);

float4x4 is the output of a matrix multiplication. At least there should be a warning when compiling the shader with implicit truncation or something.

1 minute ago, Auskennfuchs said:

float4x4 is the output of a matrix multiplication. At least there should be a warning when compiling the shader with implicit truncation or something.

Since it's a vector-translation it's okay that way. There are plenty of samples which show this exact approach. And it does work fine. Like I said, it was most likely a mapping issue - the w-coordinate had the value that was currently at this memory location.