淺談three.js中的needsUpdate的應(yīng)用_HTML5教程

推薦：基于HTML5超酷攝像頭（HTML5 webcam）拍照功能實現(xiàn)代碼
基于HTML5實現(xiàn)的超酷攝像頭（HTML5 webcam）拍照功能,需要了解的朋友可以參考下

three.js里的很多對象都有一個needsUpdate屬性，文檔中很少有寫（不過three.js的文檔本來就沒多少，很多問題還得靠github上的issues），網(wǎng)上各式各樣的教程中也不太會寫這個，因為對于簡單的入門程序而言，是用不到這個屬性的。
那么這個屬性到底是用來干嘛的，一言以敝之就是告訴renderer這一幀我該更新緩存了，盡管作為一個標志位用途很簡單，但是因為要知道為什么要更新緩存，要更新哪些緩存，所以還是有必要好好了解下的。
為什么需要needsUpdate
首先還是來看下為什么需要緩存，緩存的存在一般都是為了減少數(shù)據(jù)傳輸?shù)拇螖?shù)，從而減少程序在數(shù)據(jù)傳輸上消耗的時間，這里也是，一般一個物體(Mesh)要最后能夠成功顯示到屏幕前是很不容易的，需要轉(zhuǎn)三次戰(zhàn)場
首先是通過程序?qū)⑺�有的頂點數(shù)據(jù)和紋理數(shù)據(jù)從本地磁盤讀取到內(nèi)存當中。
然后程序在內(nèi)存中做了適當?shù)奶幚碇�后就要將那些需要繪制到屏幕前的物體的頂點數(shù)據(jù)和紋理數(shù)據(jù)傳輸?shù)斤@存當中。
最后在每一幀渲染的時候?qū)�顯存中的頂點數(shù)據(jù)和紋理數(shù)據(jù)flush到GPU中進行裝配，繪制。
根據(jù)那個金字塔式的數(shù)據(jù)傳輸模型，第一步顯然是最慢的，如果是在WebGL這樣的環(huán)境中通過網(wǎng)絡(luò)來傳輸，那就更加慢了，其次是從內(nèi)存?zhèn)鬏數(shù)斤@存的時間，這個后面會做一個簡單的數(shù)據(jù)測試。
然后是這三步操作的使用頻率，對于小場景來說，第一步是一次性的，就是每次初始化程序的時候就會將一個場景的所有數(shù)據(jù)都加載到內(nèi)存中了，對于大場景來說，可能會做一些異步加載，但是目前暫時不在我們考慮的問題當中。 對于第二步的頻率，應(yīng)該是這次要講的最主要的，首先寫個簡單的程序測試一下做這一步傳輸所帶來的消耗


