目前的3D引擎的渲染幀和邏輯幀都是在一個(gè)線程上運(yùn)行的，在網(wǎng)絡(luò)游戲中大量玩家聚集，繁重的骨骼動(dòng)畫(huà)計(jì)算和粒子計(jì)算極大的拖累了渲染幀數(shù)，有兩種有效措施：1、控制同屏顯示人數(shù)，但玩家體驗(yàn)不好 2、幀數(shù)低于某值時(shí)減少動(dòng)畫(huà)Tick頻率，但帶來(lái)的問(wèn)題是動(dòng)畫(huà)不連貫。
        如果考慮使用多線程優(yōu)化，最容易想到的就是采用平行分解模式，將骨骼動(dòng)畫(huà)計(jì)算和粒子計(jì)算寫(xiě)成兩個(gè)for循環(huán)，然后用OpenMP將其多線程化，但事實(shí)上這樣并不會(huì)提高多少效率，這兩者計(jì)算仍然要阻滯渲染幀，線程的創(chuàng)建也有一定的消耗。于是我想到了一種極端的解決方案，采用任務(wù)分解模式，將渲染和邏輯完全分離到兩個(gè)線程去，互不影響，當(dāng)然這樣線程同步會(huì)是大問(wèn)題，畢竟線程的數(shù)量和BUG的數(shù)量是成正比的。
        我們首先來(lái)分析下這兩個(gè)線程分別需要做什么工作，需要那些數(shù)據(jù)。渲染線程需要獲取實(shí)體的位置、材質(zhì)等信息，并交給GPU渲染，邏輯線程需要更新實(shí)體的位置、材質(zhì)、骨骼動(dòng)畫(huà)等數(shù)據(jù)，很顯然一個(gè)寫(xiě)入一個(gè)讀取，這為我們實(shí)現(xiàn)一個(gè)沒(méi)有線程同步的多線程3D渲染系統(tǒng)提供了可能。
        為了讓讀取和寫(xiě)入不需要Lock，我們需要為每一份數(shù)據(jù)設(shè)計(jì)一個(gè)帶有冗余緩存的結(jié)構(gòu)，讀取線程讀取的是上次寫(xiě)入完成的副本，而寫(xiě)入線程則向新的副本寫(xiě)入數(shù)據(jù)，并在完成后置上最新標(biāo)記，置標(biāo)記的操作為原子操作即可。以Vector為例，這個(gè)結(jié)構(gòu)大致是這樣的：
        當(dāng)然我們可以用模板來(lái)寫(xiě)這個(gè)結(jié)構(gòu)，讓其適用于int，float，matrix等多種數(shù)據(jù)類(lèi)型，余下的工作就簡(jiǎn)單了，將所有有共享數(shù)據(jù)的類(lèi)的成員變量都定義為以上這種數(shù)據(jù)類(lèi)型，例如我們可以定義：
        SharedData<Matrix4f>  m_matWorld;
        在渲染線程中調(diào)用pDevice->SetWorldMatrix( m_matWorld.Read() );
        在邏輯線程中調(diào)用m_matWorld.Write( matNewWorld );

        需要注意的是，這種方案并非絕對(duì)健壯，當(dāng)渲染線程極慢且邏輯線程極快的情況下，有可能寫(xiě)入了超過(guò)了DATACENTER_CACHE次，而讀取卻尚未完成，那么數(shù)據(jù)就亂套了，當(dāng)然真要出現(xiàn)了這種情況，游戲早已經(jīng)是沒(méi)法玩了，我測(cè)試的結(jié)果是渲染幀小于1幀，邏輯幀大于10000幀，尚未出現(xiàn)問(wèn)題。
        FlagshipEngine采用了這一設(shè)想，實(shí)際Demo測(cè)試結(jié)果是，計(jì)算25個(gè)角色的骨骼動(dòng)畫(huà)，從靜止到開(kāi)始奔跑，單線程的情況下，幀數(shù)下降了20%～30%，而使用多線程的情況下，幀數(shù)完全沒(méi)有變化！