Sự khác biệt giữa kết xuất trong phần mềm hoạt hình OpenGL và 3D


16

Với OpenGL và như vậy tôi có thể hiển thị một số thứ trông khá tuyệt vời trong "FPS thời gian thực" 60 FPS. Tuy nhiên, nếu tôi cố gắng tạo một video có cùng cảnh đó trong giả sử Maya, hoặc 3ds Max, sẽ mất nhiều thời gian hơn để nó hiển thị mặc dù nó có cùng độ phân giải và FPS.

Tại sao hai loại kết xuất này mất các khoảng thời gian khác nhau cho cùng một kết quả?

Lưu ý: Có, tôi nhận ra rằng phần mềm hoạt hình 3D có thể tạo ra hình ảnh vượt trội so với những gì có thể được thực hiện trong thời gian thực. Nhưng đối với câu hỏi này tôi đang đề cập đến một cảnh phức tạp như nhau.


1
Câu trả lời ngắn gọn là OpenGL có các phím tắt.
dùng253751

Câu trả lời:


9

Sự khác biệt chính là với OpenGL, giả sử một trò chơi video, bạn sẽ có một quy trình gọi là rasterization , về cơ bản sẽ quan tâm đến việc xác định phần nào của cảnh bạn nhìn thấy.

Nó cần phải nhanh để chúng ta có thể trải nghiệm nó như thời gian thực.

Do đó, thuật toán thực hiện một vài bước đơn giản.

  • kiểm tra xem một phần nào đó của cảnh có trong tầm nhìn của tôi không

    Frustum Culling

  • kiểm tra xem cái gì đó ở phía trước nó có thể được hiển thị sau bằng cách sử dụng bộ đệm sâu

    Bộ đệm sâu

  • sắp xếp các đối tượng chúng ta tìm thấy để vẽ

  • vẽ chúng bằng cách chiếu chúng trên màn hình
  • che chúng dựa trên kết cấu / shader / đèn / ...

Mặt khác, một phần mềm kết xuất (Blender / Max / Maya / ...) rất có thể sử dụng một số loại raytracing

Điều này liên quan đến rất nhiều toán học để đạt được mức độ hiện thực cao hơn. Về cơ bản nó hoạt động theo cùng một cách:

  • tạo một máy ảnh và một mặt phẳng hình ảnh trước nó
  • bắn một tia (hoặc nhiều tia mẫu) qua từng pixel
  • kiểm tra xem tia có chạm vào bất cứ thứ gì trong cảnh không
  • lần truy cập gần nhất là điểm cuối cùng được vẽ trong pixel (như bộ đệm độ sâu)
  • tính ánh sáng cho điểm đã cho Tính toán ánh sáng

....

Tôi sẽ dừng danh sách ở đây vì đây là điểm mà raytracing cất cánh.

Thay vì chỉ kiểm tra nếu một điểm bị bắn trúng, hầu hết raytracer hiện bắt đầu tính toán:

  • lượng ánh sáng xuyên qua bề mặt
  • bao nhiêu ánh sáng được phản xạ
  • chiếu các tia mới từ điểm trúng vào cảnh cho đến khi nó có thể chiếu vào nguồn sáng

Có rất nhiều kỹ thuật với các mức độ hiện thực khác nhau có thể được sử dụng để tính toán ánh sáng của một điểm nhất định trong cảnh.

TL; DR Ý chính là một raytracer hầu như cố gắng chính xác về mặt vật lý khi chiếu sáng và do đó có nhiều phép tính hơn để thực hiện trên mỗi pixel (đôi khi bắn hàng ngàn tia) và mặt khác, các trò chơi có tốc độ của chúng vẽ các phần lớn hơn của màn hình với các phép tính ánh sáng đơn giản hơn và nhiều thủ thuật đổ bóng cho phép nó trông thật hơn.


7

Bạn đang so sánh táo với cam

Trò chơi giống như cổng xem trong ứng dụng mô hình của bạn. Bạn có thể sử dụng chế độ xem để kết xuất và bạn sẽ có cùng tốc độ 60fps.

