Tại sao DirectX sử dụng hệ tọa độ tay trái?

Tôi đã cân nhắc việc đăng bài trên Stack Overflow, nhưng câu hỏi đặt ra cho tôi là quá chủ quan vì tôi không thể nghĩ ra một lời giải thích kỹ thuật hợp lý cho sự lựa chọn của Microsoft trong vấn đề này. Nhưng câu hỏi này đã làm tôi bực mình quá lâu và vấn đề liên tục xuất hiện trong một trong những dự án của tôi và tôi chưa bao giờ thực sự thấy một nỗ lực giải thích điều này:

OpenGL sử dụng hệ thống tọa độ thuận tay phải, trong đó phần + Z của hệ tọa độ thế giới mở rộng về phía người xem.

DirectX sử dụng hệ thống thuận tay trái trong đó phần + Z của tọa độ thế giới kéo dài vào màn hình, cách xa người xem.

Tôi chưa bao giờ sử dụng API Glide , vì vậy tôi không biết nó hoạt động như thế nào, nhưng từ những gì tôi có thể thu thập, nó cũng sử dụng một hệ thống thuận tay trái.

Có một lý do kỹ thuật cho việc này? Và nếu không, có một số lợi thế về mặt khái niệm đối với sự thuận tay cụ thể của một hệ tọa độ không? Tại sao người ta sẽ chọn cái này hơn cái kia?

Tôi biết đây là một bài viết cũ, nhưng tôi thấy bài đăng này được tham chiếu và không thích giai điệu của câu trả lời đã chọn.

Vì vậy, tôi đã làm một chút điều tra!

1. DirectX đã cũ . Nó được phát hành lần đầu tiên vào năm 1995, khi thế giới có nhiều hơn Nvidia và ATI , DirectX vs OpenGL. Đó là hơn 15 năm, mọi người.
2. 3dfx Interactive ' Glide (một trong những đối thủ của DirectX ngày trước. OpenGL không có nghĩa là để chơi game trước đó) đã sử dụng hệ thống tọa độ thuận tay trái.
3. POV-Ray và RenderMan (phần mềm kết xuất của Pixar), cũng sử dụng hệ thống tọa độ thuận tay trái.
4. DirectX 9+ có thể hoạt động với cả hai hệ tọa độ.
5. Cả WPF và XNA (hoạt động với DirectX trong các cảnh) đều sử dụng hệ thống tọa độ thuận tay phải.

Từ điều này, tôi có thể suy đoán về một vài điều:

• Tiêu chuẩn công nghiệp không phải là tiêu chuẩn như mọi người muốn.
• Direct3D được xây dựng trong thời gian mọi người làm mọi thứ theo cách riêng của họ và các nhà phát triển có thể không biết rõ hơn.
• Thuận tay trái là tùy chọn, nhưng theo thông lệ trong thế giới DirectX.
• Vì các quy ước đã hết hiệu lực, mọi người đều nghĩ DirectX chỉ có thể hoạt động với thuận tay trái.
• Microsoft cuối cùng đã học và tuân theo tiêu chuẩn trong bất kỳ API mới nào mà họ đã tạo.

Do đó, kết luận của tôi sẽ là:

Khi họ phải chọn, họ không biết về tiêu chuẩn, chọn hệ thống 'khác' và mọi người khác chỉ đi theo để đi xe. Không có doanh nghiệp mờ ám, chỉ là một quyết định thiết kế đáng tiếc đã được thực hiện bởi vì khả năng tương thích ngược là tên của trò chơi của Microsoft.

Tôi ngạc nhiên không ai đề cập đến điều gì: OpenGL cũng hoạt động trong một hệ thống tọa độ thuận tay trái. Ít nhất, nó hoạt động khi bạn làm việc với các shader và sử dụng phạm vi độ sâu mặc định.

Khi bạn ném ra đường ống chức năng cố định, bạn xử lý trực tiếp với "không gian clip". Đặc tả OpenGL định nghĩa không gian clip là một hệ tọa độ đồng nhất 4D. Khi bạn theo dõi các biến đổi thông qua tọa độ thiết bị được chuẩn hóa và xuống không gian cửa sổ, bạn sẽ thấy điều này.

Không gian cửa sổ nằm trong không gian của các pixel của cửa sổ. Nguồn gốc nằm ở góc dưới bên trái, với + Y đi lên và + X đi bên phải. Nghe có vẻ rất giống một hệ tọa độ tay phải. Nhưng còn Z thì sao?

