亚洲香蕉成人av网站在线观看_欧美精品成人91久久久久久久_久久久久久久久久久亚洲_热久久视久久精品18亚洲精品_国产精自产拍久久久久久_亚洲色图国产精品_91精品国产网站_中文字幕欧美日韩精品_国产精品久久久久久亚洲调教_国产精品久久一区_性夜试看影院91社区_97在线观看视频国产_68精品久久久久久欧美_欧美精品在线观看_国产精品一区二区久久精品_欧美老女人bb

首頁 > 開發 > JavaScript > 正文

淺談three.js中的needsUpdate的應用

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

復制代碼代碼如下:
var canvas = document.createElement('canvas');
var _gl = canvas.getContext('experimental-webgl');
var vertices = [];
for(var i = 0; i 1000*3; i++){
vertices.push(i * Math.random() );
}
var buffer = _gl.createBuffer();
console.profile('buffer_test');
bindBuffer();
console.profileEnd('buffer_test');
function bindBuffer(){
for(var i = 0; i 1000; i++){
_gl.bindBuffer(_gl.ARRAY_BUFFER, buffer);
_gl.bufferData(_gl.ARRAY_BUFFER, new Float32Array(vertices), _gl.STATIC_DRAW);
}
}

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

復制代碼代碼如下:
var canvas = document.createElement('canvas');
var _gl = canvas.getContext('experimental-webgl');
var texture = _gl.createTexture();
var img = new Image;
img.onload = function(){
console.profile('texture test');
bindTexture();
console.profileEnd('texture test');
}
img.src = 'test_tex.jpg';
function bindTexture(){
_gl.bindTexture(_gl.TEXTURE_2D, texture);
_gl.texImage2D(_gl.TEXTURE_2D, 0, _gl.RGBA, _gl.RGBA, _gl.UNSIGNED_BYTE, img);
}

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

復制代碼代碼如下:
"#define MAX_DIR_LIGHTS " + parameters.maxDirLights,
"#define MAX_POINT_LIGHTS " + parameters.maxPointLights,
"#define MAX_SPOT_LIGHTS " + parameters.maxSpotLights,
"#define MAX_HEMI_LIGHTS " + parameters.maxHemiLights,

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

