Trang chủ | Email | W2G.,JSC | Liên hệ-Góp ý | SearchWiki:

W2G.,JSC

Quảng cáo

Project

Simulationvn

Tài liệu lập trình

3D Graphics - Đồ họa 3D

Xử lý ảnh

Sách điện tử

sửa SideBar

Scene Graph: Qúa khứ, hiện tại và tương lai

Lời nói đầu

Để giúp cho hiểu biết về Scene Graph, giúp ta có một cái nhìn nhanh về lịch sử phát triển của các ngôn ngữ đồ họa như Open GLDirect X. Trước đây, đồ họa thời gian thực tồn tại trên thiết bị phần cứng sinh hình ảnh đặc biệt (gọi là IG) mà chứa đựng toàn bộ CSDL trực quan theo một định dạng độc quyền. Các nhà dựng mô hình tạo ra những CSDL của họ và tải chúng lên trên phần cứng IG. Những người lập trình thông thường bị giới hạn việc sửa đổi các thành phần của những CSDL này, như việc xác định vị trí hay việc quay một máy bay trực thăng hoặc thiết bị xác định thời gian khi mô phỏng. Hãng SGI đã giới thiệu nhiều tùy chọn mở và chương trình cho phần cứng sinh hình ảnh, cùng với nó, những ngôn ngữ đồ họa mà cho phép tính có thể lập trình trực tiếp. Thư viện Open GL (Từ nguyên bản của SGI là "GL") gồm có các dòng lệnh vẽ sơ khai đầu tiên (vẽ đa giác, đường, điểm, .v.v.) các thiết đặt trạng thái (đặt màu, texture, .v.v.) và ma trận các thao tác (Push/Pop cho khung cảnh mô hình hoặc ma trận phối cảnh, .v.v.). Nhưng nó chứa đựng rất ít thông tin cho phép hệ thống tự động tối ưu hóa và cải thiện hiệu năng thực hiện việc sinh cảnh. Thư viện này được dùng để vẽ tất cả các loại cảnh trong không gian 3 chiều. Như vậy những đa giác nằm ngoài khung cảnh tiêu tốn tài nguyên - phần cứng thậm chí không biết chúng ra khỏi khung cảnh cho đến khi hệ thống bị đổ vỡ, hoặc nó cũng không quan tâm đến việc cần thiết thay đổi trạng thái, thêm texture, và những thủ tục đồ họa dùng chung khác. Mà điều này tốt nhất nên tránh nếu chúng không tương thích với hình ảnh cuối cùng trong khi mô phỏng.

Chọn lọc (Culling)

Chọn lọc là quá trình loại bỏ mọi thứ từ một khung cảnh mà không đóng góp đến hình vẽ cuối cùng, bao gồm các thứ mà đằng sau nguời quan sát, màn ảnh riêng, hoặc trong những hệ thống tiên tiến hơn, ẩn đằng sau những đối tượng khác (đã bị che khuất). Khái quát hóa chọn lọc bằng việc loại bỏ những công việc không cần thiết bằng cách so sánh các ranh giới không gian của đối tượng với khung nhìn hình chóp cụt biểu diễn không gian 3 chiều xác định. Open GL thực hiện việc này một cách cứng nhắc khi gửi cho nó các hình đa giác để thực thi lệnh vẽ - theo mặc định, nó thay đổi và kẹp tất cả các hình đa giác tới các mép của không gian khung cảnh. Hơn thế nữa, khi làm việc với Open GL rất nặng nhọc khi các đa giác có nhiều mức chi tiết khác nhau, các kiến trúc scenegraph nhận thức rằng khi thực hiện chọn lọc ở mức cao hơn sự trừu tượng hóa cho hiệu quả lớn hơn. Nếu có thể loại bỏ những đối tượng không nhìn thấy trước, thì phần cứng làm việc ít hơn và nói chung cải thiện hiệu năng và quan trọng là giảm thiểu thời gian ở mỗi khung hình. Cách làm việc tương đối đơn giản này được thưc hiên như sau. Bất kỳ đối tượng nào nằm trọn vẹn bên trong khung cảnh frustum đều được gửi về tới phần cứng. Còn những đối tượng có cả phần bên trong / phần ở ngoài, thông thường không kiểm tra ảnh hưởng tới các hình đa giác riêng lẻ trên CPU, nhưng có thể chia một đối tượng rất phức tạp thành vài đối tượng đơn giản hơn và như vậy một số chúng có thể được chọn lọc bên trong hoặc ở ngoài riêng một cách riêng lẻ. Tất nhiên, bất kỳ đối tượng nào nằm trọn vẹn bên ngoài, không gian chọn lọc được loại bỏ từ rất sớm.

Phân cấp dữ liệu

Hiệu quả thực hiện tính toán này, sẽ có lợi khi tổ chức các đối tượng trong một sự phân cấp hoặc dạng cây, truyền lan bất kỳ thông tin dùng chung nào về phía gốc của cây. Có nhiều loại cây có thể sử dụng. Nhưng hãy xây dựng cho nó có một sự phân cấp bậc N đồ họa phi tuần hoàn trực tiếp hoặc DAG. Giống như scenegraph cơ bản sẽ có một nút gốc, với một hoặc hơn nhiều nút con. Mỗi nút con có thể lần lượt chứa đựng nút rỗng hoặc nhiều nút con, một vài nút sẽ là những đối tượng đồ họa muốn vẽ. Những nút khác là dùng cho những mục đích cấu trúc và có thể trở nên phức tạp trong dữ liệu. Ví dụ, nếu một tòa nhà đã có các phòng, một nút nhóm của scenegraph (gọi nó là "Tòa nhà") có thể chứa đựng vài nút (gọi là "phòng - 0" "phòng - 1" .v.v.). Hình bao chữ nhật của nút "Tòa nhà" được định nghĩa sao cho nó chứa đựng các hình bao của tất cả các phòng. Như vậy nếu nút tòa nhà được xác định là bị ẩn đi, thì nó sẽ không có nhu cầu để kiểm tra những nút con một khi chúng cũng bị ẩn. Lợi ích khác của sự phân cấp là dễ dàng thao tác. Cho một ôtô chứa đựng các cửa và bánh xe, thật dễ để di chuyển nút "Ôtô" và các nút con (các cánh cửa và bánh xe) sẽ tự động kéo theo. Không có phân cấp, một là rất có thể phải di chuyển từng đối tượng con chúng tại mỗi thời điểm ô tô di chuyển. Tất nhiên, nó có thể được giải quyết bằng một số các con trỏ thông minh phụ thuộc vào các ma trận, trừ phi sự chính xác mà scenegraph đang làm trong nhiều hình thức mẫu. Ví dụ, xét một xe tăng. Nó có thể được tổ trức như sau :

