Khái niệm và sự khác biệt giữa Framebuffer và Renderbuffer trong OpenGL là gì?


136

Tôi bối rối về khái niệm Framebuffer và Renderbuffer. Tôi biết rằng họ bắt buộc phải kết xuất, nhưng tôi muốn hiểu chúng trước khi sử dụng.

Tôi biết một số bộ đệm bitmap là cần thiết để lưu trữ kết quả bản vẽ tạm thời. Bộ đệm trở lại. Và bộ đệm khác là bắt buộc phải được nhìn thấy trên màn hình khi những bản vẽ đó đang được tiến hành. Bộ đệm phía trước. Và lật chúng, và vẽ lại. Tôi biết khái niệm này, nhưng thật khó để kết nối những đối tượng đó với khái niệm này.

Khái niệm và sự khác biệt của chúng là gì?


7
Renderbuffer là các thành phần giống như kênh (màu sắc, khuôn tô, độ sâu và etcs) của Framebuffer. Xem: developer.apple.com/iphone/library/documentation/3DDrawing/...
eonil

2
Liên kết là iPhone cụ thể, nhưng bộ đệm khung được giải thích tốt.
j00hi

Câu trả lời:


62

Trang này có một số chi tiết mà tôi nghĩ giải thích sự khác biệt khá độc đáo. Thứ nhất:

Đích kết xuất cuối cùng của đường ống OpenGL được gọi là [ bộ đệm khung ] .

Trong khi:

Đối tượng Renderbuffer
Ngoài ra, đối tượng renderbuffer mới được giới thiệu để kết xuất ngoài màn hình. Nó cho phép kết xuất một cảnh trực tiếp đến một đối tượng renderbuffer, thay vì kết xuất thành một đối tượng kết cấu. Renderbuffer chỉ đơn giản là một đối tượng lưu trữ dữ liệu chứa một hình ảnh duy nhất có định dạng bên trong có thể kết xuất. Nó được sử dụng để lưu trữ bộ đệm logic OpenGL không có định dạng kết cấu tương ứng, chẳng hạn như stpson hoặc bộ đệm độ sâu.


196

Các bộ đệm khung đối tượng không phải là thực sự là một bộ đệm, nhưng một đối tượng aggregator có chứa một hoặc nhiều file đính kèm, mà bởi sự thay đổi của họ, là những vùng đệm thực tế. Bạn có thể hiểu Framebuffer là cấu trúc C trong đó mỗi thành viên là một con trỏ tới bộ đệm. Không có bất kỳ tệp đính kèm nào, một đối tượng Framebuffer có dấu chân rất thấp.

Bây giờ mỗi bộ đệm được gắn vào Framebuffer có thể là một Renderbuffer hoặc một kết cấu .

Các Renderbuffer là một đệm thực tế (một mảng byte, hoặc số nguyên, hoặc pixel). Các Renderbuffer cửa hàng giá trị pixel ở định dạng gốc, vì vậy nó được tối ưu hóa cho offscreen rendering. Nói cách khác, vẽ vào Renderbuffer có thể nhanh hơn nhiều so với vẽ vào kết cấu. Hạn chế là các pixel sử dụng định dạng phụ thuộc vào việc triển khai, do đó việc đọc từ Renderbuffer khó hơn nhiều so với đọc từ kết cấu. Tuy nhiên, một khi Renderbuffer đã được vẽ, người ta có thể sao chép trực tiếp nội dung của nó lên màn hình (hoặc sang Renderbuffer khác , tôi đoán vậy), rất nhanh chóng bằng cách sử dụng các thao tác chuyển pixel. Điều này có nghĩa là Renderbuffer có thể được sử dụng để thực hiện hiệu quả mẫu đệm đôi mà bạn đã đề cập.

Renderbuffers là một khái niệm tương đối mới. Trước chúng, một Framebuffer đã được sử dụng để kết xuất thành một kết cấu , có thể chậm hơn vì một kết cấu sử dụng định dạng chuẩn. Vẫn có thể kết xuất thành một kết cấu và điều đó khá hữu ích khi người ta cần thực hiện nhiều lần vượt qua mỗi pixel để tạo cảnh hoặc vẽ cảnh trên bề mặt của cảnh khác!

Wiki OpenGL có trang này hiển thị nhiều chi tiết và liên kết hơn.


13
Cảm ơn! Giải thích nó như một loại cấu trúc và con trỏ có ý nghĩa hơn đối với tôi.
DouglasHeriot

2
Điều này vẫn còn một chút khó hiểu đối với tôi. Nếu renderbuffer chỉ cho phép sao chép nhanh vào bộ đệm kết xuất khác, thì gần như không sử dụng được nó! Nếu tôi phải thực hiện một giai đoạn xử lý hậu kỳ (như SSAO) thì việc kết xuất nó thành bộ đệm khung mặc định bằng cách sử dụng kết xuất trước đó cho Kết cấu trước đó hơn là kết xuất nó vào RenderBuffer và sau đó sao chép lại màn hình?
Nhà phát triển Coffe

4
Bộ đệm kết xuất không được thiết kế để xử lý hậu kỳ tùy chỉnh. Chúng có thể được sử dụng để lưu trữ thông tin độ sâu và stprint cho một quy trình vẽ. Điều này là có thể bởi vì chỉ bản thân việc thực hiện GPL cần đọc dữ liệu kết xuất và có xu hướng nhanh hơn kết cấu, bởi vì sử dụng định dạng gốc. Nếu bạn cần xử lý bài, sử dụng kết cấu.
fernacolo
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.