Có nhiều ngôn ngữ tạo bóng được xây dựng dựa trên GLSL hoặc HLSL - những vấn đề nào họ thường giải quyết và những tiến bộ đáng giá nào họ thực hiện?


8

Whew, đó là một tiêu đề dài.

Dù bằng cách nào, tôi đang hỏi câu hỏi này, vì tôi thích nghĩ về nhiều thứ khác nhau và tôi nhận ra rằng thực sự không có lớp mã nguồn mở đơn giản nào trên GLSL, ngay cả khi chỉ thêm những thứ đơn giản như bao gồm, hoặc các chức năng thường được sử dụng.

Theo nghiên cứu về các loại, tôi đang đặt câu hỏi này, vì nhận thức của tôi về các ngôn ngữ đó là rất ít để nói - tôi biết về ngôn ngữ tạo bóng của bgfx và ShaderLab của Unity, nhưng tôi thực sự không biết chúng đạt được gì - hoặc tại sao - là một người mới tương đối với đồ họa máy tính.

Ngoài ra, danh sách mong muốn của bạn cho một ngôn ngữ bóng mờ như thế này là gì? Của tôi cho đến nay bao gồm, một số khả năng tương thích giữa các phiên bản, đầu vào "ẩn" tùy chọn cho phép dễ dàng truy cập họa tiết ở độ phân giải pixel, hoặc kích thước hình ảnh, v.v. và có thể vượt qua - ví dụ, làm mờ gaussian hai lần.

Suy nghĩ?


4
Điều này nghe giống như một cuộc thảo luận diễn đàn hơn là một câu hỏi cụ thể. Trang web này hoạt động tốt nhất với các câu hỏi có thể được trả lời bằng một câu trả lời duy nhất, thực tế. Phần "danh sách mong muốn của bạn" chắc chắn không phù hợp với trang SE.
Dan Hulme

1
Bạn có thể đến hộp cornell phòng chat của chúng tôi và bắt đầu một cuộc thảo luận
ratchet freak

Câu trả lời:


2

Tôi nghĩ thật công bằng khi nói rằng lý do có rất nhiều biến thể thích hợp của GLSL / HLSL / Cg / whatnot là vì không có ngôn ngữ lập trình nào cũng sẽ không bao giờ là một kích thước phù hợp với tất cả các công cụ. Các vấn đề khác nhau đòi hỏi các công cụ khác nhau, vì vậy đôi khi nó đáng để nỗ lực phát triển một công cụ được xây dựng tùy chỉnh nếu nó sẽ được đền đáp trong thời gian dài.

Stock GLSL tự nó không thể sử dụng được. Nó thậm chí không có được sự ổn định trên các phiên bản, vì vậy, đối với một chương trình nhắm mục tiêu nhiều hơn một phiên bản OpenGL, một số loại tiền xử lý là bắt buộc. HLSL ổn định hơn một chút giữa các phiên bản, nhưng một lần nữa, nếu nhắm mục tiêu nhiều hơn một phiên bản D3D, một số công việc sẽ cần phải thực hiện để có được tính di động tốt.

Những điều mọi người thường làm gần giống như những gì bạn đã nói, như hỗ trợ thêm cho các tính năng lập trình cơ bản như mô-đun và cú pháp thống nhất giữa các phiên bản hoặc thậm chí tính di động trên các API khác nhau (GL / D3D) mà không phải viết lại mã shader. Những thứ tinh vi hơn bao gồm các hệ thống vật liệu hoàn chỉnh hoặc những thứ như tạo ra các chương trình đổ bóng đang hoạt động .

Các ngôn ngữ tạo bóng có thể sẽ trở nên tốt hơn và chung chung hơn trong tương lai, kết hợp những thứ mà ngày nay thường được sử dụng làm tính năng cốt lõi. Kiến trúc GCN mới là một dấu hiệu của điều đó. Vì vậy, các ngôn ngữ tô bóng sẽ trở nên dễ sử dụng hơn từ bây giờ, nhưng các giải pháp được xây dựng tùy chỉnh sẽ không bao giờ biến mất vì chỉ có rất nhiều bạn có thể khái quát hóa.


Tôi tò mò - những ngôn ngữ như thế này là gì ngoài kia? Tôi biết có những hệ thống dành riêng cho động cơ như hệ thống đổ bóng của Unity hoặc UE4, cộng với một số thứ nghiên cứu học thuật như Spark , nhưng tôi không biết bất cứ điều gì khác được sử dụng trong không gian này.
Nathan Reed

@NathanReed, có lẽ Kim loại của Apple là một trong những thứ đáng chú ý nhất, cho đến thời điểm hiện tại, nhưng tôi vẫn chưa xem xét chi tiết ...
glampert

Ồ được thôi. Kim loại không nằm trên HLSL hoặc GLSL mặc dù; đó là ngôn ngữ tạo bóng chính cho các GPU của Apple biên dịch trực tiếp thành vi mã CT (thông qua một phụ trợ LLVM độc quyền mà tôi tin).
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.