Bằng cách tách đối tượng thành “các nút” và mô tả kết nối giữa những nút này, có thể thao tác các hình đa giác của xe tăng tốt hơn. Có thể làm cho các phần trở nên sống động hơn. Như có thể quay bệ pháo, khai hỏa súng, và mở nắp. Có thể làm cho các xích trái, phải của xe sống động hơn để mô phỏng khi xe quay. Lợi ích của việc render và phân loại trạng thái

Scenegraph cho thấy các lợi ích sáng sủa cho việc cải thiện quá trình tạo cảnh (render) và tối ưu hơn những tài nguyên phần cứng sẵn có. Bằng việc cất giữ mô hình của thế giới ảo, scenegraph có thể làm tăng thêm việc bổ sung sự tối ưu hóa khác, như việc song song hóa hai pha CULL (chọn lọc) và DRAW (vẽ), và quan trọng nhất là phân loại trạng thái. Phân loại trạng thái, là một khái niệm bằng cách nào đó tất cả các đối tượng đang render được phân loại bởi sự giống nhau trong trạng thái (texture map, giá trị chiếu sáng, sự trong suốt, .v.v.). Khi trạng thái thay đổi tạo cho hiệu năng vận hành hành phần cứng giảm, ngay cả với hệ thống phần cứng mới nhât. Một ví dụ điển hình là khi đang bật tắt ánh sáng hãy tưởng tượng loại kiến trúc phần cứng SIMD, thi hành mã cùng lúc song song với 4 bộ xử lý hình học. Nó có thể là một phiên bản đoạn mã cho những đối tượng "đã được chiếu sáng" và một phiên bản cho các đối tượng "không được chiếu sáng". Việc thay đổi từ đã được chiếu sáng đến trạng thái không được chiếu sáng có thể gây ra cho 4 bộ xử lý để dồn lại và nạp lại. Nhưng nếu có thể cố bật tắt ánh sáng chỉ một lần cho một khung thay vì mỗi lần cho một đối tượng, thì có thể cải thiện sự thực hiện. Một ví dụ khác thậm chí còn tốt hơn, tưởng tượng đang vẽ 100 ôtô, mỗi cái chứa đựng vài hình đa giác có vật liệu là kim loại (trạng thái 1), cao su (trạng thái 2) và kính (trạng thái 3), nó có thể có lợi để vẽ tất cả những đối tượng kim loại trước, rồi kế đến là các đối tượng cao su, và sau đó là kính. Có thể có 3 trạng thái thay đổi, hoặc có thể có 300. Và ít nhất vài trạng thái phải được yêu cầu phân loại khi quan tâm đến chất lượng đồ họa khi cảnh có chiều sâu và hiệu ứng hòa trộn. Tuy nhiên, phân loại trạng thái sớm được hạn chế bởi việc nếu hai đối tượng có rất nhiều sự biến đổi khác nhau (ví dụ 2 kính che gió hai ô tô ở vị trí khác nhau). Không hiệu quả khi phân loại những đối tượng này bằng một trạng thái đơn lẻ bởi vì việc thay đổi các ma trận khung cảnh cũng là một thao tác khá đắt. Tuy nhiên, ngày nay, thông thường tốt nhất cần phân loại bằng trạng thái đầu tiên, tuy nhiên sự chính xác trạng thái là yếu tố quan trọng nhất (và bởi vậy điều quan trọng nhất phân loại đúng trọng thái chính ảnh hượng nhiều đến quá trình tạo cảnh). Thậm chí khi mô tả CSDL có thể thay đổi làm sao khi phân loại trạng thái phụ thuộc vào phần cứng.

Đóng gói trạng thái

Scenegraphs ngay từ đầu đã dùng khái niệm đóng gói trạng thái để làm dễ dàng phân loại trạng thái. Điều này có nghĩa rằng mỗi đối tượng trong scenegraph trỏ vào một cấu trúc trạng thái riêng biệt. Một tập hợp các màu vật liệu, texture, chiếu sáng, trong suốt, .v.v. Scenegraph có thể so sánh những đối tượng trạng thái này cho những cấu trúc giống nhau hoặc chỉ là phân loại bởi những con trỏ. Mặc dầu vậy, khi chuyển từ một tập hợp trạng thái đến tập hợp trạng thái khác, hệ thống chỉ thử thay đổi những điểm khác nhau thích đáng và không áp dụng trộn lẫn tất cả các tham số trạng thái, chỉ một vài trong số đó, như texture, hay việc hợp liệu. Trong những hệ thống này, việc chia sẻ trạng thái được hoàn thành bởi việc có hai đối tượng đồ họa trỏ vào cùng tập hợp trạng thái đó. Nó có những lợi thế khác, như là khả năng để nhanh chóng chuyển từ các trạng thái “ánh sáng thường” tới các trạng thái “ánh sáng đỏ” sử dụng sự trao đổi con trỏ đơn giản.

Trong ví dụ này, nhiều nút (các hình chữ nhật) trong việc mô tả phân cấp xe tăng được gán những trạng thái (các hình oval). Khi xe tăng được vẽ, có thể phân loại những đối tượng bởi trạng thái và cố tối giản số lượng thay đổi trạng thái.

Phép biến đổi đồ thị

Scenegraphs ngay từ đầu chủ yếu tận dụng lợi thế của việc biến đổi đồ thị, miêu tả các cây phân cấp đối tượng trong các giới hạn của các mối quan hệ dịch chuyển thừa kế cha/con. Ví dụ, một nút ôtô có thể có bốn nút bánh xe mà có liên hệ tương đối với trục xe và các nút lái (trung tâm của trục quay), lần lượt được liên hệ tương đối tới ôtô. Hoặc, có thể, một tòa nhà bao gồm các bức tường, sàn nhà, cửa sổ, và các phòng bên trong, và trong mỗi phòng lại có thể chứa các cái bàn và ghế .v.v.

