Phác thảo màu trắng kỳ lạ xung quanh mô hình


19

Tôi đang làm việc với một trò chơi trong XNA 4 và gần đây tôi đã chuyển sang triển khai tạo bóng hoãn lại sau hướng dẫn này . Một phác thảo màu trắng kỳ lạ đang hiển thị trên các mô hình của tôi bây giờ và tôi không chắc điều gì gây ra điều này. Tôi nghĩ có lẽ đó là sự thiếu chính xác đối với mục tiêu kết xuất bình thường hoặc mục tiêu kết xuất độ sâu nhưng việc tăng chúng lên 64 bit (Rgba64) thay vì 32 (Màu) không giúp ích được gì. Tôi cũng nghĩ rằng nó có thể là một số vấn đề với tính toán đầu cơ nên tôi đã thử đặt giá trị đầu ra thành 0 nhưng điều đó cũng không giúp được gì. Gỡ lỗi pixel trong PIX cho thấy giá trị khuếch tán đang được tính gần như trắng cho pixel đó. Có ý kiến ​​gì không? Tôi đã bao gồm một hình ảnh của vấn đề dưới đây, dễ dàng hơn để nhìn thấy nó ở kích thước đầy đủ.

Pixel Shader:

float4 PixelShaderFunction(VertexShaderOutput input) : COLOR0
{
    input.ScreenPosition.xy /= input.ScreenPosition.w;

    float2 texCoord = 0.5f * (float2(input.ScreenPosition.x, -input.ScreenPosition.y) + 1) - halfPixel;

    float4 normalData = tex2D(normalSampler, texCoord);

    //Transform normal back into [-1, 1] range
    float3 normal = normalize(2.0f * normalData.xyz - 1.0f);

    float specularPower = normalData.a;
    float specularHardness = tex2D(colorSampler, texCoord).a * 255;
    float depthVal = tex2D(depthSampler, texCoord).r;

    //Compute screen-space position
    float4 position = float4(input.ScreenPosition.xy, depthVal, 1.0f);

    //Transform to world space
    position = mul(position, InvertViewProjection);
    position /= position.w;

    //Surface-to-light vector
    float3 lightVector = lightPosition - position;

    float3 projectedTexCoords = position - lightPosition;
    projectedTexCoords = mul(projectedTexCoords, float3x3(
                            float3(-1, 0, 0),
                            float3(0, 1, 0),
                            float3(0, 0, 1)));

    float distanceToLight = length(lightVector) / lightRadius;
    float shadow = ShadowContribution(projectedTexCoords, distanceToLight);

    float attenuation = saturate(1.0f - distanceToLight);

    lightVector = normalize(lightVector);

    //Compute diffuse light
    float normalDotLight = max(0, dot(normal, lightVector));
    float3 diffuseLight = normalDotLight * Color.rgb;

    float3 reflectionVector = normalize(reflect(-lightVector, normal));
    float3 directionToCamera = normalize(cameraPosition - position);
    float specularLight = specularPower * pow(saturate(dot(reflectionVector, directionToCamera)), specularHardness);

    return shadow * attenuation * lightIntensity * float4(diffuseLight.rgb, specularLight);
}

Chỉnh sửa : Xin lỗi về JPG, trình tải lên của stackexchange đã tự mình làm điều đó. Roy T: Tôi thực sự đã tham khảo chuyển đổi XNA4 của bạn về hướng dẫn cho các phần đã thay đổi từ XNA3. Vì tôi không thực hiện bất kỳ thay đổi lớn nào đối với mã, tôi nghĩ có thể lỗi này tồn tại trong bản gốc nhưng không thể nhìn thấy với rất nhiều ánh sáng di chuyển xung quanh, vì vậy tôi đã loại bỏ tất cả trừ một ánh sáng và lỗi lại xuất hiện (nhìn gần khuỷu tay của thằn lằn)

Dưới đây là nội dung GBuffer cho cảnh của tôi:

Bộ đệm màu: Bộ đệm sâu: Bộ đệm thông thường: Kết xuất cuối cùng:

Chỉnh sửa2 :

Tôi bắt đầu nghi ngờ vấn đề là CombineFinal.fx khi nó lấy mẫu bản đồ màu. Đây là tính toán cho pixel có màu đúng ngay bên cạnh pixel trắng:

diffuseColor        : (0.435, 0.447, 0.412)
diffuseLight        : (1.000, 1.000, 0.902)
light               : (1.000, 1.000, 0.902, 0.000)
PixelShaderFunction : (0.435, 0.447, 0.371, 1.000)
specularLight       : 0.000

Và đây là đầu ra từ một pixel trắng không đúng màu ngay bên cạnh nó:

diffuseColor        : (0.824, 0.792, 0.741)
diffuseLight        : (1.000, 1.000, 0.902)
light               : (1.000, 1.000, 0.902, 0.000)
PixelShaderFunction : (0.824, 0.792, 0.669, 1.000)
specularLight       : 0.000

