Card đồ họa làm gì với phần tử thứ tư của vectơ làm vị trí cuối cùng?


25

Từ câu hỏi này, có vẻ như bạn sẽ muốn một vectơ vị trí bốn phần tử, vì nó đơn giản hơn để sửa đổi vị trí của nó với phép nhân ma trận.

Về bản thân, điều này có nghĩa là yếu tố thứ tư đơn giản nên được bỏ qua khi coi nó là đại diện cho điểm 3D (giả sử không có biến đổi), nhưng tôi biết điều này không đúng, vì khi tôi cung cấp vector4 cho GPU, nếu là thứ tư phần tử không phải là một, nó không được hiển thị - tại sao?

Tầm quan trọng của yếu tố thứ tư là gì, một khi nó nằm trong trình rasterizer?

EDIT : Khi xem xét câu hỏi này có phần kém chữ; sẽ chính xác hơn khi đoạn thứ hai nói: "nếu giá trị của phần tử thứ tư không nằm trong một phạm vi nhất định, thì nó không được hiển thị 'chính xác' / 'như mong đợi'".


không một vectơ4 có tọa độ (x, y, z, 0,5) cho cùng kết quả của vectơ4 với tọa độ (2x, 2y, 2z, 1)?
FxIII

@FxIII, tôi không thể sao chép chính xác nhưng bạn nói đúng đó là một tuyên bố chăn không chính xác được thực hiện trong bài viết gốc của tôi, sau một vài thử nghiệm nữa tôi đã cập nhật nó.
sebf

Câu trả lời:


23

Thành phần thứ tư là một mẹo để theo dõi dự báo phối cảnh. Khi bạn thực hiện phép chiếu phối cảnh, bạn muốn chia cho z: x '= x / z, y' = y / z, nhưng đây không phải là một hoạt động có thể được thực hiện bởi ma trận 3x3 hoạt động trên một vectơ x, y, z. Thủ thuật đã trở thành tiêu chuẩn để thực hiện điều này là nối thêm tọa độ thứ tư, w và tuyên bố rằng x, y, z sẽ luôn được chia cho w sau khi tất cả các phép biến đổi được áp dụng và trước khi rasterization.

Phép chiếu phối cảnh sau đó được thực hiện bằng cách có một ma trận di chuyển z vào w, để cuối cùng bạn chia cho z. Nhưng nó cũng cho phép bạn linh hoạt để lại w = 1.0 nếu bạn không muốn thực hiện phân chia; ví dụ nếu bạn chỉ muốn chiếu song song, hoặc xoay hoặc bất cứ thứ gì.

Khả năng mã hóa các vị trí là w = 1, chỉ đường là w = 0 và sử dụng hàng / cột thứ tư của ma trận để dịch là một lợi ích phụ tốt, nhưng đó không phải là lý do chính để nối thêm w. Người ta có thể sử dụng các phép biến đổi affine (ma trận 3x3 cộng với vectơ dịch 3 thành phần) để thực hiện dịch mà không có bất kỳ w nào trong tầm nhìn. (Người ta sẽ phải theo dõi vị trí và hướng đi, và áp dụng các chức năng biến đổi khác nhau cho từng vị trí; điều đó hơi bất tiện, nhưng không thực sự là vấn đề lớn.)

(BTW, về mặt toán học, các vectơ được tăng cường với w được gọi là tọa độ đồng nhất và chúng sống ở một nơi gọi là không gian chiếu . Tuy nhiên, bạn không cần phải hiểu toán học cao hơn để làm đồ họa 3D.)


Một lần nữa hơi sai khi nói về các vectơ và điểm trong các thuật ngữ đó vì có sự đồng hình giữa các điểm và vectơ (điểm và vectơ di chuyển gốc đến điểm đó là cùng một thực thể). Sẽ đúng hơn khi nói về các điểm / vectơ (w! = 0) và hướng (chiếu) (w = 0). Dù sao, việc sử dụng sai thuật ngữ "vectơ" là một tiêu chuẩn khá hợp nhất trong ngôn ngữ thư viện 3d.
FxIII

@FxIII: Đã sửa. Thật khó hiểu khi sử dụng "vectơ" theo nghĩa toán học tiêu chuẩn và như một từ đồng nghĩa với "hướng" trong cùng một bài.
Nicol Bolas

@FxIII và Nicol Bolas: Tôi không đồng ý. Bạn thực sự mã hóa các vectơ là w = 0 - bao gồm cả hai vectơ chỉ đại diện cho một hướng và các vectơ thực tế trong đó độ dài là quan trọng. Chẳng hạn, bạn có thể biến đổi vectơ vận tốc góc (hướng = trục quay, chiều dài = tốc độ) của một đối tượng giữa không gian cục bộ và không gian thế giới bằng cách sử dụng ma trận của đối tượng. Bạn không muốn vận tốc góc được thêm vào bản dịch của đối tượng; bạn chỉ muốn nó được xoay. Vì vậy, bạn đặt w = 0. Tôi không thấy vấn đề?
Nathan Reed

