Khóa luận Xây dựng game Engine đa nền tảng quản lý khung cảnh

an ròng rã từ một đến ba năm. Chính việc game ngày càng trở nên phức tạp như vậy nên hiện nay, các game thương mại không còn phát triển từ nguyên thủy nữa mà được phát triển lên từ game engine. Game engine hỗ trợ việc xây dựng game một cách nhanh chóng, đơn giản hơn đồng thời cung cấp khả năng tái sử dụng code cao do có thể phát triển nhiều game từ một game engine. Ở Việt Nam, Game online mới chỉ thực sự thâm nhập vào thị trường cách đây 6 năm nhưng chỉ trong khoảng thời gian ít ỏi đó, chúng ta đã có một số lượng nhà phát hành game lên tới con số hàng chục, số game được phát hành cũng tương ứng với số lượng đó. Nhưng theo như chúng tôi được biết, gần như tất cả các game online đang được phát hành ở Việt Nam là được nhập khẩu từ nước ngoài, chủ yếu là Trung Quốc và Hàn Quốc ( trừ một số game nhỏ chơi trên web như đánh bài, đánh cờ ..) Một câu hỏi mà có lẽ tất cả những người chơi game đều trăn trở là “bao giờ mới được chơi game Việt Nam?”. Chúng tôi chọn đề tài này làm khóa luận tốt nghiệp không phải với một tham vọng quá lớn, chỉ là muốn đi những bước chân chập chững đầu tiên vào thế giới phát triển game rộng lớn, để thu lượm kiến thức về lĩnh vực khó khăn nhưng đầy thú vị này và hi vọng ở một tương lai không xa, chúng tôi có thể góp một phần sức lực giái đáp trăn trở của cộng đồng người chơi game Việt Nam. 1.2. Mục tiêu Xây dựng một Game Engine đa nền có thể chạy trên nhiều hệ điều hành khác nhau, hướng đến phân khúc phát triên game nhập vai trực tuyến (MMORPG). Game Engine này được đặt tên là GEM. Đây là mục tiêu dài hạn, còn hiện tại, do thời gian làm luận văn chỉ khoảng 5 tháng nên nhóm chúng tôi chỉ tập trung hoàn thiện thành phần Render Engine trong Game Engine ( Xem chi tiết ở chương 2). 1.3. Giới thiệu chung Như đã giới thiệu ở trên, Game Engine là một lớp trung gian giữa game và nền tảng bên dưới, các thư viện lập trình cấp thấp. GEM là một game engine nên dĩ nhiên nó cũng tuân thủ theo nguyên tắc này Hình 1: Kiến trúc phân tầng của GEM. Đặt điểm đầu tiên của GEM là khả năng chạy đa nền.Để đặt được điều đó, GEM sử dụng các bản build trên các nền tảng khác nhau ( chứ không phải sử dụng thông dịch ). Các đoạn code phụ thuộc nền tảng sẽ được phân chia bằng việc sử dụng các cờ tiền biên dịch, hạn chế tối đa việc sử dụng các lớp abstract – vì việc này sẽ làm giảm hiệu suất chương trình đáng kể [1]. Cũng vì lí đo chạy đa nền nên chúng tôi lựa chọn openGL làm giao diện lập trình đồ họa 3D cấp thấp cho GEM, do chuẩn openGL là chuẩn mở và không bị phụ thuộc vào hệ điều hành. GEM được thiết kế hướng đối tượng và yêu cầu về hiệu năng chạy cao nên chúng tôi sử dụng ngôn ngữ C++ - ngôn ngữ đáp ứng hoàn hảo các điều kiện trên. Đa số các Game Engine trên thế giới hiện nay đều được phát triển bằng ngôn ngữ C++. Chúng tôi thiết kế GEM nhắm đến phân khúc phát triển game nhập vai trực tuyến, nên khả năng tương thích với một phạm vi rộng cấu hình phần cứng là một điều kiện quan trọng, dự kiến sẽ support các card đồ họa hỗ trợ openGL 1.4 và shader 1.0 trở lên. Bảng cấu hình tối thiểu dự kiến : Hãng sãn xuất Dòng card hỗ trợ nVidia Từ GeForce4 Ti trở lên ATI Từ Radeon 9500 trở lên Intel ( card tích hợp ) Từ Intel® GMA 3100 ( chipset G31,Q33) trở lên Chương 2. Kiến trúc tổng thể GEM là được chia thành nhiều thành phần để tiện cho việc phát triển và bảo trì. Cụ thể GEM gồm các thành phần như sau : Hình 2: Kiến trúc tổng thể. Ghi chú : Do thời gian làm luận văn có hạn, chúng tôi mới chỉ hoàn thành những thành phần sau : Giao tiếp với hệ điều hành, Các kiểu dữ liệu cơ bản, Render Engine. Những thành phần này đủ để hỗ trợ người sử dụng tạo ra các khung cảnh 3D và tương tác với chúng. 2.1. Thành phần Các kiểu dữ liệu cơ bản Các kiểu dữ liệu cơ bản là thành phần bao gồm các cấu trúc dữ liệu cơ bản như mảng động, vector, ma trận…, các phép toán trên các kiểu dữ liệu đó cung cấp cho thành phần khác sử dụng Hình 3: Biểu đồ lớp của thành phần Các kiểu dữ liệu cơ bản. Các kiểu dữ liệu này có thể chia thành 2 nhóm chính : - Các yếu tố trong không gian 3D : + Vector2, Vector, Vector4 : các loại vector biểu diễn tọa độ 2 chiều, 3 chiều và tọa độ đồng nhất + Aabb ( Axis aligned bounding box ) : hình hộp chữ nhật có các cạnh dọc theo 3 trục xyz, được mô tả bằng 2 điểm (xmin, ymin, zmin ), ( xmax, ymax, zmax ) + Sphere : hình cầu, được mô tả bởi tọa độ tầm và bán kính. + LineSequent, Line, Ray : đoạn thẳng, đường thẳng, tia. + Matrix : ma trận sử dụng để biểu diễn các phép biến đổi : dịch, xoay, co giãn trong không gian 3 chiều. + Plane : mặt phẳng được mô tả bằng các hệ số của phương trình : ax + by + cz + d = 0. + Frustum : là hình chóp cụt biểu diễn khung nhìn của camera, được mô tả bằng 6 mặt phẳng tạo nên nó. - Các kiểu đối tượng lưu trữ : + String. + Array : mảng động với hệ số mở rộng có thể tùy biến. + GemAllocator : sử dụng bởi các lớp khác để thực thi việc cấp phát và giải phóng bộ nhớ. + List : linked list 2 chiều. + Stack. 2.2. Thành phần Giao tiếp với hệ điều hành Giao tiếp với hệ điều hành là thành phần thực thi các công việc cần giao tiếp với hệ điều hành như điều phối event, đọc ghi file, lấy thời gian hệ thống… Trong đó quan trọng nhất là quá trình điều phối event : Hình 4: Quá trình điều phối event. GEM lấy event từ Message System của hệ điều hành, từ đó lấy các thông tin cần thiết tạo ra GemEvent - lý do cần tạo ra GemEvent là để tránh bị phụ thuộc vào hệ điều hành. Sau đó, GemEvent sẽ được gửi lần lượt đến các thành phần có khả năng nhận và xử lý event. 2.3. Thành phần Render Engine 2.3.1. Khái quát về Render Engine Render Engine là thành phần cốt lõi của một Game Engine. Nó hỗ trợ người dùng các công việc thiết yếu để tạo ra một khung cảnh 3D. Người dùng sẽ không cần biết nhiều đến những công việc tầng thấp như quá trình đọc file tài nguyên, sử dụng 3D Graphic API, quá trình tạo các effect… mà chỉ cần dùng giao diện do Render Engine cung cấp. Render Engine là thành phần duy nhất trong Game Engine giao tiếp với các thư viện đồ họa cấp thấp ( cụ thể ở đây là openGL và Cg ) Hình 5: Kiến trúc phân tầng của Render Engine. 2.3.2. Kiến trúc của Render Engine Render engine được chia thành các module sau : Hình 6: Biểu đồ gói của Render Engine. - Graphic Driver là module duy nhất trực tiếp sử dụng 3D Graphic API (openGL), cung cấp cho các module khác một giao diện đơn giản hơn để tương tác với card đồ họa. - Quản lý tài nguyên là module quản lý các tài nguyên cần thiết để xây dựng một khung cảnh 3D như mesh, animated mesh, texture 2D, cubemap…Module này được bạn Hoàng Tuấn Hưng trình bày trong khóa luận  “Xây dựng Game Engine đa nền tảng – Quản lý tài nguyền và chuyển động đối tượng ”. - Quản lý khung cảnh là module thực hiện việc tổ chức và kiểm soát các đối tượng tồn tại trong một khung cảnh 3D, từ đó thực hiện quá trình render toàn bộ khung cảnh đó tạo nên hình ảnh 2D tại vị trí nhìn. Module này được trình bày chi tiết trong các chương sau của tài liệu này. -Hiệu ứng ánh sáng và vật liệu là module mở rộng các thành phần của Quản lý khung cảnh để tạo các hiệu ứng về ánh sáng, vật liệu, và đổ bóng. Module này được bạn Bùi Hoàng Khánh trình bày trong khóa luận “Xây dựng Game Engine đa nền tảng – Hiệu ứng ánh sáng và vật liệu”. -Mô phỏng tự nhiên là module mở rộng các thành phần của Quản lý khung cảnh để mô phỏng các yếu tố tự nhiên cần có trong game như nước, địa hình, lửa, khói… Module này được bạn Trần Thái Dương trình bày trong khóa luận “Xây dựng Game Engine đa nền tảng –Mô phỏng tự nhiên”. - Chuyển động của đối tượng là module mở rộng các thành phần của Quản lý hung cảnh, thực hiện quá trình nội suy trong các mô hình chuyển động ( thường là các nhân vật trong game ) thông qua hai kĩ thuật thông dụng là keyframe và skinning. Module này được bạn Hoàng Tuấn Hưng trình bày trong khóa luận  “Xây dựng Game Engine đa nền tảng – Quản lý tài nguyền và chuyển động đối tượng”. 2.4. Các thành phần còn lại. Các thành phần Mạng, Trí tuệ nhân tạo, Tính toán vật lí, Âm thanh chưa được triển khai nên chúng tôi không đề cập đến trong tài liệu này. Chương 3. Quản lý khung cảnh 3.1. Khái niệm khung cảnh và cách tổ chức khung cảnh Khung cảnh có thể hiểu giống như một trường quay phim. Nó bao gồm tất cả các đối tượng tham gia vào quá trình tạo nên hình ảnh, ví dụ như các camera, các nhân vật, các vật thể, các nguồn chiếu sáng… Dĩ nhiên trong một chương trình máy tính, khung cảnh được dữ liệu hóa và chúng tôi định nghĩa nó là tổng hợp tất cả dữ liệu mô tả các đối tượng trong một không gian 3D. Khung cảnh là rất nhiều dữ liệu, vì vậy một yêu cầu bắt buộc phải tổ chức nó một cách hợp l‎ý để tiện sử dụng trong quá trình render. Ở đây, chúng tôi tổ chức nó thành một cây quan hệ về không gian và đồng thời là Bounding Volume Hierachies (BVHs). 3.1.1. Cây quan hệ về không gian Cây quan hệ về không gian là một cây mà trong đó, node con nằm trong không gian của node cha. Nghĩa là khi không gian của node cha thay đổi sẽ làm node con thay đổi theo. Việc tổ chức khung cảnh thành cây quan hệ về không gian sẽ giúp mô tả mối quan hệ giữa các đối tượng một cách dễ dàng. Ví dụ như trong khung cảnh có một chiếc ôtô và 2 nhân vật ngồi trong đó, khi đó 2 nhân vật sẽ là 2 node con của node cha ôtô, khi ôtô di chuyển, do bị ràng buộc về không gian nên 2 nhân vật cũng sẽ di chuyển theo. 3.1.2. Bounding Volume Hierachies. a. Khái niệm Bounding Volume: Để đơn giản hóa một số giai đoạn tính toán trong quá trình render SceneGraph, chúng ta sử dụng một số hình đơn giản hơn bao bọc quanh các đối tượng.Các hình đó được gọi là bounding volume. Ở đây chúng tôi sử dụng 2 loại bounding volume là : + Axis Aligned Bounding Box. + Bounding Sphere. Hình 7: Axis Aligned Bounding Box và Bounding Sphere trong GEM. b. Khái niệm Bounding Volume Hierachies (BVHs): BVHs có thể hiểu là một cây bounding volume, trong đó bounding volume của node cha sẽ chứa tất cả bounding volume của node con. Việc sử dụng BVHs giúp giảm độ phức tạp của quá trình cắt theo khung hình (View Frustum Culling) Hình 8: Ví dụ cây khung cảnh và BHVs tương ứng. Trong hình trên, sơ đồ bên phải là cây khung cảnh, bên trái là ví trí các node trong không gian và bounding volume của nó. Ta có thể thấy bounding volume của node A là tổng bounding volume của 2 node con, bounding volume của root là tổng bounding volume của tất cả các node con. 3.2. Thiết kế cấu trúc Hình 9: Biều đồ lớp của module Quản lý khung cảnh. SceneGraphManager : lớp đóng vai trò là gốc của cây khung cảnh, chứa các phương thức thực thi quá trình render cây khung cảnh. SceneNode : là lớp cơ sở để tạo thành cây khung cảnh. SceneNode bao gồm các dữ liệu mà mọi đối tượng trong không gian 3D đều cần phải có. Các loại node khác sẽ thừa kế từ lớp này. CameraSceneNode, SolidMeshSceneNode, SkyBoxSceneNode ... : là các loại node được triển khai từ lớp cơ sở SceneNode, một loại node ứng với một loại đối tượng cụ thể. RenderList : là tập hợp các node có chung một tập các trạng thái render. Các node trong cây khung cảnh sẽ được đưa về các render list rồi sau đó mới thực hiện việc render các render list. Việc làm này sẽ hạn chế tối đa việc chuyển các trạng thái render, năng hiệu suất của hệ thống. RenderContext : Là tập hợp các trạng thái render. Animation : Là lớp cơ sở cho mọi loại animation. Một SceneNode sẽ có một list các animation và thực hiện tất cả các animation đó ở đầu mỗi khung hình. ValueAnimation, DestroyAnimation .. : Là các loại animation cụ thể được triển khai từ lớp cơ sở Animation. 3.2.1. Lớp SceneNode Hình 10: Lớp SceneNode. Các thuộc tính chính : - position, scale, rotation,angle : các phép biến đổi dịch, co dãn,xoay và góc xoay của không gian node này so với không gian của node cha. - modelMatrix : ma trận biến đổi không gian của node này sang không gian thế giới ( lưu ma trận này để tăng tốc quá trình render – nếu không, bất kì khung hình nào cũng phải tính lại nó mặc dù không gian của node có thể không biến đổi ) - chidren : danh sách các node con của node. - parent : node cha của node này - boundingBox : aabb của node này trong không gian địa phương của nó. - boundingBoxInWorld : aabb của node này trong không gian trong không gian thế giới. - treeBoundingBox : tổng hợp boundingBoxInWord của node này và treeBoundingBox của các node. - boundingSphere, boundingSphereInWorld, treeBoundingSphere : như trên nhưng thay aabb bằng bounding sphere. - animationList : danh sách các animation tác động lên node này Các phương thức chính : - updateModelMatrix() : phương thức này sẽ kiểm tra các trạng thái của node ( không gian của nó có biển đổi không, không gian của node cha có biến đổi không.. ) và tính lại ma trận modelMatrix nếu cần thiết. -viewFrustumCulling(Frustum& frustum) : phương thức đệ quy thực thi quá trình view frustum culling. - prepareRender() : phương thức đệ quy thực thi quá trình prepareRender. - render : phương thức được gọi khi render node này, các loại node sẽ triển khai phương thức này cách render loại node đó. - animate : thực thi tất cả các animation này trong animationList của node này. 3.2.2. Một số loại node khác a. SolidMeshSceneNode : SolidMeshSceneNode loại node dành cho các đối tượng có mô hình cố định (thường là các đồ vật ). Mỗi SolidMeshSceneNode sẽ sử dụng mesh trong mesh bank và texture trong texture bank, khi node này được render, hệ thống sẽ render mesh đó với ma trận biến đổi thích hợp ( có hỗ trợ tính năng Level of Detail – LOD – xem chi tiết về LOD trong phần 3.1.Các thuật ngữ ) Biểu đồ lớp : Hình 11: Lớp SolidMeshSceneNode. Các thuộc tính chính : - activeMeshID : mesh hiện tại đang sử dụng - meshLOD : tập hợp tất cả các mesh mà node này sử dụng để hỗ trợ tính năng static LOD - colorSamplerID : texture sử dụng để làm kênh color Minh họa : Hình 12: Hình ảnh Bàn cờ và các quân cờ dùng SolidMeshNode. b. CameraSceneNode CameraSceneNode là loại node chứa các thông tin camera: vị trí, hướng quay và góc quay.v.v., đồng thời nó cũng là 1 event receiver để xử lí các event của người dùng ( ví dụ như di chuột thì camera xoay .v.v. ) Biểu đồ lớp : Hình 13: Lớp CameraSceneNode. Các thuộc tính chính : - m_Up : Vector up của camera. - m_Center : Vector center của camera ( điểm nhìn ) - m_Far, m_Left, m_Right, m_Top, m_Bottom, m_Fovy, m_Aspect : các thuộc tính xác định khung nhìn của camera. Các phương thức chính : - look() : tính các ma trận biến đổi cần thiết với vị trì đặt camera là position, vị trí nhìn là m_Center, vector up là m_Up. - calculationFrustum() : tính khung nhìn hiện tại của camera ( Xem chi tiết trong phần 2.3.2.2.Render SceneGraph ) - onEvent(Event& event) : xử lí event nhận được đo quá trình dispatch event gửi đến. c.SkyboxSceneNode SkyboxSceneNode là loại node dùng để tạo cảnh vật ở xa vô cực, thường là bầu trời, cảnh núi mây ở rất xa vị trí nhìn. Để làm điều này, SkyboxSceneNode sử dụng hình lập phương rồi dán texture chứa hình ảnh ở rất xa vào, camera sẽ luôn nằm ở vị trí trung tâm của khối lập phương. Biểu đồ lớp : Hình 14: Lớp SkyboxSceneNode. Các thuộc tính chính : - xzTexture, yPositiveTexture,yNegativeTexture : Các texture chứa hình ảnh ở rất xa. Minh họa : Hình 15: Skybox. 3.2.3. Lớp SceneGraphManager Hình 16: Lớp SceneGraphManager. Các thuộc tính chính : - activeCamera : camera được sử dụng để nhìn toàn bộ khung cảnh. - renderList : 16 render-list. - renderOrder : mảng xác định thứ tự render các render-list. Các phương thức chính : - registerRenderList(..) : đăng kí một node vào một render-list. - unregisterRenderList(..) : loại bỏ một node ra khỏi một render-list. - drawSceneGraph() : render toàn bộ khung cảnh. - setRenderOrder(..) : xác định thứ tự render của các render-list. 3.2.4. Lớp RenderList và RenderContext Hình 17: Lớp RenderList và RenderContext. Một RenderList bao gồm một danh sách các node node_list và một RenderContext rc. Các node nằm trong node_list sẽ được render với các trạng thái đặt trong rc. RenderContext : Các thuộc tính : - RenderContext bao gồm rất nhiều trạng thái render trong đó có hể chia làm 2 nhóm : nhóm các trạng thái của openGL và các trạng thái của GEM. Các phương thức : - pushState() : đặt tất cả các trạng thái render. - popState() : phục hồi lại tất cả các trạng thái render như trước khi gọi pushState() 3.3. Thiết kế chức năng Chức năng chính của module này là render toàn bộ cây khung cảnh. Quá trình render trải qua những bước sau : - Bước 1 – prepare-render : duyệt cây theo chiều sâu, tại mỗi node, thực hiện tất cả các animation, kiểm tra trạng thái của node để xác định xem có cần tính lại các ma trận biến đổi không. - Bước 2 – Tính lại BVHs : Duyệt cây theo thứ tự sau (postfix) ,kiểm tra cờ trạng thái, tính lại tree bounding volume của node nếu cần thiết. - Bước 3 – Tính lại các ma trận biến đổi của Camera và tính khung nhìn. - Bước 4 – view frustum culling : phát hiện các node nằm bên ngoài khung nhìn và loại chúng ra khỏi quá trình render. - Bước 5 - Render từng render-list : tùy vào các trạng thái render nằm trong render context, các node trong render-list có thể sẽ được sắp xếp theo khoảng cách đến camera, thực hiện occlusion culling mới được render. 3.3.1. Prepare-render Hình 18: Biều đồ hoạt động của giai đoạn prepare-render. Quá trình prepare-render trải qua các bước như sau : - Bước 1 : Đi đến node tiếp theo theo chiều sâu. - Bước 2 : Gọi hàm animated() của node. Hàm này sẽ thực thi tất cả các animation có trong animationList của node này. - Bước 3 : Kiểm tra các cờ trạng thái liên quan đến ma trận biến đổi và tính lại các ma trận nếu cần thiết. Trong đó : + UPDATE_SCALE_MATRIX : khi cờ này được bật, nghĩa là node này bị thay đổi về độ phóng to ( hoặc thu nhỏ ) so với khung hình trước, do đó sẽ phải tính lại ma trận phóng của node. + UPDATE_ROTATION_MATRIX : khi cờ này được bật, nghĩa là node này bị thay đổi về góc quay ( hoặc độ quay ) so với khung hình trước, do đó phải tính lại ma trận quay của node. + UPDATE_TRANSLATE_MATRIX : khi cờ này được bật, nghĩa là node này bị dịch chuyển vị trí so với khung hình trước, do đó phải tính lại ma trận dịch của node. + PARENT_MATRIX_CHANGE : khi cờ này được bật nghĩa là ma trận biến đổi của node cha bị thay đổi, hay chính là không gian của node cha bị thay đổi. Nếu một trong các cờ trên được bật, thì node sẽ phải tính lại modelMatrix theo công thức như trong hình vẽ. modelMatrix là ma trận biến đổi không gian của node sang không gian thế giới, được sử dụng trong quá trình render vật thể. - Bước 4 : Nếu node này phải tính lại modelMatrix ( nghĩa là không gian của nó bị thay đổi so với khung hình trước ) ta phải bật một số cờ ở các node con và node tổ tiên ( node cha, node ông.. ) của node này. Cụ thể : + Bật cờ PARENT_MATRIX_CHANGE ở các node con ( thông báo không gian của node cha bị thay đổi ) + Bật cờ UPDATE_TREE_BOUNDING_VOLUME ở các node tổ tiên, thông báo các node đó sẽ phải tính lại tree bounding volume trong quá trình Tính lại BVHs ( xem chi tiết trong phần b của chương này ). 3.3.2. Tính lại BVHs Hình 19: Biều đồ hoạt động của giai đoạn Tính lại BVHs. Quá trình tính lại BVHs như sau : duyệt cây Scene Graph theo thứ tự sau ( do phải có tree bounding volume của node con mới tính được tree bounding volume của node cha ) : - Tại mỗi node, kiểm tra cờ UPDATE_TREE_BOUNDING_VOLUME. Cờ này được bật khi một trong những node con bị biến đổi về không gian hoặc khi thêm bớt node con ( so với khung hình trước ). - Nếu cờ được bật, tính lại tree bounding volume của node theo công thức : tree BV = tổng ( tree BV của tất cả các node con ) + BV của node này. 3.3.3. Tính lại các ma trận biến đổi của Camera và tính khung nhìn a.Các ma trận biến đổi của camera Camera là đối tượng mô phỏng mắt người trong Scene Graph. Tức là chúng ta sẽ thu hình ảnh ở vị trí đặt camera. Camera sẽ lưu trữ và tính toán 2 ma trận biến đổi  view matrix và project matrix : + View matrix : là ma trận biến đổi không gian thế giới sang không gian nhìn. + Project matrix : là ma trận biến đổi từ không gian nhìn sang không gian chiếu. b.Quá trình tính lại view matrix và project matrix Trước tiên, ta kiểm tra các cờ trạng thái của active camera để xác định xem có cần tính lại các ma trận biến đổi hay không : + Nếu cờ UPDATE_VIEW_MATRIX hoặc PARENT_MATRIX_CHANGE được bật : tính lại view matrix từ vị trí đặt, vector up và hướng nhìn của camera. + Nếu cờ UPDATE_PROJECTION_MATRIX được bật : tính lại projection matrix từ các thuộc tính m_Near,m_Far, m_Bottom, m_Top, m_Right, m_Left của camera ( Xem lại lớp Camera trong 4.2.1.d.Các loại node cơ bản ). c.Tính khung nhìn Khái niệm khung nhìn : là không gian mà chỉ những đối tượng nằm trong ( hoặc một phần nằm trong ) mới được nhìn thấy bởi camera. Ở đây camera hoạt động theo phép chiếu phối cảnh nên khung nhìn là một hình chop cụt do 6 mặt phẳng ghép lại : near, far, top, bottom, right, left. Hình 20: Ví dụ minh họa khung hình. Chúng tôi sử dụng phương pháp tính 6 mặt phẳng tạo nên khung nhìn từ view matrix và projection matrix theo [2]. 3.3.4. View frustum culling a. Khái niệm view frustum culling Ta đã biết chỉ các vật thể nằm trong ( hoặc một phần nằm trong ) khung nhìn mới được nhìn thấy. Như vậy, nếu xác định được node nào nằm bên ngoài view frustum, ta có thể loại nó ra khỏi quá trình render. Để đơn giản hóa việc kiểm tra xem một node có nằm ngoài khung nhìn hay không, ta sử dụng Bounding Volume của nó để kiểm tra ( do Bounding Volume có hình dạng rất đơn giản hơn nhiều so với bản thân vật thể). View frustum culling là việc phát hiện các node nằm bên ngoài frustum đựa vào BVHs là loại chúng ra khỏi quá trình render. b. Quá trình thực hiện view frustum culling Hình 21: Biều đồ hoạt động giai đoạn view frustum culling. Thực hiện view frustum culling như sau : Duyệt cây khung cảnh theo chiều sâu - Tại mỗi node, kiểm tra vị trí của tree bounding sphere so với khung nhìn ( tree bounding sphere là một trong hai loại tree BV của mỗi SceneNode ) : + Nếu nằm trong : toàn bộ nhánh cây với gốc là node này nằm trong khung nhìn, không cần duyệt các node thuộc nhánh này nữa. + Nếu nằm ngoài : toàn bộ nhánh cây với gốc là node này nằm ngoài khung nhìn, toàn bộ node trong nhánh nằm bị bật cờ trạng thái FRUSTUM_CULLED ( đánh dấu đã bị cắt ) và không cần duyệt đến các node thuộc nhánh này nữa. + Nếu giao : kiểm tra vị trí của tree bounding box so với khung nhìn ( vì bounding box bó sát vật thể hơn nhiều so với bounding sphere ). # Nằm trong : toàn bộ nhánh cây với gốc là node này nằm trong khung nhìn, không cần duyệt các node thuộc nhánh này nữa. # Nằm ngoài : toàn bộ nhánh cây với gốc là node này nằm ngoài khung nhìn, toàn bộ node trong nhánh nằm bị bật cờ trạng thái FRUSTUM_CULLED ( đánh dấu đã bị cắt ) và không cần duyệt đến các node thuộc nhánh này nữa. # Giao : không kết luận gì, đi đến node tiếp theo. c. Thuật toán kiểm tra vị trí của bounding sphere so với khung nhìn Để kiểm tra ví trị của một bounding sphere so với frustum, ta thực hiện như sau : Với từng mặt phẳng của Frustum : + Tính khoảng cách d từ tâm đến mặt phẳng + Nếu d < -R. Kết luận: bounding sphere nằm bên ngoài frustum + Nếu R > d > -R. Kết luận: bounding sphere giao với frustum Ngược lại, kết luận bounding sphere nằm bên ngoài Frustum ( R là bán kính của bounding sphere ) Hình 22: Ví dụ một Bounding Sphere có d > R. d. Thuật toán kiểm tra vị trí của bounding box với khung nhìn Thuật toán cơ bản để kiểm tra ví trí của bounding box với frustum là kiểm tra vị trí của 8 đỉnh của bounding box so với khung nhìn : - Nếu tất cả các đỉnh đều nằm trong thì kết luận bounding box nằm trong. - Nếu tất cả các đỉnh nằm ngoài thì kết luận bounding box nằm ngoài. - Các trường hợp còn lại kết luận bounding box giao với khung nhìn. Có nhiều tối ưu cho thuật toán trên và chúng tôi đã triển khai các tối ưu trong [3] 3.3.5. Render các render-list a. Khái niệm render-list Một render-list là tập hợp các Scene Node có chung các trạng thái render. Các trạng thái render ở đây là các trạng thái của openGL và một số trạng thái khác của GEM. Việc tập trung các Scene Node thành các render list sẽ hạn chế tối đa việc chuyển các trạng thái render, giúp tăng hiệu suất hệ thống. Một Scene Node có thể cùng lúc ở nhiều render-list. b. Các render list của GEM Trong GEM có 16 render list sau : - ERL_SKY_BOX : Render list đặc biệt dành cho SkyboxSceneNode, do loại node này phải đặt một số trạng thái render đặc biệt. - ERL_LIGHT : Render list đặc biệt dành cho các nguồn chiếu sáng (LightSceneNode và DLightSceneNode ). - ERL_SOLID : Render list mặc định dành cho các loại node có dạng đặc ( không nhìn xuyên qua được ). - ERL_TRANLUCENT : Render list mặc định dành cho các loại node có dạng trong suốt ( hình xuyên qua được ). - ERL_USER_DEFINE0 -> 9 : 10 Render list dành sẵn cho người sử dụng tùy biến. - ERL_SHADOW_VOLUME : Render list đặc biệt dành để render bóng của vật thể. - ERL_OCCLUSION_TEST : Render list dùng trong quá trình occlusion culling. c. Biểu đồ hoạt động Hình 23: Biều đồ hoạt động