web進入3d時代的時間并不長，web在3d領域的發展卻十分迅速。web 3d技術已經在房地產房型展示、博物館藝術品或文物展示、電商平臺的商品展示領域獲得廣泛應用。然而web 3d技術在仿真領域的應用卻比較鮮見。

目前而言，3d仿真還是PC軟件的天下，大部分仿真軟件都會使用UE4或unity3d這樣的重量級引擎，我司用的OGRE也是一款重量級引擎。以OGRE為例，其誕生于2000年左右，最后更新截至于2012年，ROS系軟件RVIZ和gazebo都是使用OGRE開發。當初我司選用OGRE作為開發引擎，主要是因為希望能和C++無縫結合，開源，能夠在ubuntu下運行，畢竟大部分人工智能算法投入生產后都是使用C++。

但是，基于一年的開發使用經驗，OGRE的缺陷正在逐漸暴露出來，這是一個常年不更新的框架，一個與最新技術水平脫鉤六年的框架，技術理念十分陳舊，資料也很匱乏。比如繪制凹凸的多邊形，沒有現成的類型可以使用，三角化算法沒有集成，網上又很難找到案例。3D文字的繪制官方本身沒有提供api，非官方提供的代碼運行效率卻又不佳。對3d對象的幾何數據、空間節點和材質的管理是各自獨立的，靈活性太高，方便性不足。單例、智能指針和普通指針混用，缺乏統一的風格。我把較多的時間花在彌補這些缺陷上，不能專心于仿真本身的設計。鑒于此，我向公司多次提出使用新的三維引擎，但是沒有引起足夠的重視。由于模擬器已經深度集成OGRE，重新使用新的三維引擎必然是傷筋動骨的，積重難返成為使用新技術的主要障礙。

傳統意義上，使用C++代表著運行效率高，但是通過使用OGRE發現，C++運行效率高還有一個前提，就是寫C++的人的水平也要高，指導怎么充分利用計算資源，并能設計出簡單有效的框架。在我們小組內，我能設計出簡單有效的框架，有人掌握豐富的C++技巧，但是沒人知道怎么和底層緊密結合，所以我們的C++并沒有高的運行效率，反而有時候運行很慢。所以如果做不到和底層緊密結合，還不如把這些工作交給開發三維引擎的人，因為他們花了大量的時間在研究這個。

基于我之前使用qml開發3d可視化軟件和標注工具的經驗，我萌生了一個想法，3d使用web開發仿真界面也未必不可行，如果公司在短時間內不能采用新的三維引擎，那么我可以先自行嘗試一下使用web3d技術。

qml是什么？qml是qt公司力推的新UI框架qtquick的主要開發語言。qtquick是從web借鑒而來，qml則是從js衍生而來。其大體的原理是使用qml像html、css那樣設計界面，像nodejs那樣用C++作為和系統交互的語言，本質上與electron類似。我之前的工作中，因為喜歡新技術，threejs上手比較快，用qml嵌套canvas3d，集成了threejs構建3d場景，開發了一款實時顯示的可視化的軟件。盡管也存在運行效率的問題，但是已經顛覆我對腳本語言的看法。腳本語言不僅可以開發大型的實時軟件，并且擁有更高的開發效率，在沒有軟硬件通吃的3d開發人員的情況下，使用腳本語言開發3d軟件也是一個不錯的選擇。

在我司，我承接了3d標注工具的開發。最開始，3d標注工具是打算用OGRE開發，而且網上那個已有案例。當時需求催的比較緊，本來是打算把已有的3d代碼打包成比較通用的庫之后，再開發，后來評估發現這樣還不如重新寫一個，因為當時的3d代碼的通用性實在是太差了。于是我提出我曾經用threejs快速開發過3d軟件，我可以再次使用threejs開發一個全新的標注工具。這樣我花了一個月時間，用qml和threejs把他們要的3d標注工具開發了出來。這么開發還有一個好處，就是當標注人員越來越多的時候，標注工具需要web化，本來標準工具就是用threejs寫的話，web化起來比較容易。

幾個月過去后，我司成立了標注公司，標注需要大量的人，標注工具也需要web化了。于是之前的代碼再次派上了用場。基于之前我使用過vue和element-ui，這次web化的時候我再次使用這兩個框架。web開發和qml開發有所不同，web開發沒有編譯過程，調試可以在瀏覽器內完成，谷歌瀏覽器提供了強大的開發工具，能夠所改即所見，dom組件對應代碼，相比qt提供的工具來說方便了不少。而且直接使用web開發后，可以使用threejs的最新版本，功能沒有限制，可以直接使用一些配套腳本，并且渲染效率有所提高。

本來我是想，所有功能都在前端完成，如果可能的話。但是我在開發過程中我發現了一個問題，就是前端無法獲取本地的文件目錄，這個只能在后端完成，后端使用什么語言，什么框架又成了一個問題。因為之前用過java和C++寫過簡單的服務器，所以我知道java過于重量級，而C++沒有什么好的服務器框架。我想能不能使用websocket，因為websocket可以從后端主動發數據給前端，讓前端實時顯示，在數據播放的時候也可以做一些標注工作。于是我找到了websocketd，一個簡單易用，并且支持多種的腳本的軟件。這個軟件本身就是一個可執行程序，可以通過命令行運行，參數設置為要執行的腳本即可，實在是比一個有一大堆需要學習的api的成熟框架要好用的多。而且這個時候我僅僅是需要用后端獲取一下本地目錄，這是一個很簡單的需求。我已經學會了python，知道怎么用glob獲取目錄，所以python是后臺腳本的第一選擇。

