Hệ thống thời gian thực và ứng dụng trong kỹ thuật mô phỏng

Tóm tắt Hệ thống thời gian thực và ứng dụng trong kỹ thuật mô phỏng: ...ave clock) theo kiểu “polling”, tất cả các đồng có cùng độ chính xác, nếu đồng hồ chính bị hỏng thì một trong những đồng hồ phụ sẽ thay thế. Đối với các hệ thống phân tán, đồng hồ hệ thống bao gồm tất cả các đồng hồ phân tán và được đồng bộ với nhau theo cùng một thuật toán. 5.3. Quan niệm v...p cho những người thực hiện hoàn thành chính xác hơn công việc của mình. Các chiến lược phân tích thiết kế thường được sử dụng như : 1) Chiến lược từ trên xuống (Bottom-Up design) : Chiến lược này được tiếp cận theo hướng xem xét bài toán từ các khía cạnh chi tiết và sau đó mới tổng quát l...nd. Để hiểu rõ hơn ta hãy tìm hiểu sự khác nhau giữ đồ họa 3D thời gian thực và hoạt cảnh 3D. Hoạt cảnh được sử dụng trong các sản phẩm Mutilmedia cụ thể là tạo film, hoặc các sản phẩm đồ họa phục vụ công việc in ấn. Còn phần mềm đồ họa thời gian thực được ứng dụng trong các ứng dụng mô phỏn...

