bóng stpson - động cơ 3 doom - lỗi chính xác - vết nứt bóng - tại sao?


8

Tôi đang thử nghiệm các giới hạn của động cơ Doom 3 - liên quan đến kích thước bản đồ tối đa.

Tôi nhận thấy một số lỗi chính xác của bóng stprint trở nên rõ rệt hơn khi các đối tượng ngày càng rời xa nguồn gốc bản đồ.

tại vị trí: -10901 -18214 -11204 ví dụ 1

tại vị trí: -10802 -26483 -19383 ví dụ2

tại vị trí: -10802 -34683 -27540 ví dụ3

Tôi tin rằng những lỗi này đã được gọi là "vết nứt bóng tối" nhưng tôi không tích cực về những gì các tạo tác này đã được gọi trước đây.

Gần như tất cả các cổ vật xuất hiện dọc theo ranh giới của ánh sáng / bóng tối - có thể được nhìn thấy ở đây: nhập mô tả hình ảnh ở đây

Có ai đã nhìn thấy loại tạo tác đồ họa này trước đây với bóng stprint chưa? Họ được gọi là gì? Nguyên nhân là gì?

Ví dụ khác: linh tinh1 linh tinh2

Đây là Vanilla Doom 3 Engine như được tìm thấy ở đây: https://github.com/TTimo/doom3.gpl

Tôi nhận thấy trong khi kiểm tra r_useOptimizedShadows cvar (xử lý khối lượng bóng của hình học thế giới) mà tạo tác đã biến mất. Sau đó, tôi đã làm việc theo cách của tôi để chức năng này:

R_LinkLightSurf( &vLight->globalShadows, tri, NULL, light, NULL, vLight->scissorRect, true /* FIXME? */ );

mà tôi đã thay đổi thành này:

R_LinkLightSurf( &vLight->globalShadows, tri, NULL, light, NULL, vLight->scissorRect, false /* FIXME? */ );

Điều đó được loại bỏ khỏi các vật phẩm - nhưng bây giờ nó giả định rằng chúng ta không bao giờ ở trong các khối bóng của hình học thế giới. Vì vậy, bất cứ khi nào chúng ta đi vào bên trong một khối lượng bóng, khối lượng bóng đó không được hiển thị đúng.


1
Không chắc chắn về việc thực hiện cụ thể này nhưng điểm nổi sẽ mất độ chính xác khi bạn đi từ 0.
Concept3d

2
Đã đồng ý. 7 chữ số chỉ bằng khoảng độ chính xác tối đa bạn có thể mong đợi từ các số dấu phẩy động 32 bit (còn gọi là C / C ++ float). Bạn đã dễ dàng sử dụng hết 5 trong số đó. vi.wikipedia.org/wiki/ từ
rắn5

@ Concept3d - Tôi cho rằng việc chuyển đổi các số float có liên quan thành đôi sẽ giúp ích gì? Nếu ai đó có bí quyết kỹ thuật để làm điều đó. Ngay cả khi nó sẽ dẫn đến thời gian kết xuất lâu hơn.
Stepan1010

1
@glampert Mình cập nhật câu hỏi. Đó là động cơ vanilla Doom 3.
Stepan1010

1
Điều gì xảy ra khi bạn thay đổi tính toán khối lượng bóng? (Ví dụ: chỉ chia tỷ lệ tất cả các khối lượng bóng theo một giá trị nhỏ) Các tạo tác vẫn xuất hiện / thay đổi / biến mất?
Roy T.

Câu trả lời:


3

Cuối cùng tôi đã tìm ra một giải pháp - thực sự là một vài giải pháp khác nhau. Tôi đã không tìm ra nguyên nhân thực sự của tạo tác từ góc độ lập trình đồ họa - nhưng tôi đã tìm thấy một số giải pháp.

Như tôi đã nói trước đây trong câu hỏi của mình, có vẻ như tạo tác chỉ xảy ra trên các khối bóng được tính toán trước của hình học tĩnh thế giới (về cơ bản là hình học mà động cơ biết là sẽ không bao giờ di chuyển nên nó tính toán trước -Thời gian khối lượng bóng và những thứ khác với một lệnh được nhập trong bảng điều khiển được gọi là "dmap"). Tôi đã không tìm ra lý do tại sao nó chỉ nằm trên bóng của hình học thế giới tĩnh mà không phải trên bất kỳ mô hình ASE hoặc LWO nào.

Bây giờ, điều mà tôi nhận thấy là thực sự có rất nhiều tham số có thể được sử dụng với lệnh dmap - một trong những tham số này được gọi là "ShadowOpt" - phải đại diện cho mức tối ưu hóa bóng. Tham số này đặt ra một enum - dường như có một vài mức tối ưu hóa bóng khác nhau:

typedef enum {
    SO_NONE,            // 0 // NOTE: I haven't tried this one yet - should test this one.
    SO_MERGE_SURFACES,  // 1 // NOTE: this was the original default one - it causes some artifacts - the ones I have been trying to fix.
    SO_CULL_OCCLUDED,   // 2 // NOTE: this one works the best - takes a bit longer - but it has alot of unnecessary print statements that could probably be removed.
    SO_CLIP_OCCLUDERS,  // 3 // NOTE: I haven't tried this one yet - but it is not used anywhere.
    SO_CLIP_SILS,       // 4 // NOTE: I haven't tried this one yet - should test this one.
    SO_SIL_OPTIMIZE     // 5 // NOTE: this one doesn't seem to work well at all - and it takes an extrememly long amount of time - was probably an expirimental version.
} shadowOptLevel_t;