Không có lý do tại sao bạn không thể có được đồ họa thời gian thực rất tốt từ các phần mềm mô hình hóa như Maya hoặc 3DS Max. Kết quả là ngang bằng với nhiều trò chơi. Họ có các shader viewport giống như các trò chơi. Ngoài ra còn có một tùy chọn kết xuất khung nhìn giúp chia khung hình thành đĩa nhanh nhất có thể (Tôi đã thực hiện kết xuất full HD ở tốc độ 30 khung hình / giây từ Maya). Tất cả bạn phải làm là ngừng sử dụng các phần mềm raytracers được cung cấp.

Có một số khác biệt mặc dù. Sự khác biệt chính là bạn với tư cách là người dùng không tối ưu hóa công cụ nhiều như các nhà phát triển trò chơi làm (tối ưu hóa là sử dụng tất cả các thủ thuật trong sách). Thứ hai, nguyên thủy hoạt hình của bạn hoạt động trên CPU vì bạn cần sự linh hoạt. Trong các trò chơi, người ta có thể đủ khả năng để thực hiện tối ưu hóa. Tất cả trong tất cả bạn phải trả cho việc không có một nhóm lập trình bên cạnh bạn.

Trên thực tế, nhiều thứ có thể đã được tính toán trước, vì vậy chúng không được tổ chức tốt hơn nhanh hơn nhiều. Nướng chiếu sáng gián tiếp của bạn sẽ đánh bại kết quả không nướng mỗi ngày.

Tại sao các raytracers chậm hơn?

Họ không *, người ta chỉ có xu hướng làm nhiều công việc hơn trên máy dò tia vì nó dễ. Tính năng theo tính năng họ không chậm hơn nhiều trong các chu kỳ tính toán. Ví dụ, không cần thiết bị đánh dấu tia để chiếu tia thứ cấp (phản xạ sự sống trong trường hợp đó, máy dò tia sẽ loại bỏ hình học hoặc thậm chí không tải nó, trong thực tế, tia thần kinh thực hiện điều đó). Nó thường được thực hiện bởi vì nó tầm thường để làm như vậy và đó là lợi thế rõ ràng của các bộ quét tia. Bạn thậm chí có thể cấu hình chúng để chạy trên CPU trong một số trường hợp. Chúng chỉ được tối ưu hóa cho những thứ khác nhau:

  1. Phát ra dữ liệu vào đĩa, không chỉ khung mà tất cả dữ liệu. Một cái gì đó sẽ phá vỡ hầu hết các trò chơi tốc độ ngay lập tức.

  2. Làm việc trên phần cứng nói chung. GPU nhanh hơn nhiều đối với một số thứ nhất định khi bạn tối ưu hóa cho GPU. Nhưng nó không hoạt động cho tất cả các tải, trên thực tế, CPU Intel có tốc độ tính toán nói chung nhanh hơn GPU. GPU chỉ là song song ồ ạt mà CPU không có. Kiến trúc chiến thắng nếu bạn có thể ở trong GPU và giảm thiểu chuyển và tối ưu hóa cho kiến ​​trúc GPU.

Vì vậy, bạn trả tiền cho sự linh hoạt và dễ sử dụng. Nhưng vâng, thừa nhận cả Maya và Max đều phải chịu đựng tuổi già. Vì vậy, họ có thể được nhanh hơn.

TL; DR Sự khác biệt chủ yếu là tối ưu hóa (đọc nhiều thủ thuật) và các tài nguyên bên ngoài có sẵn.

PS: Có một quan niệm sai lầm rằng điều này là do nó đúng hơn về mặt thể chất. Nó chắc chắn có thể được nhưng bộ dò tia không hẳn là chính xác hơn so với trò chơi trung bình của bạn hoặc bất kỳ tính toán nào khác. Trong thực tế, nhiều trò chơi sử dụng các mô hình thực sự tốt trong khi khá nhiều nhà tạo mô hình thì không.

* Xem http://www.graphics.cornell.edu/~bjw/mca.pdf


2
Xin lỗi, nhưng điều đó hoàn toàn sai. OpenGL và DirectX sử dụng các xấp xỉ vốn đã nhanh hơn so với quét tia chính xác. Toàn bộ điểm của đồ họa 3D được tăng tốc là có các thuật toán cân bằng giữa thực tế và tốc độ, trông đủ tốt cho hầu hết các ứng dụng thực tế: chơi game, CAD, v.v.
IMil