pdf36 trang | Chia sẻ: havih72 | Lượt xem: 185 | Lượt tải: 0download
Nội dung tài liệu Hệ thống thời gian thực và ứng dụng trong kỹ thuật mô phỏng, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
trên mô hình toán học – Đại số tuyến tính – Ma trận cụ thể cho phép 
có thể cộng trừ nhân chia, cho ra những kết quả cụ thể mà dựa trên đó sẽ có một sự 
đánh giá chính xác hệ thống cũng như từng thành phần của hệ thống. 
2
1
54321
2
1
54321
21
54321
00100
21000
10000
00211
,
,,,,
),,,(
t
t
ppppp
O
t
t
ppppp
I
ttT
pppppP
OITPC
=
=
=
=
=
Ví dụ một mạng Petri 
Mạng Petri có thể được biểu diễn bằng đồ thị Petri (Petri graph), với hai loại node: 
trạng thái và chuyển đổi. Cung nối trực tiếp chỉ liên kết giữa hai node khác loại (trạng 
thái - chuyển đổi hoặt chuyển đổi - trạng thái, trường hợp đặc biệt có thể là cùng 
loại). 
Hình 8: Đồ thị Petri liên kết với mạng Petri ví dụ trên 
Với định nghĩa trên thì mạng Petri chỉ trình bày được những yếu tố tĩnh trong hệ 
thống. Như vậy sẽ không mô hình hoá được những tác nhân mang tính động. Mạng 
Petri đánh dấu (Marked Petri Net) được sử dụng để mô hình sự biến đổi theo thời 
gian của hệ thống. Trong đó các trạng thái sẽ được đánh dấu bằng những điểm trong 
đồ thị gọi là thẻ đánh dấu (marking tokens). 
Hình 9: Một đồ thị Petri đánh dấu 
Thẻ đánh dấu là một vector N chiều xác định số thẻ mỗi trạng thái . Hệ thống trở 
thành hệ thống động khi các thẻ lần lược duyệt qua các node trên mạng. Quá trình di 
chuyển các thẻ xuyên qua các chuyển đổi tới hạn. Một biến đổi được gọi là tới hạn 
chỉ khi tất cả các trạng thái đứng trước nó được đánh dấu, các chuyển đổi này còn 
được gọi là chuyển đổi cho phép. Chỉ có duy nhất một chuyển đổi tới hạn tại một thời 
điểm và tuỳ chọn ngẫu nhiên giữa các chuyển đổi cho phép (ưu tiên cho cạnh có 
trọng lượng lớn nhất). Một chuyển đổi tới hạn kéo theo những ảnh hưởng trên những 
trạng thái đứng trước và sau chuyển đổi đó : 
+ w thẻ được gở bỏ khỏi mỗi trạng thái đứng trước. 
+ w thẻ được thêm vào mỗi trạng thái đứng sau. 
Một giới hạn xảy ra có các tính chất sau : 
+ Chủ động : Một chuyển đổi cho phép được tới hạn nhưng không bắt buộc. 
+ Trọn vẹn : Tất cả các quá trình liên quan cũng tới hạn. 
+ Tức thời : Không có tồn tại thời gian trể giữa các quá trình liên quan. 
Hình 10: Một đồ thị Petri hình 8 sau khi chuyển đổi t1tới hạn 
Hình 11: Một đồ thị Petri hình 8 sau khi kết thúc tất cả các chuyển đổi 
Không cần đi vào chi tiết từng thiết kế, ta nhận thấy rằng trong mạng Petri, điều kiện, 
trạng thái trong thực tế tương ứng với node trạng thái trong mô hình và sự kiện, kết 
quả tương ứng với chuyển đổi. 
Hình 12: Mô tả mạng Petri của một quá trình chia sẽ CPU cho các tiến trình Khi CPU 
rảnh rỗi (idle) - p2 được đánh dấu. Ngay khi có một tiến trình vào chờ trên hàng đợi 
CPU - p1 được đánh dấu, tiến trình đó được thực hiện - t1. Kết thúc t1 
– p3 được đánh dấu. t2 thực hiện. Kết thúc t2 – p4 được đánh dấu, CPU được giải phóng – 
p2 được đánh dấu. Quá trình được lặp lại khi có một tiến trình vào hàng đợi CPU. 
11. Đồ họa 3D thời gian thực 
Đến đây thuật ngữ “thời gian thực” đã rõ ràng và không có nghĩa là thực sự nhanh. 
Đối với hệ thống hiển thị thời gian thực điều kiện tốt nhất của số khung hình hiên thị 
trên màn hình là trong khoảng 60 đến 85 frames/second. Để hiểu rõ hơn ta hãy tìm 
hiểu sự khác nhau giữ đồ họa 3D thời gian thực và hoạt cảnh 3D. 
Hoạt cảnh được sử dụng trong các sản phẩm Mutilmedia cụ thể là tạo film, hoặc các 
sản phẩm đồ họa phục vụ công việc in ấn. Còn phần mềm đồ họa thời gian thực được 
ứng dụng trong các ứng dụng mô phỏng, ví dụ như tập bay, tập lái, trò chơi, có khả 
năng tương tác. Cả hai loại sản phẩm này đều sử dụng các hình ảnh mô hình thực tế 
với mức độ chi tiết cao cùng với các thuật toán làm trơn các trạng thái thay đổi của 
cảnh đồ họa. Thông qua các thuật toán tô bóng số lượng khung hình ngữ cảnh trong 
một đơn vị thời gian. Nhưng có vài sự khác biệt như sau. 
• Phần mềm mô phỏng cần số lượng khung hình là thời gian thực, nghĩa các 
khung hình phải liên tục khi dữ liệu được cập nhật (bao gồm cả vị trí và 
hướng quan sát). Còn hoạt cảnh số lượng khung hình được đặt trước, khi tạo 
cảnh phải mất hàng giờ để tạo. 
• Phần mềm mô phỏng cần độ tương tác cao để điều khiển sự chuyển động của 
các đối tượng trong cảnh. Hoạt cảnh không cho phép tương tác, người dùng 
cảm nhận thự động với cảnh. 
• Sự khác biệt quan trọng khác là tương tác ở mô phỏng là có mục đích. Ngoài 
ra mô hình trong mô phỏng có phần kém chi tiết hơn trong hoạt cảnh mục 
đích là để tăng số lượng khung hình 
• Phần mềm mô yêu cầu số lượng khung hình đạt 15-60 fps, phụ thuộc vào độ 
phức tạp và chi tiết của cảnh. Còn film luôn yêu cầu số lượng khung hình là 
24 hoặc tùy thuộc vào yêu cầu và chuẩn của nó nhừng số lượng khung hình 
luôn cố định theo thời gian. 
11.1. Hiển thị đồ họa thời gian thực: 
Phương pháp truyền thống khi hiển thị cảnh đồ họa 3D thời gian thực sử dụng ba 
pha riêng biệt APP, CULL, DRAW: APP làm nhiệm vụ cập nhật dữ liệu động, bao 
gồm vị trí camera, vị trí của các đối tượng chuyển động, CULL phụ thuộc vào APP 
làm nhiệm vụ lọc cảnh và sắp xếp đối tượng theo độ ưu tiên trong khung nhìn để tăng 
tốc độ hiển thị cảnh đồng thời tùy thuộc vào việc cập nhật vị trí của camera, tạo dữ 
liệu hiển thị theo kiểu danh sách để pha DRAW vẽ cảnh lên màn hình. Quá trình vẽ 
là quá trình duyệt qua danh sách và thông báo cho OpenGL xử lý ta có thể xem hình 
12 dưới đây. 
Hình 12: Ba pha trong hiển thị đồ họa thời 
gian thực 
Hình 13 - Chia những pha thành những nhiệm 
vụ song song cho hệ thống có nhiều màn hình 
hiển thị đồ họa 
Trong một hệ thống có nhiều màn hình hiển thị đồ họa, CULL và DRAW trở nên rất 
cần thiết vì các pha này sẽ sản sinh ra danh sách hiển thị và thực hiện vẽ trên các 
màn hình ở các khung nhìn khác nhau. Tuy nhiên trong hệ thống đó vẫn chỉ cần một 
pha APP chung để cập nhật dữ liệu. Dưới đây là trình tự yêu cầu cần thực hiện theo 
quan điểm đa nhiệm cho nhiều màn hình hiển thị. Với mô hình máy đơn cần xử lý 
các pha theo từng thời kỳ (APP, CULL0, DRAW0, CULL1, DRAW1, CULL2, 
DRAW2). Theo trình tự này cần nhiều thời gian để thực hiện một khung hình qua 
trình tự thực hiện các pha. 
Để phân nhiệm ta định ra hai nhiệm vụ sau được miêu tả như ở hình 13: 
ƒ Nhiệm vụ thực hiện pha APP. 
ƒ Nhiệm vụ CULL / DRAW cho mỗi màn hình. 
Với hệ thống đa xử lý, tất cả các nhiệm vụ có thể được thực hiện song song trên 
từng bộ xử lý riêng biệt. Hơn nữa, CULL / DRAW có thể được chia ra từng phần để 
có thể chạy song song trong hệ thống. 
Có hai mô hình thực hiện trên hệ thống xử lý song song: 
ƒ Chia cắt một nhiệm vụ lớn thành nhiều nhiệm vụ nhỏ độc lập để thực hiện 
song song từng nhiệm vụ trên mỗi máy để giảm bớt thời gian xử lý. 
ƒ Thực hiện nhiệm vụ lớn song song trên các máy sao cho đồng bộ về thời gian 
trên hệ thống. 
Với hai mô hình này ta tách pha CULL/DRAW từ pha APP, rồi sau đó tiếp tục chia 
pha CULL và DRAW thành nhiều nhiệm vụ chạy song song riêng biệt theo mô hình 
thứ nhất. Ghép CULL/DRAW thành một nhiệm vụ kép cho mỗi hệ thống hiển thị 
theo mô hình thứ hai. 
Nhưng xuất hiện vài vấn đề ở từng giai đoạn khi chạy song song. Trước hết, những 
pha phải xử lý dữ liệu ra từng kỳ. Nghĩa là pha APP phải kết thúc làm việc trên dữ 
liệu trước pha CULL. Tương tự như vậy pha DRAW không thể bắt đầu xử lý dữ liệu 
khi mà pha CULL chưa làm việc xong. Tuy nhiên, APP không cần phải đợi cho đến 
khi cả hai pha CULL và DRAW làm việc xong mà vẫn có thể xử lý dữ liệu ở khung 
hình tiếp theo và hệ thống có thể vận hành theo như Hình 11.3 mô tả dưới đây. Bên 
cạnh đó dữ liệu dùng chung giữa hai giai đoạn phải được bảo vệ hoặc dùng bộ đệm. 
Bên cạnh đó dữ liệu đang ghi bởi pha ở giai đoạn này không thể đọc ở cùng pha chạy 
song song trên hệ thống. Điều này đòi hỏi cần có hệ thống quản lý dữ liệu lớn để xử 
lý dữ liệu 3D. Đây chính là mô hình của hãng SGI đưa ra và có hiệu quả trong các 
sản phẩm đồ họa của hãng như ở hình 14. Nhưng vài năm gần đây đã trở lên lạc hậu 
do một vài lý do sau: 
ƒ Vấn đề thời gian thực, khi các sản phẩm mô phỏng yêu cầu độ hiển thị khung 
hình là 60 Hz nghĩa là mỗi khung hình cần 16.667 mili giây để các pha thực 
hiện xong nhiệm vụ của nó. Vào những năm 90, SGI đã phát triển kỹ thuật đồ 
họa thời gian thực với những bộ xử lý có thể đạt các yêu cầu trên nhưng hệ 
thống máy tính có tốc độ thấp hơn so với hiện tại. Trong khi tốc độ đồ họa phụ 
thuộc rất nhiều vào hai pha APP và CULL. 
ƒ Hơn thế nữa, hệ thống băng thông rộng phát triển giảm bớt thời gian liên 
thông giữa các pha ở máy chủ và các máy trạm, cùng với kỹ thuật xử lý đa 
luồng sẽ có những kết quả khả quan mới. 
ƒ Một vấn đề cuối cùng rất cần thiết đó là những yêu cầu đối với thiết bị mô 
phỏng là phải đáp ứng được các tương tác của người dùng. Vì vậy yêu cầu 
hình ảnh trực quan và sinh động với tốc độ hiển thị thời gian thực. 
Hình 14 - Mô hình xử lý song song "Truyền thống" 
11.2. Cách tiếp cận mới 
Các ứng dụng đồ họa 3D chất lượng cao chạy trên phần cứng hiện thời mong muốn 
có số khung hình lớn hơn 60 cần phải có thời gian xử lý của pha Pre - CULL (Có thể 
hiểu như pha APP – theo mô hình cũ) và CULL nằm trong khoảng 1 mili-giây đến 
3,5 mili-giây để thực hiện một khung hình. Xét hệ thống xử lý đơn, một màn hình 
hiển thị. Với yêu cầu giảm bớt thời gian trên pha Pre – CULL và CULL, sơ đồ các 
pha có dạng như hình 15. 
Hình 15 - Bộ xử lý đơn, một màn hình hiển thị theo mô hình pha Pre – CULL và CULL 
Qua sơ đồ trên ta thấy tất cả các pha đều nằm trong một khung hình, và như vậy độ 
trễ có thể giảm được trong mỗi khung hình. Nhưng pha DRAW chiếm quá nửa thời 
gian thực hiện một khung hình. Các ứng dụng đồ họa có các lợi thế từ các đồ thị 
khung cảnh, mà tại đây pha CULL sẽ loại bỏ các đối tượng không thuộc khung hình 
cần hiển thị để đưa vào các nhánh của đồ thị nhằm tối ưu hóa dữ liệu. 
Xét mô hình đa xử lý với nhiều màn hình hiển thị. Cần phải tận dụng hết lợi ích của 
hệ thống đa xử lý bằng việc sử dụng luồng chính chạy pha Pre - CULL, và các pha 
CULL/DRAW ở các hệ thống con. Để làm được điều này chúng ta giả thiết hai khía 
cạnh về quản lý dữ liệu : 
1) Dữ liệu được ghi bởi pha Pre –CULL có thuộc tính toàn cục. 
2) Dữ liệu được sinh ra ở các pha CULL mang tính cục bộ nhưng có thể tiếp 
cận được bởi mỗi cặp nhiệm vụ CULL/DRAW. 
11.3. Ứng dụng thiết kế Mô hình xử lý đa luồng trong đồ họa 
Mô hình tổng quát được thiết kế theo sơ đồ chung như trên hình 16: 
Luồng Chính. Luồng thực hiện Pre - CULL. Khai báo trong hệ là một CPU đảm 
nhiệm nhiệm vụ đó. 
CULL / DRAW. Có thể chạy như một luồng đơn, hoặc những luồng riêng biệt phụ 
thuộc vào mô hình xử lý được chọn từ mục trước. Điều này có thể được xác định bởi 
hostname trong hệ thống, và một tham số chỉ định CPU nào trên hệ thống sẽ làm việc 
với nó để hiển thị cảnh. 
Hình 16 Mô hình xử lý song song tổng quát 
Có hai mô hình trong mục trước đã đề cập để thực hiện mô hình đa nhiệm (multi-
task), đa màn hình hiển thị đồ họa (multi – display). Sự khác nhau là ở chỗ có quyết 
định ghép hai pha CULL/DRAW thành một hay không. Ở đây đưa ra hai phương 
pháp mỗi phương pháp có những đặc tính riêng. 
Mô hình A 
Mô hình này ghép hai pha CULL/DRAW thành một nhiệm vụ kép được miêu tả theo 
sơ đồ như hình 17 dưới đây. 
Hình 17: Ba pha hiển thị đồ họa thời gian thực theo mô hình A 
Mô hình này giả thiết một khung hình được thực hiện theo thứ tự, và dùng một luồng 
cho nhiệm vụ kép CULL/DRAW. Thời gian mỗi tiến trình B và C được thực hiện 
theo sơ đồ hình 18. Pha Pre – Cull cập nhật dữ liệu động trong đồ thị khung cảnh. Dữ 
liệu động này bao gồm vị trí camera, định vị những đối tượng chuyển động bên trong 
cảnh, số khung hình thời gian trôi qua, và đồng bộ những phương tiện quản lý dữ liệu 
khác. Dữ liệu này được giả thiết là dữ liệu toàn cục, được cấp phát và có thể lấy được 
bởi ứng dụng. Như vậy, pha CULL phải đợi cho đến khi Pre – CULL kết thúc tiến 
trình. Khi pha Pre – Cull thực hiện xong sẽ báo hiệu cho pha CULL thực hiện. CULL 
sẽ đọc dữ liệu động đã được cập nhật, và sinh dữ liệu để hiển thị, dữ liệu này mang 
tính cục bộ không cho ứng dụng tiếp cận nhưng có thể lấy được từ pha DRAW. Dữ 
liệu này được xử lý và phân ra từng kỳ. Pha DRAW sẽ duyệt qua danh sách và hiển 
thị cảnh đồ họa. 
 Hình 18. Sơ đồ miêu tả quan hệ dữ liệu giữa các pha ở mô hình A 