復制代碼代碼如下:
parameters.map ? "#define USE_MAP" : "",
parameters.envMap ? "#define USE_ENVMAP" : "",
parameters.lightMap ? "#define USE_LIGHTMAP" : "",
parameters.bumpMap ? "#define USE_BUMPMAP" : "",
parameters.normalMap ? "#define USE_NORMALMAP" : "",
parameters.specularMap ? "#define USE_SPECULARMAP" : "",

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

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
亚洲香蕉成人av网站在线观看_欧美精品成人91久久久久久久_久久久久久久久久久亚洲_热久久视久久精品18亚洲精品_国产精自产拍久久久久久_亚洲色图国产精品_91精品国产网站_中文字幕欧美日韩精品_国产精品久久久久久亚洲调教_国产精品久久一区_性夜试看影院91社区_97在线观看视频国产_68精品久久久久久欧美_欧美精品在线观看_国产精品一区二区久久精品_欧美老女人bb
欧美亚洲国产日韩2020| 国产精品久久久久久久久久免费| 大荫蒂欧美视频另类xxxx| xvideos亚洲人网站| 欧美大码xxxx| 国产91色在线|| 欧洲精品在线视频| 欧美另类交人妖| 91精品国产色综合久久不卡98| 成人国产精品久久久| 日韩精品在线观| 亚洲国产欧美一区二区丝袜黑人| 亚洲影视中文字幕| 亚洲在线免费观看| 91亚洲一区精品| 亚洲aaaaaa| 最近2019好看的中文字幕免费| 裸体女人亚洲精品一区| 久久国产精品视频| 欧美日韩亚洲91| 欧美贵妇videos办公室| 国产在线精品一区免费香蕉| 91免费人成网站在线观看18| 色偷偷av亚洲男人的天堂| 国产精品久久久久久久久粉嫩av| 亚洲丝袜一区在线| 亚洲人在线观看| 国产精品久久久久久久久久免费| 日韩av电影在线免费播放| 日韩在线视频二区| 欧美性xxxx| 九九久久国产精品| 亚洲永久在线观看| 欧美日韩午夜剧场| 91av免费观看91av精品在线| 国产免费成人av| 精品欧美aⅴ在线网站| 亚洲国产精品免费| 久久久久久久成人| 精品亚洲一区二区三区在线观看| 久久久精品一区二区| 欧美人与性动交a欧美精品| 都市激情亚洲色图| 久久777国产线看观看精品| 庆余年2免费日韩剧观看大牛| 国产精品美女主播| 国产亚洲欧美另类中文| 国产欧美精品在线| 91久久久久久久久久久久久| 午夜伦理精品一区| 亚洲人成伊人成综合网久久久| 亚洲性日韩精品一区二区| 亚洲色图第三页| 久久久久久久国产| 日韩乱码在线视频| 亚洲欧美在线x视频| 亚洲综合自拍一区| 成人国产精品久久久| 97久久超碰福利国产精品…| 久久99精品国产99久久6尤物| 主播福利视频一区| 国产精品pans私拍| 久久好看免费视频| 俺也去精品视频在线观看| 国产精品视频99| www.日韩欧美| 久久99久久99精品中文字幕| 亚洲精品久久久久久久久久久| 91av在线影院| 97激碰免费视频| 成人激情电影一区二区| 欧美激情亚洲一区| 成人黄色av网| 黄色成人在线播放| 国产啪精品视频| 欧美精品久久久久| 亚洲男人的天堂在线播放| 久久久精品2019中文字幕神马| 久久久久久久久久久亚洲| 亚洲国产精品悠悠久久琪琪| 国产精品国模在线| 97色伦亚洲国产| 欧美性猛交xxxx黑人猛交| 亚洲图片欧美午夜| 久久精品亚洲94久久精品| 亚洲美女动态图120秒| 国产在线精品一区免费香蕉| 日韩经典一区二区三区| 国产精品男人的天堂| 久久免费视频在线| 亚洲人成伊人成综合网久久久| 国产精品jvid在线观看蜜臀| 久久精品国产电影| 欧美一区二区色| 久久久久久一区二区三区| 国产精品久久久久久久久久ktv| 欧美日韩免费区域视频在线观看| 欧美视频在线视频| 日韩av在线网页| 亚洲精品久久久久久久久久久久| 色婷婷综合久久久久| 97精品国产97久久久久久| 久热精品视频在线观看一区| 亚洲精品丝袜日韩| 欧美裸体xxxx| 亚洲一区中文字幕| 5566成人精品视频免费| 成人黄色午夜影院| 国产精品激情av电影在线观看| 久久精品国产96久久久香蕉| 日韩一区二区三区在线播放| 国产美女久久精品| 亚洲人午夜色婷婷| 国产丝袜高跟一区| 久久久噜久噜久久综合| 性欧美xxxx视频在线观看| 欧美中文在线视频| 久久香蕉国产线看观看av| 国产欧美精品va在线观看| 欧美亚洲第一页| 97超视频免费观看| 日韩精品视频中文在线观看| 欧美理论在线观看| 亚洲天堂免费视频| 97在线视频免费播放| 欧美高清在线观看| 久久久久久高潮国产精品视| 亚洲天堂免费观看| 久久久久久久香蕉网| 97久久伊人激情网| 91精品在线观| 亚洲国产精品99| 亚洲国产一区自拍| 亚洲va国产va天堂va久久| 国产精品久久久久久久app| 国产精品久久久久久亚洲调教| 亚洲一区二区在线| 欧美三级免费观看| 日韩一区视频在线| 久久精品人人做人人爽| 久久久久久久久久久亚洲| 国产精品户外野外| 国产精品自拍偷拍视频| 亚洲免费影视第一页| 国内外成人免费激情在线视频网站| 奇米四色中文综合久久| 日韩av电影中文字幕| 黄色一区二区在线| 亚洲国产精品一区二区久| 欧美成人精品在线视频| 亚洲欧美国产日韩中文字幕| 久久久久久久一区二区| 国产精品高精视频免费| 国产日产久久高清欧美一区| 精品少妇一区二区30p| 欧美午夜精品伦理| 欧美一区三区三区高中清蜜桃| 欧美不卡视频一区发布| 91精品视频网站| 欧美精品久久久久久久久| 大桥未久av一区二区三区| 国产精品欧美日韩一区二区| 日韩av手机在线| 国产精品小说在线|