Hệ trục tọa độ động

Các hệ trục tọa độ động (Dynamic Coordinate Systems - DCS) được bổ sung thêm vào các phần của xe tăng, nơi muốn xe tăng có thể di chuyển vòng quanh hay ụ pháo để quay độc lập. Các nút DCS được tổ chức nhiều hơn trước đây, bởi vì chủ yếu thông tin tính toán thêm không thể tính trước được, nhưng thay vào đó được tính lại khi đối tượng đã di chuyển. Ví dụ, khi chọn lọc. Thường sử dụng các hình bao chữ nhật hoặc hình bao cầu để chứa đựng tất cả các nút con, quá trình đệ quy tác động tới các hình bao của chúng. Nếu không gian hình bao của nút bị ẩn, thì tất các nút con của nó do vậy cũng bị ẩn. Khi một nút con di chuyển, hình bao cần tính toán lại. Như vậy về mặt lôgic là như sau: việc tính toán lại hình bao chỉ khi nút con di chuyển. Nhưng điều gì xẩy ra khi tất các nút con di chuyển? Và có phải tính toán lại các biên hộp mỗi lần hay chờ đợi cho đến khi chúng được di chuyển hết? Trong trường hợp đó, có thể tốt tính toán lại hình bao một lần cho một frame, hoặc tốt hơn, nên có cờ để cho biết rằng, nếu có bất cứ nút con nào thay đổi thì ở frame đó cần tính toán lại hình bao một lần cho một frame.

Hệ trục tọa độ tĩnh

Trong tr¬ường hợp các tòa nhà, một khi chúng không di chuyển, có thể sử dụng các hệ tọa độ tĩnh (được gọi là SCS). Đó là phép biến đổi ma trận đơn giản. Sự khác nhau chính là ở chỗ, các nút SCS đó có thể tính toán trước với những thông tin quan trọng, như các thông tin hình bao và va chạm. Quan trọng hơn, trong một hệ thống MP (đa nhiệm), các nút SCS được bảo đảm để không đổi từ trạng thái từ quá này đến quá trình khác, trong khi các nút DCS cần bộ đệm để trong quá trình thay đổi không có ảnh hưởng tức thời đến cái khác. Một ví dụ nhanh của các vấn đề phân loại trên MP hay xuất hiện là, giả sử hai hình lập phương, một đang được đưa vào quá trình xử lý và cái khác được vẽ. Nếu trong quá trình thực hiện đầu tiên đang thực hiện thì tiến hành sửa đổi cả hai hình lập phương trước hoặc vẽ, điều đó là tốt không cần bàn. Nếu quá trình đầu tiên ta lại di chuyển các hình lập phương sau khi chúng được vẽ, điều này được tán thành, nhưng sẽ không nhìn thấy sự thay đổi cho đến khi hình tiếp theo được vẽ. Nhưng nếu quá trình đầu tiên sửa đổi một hình lập phương và sau đó cả hai được vẽ trước khi sửa đổi cái khác, có thể nhìn thấy những hiện tượng lạ làm các hình lập phương xuất hiện dao động lẫn nhau. Gây ra cảm giác không tốt trong hệ thống MP thật, trong quá trình đầu tiên ở giai đoạn cập nhật hình lập phương trong khi hình khác được vẽ, sẽ sinh ra các kết quả không thể đoán trước. Thông thường có thể không sử dụng đa luồng hoặc đa nhiệm, nhưng nó đang càng ngày càng trở nên quan trọng, thậm chí trên các máy CPU đơn lẻ. Với hyperthreading, khe cắm AGP, và các bảng điều khiển chứa đựng các bộ xử lý độc lập, đồng bộ hóa dành cho pha DRAW là luồng chính, việc chạy ở một frame khác hiện là thách thức cho những người quan tâm. Thêm các nhóm, LOD, và các nút chức năng khác

Ngoài những nút hệ tọa độ và những đối t¬ượng đồ họa cơ bản, scenegraph bổ sung thêm các kiểu nút khác vào để cải tiến thêm cho “chế độ lưu trữ” và sự tối ưu hóa gắn với khung cảnh. Hầu hết các kiểu nút này bắt nguồn từ một nút nhóm cơ bản, đóng vai trò như lớp chứa đơn giản chứa bất kỳ số nút con nào, không gian gần hoặc xa nhưng không đụng đến bất kỳ sự hạn chế nào trên nút con của nó. Mức độ chi tiết các nút sử dụng những tính toán cho một đối tượng được xác định là khoảng cách từ người quan sát tới tâm chi tiết được biểu diễn thành sự chuyển đổi giữa hai hoặc nhiều nút con đại diện một đối tượng ở những độ chi tiết khác nhau. Ý tưởng cơ bản là đối tượng ở xa có thể được render ở độ chi tiết thấp hơn (tí hình đa giác hơn, các texture nhỏ hơn, .v.v.). Nhiều ý đồ được thực hiện để phân chia việc chuyển đổi đối tượng hoặc giảm nhẹ giữa các trạng thái LOD, trạng thái mỹ thuật dựa trên cái gọi là các mức liên tiếp của những ý đồ chi tiết khác nhau. Các nút Switch là một dạng của nút nhóm mà đặt nút con tích cực (NULL hoặc một nút con N) dựa vào giá trị khóa(ví dụ: 0 tới n - 1). Các nút Sequence là một dạng của nút Switch các chu trình giá trị khóa dựa vào thời gian. Các hoạt cảnh có thể được làm với các nút nay - mỗi khung cảnh hoạt cảnh được lưu như một đối tượng nút con duy nhất và nút cha nối tiếp điều khiển hoạt động khung cảnh. Ví dụ một DCS - nối tiếp có thể được dùng vào việc bắt sự chuyển động kết nối với hoạt cảnh, nơi mà một mảng các sự biến đổi được áp dụng trong cùng cách một nút làm đi làm lại thông qua danh sách các nút con (nó thường yêu cầu có N nút SCS bằng một chuỗi, sẽ rất lãng phí) Ví dụ DCS-nối tiếp có thể được nén và cất giữ hiệu quả làm CPU mất rất ít thời gian để quay ngược lại.