我花大概一個月的時間將原有的qt開發的標注工具轉化成了web軟件，相比原版，web版的點云加載和點選速度更快，操作更簡便，界面更現代化。其中點云加載和點選速度更快是我沒有料想到的。因為qt不支持js讀取文件所以原來是用C庫加載的，而且我還因為大點云點選速度較慢對點云做了分割處理，就這樣加載速度還不及后來直接用前端的js加載速度快，點選速度也不及后來沒有分割的速度。需要指出的是，雖然后來的web版中我沒有寫算法分割，但是可能在使用的新版threejs的點云算法中已經做了分割。qt允許集成的threejs版本是74，而最新的threejs已經進化到了99，這之間的25個版本點云算法可能已經有了巨大的提升。至于加載速度，我有測過，加載時間主要在調用C庫api的階段，而后數據發到qml耗時并不長。而js加載點云是直接讀文件，不存在語言之間的數據傳遞。所以js加載速度快本來就是情有可原的，并且可能在加載算法上還要優于我使用的C庫。

講了這么多，還是在web 3d上，和仿真沒有產生關系，我前面提到websocket通信支持后端對前端主動發數據，那么只要網絡夠好，延遲夠低，那么web也可以實現實時刷新。比如我們有一輛車在前端顯示，那么后端不斷的發送新的位姿數據，前端的車輛就會動起來。鑒于我正在開發車輛的動力學模型，正需要一個3d的顯示界面，之前使用模擬器作為可視化工具時，把大量的時間花在怎么修改模擬器上，反而沒多少時間調試模型，所以我使用之前標注工具的代碼，將其改造成一個實時仿真工具。

這時候再用websocketd就不行了，因為websocketd不支持python腳本引用非標準庫，就是使用numpy還行，使用pytorch這樣的第三方庫就不行了，所以有必要再找一個再復雜一點的框架。于是我開始搜索python的web框架，基本上就三個，DJango、Tornado和Flask。DJango是一個重型框架，Flask是一個微內核框架，而Tornado介于兩者之間。在比較websocket方面的支持力度上，似乎只有Tornado是原生支持的，畢竟Tornado宣稱的優點就是適應長連接。

對于仿真而言，最有趣的地方在于能夠看到一個事物朝著自己預想的方向發展，如果沒有可以通過各種方法找出問題所在。如果模型正確，還可以預測出未來的發展方向。對于我來說，我現在有一個python寫的車輛模型，有一個顯示車輛位姿的界面，如果在界面上加上一些輸入控制參數的控件，那么可以在界面上實時觀察到控制參數對車輛位姿的影響。由于python有ros的全套api，在后臺接受ros消息驅動車輛行走也是可能的。

有了3d顯示界面，還需要仿真控制按鈕，開始、暫停、重置、是否加載神經網絡模型，這些和simulink類似。我還需要曲線來顯示車速和加速度，這也和simulink類似。在顯示曲線上，我也頭疼了一番，比較了echart，chartjs，這兩個都是開源庫，echart是國產的，百度出品，而chartjs是github上的開源庫，相較而言，我更喜歡chartjs的國際范，chartjs社區相當活躍，有更多人使用的產品，其問題肯定更少。chartjs雖然沒有專門的實時更新的例子，但是實現實時更新只是一句話的是，就是把dataset改了。

chartjs解決了而為曲線的顯示問題，但是我在開發神經網絡模型的時候需要顯示3d的散點圖，我最開始使用的是matplotlib，卡的一筆，而且沒有交互功能，查詢點的數據要自己寫事件響應的代碼，太麻煩，所以我在同事的推薦下使用plotly，結果沒賬號不能用，后來注冊了賬號還是不能用，我直接放棄了。接著我使用了一個開源的免費的競品bokeh，同樣是用python控制數據，前端顯示數據，但是是生成一個離線網頁，2d散點圖用的很好，當我覺得就是你的時候，才知道這家伙不支持3d，后來想想也是web里2d和3d是兩套不同的技術。絕望中我又想起了pytorch有一套自己的可視化工具visdom。

visdom和plotly和bokeh一樣都是基于web的可視化框架。不同在于visdom是開源免費的，自帶服務器程序，并且支持3d。其實visdom也是使用plotly的，估計付了費。但是visdom的用戶不用付費。他的3d的api設計也十分人性化，可以直接渲染矩陣，2d和3d公用同一個散點圖api，函數內部會自動判斷矩陣的維數。visdom可以在一個頁面內同事顯示多個子窗口，布局管理是自動的，這個也為數據監控提供了極大方便，我可以拿visdom的默認界面作為我的仿真軟件的數據監控界面。也就是說chartjs也可以不用了，直接在python后臺發送數據就行。

大概總結一下，我所面臨的問題是如何快速開發有3d顯示界面的車輛動力學仿真軟件。我的解決方案是使用web 3d+websocket+python。

python模型-tornado=>data via websocket=>threejs/chartjs

仿真的模型是用pytorch構建，車輛的運動學公式加上pytorch從數據中學習而來的表格構成了整個模型，然后tornado的定時事件中定時調用模型的步進函數，可以完全不依賴ros就能跑。

由于目前算法的調試還比較粗糙，仿真往往還只是邏輯驗證的過程，發現算法中的流程或邏輯錯誤，還不能支持調參的需要。其中主要的問題是仿真和實際的差距還比較大。例如車輛的剎車距離和實際不一致，這個問題主要是因為車輛的實際加速度并不是控制指令發過來的加速度，這兩者之間不是直接的等于關系，VCU在接受控制指令中的加速度和其他車輛狀態信號后，會根據某種算法換算成變速器檔位和油門或剎車信號等，這種算法對我們來說是黑盒的。這種情況下用傳統的動力學公式建模并不是那么容易的事。所以我考慮到了使用機器學習方法，從數據中習得模型。

總結

以上是生活随笔為你收集整理的wpf开发仿真3d软件_web 3d 与仿真的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。