整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
<from></form>標簽對用來創建一個表單，即定義表單的開始和結束位置，<form>標簽具有下面等屬性。
屬性：size、value、maxlength、readonly、disabled
屬性：checked
如何在列表中實現取消選項
屬性：cols、rows
屬性：for、accesskey
久前我們寫了關于浮動屬性的文章。 所以, 現在是一個很好的時間來解釋clear的屬性。
clear的屬性與浮點屬性直接相關。 它指定元素是否應該在浮動元素的旁邊, 或者它是否應該移動到它們的下方。 此屬性既適用于浮動元素, 也適用于非浮動元素。
如果一個元素能夠適應浮動元素旁邊的水平空間, 它將會適合; 除非您將 clear 屬性應用于與浮體相同的方向。 然后元素會移動到浮動元素的下方。
在 CSS 中創建的每個元素都需要添加優質設計。
clear的屬性可以有以下值:
none——元素沒有被移動到清除過去的浮動
left-元素被移動到清除過去的左側浮動
right-元素被移動到清除過去的右浮標
Both-這個元素都向下移動以清除左右浮動
在咨詢了 Can i Use 服務后, 我們發現支持率超過了87% 。
HTML：
css：
在這里我們可以看到已經浮動的 div: left 應用到他們。 在我們清楚地表明: 在文本段落左邊, 它移動到浮動元素之下。
HTML：
CSS：
接下來, 我們會看到兩個具有 float 的 div: 右屬性和帶有 clear: right 屬性的段落。 通過設置這個, 段落會移動到浮動元素的下方。
現在是為文本添加一些格式的好時機。
HTML：
CSS：
最后, 最后一個示例顯示 clear 的使用: 兩個屬性。 這兩個占卜者分別左右浮動, 而該段具有添加到其中的clear屬性。 通過這個, 它會移動到浮動元素的下面。 值得一提的是, 這是最常用的清除屬性。
希望這篇文章能對你的項目有所幫助。當使用這個屬性時要小心, 過去已經引起了許多混亂。但是, 我們確信讀完這篇文章之后, 你可以愉快地編碼！
本文中，我們將重點關注用于優化 Babylon.js 港口場景的優化和架構技術。
我們的場景總共有超過 600 個網格和 1,000,000 個頂點。 在我們的 2018 Macbook Pro 上的 Google Chrome 中，它始終以 45+ FPS 的速度運行。 我們發現 Firefox 的幀速率約為 40 FPS，Safari 的幀速率要低得多，但仍可用，為 25 FPS，主要是因為它不支持 WebGL 2.0。
推薦：用 NSDT設計器 快速搭建可編程3D場景。
這里討論的優化技術確實涵蓋了 Babylon.js，但也側重于改進我們使用的底層模型、材質和照明的方法，這對性能有巨大影響。 我們所有的模型都是使用 Blender 構建的，因此，此處包含的示例通常引用 Blender 解決方案，但也可以使用任何其他 3D 計算機圖形軟件。
注意：還有比這里描述的更多的優化技術，有些可能不適用于你自己的環境（例如，我們的一些技術要求我們的模型在場景中是靜態的）。 有關推薦技術的更多列表，請查看 Babylon 自己關于此主題的文章。
為場景設計資源時需要進行權衡。 以我們的港口為例。
五月花號數字體驗中使用的 3D“港口”模型的鳥瞰圖
我們可以在單個 .blend 文件中對整個場景進行建模，并通過單個 .gltf 文件將其傳輸到 Babylon。 或者，我們可以在獨立的 .gltf 文件中設計每個建筑物、船只、樹木和巖石，然后在 Babylon.js 腳本中導入和定位資產。
更少的模型和網格意味著 Babylon 渲染循環的循環次數更少。 在 3D 軟件中安排場景也更容易，并且可以由不熟練的 JavaScript 程序員的團隊成員來完成。 但是，如果你有一個特別大的模型，加載時間可能會很長（就上下文而言，我們的最終 .glb 文件為 8MB）。
或者，我們可以在自己的 .gltf 文件中構建單獨的資產（建筑物、樹木等），然后導入這些文件并使用 JavaScript 來定位它們。 與自己的 3D 軟件相比，這對于設計布局和空間來說不太實用，但由于可以并行加載模型，因此可以縮短加載時間。 它還可以輕松利用 Babylon 自己的實例功能，從而進一步優化樹木的放置等。
在 MAS 數字體驗中，我們選擇了混合方案。 大多數情況下，我們在 Babylon.js 之外即 Blender 中構建的資產。 我們發現讓非開發人員編輯場景的自由非常有用，不容犧牲。 我們對加載時間感到滿意，因為體驗總是預先加載介紹性動畫，因此在后臺進行的場景加載不太明顯。 此外，我們知道我們希望在 Blender 中對場景進行高質量渲染。 在那里構建完整的場景意味著靜態渲染可以完美地反映基于瀏覽器的世界。
為了實現優化，我們需要在整個開發過程中意識到我們的表現。 雖然 Babylon.js 有自己出色的調試檢查器，但我們發現在開發中有用的最簡單的資源是創建我們自己的 FPS 計數器，該計數器始終留在角落里。 Babylon 引擎可以揭示其價值。
MAS 港口場景視圖，顯示左上角的小型定制 FPS 計數器
當我們向場景中添加新資源時，當我們做一些有損性能的事情時，情況就變得非常明顯。 此外，當有意識地優化我們的場景時，這提供了一個非常易于閱讀的改進指標。
不過，執行此操作時請務必與你的場景進行交互。 當相機靜止時，場景以 60 FPS 運行，并不意味著它會保持這種狀態。 四處走動，點擊東西，做你的用戶會做的事情！
如果你正在努力找出性能影響發生的地方，我們在檢查器中發現了這些非常有用的 Babylon 功能，它們可以幫助你：
在Babylon.js的檢查器中，我們可以選擇更改渲染模式。 可以通過在場景代碼中包含以下行來查看檢查器：
scene.debugLayer.show()從現在顯示的菜單中，單擊左側“場景資源管理器”中的“場景”對象。 在右側的“渲染模式”下，你可以在“點”、“線框”和“實體”之間切換。 我們發現的這些替代視圖給出了非常清晰的多邊形密度圖像。
Babylon.js 的檢查器視圖的屏幕截圖，其中可以在“點”、“線框”和“實體”渲染模式之間切換
在本例中，我們可以看到，該圖像中心的建筑物（代表 IBM 的運營決策管理器）的優化效果仍然不佳，因為考慮到它包含多少條邊以及因此包含的多邊形。
檢查器的另一個最有用的功能是能夠打開/關閉場景中的每個網格。 這提供了一種非常簡單的方法來監控特定資源對場景性能的影響，這可能與多邊形計數無關。
關于如何執行此操作，有兩種選擇：
在 Blender 中，我們發現將對象組的父級設置為單個空創建的變換節點。 這些在這里特別有用，因為當導入到 Babylon 時，可以打開/關閉每個節點的“isEnabled”選項，從而一次點擊所有子節點，從而使尋找潛在的性能改進變得更加容易。 Blender 集合在導出到 gltf 時丟失。
啟用全場景后，我們達到了 48 FPS。
關閉產品構建后，獲得了 1 FPS 的增益
當在與產品相關的建筑物的檢查器中關閉“isEnabled”選項時，對 FPS 的影響很小 - 現在為 49 FPS。
關閉填充建筑物可提高 11 FPS，最高可達 59 FPS
不過，當關閉“填充”建筑物時，我們注意到顯著的改進，幀速率躍升至 59/60 FPS。 顯然，這些網格是我們需要集中注意力并進一步優化的地方。
我們應該遵循一些標準的良好實踐，這些實踐適用于任何實時渲染的場景，無論是 Babylon.js 還是基于瀏覽器。
最簡單的衡量指標是多邊形數量。 渲染 4 個頂點比渲染 4,000,000 個頂點要快得多。 在可能的情況下，巧妙地處理你的模型，只在重要的地方添加細節。 如果你的相機拉得太遠以至于你永遠看不到它，那么在角色模型上雕刻高清臉部就沒有意義了。
Ian Hubert 的 1 分鐘“懶惰”Blender 教程是一個很好的例子，說明即使使用超低多邊形網格也可以獲得多少“細節”。 為 4k 渲染和高預算電影構建高清模型固然很棒，但如果你希望構建基于瀏覽器的體驗，則需要靈活選擇模型在何處以及如何呈現細節。
巖石模型重新拓撲的“之前和之后”視圖，取自 SketchFab 的 3D 掃描資產重新拓撲指南
如果你有一個高多邊形模型并希望對其進行優化，那么重新拓撲就是你的朋友。 這可能是一個乏味的過程，但性能的改進是顯著的。
如果你的建筑物具有門窗等細節，那么你還可以烘焙法線貼圖以提供細節外觀，而不會減少頂點數。 法線貼圖在不犧牲多邊形計數的情況下添加高細節方面特別有效。
左：應用了法線貼圖的模型； 中間：沒有法線貼圖的基礎網格； 右：法線貼圖
值得注意的是，.gltf 網格具有三角面，因此當你將模型移動到 Babylon 時看到“面數”大幅增加時，請不要感到驚訝。 如果可能，請在導入之前對面進行三角測量，以確保您可以控制多邊形和面數。
如上所述，渲染 4 個頂點比渲染 4,000,000 個頂點要快。 我們可以“欺騙”渲染器，讓其認為我們使用的頂點較少的一種方法是通過實例化。 這減少了 Babylon 在每次渲染中必須執行的繪制調用總數。
在我們完成的港口場景中，我們有 631 個活動網格，以及 73 個繪制調用。 如果沒有實例化，我們預計會出現 631 次繪制調用，并且在我們的示例中渲染速度會慢 5-10 倍。
實例化：Blender 中單個建筑物的突出顯示實例
實例是使用硬件加速渲染繪制大量相同網格的絕佳方法（讓我們想象一下森林或軍隊）。 這可以在你選擇的 3D 軟件中完成（我們使用 Blender，可以使用鏈接的副本來實現），也可以直接在 Babylon.js中用JavaScript完成（如果你的場景適合從內部定位對象的用例） 。
在場景中多次實例化和重復使用同一模型的一個負面后果是，通常很明顯你已經一遍又一遍地沖洗和重復相同的網格。
在這里，我們分享了 Blender 中的一些渲染示例，展示了如何利用實例化，同時保持模型的規模感和可變性。
左：16 個頂點（帶實例）； 16k 個頂點（無）— 中間：48 個頂點（有）； 48k 個頂點（無）— 右：228 個頂點（有）； 228k（無）
在我們的第一張圖片中，我們有一個建筑物實例化了 1,000 次。 在第二次渲染中，我們使用建筑物的 3 種材質變體，將其平均分配到 1,000 個實例中。 最后，在第三張圖像中，我們修改建筑物，使其不對稱，并引入繞垂直軸的隨機旋轉。 這些微小的變化帶來了變化感，同時保持了優化的幾何形狀。
使用 Babylon 時，文件通常使用 .gltf 格式導入。 但你可能會注意到，當你的模型加載到 Babylon 中時，它已將你的模型拆分為多個單獨的對象。
這發生在逐個材質的基礎上，意味著在渲染循環中，Babylon 每次都會循環遍歷每個新創建的對象，而不僅僅是單個原始網格 - 昂貴！
這里的理想解決方案是使用盡可能少的材質，雖然你可能希望每個對象都具有漂亮的 4K 紋理和 PBR 材質，但如果能夠并且它符合你想要的美感，可以使用調色板 。
左：從 IBM Carbon Palette 創建的多樣化調色板。 右：我們用于港口場景的調色板，其中包括漸變段
使用調色板，你可以為所有對象定義單一材質。 將該材質的基礎/反照率顏色設置為調色板紋理，并確保模型的 UV 面與你想要的顏色一致。
為此，在 3D 軟件中，UV 展開對象，將對象的 UV 縮放至零，然后將 UV 移動到與你希望該面的顏色相匹配的彩色方塊中。 如果你使用 Blender，Imphenzia 在他的 10 分鐘 Blender 挑戰中經常這樣做，他在這里詳細介紹了這項技術。
每個調色板只需為 3x3 像素（9 種不同顏色）或 8x8 像素（64 種顏色）。 你還可以選擇更大的調色板，這樣你也可以選擇將漸變添加到調色板中。 我們在五月花號體驗中將這種技術用于港口的調色板，如上所示。
如前所述，Babylon 的文檔包含豐富的解決內存使用和性能問題的方法。 我們發現兩個特別有用的資源是：
具體來說，我們在適當的場景和網格導入中使用了以下方法：
如果在你的場景中，不需要直接與 3D 網格交互，那么禁用鼠標事件我們發現非常有效。
scene.pointerMovePredicate = () => false;
scene.pointerDownPredicate = () => false;
scene.pointerUpPredicate = () => false;我們在《Harbor》和《Challenge 3》場景中使用了這種方法。 鑒于我們需要檢測用戶點擊環境對象（巖石、浮標和船只），我們無法在《Challenge 1》 中使用此功能。
所有頂點緩沖區都在 CPU 內存上保留其數據的副本，以支持碰撞、拾取、幾何編輯或物理。 如果不需要使用這些功能，可以調用此函數來釋放相關內存：
scene.clearCachedVertexData();如果你的網格體不會改變位置、旋轉或大小，那么通過調用以下命令“凍結”網格體會非常有效：
mesh.freezeWorldMatrix();即使它們確實發生了變化，但是是間歇性的，那么你可以通過調用以下命令重新打開世界矩陣計算：
mesh.unfreezeWorldMatrix();如果不要求用戶單擊或選取網格體，則可以在導入網格體時添加以下行以進一步增強性能：
mesh.isPickable = false;
mesh.doNotSyncBoundingInfo = true;在我們的項目完成后，我們實際上發現了使用 BabylonJS 和 VueJS 的一個陷阱。 雖然我們對這里的 FPS/性能非常滿意，但事實證明，我們通過將 BabylonJS 引擎和場景綁定為 VueJS 中的反應變量而導致了巨大的 FPS 赤字。
我不會在這里討論太多細節，但在這篇論壇帖子中對此進行了非常詳細的介紹。
原文鏈接：http://www.bimant.com/blog/babylonjs-large-scale-scene-optimization/
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