Performer

Performer là thư viện đồ họa của SGI là ví dụ từ ngay từ sớm của cấu trúc scenegraph chủ yếu được biết như là đồ thị biến đổi đa nhiệm. Trình biểu diễn có những đối tượng trạng thái không tồn tại trong cây phân cấp, nhưng được tham chiếu bởi các đối tượng đồ thị. Performer tạo nên nhiều tiến bộ trong việc sử dụng kỹ thuật lập trình MP để tối ưu hóa việc thực hiện trên những hệ thống đa xử lý của SGI. Performer đã làm được một công việc lớn của phân loại trạng thái tuy nhiên bản thiết kế sớm quyết định giới hạn phân loại trạng thái, các đối t¬ượng không được nhóm lại cho trạng thái render giống nhau nếu chúng có các nút DCS khác nhau ở trên chúng. Trình biểu diễn cũng được mở rộng sử dụng các mặt nạ nhánh ngang và cho nút callbacks áp dụng tới những hiệu ứng đặc biệt.

Thêm những nút trạng thái vào cây

Các phiên bản Scenegraphs về sau đã thêm khái niệm trạng thái như một kiểu nút thực tế. Đã tạo nên những tiến bộ, đặc biệt trong dạng trạng thái chung được tập hợp lại. Ví dụ, nếu đã có 100 đối tượng gạch, có thể chèn một nút “Gạch” như nút cha tới 100 đối tượng đó và quá trình tạo cảnh sẽ hoàn toàn render chúng cùng nhau. Sự thật thì một trong số các nút đứng đầu có lợi của các nút trạng thái. Việc rõ ràng khi phân loại trạng thái đưa cho người dựng mô hình scenegraph gặp nhiều thuận lợi, với những người dựng mô hình thành thạo, cung cấp nhiều điều kiện và tiềm năng hơn khi tối ưu hóa cũng như tự động phân loại trạng thái. Nhưng trong trường hợp tổng quát có lẽ không phải là sự lựa chọn đúng đắn. Tại sao vậy? Một ví dụ minh họa cho 100 đối tượng xe tăng, mỗi chiếc có ba trạng thái (dáng đi, chất liệu…). Nhưng từ đó muốn từng chiếc xe tăng có thể di chuyển độc lập, chúng sẽ được nhóm lại với mỗi xe có nút DCS cha của chính chúng, cộng với nhiều nút DCS cho những bánh xe và ụ pháo nếu muốn. Ở dưới đỉnh DCS đó, có ba nút trạng thái và ở dưới những hình học riêng lẻ kia (dùng chung hoặc được thể hiện). Có nghĩa rằng, trong giới hạn thực hành, có 100 nút bánh, chất liệu, sẽ thay đổi trạng thái ít nhất 300 lần trong thời gian tạo cảnh.

Vis Kit?

Mô hình Vis Kit? là một ví dụ điển hình của cách tiếp cận này. Nó cũng bổ sung thêm những kiểu nút sử dụng khác như "camera" (Như người quan sát bên trong scenegraph, hơn là ở tọa độ tuyệt đối 0,0,0 trong không gian khung cảnh). Nhưng trong những cách khác, Vis Kit? rất giống những phiên bản đầu của Performer Thêm các nút hành động hoặc các nút sự kiện

Scenegraph có nhiều khái niệm cho nút callback mà người lập trình có thể chỉ rõ. Trong Performer, mỗi nút có thể có nhiều callback, phụ thuộc vào ngữ cảnh. Trong quá trình xử lý lại pha chọn lọc, bất kỳ callback chọn lọc nào (nếu hiện hữu) sẽ được kéo theo để ảnh hưởng tới kết quả chọn lọc. Trong quá trình vẽ, bất kỳ callback vẽ nào giống nhau được kéo theo để vẽ những hiệu ứng đặc biệt. Khi những quá trình này làm việc tại chiều sâu cây phân cấp nhánh ngang đầu tiên, nhánh callback ngang trước thường được cung cấp để làm trước và/hoặc sau đó đến nhánh ngang của những nút con. Về mặt ứng dụng, callback cũng được cung cấp để tính toán hoặc tự động hóa trên một nút cho mỗi khung cảnh (ví dụ, cho lôgic có điều kiện, cho hoạt cảnh, di chuyển một DCS, tập hợp những thông tin được thống kê, .v.v.). Tuy nhiên, những hạn chế chính của các hành động tự động cho nút bao gồm hai phần. Trước hết, là rất khó để hoạch định hiệu quả, từ đó ứng dụng không biết trước những nút nào sẽ được hiển thị hoặc mất bao nhiêu thời gian cho bất kỳ callback tiêu hao. Chúng có thể mất một số thời gian tùy ý cho việc thể hiện, và nói chung để xúc tiến xử lý của việc họn lọc hoặc vẽ. Chúng cũng được được rải rắc một phần trong không gian gắn với cache và dự báo trước các nhánh - những thao tác giống nhau hầu như không được thự hiện trong những lần lặp lại. Ví dụ, trong các ứng dụng Performer, các callback đôi khi được xây dựng để gây ra cho CPU các nhịp trễ và không tất định, tác động tất yếu. Hạn chế thứ hai của callback phức tạp hơn. Về mặt ứng dụng, các callback cần được kéo theo trước khi việc chọn lọc hoặc vẽ các nhánh ngang bắt đầu (ứng dụng có thể thay đổi vị trí của các đối tượng, di chuyển chúng bên trong và ra khỏi khung cảnh), nhánh ngang thông thường thăm mọi đối tượng trong scenegraph, thậm chí là những đối tượng không nằm trong màn hình. Nó có thể rất không hiệu quả và cuối cùng đánh bại những lợi thế của chọn lọc thông qua việc thúc ép tức thời chế độ thi hành. Một hệ thống tốt hơn có thể thực hiện vài chọn lọc trước và sau đó thực hiện xử lý cho nút dựa vào việc làm sao đóng một đối tượng đang ở trong khung cảnh. Các đối tượng nằm xa thông thường cần giới hạn xử lý, thường để xác định khi chúng gia nhập vào khung cảnh. Và ứng dụng xử lý có thể di chuyển một đối tượng. Như vậy vẫn còn có một phần phụ thuộc chu kỳ giữa sự tối ưu hóa này và chọn lọc cần được hướng vào.