DiffuseColor là sự khác biệt duy nhất và màu này được lấy trực tiếp từ bản đồ màu. Có lẽ có một lỗi nhỏ trong tính toán của tọa độ kết cấu để lấy mẫu từ?

Đèn chiếu sáng:


4
Xin vui lòng không jpeg nén một ảnh chụp màn hình hiển thị một trục trặc đồ họa tinh tế. Mọi người sẽ muốn nhìn thấy vấn đề trong sinh sản hoàn hảo.
aaaaaaaaaaaa

Chà, nén jpeg thực sự cho phép trục trặc khá độc đáo tôi nghĩ, chỉ một pixel và chỉ khi một số thứ nhất định được kết hợp lại (độ lệch lớn trong độ sâu Z và độ sáng cao (khá) trên tất cả các pixel). Chúc may mắn, kết xuất hoãn lại là khá kỹ thuật.
Valmond

2
Không chắc có giúp được không, nhưng bạn đang sử dụng một phiên bản mã / hướng dẫn rất cũ, mã / hướng dẫn thực tế của Catalin Zima hiện có tại: catalinzima.com/tutorials/deferred-rendering-in-xna và XNA4.0 bị xử phạt phiên bản được đặt tại đây: roy-t.nl/index.php/2010/12/28/ Khăn
Roy T.

Ngoài ra, như mọi khi với gỡ lỗi kết xuất, bạn có thể đăng ảnh chụp màn hình từ tất cả các bộ đệm không? Có lẽ nó nằm trong bộ đệm chiếu sáng, nhưng nó có thể là thứ khác.
Roy T.

Bản năng của tôi là nó sẽ là một vấn đề với cách một phần của thuật toán xử lý một góc chính xác 90 độ, nhưng tôi sẽ phải chơi với ode sau khi làm việc để xem xét kỹ hơn.
Jordaan Mylonas

Câu trả lời:


4

Tôi cũng có đường viền màu trắng hoặc "quầng sáng" xung quanh các mô hình của mình, khi tôi bắt đầu với trình kết xuất hoãn lại của riêng mình. Vấn đề là giá trị bù kết cấu cho lớp phủ mục tiêu kết xuất không được thiết lập chính xác. Một số kết cấu cần thiết được đặt thành +0,5 pixel cho phần bù thay vì -0,5 pixel.

Chỉ sau khi điều chỉnh giá trị của một số độ lệch kết cấu thì các đường viền đã biến mất. Rất có thể đó là một trong những bóng đổ ánh sáng.

Chỉnh sửa: bằng cách này, tôi cũng đã học được từ hướng dẫn của Catalin Zima, một nhánh trong ví dụ của bạn, vì vậy nó sẽ hoạt động.


Yup, đó là nó. Tôi đã thay đổi nó thành + HalfPixel cho tất cả các mẫu phối hợp trong bóng đổ ánh sáng và hiện tại quầng sáng đã biến mất.
Telanor

0

Tôi không chắc chính xác những gì đang xảy ra, nhưng một vài điều cần kiểm tra lại:

  1. Hãy chắc chắn rằng bạn đã tắt tính năng lọc kết cấu khi lấy mẫu bộ đệm G - không có song tuyến hoặc bất đẳng hướng hay bất cứ thứ gì.

  2. Tôi thấy bạn đang thêm một nửa pixel vào tọa độ kết cấu; kiểm tra kỹ xem có đúng không. Tôi không đủ quen thuộc với XNA để biết phần bù phải là gì, nhưng bạn sẽ có thể kiểm tra nó bằng cách viết một shader lấy mẫu một trong các bộ đệm G và chỉ xuất ra mẫu. Sau đó lật qua lại giữa cái này và hiển thị bộ đệm G trực tiếp trên màn hình. Nếu bạn đã có độ lệch chính xác, bạn sẽ không thấy sự khác biệt nào, thậm chí không phải là một pixel.


Tôi đã đi và thay đổi mọi thứ liên quan đến GBuffer thành POINT (tôi cho rằng không cho phép lọc?) Và nó vẫn như vậy. Về điểm thứ hai của bạn, sẽ không xuất trực tiếp GBuffer giống hệt nhau: tạo một shader chỉ xuất dữ liệu? Bạn có thể giải thích thêm một chút không?
Telanor

Chà, làm thế nào bạn tạo ra các ảnh chụp màn hình của bộ đệm G ở trên? Tôi đoán bạn gọi một số loại hàm API tích hợp, để sao chép từng pixel một từ bộ đệm G sang màn hình (bộ đệm phía sau)? (Tôi không biết XNA vì vậy tôi không biết nó sẽ được gọi là gì.) Tôi đang nói, hãy so sánh đầu ra của hàm sao chép một-một tích hợp với đầu ra của trình đổ bóng pixel được viết để làm gì một bản sao một-một ... theo cách đó bạn có thể chắc chắn các tọa độ kết cấu là chính xác và bạn thực sự đang lấy mẫu một-một.
Nathan Reed
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.