先簡單解釋下這個程序，vertices是一個保存頂點的數(shù)組，這里是隨機生成了1000個頂點，因為每個頂點都有x,y,z三個坐標，所以需要一個3000大小的數(shù)組， _gl.createBuffer命令在顯存中開辟了一塊用來存放頂點數(shù)據(jù)的緩存，然后使用_gl.bufferData將生成的頂點數(shù)據(jù)從內(nèi)存?zhèn)鬏斠环輈opy到顯存中。 這里假設(shè)了一個場景中有1000個1000個頂點的物體，每個頂點是3個32位4個字節(jié)的float數(shù)據(jù)，計算一下就是差不多1000 x 1000 x 12 = 11M的數(shù)據(jù)，profile一下差不多消耗了15ms的時間，這里可能看看15ms才這么點時間，但是對于一個實時的程序來說，如果要保證30fps的幀率，每一幀所需要的時間要控制在30ms左右，僅僅是做一次數(shù)據(jù)的傳輸就花去了一半的時間怎么成，要知道大頭應(yīng)該是GPU中的繪制操作和在CPU中的各種各樣的處理啊，應(yīng)該吝嗇整個渲染過程中的每一步操作。
所以應(yīng)該盡量減少這一步的傳輸次數(shù)，其實可以做到剛加載的時候就把所有的頂點數(shù)據(jù)和紋理數(shù)據(jù)從內(nèi)存一并傳輸?shù)斤@存當中，這就是現(xiàn)在three.js做的，第一次就把需要繪制的物體(Geometry)的頂點數(shù)據(jù)傳輸?shù)斤@存中，并且緩存這個buffer到geometry.__webglVertexBuffer，之后每次繪制的時候都會判斷Geometry的verticesNeedUpdate屬性，如果不需要更新就直接使用現(xiàn)在的緩存,如果看到verticesNeedUpate為true, 就會重新將Geometry中的頂點數(shù)據(jù)傳輸?shù)絞eometry.__webglVertexBuffer中，一般對于靜態(tài)物體我們是不需要這一步操作的，但是如果遇到頂點會頻繁改變的物體，例如用頂點來做粒子的粒子系統(tǒng)，還有使用了骨骼動畫的Mesh, 這些物體每一幀都會改變自己的頂點，所以需要每一幀都需要將其verticesNeedUpdate屬性設(shè)為true來告訴renderer我需要重新傳輸數(shù)據(jù)了！
其實在WebGL程序中，更多的會在vertex shader中去改變頂點的位置來完成粒子效果和骨骼動畫，盡管如果放在cpu端計算更容易擴展，但是因為javascript的計算能力的限制，更多的還是會把這些計算量大的操作放到gpu端操作。 這種情況下并不需要重新傳輸一次頂點數(shù)據(jù)，所以上面那種case在實際程序中其實用到的不多，更多的還是會去更新紋理和材質(zhì)的緩存。
上面那個case主要描述的是一個傳輸頂點數(shù)據(jù)的場景，除了頂點數(shù)據(jù)，還有一個大頭就是紋理，一張1024*1024大小的R8G8B8A8格式的紋理所要占用的內(nèi)存大小也要高達4M，于是看下面這個例子


這里就不需要變態(tài)的重復(fù)1000次了，一次傳輸10241024的紋理就已經(jīng)花了30ms，一張256256的差不多是2ms，所以three.js中對于紋理也是盡量只在最開始的時候傳輸一次，之后如果texture.needsUpdate屬性不手動設(shè)為true的話就會一直直接使用已經(jīng)傳輸?shù)斤@存中的紋理。
需要更新哪些緩存
上面通過兩個case描述了為什么three.js要加這么一個needsUpdate屬性，接下來列舉一下幾個場景來知道在什么情況下需要手動的更新這些緩存。
紋理的異步加載
這算是一個小坑吧，因為前端的圖片是異步加載的，如果在創(chuàng)建好img后直接寫texture.needsUpdate=true的話，three.js的renderer中會這一幀中就使用_gl.texImage2D將空的紋理數(shù)據(jù)傳輸?shù)斤@存中，然后就將這個標志位設(shè)成false, 之后真正等到圖片加載完成的時候確不再更新顯存數(shù)據(jù)了，所以必須要在onload事件中等整張圖片加載完成后再寫texture.needsUpdate = true
視頻紋理
大部分紋理都是像上面那個case直接加載和傳輸一次圖片就行了，但是對于視頻紋理來說并不是，因為視頻是一個圖片流，每一幀要顯示的畫面都不一樣，所以每一幀都需要將needsUpdate設(shè)為true來更新顯卡中的紋理數(shù)據(jù)。
使用render buffer
render buffer是比較特殊的對象，一般的程序在整個場景繪制出來后都是直接flush到屏幕了，但是如果多了post processing或這screen based xxx(例如screen based ambient occlusion)的話，就需要將場景先繪制到一個render buffer上，這個buffer其實就是一張紋理，只不過是上一步繪制生成的，而不是從磁盤加載的。three.js中有一個專門的texture對象WebGLRenderTarget來初始化和保存renderbuffer, 這種紋理也需要在每一幀設(shè)置一下needsUpdate為true
Material的needsUpdate
材質(zhì)在three.js中是通過THREE.Material來描述的，其實材質(zhì)并沒有什么數(shù)據(jù)要傳輸，但是為什么還要搞一個needsUpdate呢，這里還要說一下shader這個東西，shader直譯過來是著色器，提供了在gpu中編程處理頂點和像素的可能性，在繪畫中有個shading的術(shù)語來表示繪畫的明暗法，GPU中的shading也類似，通過程序計算光照的明暗來表現(xiàn)物體的材質(zhì)，ok, 既然shader是一段跑在GPU上的程序，那么像所有程序一樣都需要進行一次編譯鏈接的操作， WebGL中是在運行時對shader程序進行編譯的，這當然需要消耗時間，因此也是最好能夠一次編譯就運行到程序結(jié)束。所以three.js中就在material初始化的時候就編譯鏈接了shader程序并且緩存了編譯鏈接后得到的program對象。一般一個material是不需要再去重新編譯整個shader了，材質(zhì)的調(diào)整只需要修改shader的uniform參數(shù)就行了。但是如果是替換了整個材質(zhì)，比如將原來phong的shader替換成了一個lambert的shader，就需要將material.needsUpdate設(shè)置成true去重新做一次編譯。不過這種情況不多見，更常見的是下面提到的一種情況。
添加和刪除燈光
這個應(yīng)該還是在場景中比較常見了的吧，可能很多剛開始用three.js的人都會掉進這個坑里，在給場景動態(tài)添加了一個燈光后發(fā)現(xiàn)這個燈光怎么不起作用，不過這是在用three.js內(nèi)置的shader的情況下，例如phong, lambert，看renderer里的源代碼就會發(fā)現(xiàn)three.js在內(nèi)置的shader代碼中使用#define來設(shè)置場景中燈光的個數(shù)，而這個#define的值是在每次更新材質(zhì)的時候通過字符串拼接shader得到，代碼如下