Inventor

Inventor tồn tại trong SGI cùng thời điểm với Performer rất nhiều khuynh hướng khác nhau. Nhưng mục đích chính hỗ trợ vượt mức việc thực hiện. Kết quả là rât khả thi và hỗ trợ tối đa một bộ phận các nút scenegraph, nhưng việc thực hiện rất mất thời gian. Đến mức mà Inventor đã được giành riêng cho các dự án cơ khí và CAD/CAM ở đó kết quả đạt được trong thời gian thực là không quan trọng. Nhiều người đã cố kết hợp cả Performer và Inventor để có được điều tốt nhất nhưng hầu hết thường thất bại. Bổ sung thêm các nút sự kiện

Các nút sự kiện là sự bổ sung sau cùng cho hệ thống như Inventor và con của nó, VRML. Ý tưởng đằng sau một hệ thống sự kiện scenegraph khá thông minh về măt lý thuyết. Nếu camera hoặc người quan sát là một đối tượng bên trong scenegraph, có thể kiểm tra kết quả khi đối tượng đụng chạm với một hoặc nhiều “Trigger” ẩn. Một trigger hay đối tượng nhạy cảm có thể được liên kết đến một hiệu ứng hay đối tượng hành động mà sẽ miêu tả một nút. Các sự kiện có thể là chuột, hay cũng có thể là bàn phím cơ bản, như vậy nếu kích vào một nút 3 chiều, thì một vài thứ khắc xảy ra trong thế giới thực tế. Theo cách này có thể viết toàn bộ chương trình tương tác người dùng trong scenegraph. Những cánh cửa có thể được mở, ánh sáng được bật bởi chuyển đổi thực một cách nhẹ nhàng, .v.v. Tất cả dữ liệu được điều khiển.

VRML

VRML là viết tắt của Virtual Reality Modeling/Markup Language – Mô hình thực tại ảo / Ngôn ngữ đánh dấu là sự mở rộng của Inventor, phác thảo sau nhiều cuộc cạnh tranh. Nó rất giống với Inventor trong định dạng hàm và cản trở từ nhiều quá trình không tác dụng. Nhưng thật kín đáo và đơn giản để truyền qua các kết nối ngang. Nó cũng được bổ sung thêm những khái niệm cho tính mở rộng.

Những nút đặc biệt

Geo Spatial?

Các vấn đề Geo Spatial? (như vẽ toàn bộ trái đất) yêu cầu một số nút đặc biệt để gắn với giới hạn chính xác phần cứng có được của phần cứng đồ họa, là dấu chấm động chính xác. Thông tin geospatial thật yêu cầu hơn 23 bít phần định trị để miêu tả hợp lý và scenegraph nói chung được sử dụng 32 bít float, như vậy thêm vài kiểu Geo Node? mới vào các sơ đồ scenegraph. Geo Vrml? là một cách tiếp cận như vậy, điều khiển phần lớn bởi SRI. Keyhole sử dụng cách tiếp cận của nó cho Earth Viewer?. PVS

PVS là viết tắ của “Potential Visual Set” là một giới hạn rọng cho việc phân loại ký thuật chọn lọc tổng quát hóa. Trong chọn lọc cơ bản, đệ quy tìm các đối tượng nào rơi trên hoặc trong vài không gian biên, thông thường một hình chóp cụt. Trong chọn lọc phổ biến, có thể tính toán trước những danh sách các đối tượng mà được nhóm trong không gian (giống các nút “Group”, chỉ chúng không cần có liên hệ có thứ bậc) và có thể hiển thị cùng lúc. Các kỹ thuật khác có thể sử dụng các đối tượng tạo bóng hoặc khối mà quản lý những vùng nhất định ngoài không gian.

Ví dụ, tiếp cận “ô và cổng ”, thường nhóm mọi vật vào trong những căn phòng hoặc những ô, với mỗi ô có một danh sách những đối tượng trong nó và một danh sách những cánh cổng , những cái cửa, hoặc những kết nối khác với các ô kề bên (hoặc thậm chí xa nhưng đã kết nối). Khi một cánh cổng đặt hiển thị, việc chọn lọc thông thường tìm kiếm các ô đã được kết nối của cổng và kiểm tra tất cả các cổng của nó, và cứ đệ quy như vậy, mỗi lần thêm (O Ring?) toàn bộ các đối tượng hiển thị và mỗi lần giảm (AN Ding?) hình cụt cho cánh cổng để có thể nhìn xuyên suốt. Trong những quá trình đơn giản, những đối tượng bên trong một ô đơn được được xem xét hiển thị bất cứ khi nào ô được chọn. Chọn lọc không gian truyền thống thông thường được sử dụng để thúc đẩy chậm hiển thị thiết đặt.

Cái thú vị nhất với các “Cell and Portal” chính là nó còn có thể khái quát hóa khái niệm render cho các framebuffer và các đích và sử dụng các standin hoặc các impostor. Một ô cửa có thể là cánh cổng dẫn tới một căn phòng khác, hoặc có thể được thực hiện giống các đa giác có texture, được render trước từ hình ảnh của phòng đó từ viễn cảnh chính xác. Những tấm gương được thực hiện bằng nhiều cách giống nhau. Một tấm gương có thể được render bởi ma trận khung cảnh nghịch đảo và chiếu camêra xuyên qua gương, sau đó lại vẽ vào trong framebuffer bình thường. Hoặc nó có thể được render bằng việc chiếu camêra xuyên qua gương, render khung cảnh cho một texture, và dán texture cho gương như một bức tranh. Mặt hạn chế của các kỹ thuật kỹ thuật PVS là chúng thường được bổ sung thêm cho scenegraph khi đã muộn và không xây dựng lên từ nền. Net Immerse? đã và đang là máy game được sử dụng rộng rãi của Cells and Portals.