Mô hình B 
Mô hình này tách riêng những luồng riêng biệt cho hai pha CULL / DRAW như hình 
19 
Hình 19: Ba pha hiển thị đồ họa thời gian thực theo mô hình B 
Dữ liệu cho mô hình này được mô tả theo sơ đồ hình 20 sau đây. 
Hình 20. Sơ đồ miêu tả quan hệ dữ liệu giữa các pha ở mô hình B 
Sơ đồ này khác với sơ đồ của mô hình A là dùng một luồng cho nhiệm vụ kép 
CULL/DRAW . Ở đây pha DRAW sẽ không duyệt dữ liệu được cung cấp bởi pha 
CULL một cách trực tiếp mà sẽ qua hai bộ đệm. Dữ liệu phát sinh từ pha CULL sẽ 
được ghi vào bộ đệm Buffer 0 trong khi pha vẽ sẽ đọc dữ liệu từ bộ đệm Buffer 1. 
Khi đồng bộ giữa hai pha CULL và DRAW những con trỏ chỉ tới những bộ đệm sẽ 
được trao đổi. Cách tiếp cận này yêu cầu khi phân cảnh ở pha CULL cần có hai bộ 
đệm cục bộ, và phải bổ sung việc đồng bộ giữa hai pha CULL và DRAW. 
11.4. Ứng dụng thư viện OpenSG trong xây dựng sản phẩm mô phỏng 
Hiện nay có nhiều thư viện đồ họa 3D đã tích hợp các thuật toán xử lý song song 
cảnh đồ họa 3D thời gian thực cho phép xây dựng các sản phẩm mô phỏng với dữ 
liệu lớn. Nổi bật hơn cả đó là thư viện OpenSG www.opensg.org. OpenSG là một hệ 
thống thư viện nguồn mở ( LGPL) cho phép sử dụng tự do. Nó chạy được trên IRIX, 
Windows và Linux dựa trên OpenGL. 
Yêu cầu sức mạnh tính toán trong một ứng dụng là gần như vô hạn - hoặc yêu cầu lập 
trình tính toán chuyên ngành hoặc yêu cầu chất lượng cao hiển thị dữ liệu. Để làm 
được điều đó cần phải có sức mạnh của một siêu máy tính hoặc một nhóm máy cùng 
xử lý theo cơ chế song song. Nhưng siêu máy tính đắt tiền hơn nhiều lần. Việc dùng 
nhiều máy tính theo cơ chế song song càng ngày càng được quan tâm trong xây 
dựng các sản phẩm. 
Dưới đây là mô hình ứng dụng 3 máy theo cơ chế song song. 
Hình 21 – Mô hình 3 máy tính theo có chế xử lý song song hiển thị 2 màn hình 
Trong sơ đồ này cần ba máy: Máy trạm chạy ứng dụng thực hiện hai pha APP và 
CULL (cập nhật dữ liệu, điều khiển tương tác người máy, thực hiện tính toán mô 
phỏng chuyên ngành.). Hai máy chủ chỉ thực hiện pha DRAW nghĩa là chỉ hiển thị 
cảnh thông qua hai camera khác nhau mô phỏng hai mắt của con nguời . Với thư viện 
OpenSG ta có thể thực hiện xử lý song song trên 48 máy. 
Hình 22. Một cảnh trả lại trong hai cửa sổ độc lập 
Hình ảnh này cho thấy ba những cửa sổ: một nhỏ chỉ cho sự tương tác mô phỏng (sự 
chuyển động chuột hay bàn phím). Cả hai cửa sổ khác nhau hiển thị một cảnh như thể 
là được hiển thị trong một cửa sổ. Để làm được điều này cần hai chương trình khác 
nhau ( Client & Server). Giới đây là toàn bộ chương trình được rút gọn. 
Chương trình chạy trên máy trạm 
// all needed include files 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
OSG_USING_NAMESPACE 
using namespace std; 
SimpleSceneManager *mgr; 
NodePtr scene; 
int setupGLUT( int *argc, char *argv[] ); 
int main(int argc, char **argv) 
{ 
#if OSG_MINOR_VERSION > 2 
 ChangeList::setReadWriteDefault(); 
#endif 
 osgInit(argc,argv); 
 int winid = setupGLUT(&argc, argv); 
 //this time we'll have not a GLUTWindow here, but this one 
 MultiDisplayWindowPtr multiWindow = MultiDisplayWindow::create(); 
 //set some necessary values 
 beginEditCP(multiWindow); 
 // we connect via multicast 
 multiWindow->setConnectionType("Multicast"); 
 // we want two rendering servers... 
 multiWindow->getServers().push_back("Server1"); 
 multiWindow->getServers().push_back("Server2"); 
 endEditCP(multiWindow); 
 //any scene here 
 scene = makeTorus(.5, 2, 16, 16); 
 // and the ssm as always 
 mgr = new SimpleSceneManager; 
 mgr->setWindow(multiWindow); 
 mgr->setRoot (scene); 
 mgr->showAll(); 
 multiWindow->init(); 
 glutMainLoop(); 
 return 0; 
} 
void display(void) 
{ 
 //redrawing as usual 
 mgr->redraw(); 
 //the changelist should be cleared - else things 
 //could be copied multiple times 
 OSG::Thread::getCurrentChangeList()->clearAll(); 
 // to ensure a black navigation window 
 glClear(GL_COLOR_BUFFER_BIT); 
 glutSwapBuffers(); 
} 
void reshape(int w, int h) 
{ 
 glutPostRedisplay(); 
} 
void mouse(int button, int state, int x, int y) 
{ 
 if (state) 
 mgr->mouseButtonRelease(button, x, y); 
 else 
 mgr->mouseButtonPress(button, x, y); 
 glutPostRedisplay(); 
} 
void motion(int x, int y) 
{ 
 mgr->mouseMove(x, y); 
 glutPostRedisplay(); 
} 
int setupGLUT(int *argc, char *argv[]) 
{ 
 glutInit(argc, argv); 
 glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE); 
 int winid = glutCreateWindow("OpenSG"); 
 glutReshapeFunc(reshape); 
 glutDisplayFunc(display); 
 glutMouseFunc(mouse); 
 glutMotionFunc(motion); 
 return winid; 
} 
Chương trình chạy trên máy chủ 
#include 
#include 
#include 
#include 
#include 
OSG_USING_NAMESPACE 
using namespace std; 
GLUTWindowPtr window; 
RenderAction *ract; 
ClusterServer *server; 
void display(); 
void reshape( int width, int height ); 
int main(int argc,char **argv) 
{ 
 int winid; 
 // initialize Glut 
 glutInit(&argc, argv); 
 glutInitDisplayMode( GLUT_RGB |GLUT_DEPTH | GLUT_DOUBLE); 
 if (!argv[1]){ 
 cout << "No name was given!" << endl; 
 return -1; 
 } 
 // init OpenSG 
#if OSG_MINOR_VERSION > 2 
 ChangeList::setReadWriteDefault(); 
#endif 
 osgInit(argc, argv); 
 winid = glutCreateWindow(argv[1]); 
 glutDisplayFunc(display); 
 glutIdleFunc(display); 
 glutReshapeFunc(reshape); 
 glutSetCursor(GLUT_CURSOR_NONE); 
 ract=RenderAction::create(); 
 window = GLUTWindow::create(); 
 window->setId(winid); 
 window->init(); 
 //create a new server that will be connected via multicast 
 //argv[1] is the name of the server (at least it should be...) 
 server = new ClusterServer(window,argv[1],"Multicast",""); 
 server->start(); 
 glutMainLoop(); 
 return 0; 
} 
void display() 
{ 
 //simply execute the render action 
 server->render(ract); 
 //and delete the change list 
 OSG::Thread::getCurrentChangeList()->clearAll(); 
} 
void reshape( int width, int height ) 
{ 
 window->resize( width, height ); 
} 
12. Môt số kết quả nghiên cứu 
Sử dụng kỹ thuật thời gian thực trong đồ họa và ứng dựng thư viene OpenSG, chúng 
tôi đã xây dựng thành công mô hình song song, đa màn hình hiển thị trên nhiều máy. 
Số khung hình đạt 60 fps bảo đảm việc tương tác qua lại của người dùng, đáp ứng 
được yêu cầu đạt ra của các thiết bị tập lái (Hiện được ứng dụng trong sản phẩm hệ 
thống tập lái xe BMP-1 do TTCN Mô phỏng thực hiện cảnh 3D được hiển thị như ở 
hình 23) 
 13. Kết luận 