@NathanReed Tôi hy vọng rằng bài đăng của tôi sẽ giúp làm rõ vấn đề, dù sao đi nữa, phần lớn quan điểm của tôi là dựa trên các định nghĩa và việc sử dụng sai thuật ngữ vectơ cộng với tính ưu việt của đại số tuyến tính so với thuật ngữ thư viện 3D tiêu chuẩn. Tất nhiên cả hai đều gây tranh cãi vì mọi yêu cầu về định nghĩa và tính ưu việt là
FxIII

@Nathan, bây giờ tôi có thể thấy rõ mục đích của phần tử thứ tư và cách thông tin chứa trong đó được sử dụng bởi trình rasterizer. Cảm ơn rất nhiều!
sebf

10

Cố gắng trả lời nhận xét thích hợp của Natan, tôi đã xem xét một số điều có thể hữu ích để hiểu điều gì thực sự xảy ra khi bạn sử dụng các vectơ trong Không gian affine để biểu diễn các vectơ 3D trong Không gian Euclide tiêu chuẩn.

Đầu tiên tôi sẽ gọi vectơ bất cứ thứ gì có tọa độ, vì vậy một điểm và vectơ là cùng một thực thể; bạn có thể thấy một vectơ là điểm khác biệt của hai điểm: V = B - A ; V di chuyển Một trong BA + V = A + B - A = B . Đặt A = 0 (gốc) và bạn sẽ nhận được V = B - 0 = B : điểm B và vectơ di chuyển 0đến B là điều tương tự.

Tôi sẽ gọi "vectơ" - theo nghĩa được sử dụng trong phần lớn các thư viện 3D - khi một vectơ của không gian affine có w = 0.

Ma trận được sử dụng vì chúng cho phép bạn biểu diễn một hàm tuyến tính ở dạng nhỏ gọn / thanh lịch / hiệu quả, nhưng các hàm tuyến tính có nhược điểm lớn là không thể chuyển đổi gốc: F ( 0 ) = 0 nếu F muốn là tuyến tính ( amog điều khác như F (λ X ) = F ( X ) và F ( A + B ) = F ( A ) + F ( B ))

Điều này có nghĩa là bạn không thể xây dựng một ma trận thực hiện dịch thuật vì bạn sẽ không bao giờ di chuyển vectơ 0 . Ở đây đi vào chơi không gian affine . Không gian affine thêm một chiều cho không gian euclide để có thể thực hiện traslantions với tỷ lệ và xoay.

Không gian Affine là một không gian chiếu theo nghĩa là bạn có thể xây dựng mối quan hệ tương đương giữa các vectơ Affine và Euclide để bạn có thể nhầm lẫn chúng (như chúng ta đã làm với các poin và vectơ). Tất cả các vectơ affine chiếu tới gốc tọa độ có cùng hướng có thể được xem là vectơ euclid giống nhau.

Điều này có nghĩa là tất cả các vectơ có cùng tỷ lệ trong tọa độ có thể được coi là tương đương:

Về mặt toán học:

tương đương

tức là mọi vectơ affine có thể được giảm xuống thành phiên bản canon trong đó w = 1 (chúng tôi chọn trong số mọi vectơ tương đương mà vectơ chúng tôi thích nhất).

Trực quan (2D euclidean - 3D affine):

tương đương thị giác

do đó, ý nghĩa của không gian "phóng chiếu" ; Bạn nên chú ý rằng ở đây không gian euclide là 2D (vùng màu lục lam)

Có một tập các vectơ affine cụ thể không thể đặt trong phiên bản chính tắc của chúng (một cách dễ dàng) một vectơ nằm trên mặt phẳng (hyper) w = 0.

Chúng tôi có thể hiển thị nó một cách trực quan:

nhập mô tả hình ảnh ở đây

những gì bạn (nên) nhìn thấy là trong khi w -> 0 thì vectơ chiếu vào không gian Euclide đi đến vô hạn nhưng đến vô hạn theo một hướng cụ thể .

Bây giờ rõ ràng rằng việc thêm hai vectơ trong không gian chiếu có thể dẫn đến các vấn đề khi bạn coi vectơ tổng là một vectơ được chiếu trong không gian euclide, điều này sẽ xuất hiện bởi vì bạn sẽ tổng hợp các thành phần W trong không gian affine và sau đó chiếu chúng vào mặt phẳng euclide (siêu).