Inventor Revisited

Inventor rất dễ sử dụng. Nó cung cấp một tập hợp phong phú các kiểu nút làm cho dễ dựng và tái tạo cảnh. Ngoài ra cũng bổ sung thêm các kiểu GUI (giao diện) 3D đẹp, hỗ trợ xây dựng nhanh các ứng dụng đồ họa.

Tuy nhiên, Inventor là một performer nghèo nàn. Nó bị ảnh hưởng từ một vài lỗi thiết kế bất thường, như ảo hóa tất cả các giao diện, thậm chí tới những thành phần dữ liệu cơ bản. Nhưng lỗi lớn nhất trong mô hình thực hiện, là các nút thi hành trong scenegraph sử dụng thời gian CPU trong khi cảnh đang được render. Và sau đó tất cả các nút phải được hiển thị, khung cảnh chọn lọc trong vùng quan sát không thực hiện, thậm chí ở ngay giai đoạn render. Điều này làm cho việc hiển thị đồ họa bị chậm không đảm bảo thời gian thực trừ phi người lập trình cố gắng tối ưu hóa nó.

Scenegraph hiện tại

Hiện nay Scenegraph khá phức tạp và sẵn có, thậm chí miễn phí và là mã nguồn mở. Nói chung được thích hợp cho sự phát triển các trò chơi đa hệ. Nhưng scenegraph hiện thời có vài nhược điểm quan trọng. Một là khái niệm nạp chồng cây với tất cả các loại nhụy hoa và những tiếng hót thay đổi từ trên xuống. Hai là không có những tiếng hót thay đổi từ trên xuống. Ba là không có cấu trúc thay đổi, tọa độ thay đổi trong phân tán hệ thống là khó. Rất ít các nhóm của scenegraph được thiết kế với MMOG. Trung tâm của vấn đề là nạp chồng mỗi lần, cải tiến tức thời kiểu Open GL thực hiện. Di chuyển cây phân cấp để có thể chọn lọc và vẽ hiệu quả hơn. Rồi bổ sung thêm tất cả vật thêm này, như treo đồ trang trí lên một cái cây Nô-en. Chúng không đơn giản như nghĩ. Cách khác, tìm các khái niệm biến đổi đồ họa gốc để tổ chức không gian CSDL trực quan để có được lợi thế của việc nhóm các đối tượng được liên kết hoặc gần nhất. Truyền thông tin không gian dùng chung lên trên cây, nơi có thể tạo các nhánh ngang đầu tiên là quyết định đúng đắn, tiết kiệm thời gian trong việc cấu thành cây cấp n. Nhưng có nhiều cách để tổ chức cơ sở dữ liệu trực quan. Các kỹ thuật Culling và PVS cần có không gian tổ chức những CSDL cho việc thực hiện tối ưu. Nếu scenegraph thay vì được tổ chức phần lớn bằng trạng thái, thì có thể chọn lọc mỗi xe tăng 3 trạng thái ba lần, một lần cho mỗi phần khớp, thay vì có thể chọn lọc bên ngoài một xe tăng và một lần duy nhất. Nhưng nếu muốn có sự thực hiện phần cứng tốt nhất, thì sắp xếp tập hợp các trang thái thay đổi nhất đầu tiên. Hơn nữa, từ đó những trạng thái thường không thay đổi, không cần sắp xếp trước mỗi khung cảnh. Nếu sắp xếp trước toàn bộ scenegraph cho sự tối ưu hóa trạng thái (hy vọng chỉ một lần), sẽ mất tính chặt chẽ đáng tin cho việc tăng tốc độ chọn lọc. Dựa vào việc muốn móc nối vài nút lên các nút khác để cho phép xử lý sự kiện, giống như cách đặt tên cho các đối tượng một cách nhất quán không thay đổi sau khi sắp xếp trạng thái hoặc không gian hoặc thậm chí không thay đổi nếu các phần của cảnh hiện thời được nạp vào hoặc không. Bằng việc thi hành các hành động mỗi nút trong suốt quá trình duyệt theo chiều sâu nhánh ngang đầu tiên, có lẽ sẽ kéo theo những đoạn tùy ý (gần như ngẫu nhiên). Trái ngược với lịch trình cải tiến, nhiều trình biên dịch đã cố thử nắm bắt lợi thế việc dự báo phân nhánh CPU, để đặt tên. Việc thiếu bộ đệm thông tin và dữ liệu có thể ảnh hưởng việc thực hiện lên tới 10 lần trên nhiều hệ thống. Như vậy nó không có ý nghĩa, nếu như có 100 nút vật lý và 100 nút hoạt cảnh chuyển động ngược, thử xử lý những nút đó cùng nhau, chỉ cần giống như thử làm cho trạng thái (đặc biệt cho những hệ thống với vecto định hướng hoặc những khả năng SIMD đặc biệt). Nó cho phép tiếp cận việc làm thế nào tối ưu hóa scenegraph. Đặt tất cả chúng cùng nhau sẽ rất dễ để nhìn thấy sự tiến hóa của scenegraph trong giai đoạn hiện nay thì nhìn thấy ngay sai lầm ở đâu đó. Đó là lý do yêu cầu một sự thay đổi trong cách tiếp cận để vượt qua rào cản đó.

Scenegraph của tương lai

Thật vậy, không thể tìm thấy một tổ chức đơn lẻ hoàn chỉnh cho scenegraph, đồng thời tối ¬ưu hóa cho cảnh không gian, trạng thái, ngữ nghĩa học, và những nghiên cứu CPU. Vài người cố gắng thiết kế bằng tay để được CSDL tốt nhất mà họ mong muốn. Nhưng ý tưởng tốt nhất là loại bỏ một trong số những sự ràng buộc cơ bản: Cái cần là một tổ chức scenegraph đơn lẻ cho một cơ sở dữ liệu trực quan đã cho. Điều đó có thể không thích hợp để có một bộ các đối tượng đơn lẻ, gọi là một nhóm đối tượng, nhưng có hai, ba, bốn, hoặc nhiều sự phân cấp liên kết với những đối tượng này trong những tổ chức không độc lập. Đây là mong muốn của nhiều nhà thiết kế scenegraph trong nhiều năm, tuy nhiên nó không bao giờ đòi hỏi trước những CSDL phân bố dọc.