Với cách tiếp cận trong bài báo chúng ta có thể sử dụng lợi thế của phần cứng hiện 
nay để xây dựng mô hình đa nhiệm, song song, đa luồng và đa màn hình hiển thị 
trong đồ họa. Mô hình nêu ra ứng dụng tốt trong các sản phẩm đồ họa yêu cầu có dữ 
liệu lớn và đòi hỏi tương tác thời gian thực. 
Tuy vậy, việc hoàn thiện mô hình cần đầu tư thêm nhiều thời gian và công sức, tập 
hợp được lực lượng đông đảo các giáo viên cùng tham gia nhất là đội ngũ chuyên gia 
chuyên ngành. Trong tương lai cần hoàn thiện thêm chức năng: 
Hình 23. Cảnh 3 chiều trong hệ thống tập lái xe BMP-1 
• Quản lý hỗ trợ các thiết bị thực tại ảo (Bao gồm bàn phím, chuột và 
joistick, Trackball). 
14. Tài liệu tham khảo 
[1]. Open Scenegraph, (Robert Osfield) 2004. www.openscenegraph.org 
[2]. Open SG, (Dirk Reiners) 2000. www.opensg.org 
[3]. Silicon Graphics Inc. SGI OpenGL Optimizer Whitepaper. 
 1998. 
[4]. Net Juggler Guide, (Allard, J. et al)  2001 
[5]. MPI: The Complete Reference, (Snir, M. et al) MIT Press, 1996 
[6]. osgVRPN:  
[7]. VRPN:  
[8]. OpenThread:  2004. 
[9]. Open Producer :  2004 

File đính kèm:

  • pdfhe_thong_thoi_gian_thuc_va_ung_dung_trong_ky_thuat_mo_phong.pdf