Phạm vi độ sâu mặc định (glDepthRange) đặt giá trị Z gần bằng 0 và giá trị Z xa thành một . Vì vậy, + Z sẽ biến mất khỏi người xem.

Đó là một hệ thống tọa độ thuận tay trái. Có, bạn có thể thay đổi kiểm tra độ sâu từ GL_LESS thành GL_GREATER và thay đổi glDepthRange từ [0, 1] thành [1, 0]. Nhưng trạng thái mặc định của OpenGL là hoạt động trong hệ thống tọa độ thuận tay trái . Và không có biến đổi nào cần thiết để lấy không gian cửa sổ từ không gian clip phủ định Z. Vì vậy, không gian clip, đầu ra của shader đỉnh (hoặc hình học) là không gian thuận tay trái (loại. Đó là không gian đồng nhất 4D, vì vậy thật khó để xác định sự thuận tay).

Trong đường ống chức năng cố định, các ma trận chiếu tiêu chuẩn (được sản xuất bởi glOrtho, glFrustum và tương tự) đều chuyển từ không gian thuận tay phải sang tay trái . Họ lật nghĩa của Z; chỉ cần kiểm tra ma trận họ tạo ra. Trong không gian mắt, + Z di chuyển về phía người xem; trong không gian hậu chiếu, nó di chuyển đi.

Tôi nghi ngờ Microsoft (và GLide) chỉ đơn giản là không bận tâm đến việc thực hiện phủ định trong ma trận chiếu của họ.

Đó là lịch sử thuần túy. Vào thời cổ đại, các lập trình viên đồ họa hang động ban đầu nghĩ về màn hình (teletype? Stonetype?) Nhìn bề mặt như một biểu đồ hai chiều. Trong toán học và kỹ thuật, các quy ước thông thường để vẽ các điểm dữ liệu trên giấy biểu đồ là: x = right, y = up. Rồi một ngày, khoảng một tuần sau khi phát minh ra bánh xe silicon, ai đó đã nghĩ đến đồ họa 3D. Khi bóng đèn nến của ý tưởng này nhấp nháy trên đầu của họ, vì bất kỳ lý do gì, họ chọn thêm Z = ra khỏi người xem. (Ouch, tay phải của tôi đau khi tưởng tượng điều đó.)

Họ không biết rằng một ngày nào đó con cháu xa của họ sẽ trở thành kỹ sư, nhà khoa học, họa sĩ giỏi, họa sĩ thương mại, họa sĩ hoạt hình, nhà thiết kế sản phẩm, v.v. và thấy đồ họa 3D hữu ích. Tất cả những người hiện đại tốt đẹp này sử dụng các hệ tọa độ thuận tay phải để phù hợp với nhau và các văn bản toán học và quy ước vật lý được thiết lập nhiều hơn.

Thật ngu ngốc khi căn cứ hệ thống tọa độ 3D trên bề mặt màn hình. Đó là mô hình được tính - hình tam giác và đa giác và mặt phẳng mô tả một ngôi nhà, ghế, yêu tinh màu xanh lá cây thừa cân hoặc thiên hà. Ngày nay, tất cả chúng ta đều thiết kế và mô hình hóa các công cụ trong các hệ thống XYZ thuận tay phải và làm như vậy về mặt thế giới của mô hình, thậm chí trước khi nghĩ nó sẽ được kết xuất như thế nào. Máy ảnh được thêm vào một số điểm, có thể được chế tạo để bay xung quanh theo những cách điên rồ và cơ sở hạ tầng vô hình có thể chuyển đổi mô hình thành các pixel mà trong ruột của nó phải xoay quanh với các biến đổi hệ thống phối hợp.

Chỉ để thêm vào sự nhầm lẫn, một số thư viện đồ họa nhận ra rằng CRT quét hình ảnh từ trên xuống dưới và do đó có Y = xuống. Điều này được sử dụng ngay cả ngày nay trong tất cả các hệ thống cửa sổ và trình quản lý cửa sổ - X11, fvwm, gtk +, Win31 API, v.v. Điều này chỉ cần quan tâm đến các lập trình viên ứng dụng và thiết kế GUI.

Cả hai về cơ bản là tương đương nhau, vì người ta có thể dễ dàng chuyển đổi thành người khác. Lợi thế duy nhất tôi có thể tìm thấy cho hệ thống thuận tay trái là: vì các vật thể ở xa người quan sát hơn, theo bất kỳ hướng nào (x, y hoặc z), khoảng cách là giá trị cao hơn. Nhưng tôi không biết đây có phải là lý do tại sao Microsoft chọn cái này hơn cái kia không.