Nhưng làm thế nào để thực hiện điều này lại là chuyện khác. Giải pháp, được xem như¬ ở trong sự tách rời những khái niệm scenegraph “các nút” từ “các đối tương” đại diện cho chúng. Bằng việc tạo nên những đối tượng được chia sẻ trong một nhóm, tối giản số lượng của phế liệu và phối hợp sẽ có thể thấy đồng thời bốn hoặc nhiều sự phân cấp đối tượng. Theo cách này “Nút” bộ phận của một đối tượng chỉ mất một ít tài nguyên đủ để trỏ đến đối tượng trong nhóm và đến các quan hệ cha mẹ / con / anh chị em trong khung cảnh đặc biệt này. Tất cả được giữ một lần trong đối tượng, mà ý tưởng chứa đựng đằng sau nó những con trỏ trỏ tới mỗi nút trong mỗi đồ thị. Lời trên là khoa học? Không thật sự. Các CSDL quan hệ có phân ra theo chỉ số từ dữ liệu từ lúc đầu. Scenegraph chỉ là một cách chỉ số hóa trong CSDL trực quan lớn. Những người thiết kế scenegraph đi đến việc nắm chắc với cái đó, mọi cái khác thì thả dốc. Vấn đề thứ hai làm sao để t¬ương quan giữa nhiều khung cảnh cơ sở dữ liệu (ví dụ các tập hợp chỉ số). Một khi những nút có trong hai cảnh quan trỏ tới cùng đối tượng, sẽ dễ thấy làm thế nào cho một nút vào một khung cảnh CSDL, có thể tìm thấy nút tương ứng cảnh quan khác bằng cách theo các con trỏ phía sau. Nó khiến việc chọn lọc tốt hơn, tối ưu hóa khung cảnh không gian và trả lại sử dụng cảnh quan trạng thái tối ưu hóa phần cứng. Trung tâm của sự thực hiện đầy đủ CSDL đã phân bố hiệu quả , rồi, đang sử dụng khung cảnh không gian để giới hạn cái gì sẽ xảy ra trong những cảnh quan khác (render, culling, physics, hoạt cảnh, .v.v.) và phân phối những sự thay đổi trong khung cảnh không gian giữa những hệ thống khác nhau. Trạng thái, ngữ nghĩa học, và ứng dụng những khung cảnh nói chung không thay đổi, ngoại trừ tính rõ ràng và quyền ưu tiên cho khoảng thời gian, như vậy của nhiệm vụ ở trong việc đồng bộ hóa những khung cảnh không gian. Khung cảnh ngữ nghĩa

Khung cảnh ngữ nghĩa học hoặc logic của một CSDL trực quan chỉ là một cách truy nhập những đối tượng trong nhóm đối t¬ượng. Sự tổ chức là tùy ý và hoàn toàn do người phát triển. Một người phát triển có thể sử dụng khung cảnh ngữ nghĩa học như một từ điển lớn tra cứu đối tượng, được tổ chức bởi kiểu đối tượng, kiểu con .v.v. Hoặc một trò chơi có thể chia cắt những đối tượng bởi vai trò của họ trong trò chơi. Nhưng ý tưởng chính là loại bỏ đi cái cây là những đối tượng thực tế trong thế giới. Cái quan trọng là cấu trúc lôgíc / ngữ nghĩa học đó được biết đến (được xuất bản) cho tất cả những người phát triển cùng sử dụng. Nhưng nó có thể được sử dụng cho những sơ đồ tinh tế hơn nữa. Ví dụ, nếu ngữ nghĩa học khung cảnh được tổ chức thành “xe cộ” và sau đó là “ô tô”, có thể thực hiện thao tác nào đó trên tất cả trò chơi vũ trụ. Không có lý do tại sao các đối tượng không thể được định vị dưới nhiều hơn một phân nhánh của cây ngữ nghĩa học. Có thể là một nhánh được gọi là “các đối tượng vật lý” giống như nhánh “Xe cộ / Ôtô”. Khung cảnh tĩnh

Như đã được bàn luận từ trước, khung cảnh trạng thái được định nghĩa là một platform sắp xếp trạng thái chi tiết và khung cảnh tập hợp trạng thái. Với một platform trên đó lôi cuốn texture là rất đắt, có thể thấy các textureID như những nhánh quan trọng nhất trong cây, do đó việc tối giản số lượng các sự thay đổi textureID. Trên platform khác, kiểu chiếu sáng có thể khó hơn để thay đổi. Khung cảnh trạng thái nói chung có thể được tính toán trên client vào thời gian nạp và không thay đổi nhiều. Những đối tượng là on hoặc off nhưng vẽ cơ bản là không có thứ tự. Một ngoại lệ cho quy tắc đó là những đối tượng phân loại chiều sâu, như những hình đa giác trong suốt. Ở đây, có thể có một nhánh của khung cảnh trạng thái mà phần động không làm chậm phần còn lại của hệ thống. Các ngôn ngữ shading