2
@IMil OpenGL có thể được sử dụng để raytracing. Nó nhanh hơn bởi vì nó được tối ưu hóa cho phần cứng trong câu hỏi. Nhưng Maya KHÔNG phải theo dõi tia. Maya và Max có thể sử dụng openGL và directX giống như trò chơi của bạn. Chế độ xem của Mayas (và 3ds) là opengl hoặc directX (sự lựa chọn của bạn). Thực tế là bộ xử lý của bạn chậm hơn trong một số tải xử lý song song là một điều khác. Vì vậy, câu trả lời đứng. Các thiết lập tiêu chuẩn của maya không thực tế hơn một đường quét tiêu chuẩn.
joojaa

5

Xem trước thời gian thực

Hoạt động trong lĩnh vực VFX của ngành, nếu bạn đang nói về việc xem trước chế độ xem thời gian thực và không hiển thị sản xuất, thì Maya và 3DS Max thường sử dụng OpenGL (hoặc có thể là DirectX - khá giống nhau).

Một trong những khác biệt về khái niệm chính giữa phần mềm và trò chơi hoạt hình VFX là mức độ giả định mà họ có thể đưa ra. Ví dụ, trong phần mềm VFX, không có gì lạ khi nghệ sĩ tải một lưới ký tự đơn, liền mạch kéo dài hàng trăm nghìn đến hàng triệu đa giác. Các trò chơi có xu hướng tối ưu hóa hầu hết cho một khung cảnh lớn bao gồm một khối thuyền gồm các mắt lưới đơn giản, được tối ưu hóa (mỗi nghìn hình tam giác).

Kết xuất sản xuất và theo dõi đường dẫn

Phần mềm VFX cũng đặt trọng tâm không phải vào bản xem trước thời gian thực mà là kết xuất sản xuất trong đó các tia sáng thực sự được mô phỏng cùng một lúc. Bản xem trước thời gian thực thường chỉ là "bản xem trước" của kết quả sản xuất chất lượng cao hơn.

Các trò chơi đang thực hiện một công việc tuyệt vời là xấp xỉ rất nhiều các hiệu ứng gần đây như độ sâu trường thời gian thực, bóng mềm, phản xạ khuếch tán, v.v., nhưng chúng thuộc loại xấp xỉ nhiệm vụ nặng nề (ví dụ: bản đồ khối mờ cho khuếch tán phản xạ thay vì thực sự mô phỏng các tia sáng).

Nội dung

Quay trở lại chủ đề này, các giả định nội dung giữa phần mềm VFX và trò chơi rất khác nhau. Trọng tâm chính của phần mềm VFX là cho phép tạo ra bất kỳ loại nội dung nào có thể được tạo ra (ít nhất đó là lý tưởng, mặc dù trên thực tế, nó thường không ở gần). Các trò chơi tập trung vào nội dung với các giả định nặng nề hơn nhiều (tất cả các mô hình nên nằm trong phạm vi hàng nghìn hình tam giác, bản đồ bình thường nên được áp dụng cho các chi tiết giả, chúng ta thực sự không nên có 13 tỷ hạt, các nhân vật không thực sự hoạt hình bằng cơ bắp giàn khoan và bản đồ căng thẳng, vv).

Do những giả định đó, các công cụ trò chơi thường có thể dễ dàng áp dụng các kỹ thuật tăng tốc hơn như loại bỏ bực bội cho phép chúng duy trì tốc độ khung hình tương tác cao. Họ có thể đưa ra các giả định rằng một số nội dung sẽ là tĩnh, được đưa xuống trước. Phần mềm VFX không thể dễ dàng đưa ra các loại giả định đó với mức độ linh hoạt cao hơn nhiều trong việc tạo nội dung.

Trò chơi làm điều đó tốt hơn

Đây có thể là một quan điểm gây tranh cãi, nhưng ngành công nghiệp trò chơi là một ngành sinh lợi hơn nhiều so với phần mềm VFX. Ngân sách của họ cho một trò chơi duy nhất có thể lên tới hàng trăm triệu đô la và họ có thể đủ khả năng để tiếp tục phát hành các động cơ thế hệ tiếp theo cứ sau vài năm. Những nỗ lực R & D của họ thật đáng kinh ngạc, và có hàng trăm trên hàng trăm tựa game được phát hành mọi lúc.