POV-Ray cũng sử dụng hệ thống hành lang thuận tay trái.

Nhà phát triển chính của DirectX (và Direct3D) Alex St. John gần đây đã nhận xét về điều đó. Trong một bài viết về lịch sử của Direct3D, ông đã viết:

Tôi [...] đã được yêu cầu chọn giao diện cho API Direct3D. Tôi đã chọn một hệ thống tọa độ tay trái, một phần ngoài sở thích cá nhân . [...] Đó là một lựa chọn tùy ý .

Nguồn: http://www.alexstjohn.com/WP/2013/07/22/the-evolution-of-direct3d/

Điều cần hiểu là một lượng lớn thời gian lập trình viên đã bị lãng phí khi chuyển đổi giữa các hệ tọa độ thuận tay trái và tay phải, và thậm chí nhiều thời gian lập trình viên đã bị lãng phí khi nhớ hệ thống nào là cần thiết tại bất kỳ thời điểm cụ thể nào.

Tất cả điều đó biến mất khi hệ thống tọa độ tay phải trở thành tiêu chuẩn công nghiệp.

Có đủ hệ thống tọa độ được sử dụng phổ biến, mà không cần tăng gấp đôi số lượng bằng cách đưa ra một câu hỏi thuận tay. Xem Minkler & Minkler, "Hệ thống phối hợp và biến đổi hàng không vũ trụ" . Nếu bạn đang kinh doanh trong ngành hàng không vũ trụ, ví dụ như mô phỏng chuyến bay, bạn CẦN cuốn sách đó.

Tôi đoán là Microsoft đã không có BẤT CỨ AI trong dự án DirectX, người biết bất cứ điều gì về các tiêu chuẩn ngành, đã không nhận ra rằng đó là một tiêu chuẩn công nghiệp và cho rằng điều đó không thành vấn đề.

Khả năng khác là họ biết các hệ thống thuận tay phải là tiêu chuẩn công nghiệp và họ đã cố tình tạo DirectX bằng tay trái, để khiến mọi người chuyển đổi mã sử dụng DirectX để sử dụng OpenGL thay vào đó, không được xem xét. Nếu tôi phát hiện ra rằng đây thực sự là trường hợp, tôi sẽ thấy cần phải bắt tay vào một sự nghiệp mới và có lẽ là ngắn ngủi như một kẻ giết người bằng rìu ở Redmond.

Đối với tất cả những người nghĩ rằng không có lợi thế cho việc thuận tay phải hoặc thuận tay trái, bạn hoàn toàn sai. Sự thuận tay phải của các hệ thống phối hợp của Cartesian xuất phát từ định nghĩa của sản phẩm chéo vector. Đối với các vectơ cơ sở XYZ u, vvà w, w = u X v.

Định nghĩa này là cơ bản cho toán học vectơ, tính toán vectơ và phần lớn vật lý. Giả sử rằng bạn đang cố gắng mô phỏng các tương tác điện từ. Bạn có một vectơ từ trường Mvà một hạt tích điện chuyển động trong trường đó với vận tốc v. Cách nào tăng tốc phí? Dễ dàng - theo hướng M X v. Ngoại trừ một số kẻ ngốc nghĩ rằng sẽ rất vui khi làm cho hệ thống hiển thị của bạn thuận tay trái, vì vậy nó sẽ tăng tốc theo hướng -M X v.

Về cơ bản, bất kỳ tương tác vật lý nào giữa hai đại lượng vectơ đều được xác định là thuận tay phải và do đó, bất cứ khi nào bạn cần mô phỏng tương tác đó, bạn nên hy vọng hệ thống đồ họa của mình thuận tay phải hoặc bạn sẽ cần phải nhớ xung quanh các dấu hiệu tiêu cực. tất cả toán học của bạn.

Câu trả lời thực sự cho việc thuận tay trái sớm của Direct3D ít độc ác hơn nhiều so với một số bạn đang suy đoán. DirectX bắt đầu khi Microsoft mua RenderMorphics vào năm 1995.

Vào thời điểm đó, văn bản đồ họa tiêu chuẩn được sử dụng trong các văn phòng RenderMorphics là "Nguyên tắc của đồ họa máy tính tương tác" của Newmann và Sproul, mọi thứ sử dụng tọa độ tay trái. Đó là cùng một cuốn sách mà tôi đã sử dụng ở trường đại học. Nhìn vào mã D3D, bạn thậm chí có thể thấy chúng bằng cách sử dụng các tên biến khớp với các phương trình trong sách.