Một trong số các thuật ngữ gần đây nhất trong đồ thị máy tính hiện đại là ngôn ngữ shading. Ý tưởng chính là những hình ảnh phức tạp có thể được xây dựng bởi sự kết hợp các hàm toán học (Cộng, trừ, nhân,.v.v.) nhiều hình ảnh đơn giản, thường xuyên thông qua một ngôn ngữ lập trình assembly nhỏ thay vì việc sử dụng những thao tác framebuffer thực tế. Ví dụ, mapping texture tạo gạch cho hình ảnh 3D một bức tường đang rung chuyển (chỗ ánh xạ rung động cung cấp những ám hiệu ánh sáng và bóng tốt để làm viên gạch nhìn có vẻ như 3D hơn) có thể được mô tả như một sự kết hợp của một texture căn hộ màu đỏ, hai hoặc ba trạng thái render của va chạm ánh xạ (việc render ánh sáng và bóng), map ánh sáng cho các bóng toàn cục và có thể map hiệu ứng chiếu sáng lóng lánh nếu đối tượng được gắn kính hoặc những mẩu kim loại nhỏ. Bóng có thể được biểu thị bằng lập trình, những giải thuật, hoặc bằng “cây đổ bóng” nơi các bóng nhỏ cấu thành được chia nhỏ dần trong mẫu phân cấp, giống như sự biến đổi không gian. Cây đổ bóng này có thể hiện, nếu scenegraph cơ bản hỗ trợ những khái niệm cao cấp như vậy, hoặc nó có thể ẩn, như sự trình bày trừu tượng của một số đọan mã được dịch trước. Nó quan trọng để nhận thấy rằng cây đổ bóng có thể dễ dàng thay đổi từ nền phần cứng này đến nền tảng phần cứng kia, phụ thuộc vào những khả năng đồ họa và những hệ số khác. Ví dụ, phần cứng nào hỗ trợ mapping va chạm cấp cao trong một quá trình đơn - nh¬ư nút cây trạng thái trong trường hợp là một nút. Phần cứng khác có thể không hỗ trợ bump mapping chút nào, nhưng vẫn có thể đạt được những hiệu ứng bump mapping bằng một tác động đến cho kết cấu, một cho những vùng sáng và một cho những vùng tối. Như vậy cây đổ đổ bóng trong trường hợp đó có thể có một nút cha với ba nút con, đại diện cho ba sự chuyển đổi qua lại.

(Ghi chú : ở đây, những cái hộp là những trạng thái và những vòng tròn đang render những đối tượng). Các cây đổ bóng sẽ thay đổi từ phần mềm API đến phần mềm API. Nhưng từ đó phân ra khái niệm Spatial View (khung cảnh không gian) từ State View (khung cảnh trạng thái), tạo điều kiện đặt điều khiển giao diện với các API đồ họa cơ sở có thể sử dụng (như Intrinsic Alchemy hay Criterion, hay Open GL hay Direct X).

Khung cảnh ứng dụng

Sự có mặt của khung cảnh ứng dụng không phải là một yêu cầu bắt buộc. Thật ra, đó là khung cảnh ít sử dụng nhất, chủ yếu vì những trình biên dịch tốt hơn nhiều trong việc hoạch định đoạn mã trên CPU. Và một vấn đề lớn là chương trình điều khiển dữ liệu chúng có thể rất khó gỡ lỗi hay đánh dấu. Nhưng, mặt khác chúng rất tốt cho sự trìu tượng hóa nền tảng trung lập và đầu tiên. Chúng cũng khá hữu ích để đưa cho cho người dùng khả năng thay đổi động cách tác động trò chơi (ví dụ lập trình mod hoặc hòa trộn đơn giản).

Khung cảnh không gian

Mặt khác, khung cảnh không gian là khung cảnh quan trọng nhất từ một phân bố CSDL không gian. Bằng việc tổ chức thế giới ảo vào trong những không gian hay những không gian con, có thể quyết định hiệu quả làm sao để ấn định tuyến đường những thông báo, những tính toán được ưu tiên, và chọn lọc CSDL để tối giản thời gian render và lưu thông mạng. Sự chia nhỏ thế giới thành những không gian có thứ bậc không phải là tùy ý, nhưng có một số sơ đồ hợp lệ để làm như vậy. Điều quan trọng là sơ đồ chia nhỏ khá tốt để điều chỉnh thủ tục chọn lọc, để không có nút nào có quá nhiều hoặc quá ít nút con ( nghĩa là một cây quá cao hoặc quá rộng). Sự lựa chọn các không gian hoặc là tĩnh học hoặc là động cũng là khái niệm mở. cho sơ đồ cây phân tứ, sự chia nhỏ là tương đối tĩnh. Nếu một đối tượng di chuyển, thì nó có thể tạo ra cho các ô phân tứ mới hoặc hủy chúng đi, nhưng không có các ô phân tứ nào di chuyển. Cho những hình cầu hoặc các cây hình bao, thể tích hình bao có thể di chuyển khi những đối tượng chúng chứa đựng di chuyển. Những quy tắc cho việc kéo căng, hay thu hẹp những thể tích hình bao cũng linh hoạt và khá dễ để thực hiện như những phương pháp lặp (với sự tối ưu hóa cục bộ, không toàn cục). Trong sơ đồ này, những thể tích hình bao có thể chồng lên nhau, nhưng chúng không cần làm như vậy. Nó không chỉ là một vấn đề cho một đối tượng sẽ được chứa đựng bên trong những thể tích biên miễn là nó chưa được chọn lọc bên trong hoặc ở ngoài nhiều hơn một lần cho một khung cảnh. Việc nhóm lại những đối tượng trong cơ cấu là một khả năng mở rộng khác. Một nhóm những xe tăng hoặc những chiến sĩ có thể là một tập hợp động bởi khoảng cách gần và chọn lọc như một nhóm, dù không có mút "cha mẹ" đơn lẻ trong giác quan scenegraph truyền thống.

Tổng kết

Trên đây là bản tóm tắt cơ sở của scenegraph, ra đời, hiện tại, và tương lai, ít nhất từ một điểm khung cảnh. Nhiều công việc có liên hệ đến việc phát triển cái gọi là scenegraph “đa khung cảnh” (“multi-view”). Mục đích cuối cùng là đến gần với một hệ thống đơn giản, nhẹ để tối ưu hóa việc render thông qua các platform.

Bài viết của tác giả Avi Bar-Zeev - email: cyranose@realityprime.com

OpenSceneGraph

Tài tiệu Open GL

Tài liệu OSG

Hình ảnh một số sản phẩm

vanmieu9_0.jpg: 250x156, 47k (December 01, 2011, at 10:13 AM)
th_vsg_02.jpg: 200x150, 5k (December 01, 2011, at 10:13 AM)
vanmieu7.jpg: 800x500, 143k (December 01, 2011, at 10:13 AM)
kho82-s3.jpg: 800x500, 101k (December 01, 2011, at 10:13 AM)
BigC-2.jpg: 800x500, 64k (December 01, 2011, at 10:13 AM)
vanmieu6.jpg: 800x500, 171k (December 01, 2011, at 10:13 AM)

sửa SideBar

Edit - History - Print - Recent Changes - Search
Page last modified on May 22, 2007, at 05:55 PM