Mặt khác, phần mềm VFX và CAD không có khả năng sinh lợi. R & D thường được thuê ngoài bởi các nhà nghiên cứu làm việc trong môi trường học thuật, với rất nhiều ngành công nghiệp thường thực hiện các kỹ thuật được công bố nhiều năm trước như thể đó là một điều gì đó mới mẻ. Vì vậy, phần mềm VFX, thậm chí đến từ các công ty lớn như AutoDesk, thường không hoàn toàn "tiên tiến" như các công cụ trò chơi AAA mới nhất.

Họ cũng có xu hướng có một di sản dài hơn nhiều. Maya là một sản phẩm 17 tuổi, ví dụ. Nó đã được tân trang lại rất nhiều, nhưng kiến ​​trúc cốt lõi của nó vẫn như vậy. Điều này có thể tương tự như cố gắng dùng Quake 2 và tiếp tục cập nhật và cập nhật nó cho đến năm 2015. Những nỗ lực có thể rất tuyệt nhưng có lẽ sẽ không phù hợp với Unreal Engine 4.

TL; DR

Vì vậy, dù sao đi nữa, đó là một chút về phía đó của chủ đề. Tôi không thể biết liệu bạn đang nói về việc xem trước thời gian thực trong chế độ xem hoặc kết xuất sản xuất, vì vậy tôi đã cố gắng bao quát một chút cả hai.


Nó cũng là một câu hỏi về thời gian. Ngay cả khi bạn có thể kết xuất ở tốc độ 60 khung hình / giây và nhận được kết quả chấp nhận được, nó hiếm khi bỏ qua để tối ưu hóa cho nó. Giả sử phải mất 3 phút cho mỗi khung hình và bạn có 200 khung hình để kết xuất. Bạn có thể có được 60 khung hình / giây bằng cách thuê một nhà văn đổ bóng và bằng cách tối ưu hóa nhưng sau đó mất ít nhất một hoặc hai ngày. Nhưng 200 khung hình trong 3 phút chỉ mất 10 giờ để bạn tiết kiệm chi phí đó. Trong thực tế, nó rẻ hơn để mua thêm phần cứng và không phải lo lắng quá nhiều về nó. Trò chơi chỉ đơn giản là không thể thực hiện phương pháp này.
joojaa

@joojaa Nó cũng phức tạp hơn một chút. Chỉ cần thực hiện các shader thời gian thực thực sự tốt cho Maya có thể mất ít nhất một năm, thậm chí từ một nhà phát triển shader có kinh nghiệm (với mức tăng ít hơn), bởi vì tính linh hoạt của hệ thống nút được nhắm mục tiêu vào kết xuất sản xuất. Sẽ cần một tư duy kỹ thuật đảo ngược và loại kỹ thuật tạo mã GLSL / HLSL mới (như hệ thống lập trình meta) để dịch các nút đổ bóng đa năng này thành một hệ thống tạo bóng thời gian thực, nắm bắt phạm vi hiệu ứng của UE 4 , ví dụ:
Rồng năng lượng

Công cụ tạo bóng của UE 4 @joojaa được nhắm trực tiếp vào một tư duy PBR gần đúng (một tập hợp con rất nhỏ của trình tạo bóng PBR của Disney). Họ đã thiết kế ngay cả hệ thống vật liệu của mình cho mục đích nhanh chóng, thời gian thực, thay vì bắt đầu với một thứ giống như hệ thống vật liệu của Maya hoàn toàn không (được thiết kế để chiếu tia). Ngay cả khi UE 4 sáng nhất hoạt động trên VP 2.0, họ sẽ phải làm việc cả ngày lẫn đêm trong nhiều năm để có thể đạt được kết quả tương tự với một thiết kế không có ý định làm loại công cụ này.
Năng lượng rồng

nhưng đó là chi phí một lần ngay cả khi bạn có đường ống đó trong ứng dụng VFX, mỗi cảnh có thể cần tối ưu hóa thêm đó. Không có lý do tại sao một người dùng maya không thể kết xuất trong UDK, ví dụ cho cùng một nền tảng shader dev.
joojaa

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.