Tôi đã thành công với tùy chọn 2 - "SO_CULL_OCCLUDED". Nó sửa tất cả các tạo phẩm - mất nhiều thời gian hơn để chạy - nhưng tôi tin rằng phần lớn thời gian này được dành để in một lượng lớn thông tin lên bàn điều khiển - những bản in này có thể bị giảm hoặc bị loại bỏ.

Một trong những nơi đã cho tôi một số manh mối là nhận xét ở đây trong tr_stpsonshadow.cpp:

// if we are running from dmap, perform the (very) expensive shadow optimizations
// to remove internal sil edges and optimize the caps
if ( callOptimizer ) {

Bây giờ, vấn đề với việc chỉ thực hiện tối ưu hóa bóng "phụ" này trong "dmap" là nếu bất kỳ đèn nào trong số này được di chuyển (điều này luôn có thể tùy thuộc vào loại dự án bạn đang thực hiện) - thì nó sẽ mặc định trở lại Quá trình tạo khối lượng bóng thời gian thực "không được tối ưu hóa" (đối với ánh sáng được di chuyển) và các tạo tác sẽ xuất hiện lại cho ánh sáng đó. Vì vậy, cách duy nhất để đảm bảo rằng những cổ vật này sẽ không xuất hiện là luôn luôn chạy quá trình tối ưu hóa rất tốn kém cho các bóng thế giới tĩnh này. Thực tế nó rất đắt vì vậy đây sẽ là giải pháp cuối cùng tuyệt đối nếu bạn không thể tìm ra một giải pháp đồ họa phù hợp. (nếu bạn làm như vậy, hãy chắc chắn để đăng giải pháp của bạn ở đây.)

Tôi muốn giới thiệu cho bất kỳ ai tạo bản đồ lớn cho động cơ vanilla Doom 3 - và sử dụng hình học worldspawn - rằng họ tạo ra một cvar mà họ có thể thay đổi tùy theo nhu cầu của họ để tạo khối lượng bóng tối ưu hóa theo thời gian thực. Tôi đã gọi cvar r_useExpensiveShadowOptimizes của tôi - dường như là một oxymoron. Ví dụ:

// if we are running from dmap, perform the (very) expensive shadow optimizations
// to remove internal sil edges and optimize the caps
if ( callOptimizer || r_useExpensiveShadowOptimizations.GetBool() ) {

Tôi cũng khuyên bạn nên tùy thuộc vào độ lớn của bản đồ của bạn (và giả sử đèn sẽ không di chuyển), bạn nên tăng mức tối ưu hóa âm lượng bóng tĩnh với tham số "ShadowOpt" cho dmap.

Vì vậy, về cơ bản tất cả những thứ bạn cần để có một bản đồ lớn và không có các tạo tác bóng tối đều có sẵn cho bạn, bạn chỉ cần quyết định những thứ bạn sẽ cần sử dụng. Làm điều đó trong thời gian thực là vô cùng tốn kém và chỉ nên được thực hiện như là phương sách cuối cùng nếu bạn không thể tìm thấy một giải pháp đồ họa phù hợp. Làm điều đó trong DMAP có ý nghĩa hoàn hảo vì nó giải quyết vấn đề và chỉ mất thêm vài giây để bản đồ biên dịch.


2

Đây rất có thể là một lỗi chính xác của con trỏ nổi, vì Doom đã sử dụng floats để kết xuất (chủ yếu là giới hạn OpenGL). Tuy nhiên, loay hoay tr_stencilshadow.cpp, tôi nhận thấy bình luận này có thể liên quan đến vấn đề ( PointsOrdered()chức năng bên trong ):

// vectors that wind up getting an equal hash value will
// potentially cause a misorder, which can show as a couple
// crack pixels in a shadow

....

// in the very rare case that these might be equal, all that would
// happen is an oportunity for a tiny rasterization shadow crack

Nó đây rồi Nó cũng có thể là một hạn chế đã biết về cách thực hiện kết xuất bóng. Thẳng thắn mà nói, mã rất lộn xộn và khó đọc, vì vậy tôi không thể nói cho bạn biết chắc chắn. Bạn có thể thử gửi mail cho các nhà phát triển để có thêm thông tin.


1
Tôi cũng thấy bình luận đó. Tuy nhiên, khi tôi nhận xét mã của hàm đó và nó đã trả về đúng (hoặc sai - không thành vấn đề) - nó dường như không tạo ra bất kỳ sự khác biệt trực quan nào với bất cứ điều gì cả. Bạn có nghĩ rằng bất kỳ nhà phát triển nào sẽ trả lời nếu tôi gửi email cho họ không? Tôi cảm thấy như họ có thể sẽ không trả lời. Tôi đoán tôi có thể thử nếu tất cả những thứ khác thất bại.
Stepan1010

@ Stepan1010 Chà, không biết nữa, Carmack là một chàng trai tuyệt vời, tôi đã từng gửi mail cho anh ấy về một cái gì đó không liên quan đến lập trình và anh ấy đã trả lời. Tôi đoán nó sẽ không gây hại cho việc thử ... Nhưng có lẽ bạn nên gửi thư cho người bảo trì repo, vì Carmack không còn là thành viên của idSoftware. Nếu bạn thể hiện một vấn đề chính đáng và công việc bạn đã làm, họ có thể quan tâm.
glampert
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.