Đó không phải là một âm mưu của Microsoft. Quyết định được đưa ra trước khi Microsoft thậm chí đi vào hình ảnh.

Cuối cùng, không phải là tốt hơn so với bên kia - bạn đang ánh xạ tọa độ 3D sang bề mặt 2D, do đó, chiều thứ ba (thực sự tạo ra 3D) có thể được chọn tùy ý, chỉ vào trình xem hoặc vào màn hình. Dù sao bạn cũng sẽ đưa mọi thứ qua một ma trận 4 x 4, vì vậy không có lý do kỹ thuật nào để chọn cái này hơn cái kia. Về mặt chức năng, người ta có thể tranh luận:

• Có một sự đồng thuận khá rộng trong điện toán và các lĩnh vực khác để trục X chạy từ trái sang phải (hàng không rõ ràng là một ngoại lệ đáng chú ý).
• Trong toán học, trục Y chỉ lên. (Ngoài ra, Up Is Where The Bubbled Go).
• Trên màn hình máy tính, trục Y chỉ xuống (vì đó là cách màn hình CRT hoạt động và cũng vì đó là thứ tự mà hầu hết các tập lệnh của con người sắp xếp các hàng).
• Khi bạn nhìn vào phía "có thể nhìn thấy" của một bề mặt trong mặt phẳng X / Y, bình thường sẽ hướng về phía người xem (chẳng hạn như khi bạn nhìn vào cảnh quay vệ tinh; điểm "độ cao trên mực nước biển" ở vệ tinh, chứ không phải tại trung tâm của Trái đất). Vì bình thường cho mặt phẳng X / Y là vectơ trục Z, do đó trục Z cũng sẽ hướng về phía người xem.
• Khi bạn nhìn vào hình ảnh 3D trên màn hình máy tính, các điểm ở xa người xem sẽ có thành phần Z lớn hơn. Do đó, trục Z sẽ trỏ vào màn hình.

Kết luận : Có một số sự đồng thuận cho trục X, nhưng đối với hai hướng còn lại, cả hai hướng có thể được tranh luận, mang lại hai cấu hình thuận tay phải và hai tay trái, và tất cả đều có ý nghĩa.

Sự thật thú vị.

Direct3D (không phải DirectX - DirectX cũng bao gồm đầu vào, âm thanh, v.v.) thực sự không có hệ thống phối hợp thuận tay trái.

Nó hoàn toàn có khả năng hỗ trợ cả hai hệ thống RH và LH. Nếu bạn xem trong tài liệu SDK, bạn sẽ thấy các chức năng như D3DXMatrixPers perspectiveFovLH và D3DXMatrixPers perspectiveFovRH. Cả hai đều hoạt động và cả hai đều tạo ra một ma trận chiếu có thể được sử dụng thành công với hệ thống lựa chọn phối hợp của bạn. Địa ngục, bạn thậm chí có thể sử dụng cột chính trong Direct3D nếu bạn muốn; nó chỉ là một thư viện ma trận phần mềm và bạn không bắt buộc phải sử dụng nó. Mặt khác, nếu bạn muốn sử dụng nó với OpenGL, bạn sẽ thấy rằng nó cũng hoạt động hoàn hảo với OpenGL (có lẽ là bằng chứng chắc chắn về sự độc lập của thư viện ma trận với chính Direct3D).

Vì vậy, nếu bạn muốn sử dụng hệ thống RH trong chương trình của mình, chỉ cần sử dụng phiên bản -RH của chức năng. Nếu bạn muốn sử dụng hệ thống LH, hãy sử dụng phiên bản -LH. Direct3D không quan tâm. Tương tự, nếu bạn muốn sử dụng hệ thống LH trong OpenGL - chỉ cần glLoadMatrix một ma trận chiếu LH. Không có thứ gì trong số này là quan trọng và nó không ở đâu gần vấn đề lớn mà đôi khi bạn thấy nó được giải quyết.

Không có lợi thế kỹ thuật nào cho sự thuận tay, nó hoàn toàn tùy ý. Cả hai đều hoạt động tốt miễn là bạn nhất quán.

Vì những lợi thế của tính nhất quán, lý tưởng nhất là người ta chỉ nên "sử dụng những gì mọi người khác đang sử dụng", vì điều đó khá khó khăn trong nhiều trường hợp, bởi vì trong thực tế, không có quy ước "ưa thích" nào cả: Tốt nhất, có một số tính nhất quán trong các cộng đồng nhất định (ví dụ OpenGL).