確實這種寫法能夠有效的減少了gpu寄存器的使用，如果只有一盞燈光就可以只聲明一個一盞燈光所需要的uniform變量，但是在每次燈光數(shù)量改變，特別是添加的時候就需要重新拼接編譯鏈接一次shader，這時候也需要將所有材質(zhì)的material.needsUpdate設(shè)為true;
改變紋理
這里的改變紋理指的并不是更新紋理數(shù)據(jù)，而是原來材質(zhì)使用了紋理，后來不使用了，或者原來材質(zhì)不使用紋理后來又加上去了，如果不手動強制更新材質(zhì)都會導(dǎo)致最后出來的效果跟自己想的不一樣，產(chǎn)生這種問題的原因跟上面添加燈光差不多，也是因為shader中加了一個宏來判斷是否使用了紋理，


所以每次map, 或者envMap或者lightMap等改變真值的時候都需要更新材質(zhì)
其它頂點數(shù)據(jù)的改變
其實上面紋理的改變還會產(chǎn)生一個問題，主要是在初始化的時候沒有紋理，但是后來動態(tài)添加上去這種環(huán)境下，光是將material.needsUpdate設(shè)為true還不夠，還需要將geometry.uvsNeedsUpdate設(shè)成true, 為什么會有這種問題呢，還是因為three.js對程序的優(yōu)化，在renderer中第一次初始化geometry, material的時候，如果判斷為沒有紋理，盡管內(nèi)存中的數(shù)據(jù)中有每個頂點uv數(shù)據(jù)，但 three.js 還是不會將這些數(shù)據(jù)copy到顯存中，初衷應(yīng)該還是為了節(jié)省點寶貴的顯存空間，但是在添加紋理后geometry并不會很智能的重新去傳輸這些uv數(shù)據(jù)以供紋理使用，必須要我們手動的將設(shè)置uvsNeedsUpdate來告知它該更新uv了, 這個問題真是開始的時候坑了我很長時間。
關(guān)于幾種頂點數(shù)據(jù)的needUpdate屬性可以看這條issue
https://github.com/mrdoob/three.js/wiki/Updates
最后
three.js的優(yōu)化做的是不錯，但是在各種優(yōu)化下帶來的是各種可能踩到的坑，這種情況最好的辦法也只能是看源代碼了，或者去github上提issues

分享：html5-websocket基于遠程方法調(diào)用的數(shù)據(jù)交互實現(xiàn)
一般在傳統(tǒng)網(wǎng)頁中注冊用戶信息都是通過post或ajax提交到頁面處理,到了HTML5后我們有另一種方法就是通過websocket進行數(shù)據(jù)交互,接下來將詳細介紹,需要了解的朋友可以參考下