Đây là lý do tại sao bạn chỉ có thể tính tổng "điểm" thành "vectơ" vì "vectơ" sẽ không thay đổi tọa độ w của "điểm", điều này chỉ đúng với "điểm" trong đó w = 1:

nhập mô tả hình ảnh ở đây

Như bạn thấy điểm màu xanh lá cây là điểm thu được khi thêm hai vectơ affine đại diện cho "điểm" màu lục lam và vectơ V " , nhưng nếu bạn áp dụng V cho mọi vectơ affine ở dạng khác nhau bởi canon, bạn sẽ thu được một kết quả sai ("điểm" "màu đỏ).

Bạn thấy rằng Không gian Affine không thể được sử dụng một cách minh bạch để mô tả hoạt động trên các Không gian Euclide và việc sử dụng sai thuật ngữ "vectơ" có ý nghĩa dưới sự ràng buộc (nghiêm ngặt) của các phép tính chỉ trên các vectơ chiếu chính .

Nói rằng, khá hợp lý khi nghĩ rằng GPU giả định rằng Vector4 phải có w = 0 hoặc w = 1, trừ khi bạn thực sự biết bạn đang làm gì.


Rất khó để chọn một câu trả lời cho câu hỏi này, vì tất cả đã góp phần vào sự hiểu biết về mối quan hệ của thành phần thứ tư được sử dụng và tại sao nó lại cần thiết. Giải thích của bạn về không gian euclide và affine là rất hữu ích, tôi chắc chắn sẽ không hiểu nó như bây giờ nếu không có mức độ chi tiết đó. Cảm ơn nhiều!
sebf

+1 cho một lời giải thích tốt (và sơ đồ!) Của không gian chiếu. Tuy nhiên, không gian affine và không gian chiếu không giống nhau (xem định nghĩa Wikipedia về không gian affine). Có lẽ một cách hay để nói điều này là: cả 3 không gian chiếu và 3 không gian affine đều có thể được nhúng trong R ^ 4, nhưng các phần nhúng không hoàn toàn là phụ âm. Mã hóa vectơ từ không gian affine là w = 0 là có thể và hữu ích, nhưng không có ý nghĩa theo quan điểm phóng chiếu. Tương tự như vậy, các hướng chiếu (điểm ở vô cực) không có ý nghĩa theo quan điểm affine.
Nathan Reed

1

Giả sử một vectơ như (x, y, z, w). Vectơ này có 4 thành phần x (x tọa độ trong không gian), y (tọa độ y trong không gian), z (tọa độ z trong không gian) và thành phần w thú vị và bí ẩn. Trên thực tế hầu hết các trò chơi 3d hoạt động trong không gian 4d. Nó còn được gọi là không gian đồng nhất 4d. Có một số lợi ích rõ ràng của nó ->

1> Nó giúp chúng ta kết hợp các ma trận dịch và xoay thành một. Nhưng bạn có thể nghĩ rằng việc sử dụng nó là gì, chúng ta có thể nhân ma trận dịch và xoay vòng và đó không phải là nhiều hơn nữa. Nếu chúng ta không có Thành phần w trong tất cả các vectơ của chúng ta sau đó khi chúng ta nhân vectơ 3d (xyz) với ma trận kết hợp dịch và xoay theo bất kỳ cách nào chúng ta sẽ vô tình nhân rộng các giá trị với x, y hoặc z (đó là cách nhân ma trận hoạt động) và điều này sẽ có thể làm hỏng ma trận vị trí (phần dịch của ma trận kết hợp) do chia tỷ lệ. Để khắc phục vấn đề này, vectơ thành phần thứ 4 được giới thiệu và thành phần này của vectơ (w) sẽ giữ giá trị 1.0 trong 99% trường hợp. Thành phần thứ 4 này cho phép chúng tôi để có các giá trị vị trí không được đánh giá (bản dịch). Ma trận được biểu diễn dưới dạng->

 [x y z w] [rx1 rx2 rx3 1]
           [ry1 ry2 ry3 1]
           [rz1 rz2 rz3 1]
           [px  py  pz  1]

và sau đó chúng ta có ma trận đơn giản nhưng mạnh mẽ. :)

2> Chúng tôi sao chép giá trị z vào thành phần w trong giai đoạn chiếu phối cảnh và chia x, y với nó. Cách này các đối tượng trở nên ngắn hơn khi chúng di chuyển khỏi màn hình.


Cảm ơn bạn! Tôi đang thấy ngày càng nhiều sự cần thiết của việc sử dụng thành phần thứ tư trong bất kỳ biểu diễn thực sự hữu ích nào của một thực thể trong không gian 3D.
sebf
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.