Vì vậy, tôi nghĩ rằng câu trả lời cơ bản cho câu hỏi này là: Họ đã chọn những gì họ đã chọn bởi vì nó cảm thấy đúng (không nghi ngờ gì họ có một số kinh nghiệm trước đây với sự thuận tay đó) và có rất ít lý do để không.

Cuối cùng, điều này tạo ra sự khác biệt nhỏ. Bất cứ ai nghiêm túc muốn trao đổi tài sản / mã với các hệ thống / cộng đồng khác sẽ phải chuẩn bị để đối phó với chuyển đổi thuận tay, vì đó là thực tế của đồ họa 3D.

Cung cấp điều này như là tài liệu bổ sung cho câu trả lời trước đây của tôi ở đây. Từ một thông số OpenGL cũ từ những năm 1990:

OpenGL không ép buộc thuận tay trái hoặc tay phải trên bất kỳ hệ thống tọa độ nào của nó.

(nguồn: http://www.opengl.org/documentation/specs/version1.2/opengl1.2.1.pdf ).

Vì vậy, vì cả D3D và OpenGL đều không thực thi bất kỳ sự thuận tay nào, câu hỏi thực sự là: tại sao mọi người lại coi đây là một vấn đề lớn?

Tôi ghét phải nói với bạn, nhưng 'bàn tay' của một bộ tọa độ thực sự mang tính chủ quan - nó phụ thuộc vào cách bạn tưởng tượng bạn đang nhìn mọi thứ. Một ví dụ, từ thông số bản đồ khối lập phương OpenGL: nếu bạn tưởng tượng bên trong khối nhìn ra ngoài, hệ tọa độ là thuận tay trái, nếu bạn nghĩ đến việc nhìn từ bên ngoài thì nó là tay phải. Thực tế đơn giản này gây ra sự đau buồn vô tận, bởi vì để có được câu trả lời đúng về mặt số, tất cả các giả định của bạn phải nhất quán, mặc dù tại địa phương nó không thực sự quan trọng với giả định nào bạn đưa ra.

Thông số kỹ thuật OpenGL chính thức là "trung lập thuận tay" và cố gắng hết sức để tránh vấn đề này - nghĩa là đưa nó ra cho lập trình viên. Tuy nhiên, có một "thay đổi tay" giữa tọa độ mắt và tọa độ clip: trong mô hình và không gian mắt chúng ta đang tìm kiếm, trong không gian clip và thiết bị chúng ta đang tìm kiếm. Tôi luôn luôn phải vật lộn với hậu quả của sự phức tạp vô tình này.

Sản phẩm chéo là bạn của chúng tôi, vì nó cho phép bạn tạo ra một hệ tọa độ 3D chắc chắn thuận tay phải hoặc tay trái từ một cặp vectơ. Nhưng bàn tay nào phụ thuộc vào loại vectơ nào bạn gọi là "X".

Tôi có thể nói rằng tiêu chuẩn công nghiệp là sai từ nơi đầu tiên

Tiêu chuẩn công nghiệp của tọa độ thực sự đến từ tọa độ bàn, khi mọi người vẽ mọi thứ trên bàn, đó là mặt phẳng ngang. X là trái / phải và Y là trước / sau, do đó, nó chỉ làm cho Z hướng lên và được sinh ra Hệ thống tọa độ tay phải

Nhưng bạn có biết Bây giờ chúng ta đang sử dụng với màn hình điều khiển Đó là mặt phẳng đứng. X vẫn là trái / phải nhưng thay vào đó Y là lên và xuống

Vậy hệ thống tọa độ tay phải sẽ gây ra điều gì? Nó làm cho + Z bị lạc hậu và -Z được chuyển tiếp Cái quái gì thế này? Lên là + và Xuống là - Phải là + và Trái là - NHƯNG Chuyển tiếp là - và Quay lại là + ??? Thật ngu ngốc nếu chúng ta tạo trò chơi cho nhân vật đó chạy trong thế giới 3D nhưng chúng ta cần phải trừ đi z để đi tiếp. Đó là lý do tại sao lập trình viên đánh giá cao DirectX

Để lấy một tiêu chuẩn xuất phát từ bàn làm việc và sử dụng nó trên màn hình là rất sai ở nhiều cấp độ ngay từ đầu. Và bây giờ chúng ta nên thừa nhận rằng họ, OpenGL và Công nghiệp, là sai. Họ chỉ sử dụng những gì họ nghĩ rằng nó sẽ khiến họ thoải mái nhưng họ đã sai và Hệ thống phối hợp tay phải chỉ là một di sản rác nên bị vứt đi càng nhanh càng tốt