㈠ UE4動不動就編譯shader，能改嗎
嵌入是可以的，但每次還是要重新編譯的。CG是角本，只能在執行才能被編譯。
MS提供了這個函數。你可以先把你的CG角本加到資源管理器中。然後用名稱引用到你的程序中。詳細你看下這個函數的文檔吧。D3DXCompileShaderFromResource（）；
㈡ 虛幻4引擎編譯版怎麼樣
虛幻4是一個新的游戲引擎，用這個引擎做出來的游戲畫面要比虛幻3好，不過這個也要看公司，給騰訊虛幻10他也做不過EA用虛幻3做出來的孤島危機。
㈢ ue4正在編譯著色器是什麼意思
這是因為UE不太支持中文輸出。在UE里配置的Java編譯命令，編譯後再UE輸出窗口輸出的內容，直接用CMD窗口編譯能夠輸出中文的編譯信息。《虛幻4引擎》簡稱ue4是由Epic Games公司推出的一款游戲開發引擎，相比其他引擎，虛幻引擎不僅高效、全能，還能直接預覽開發效果，賦予了開發商更強的能力。虛幻引擎4在大約2分半的Demo演示中，將其強大的功能發揮得淋漓盡致。與之相關的游戲有《連線》《絕地求生：刺激戰場》等等。
㈣ ue4 的開發和發型有什麼區別
總體來看，VR游戲開發的核心引擎是U3D與UE4，這兩款游戲開發引擎工具基本撐起了VR游戲製作的一片天。兩者各有千秋，Unity適合小團隊製作，甚至是獨立製作，主要趨向是手游，目前Unity仍然是手游市場佔有率最高的引擎，超過九成的Gear VR游戲都採用了Unity引擎開發。而UE4更加適合大團隊大製作，主要趨向於PC平台。下面是兩者的優劣勢對比：
Unity的優勢：
輕量級，安裝、調試和打包方便
配置VR項目十分簡單
學習成本低，文檔完善
開發成本低
UI系統
在PS4上調試方便，有批處理文件可以一鍵運行
Asset Store
提供了一些VR下的Demo作為參考
Unity的劣勢：
內建工具不夠完善
渲染差，光照系統糟糕，陰影bake有bug，只能勉強達到2A游戲入門水平
對於控制器支持較差，一些如手柄震動、VR控制器空間定位的功能引擎未集成，需要第三方插件或額外代碼
沒有材質編輯器，需要第三方插件
Prefab不支持繼承
沒有內建的Level Stream支持
Unreal的優勢：
畫面效果完全達到3A游戲水準
光照和物理渲染即便在縮水的狀況下也足以秒殺Unity
藍圖系統，從此策劃不用再寫代碼
強大的材質編輯器
各種官方插件齊全
對於手柄、VR控制器支持良好
提供各種游戲模版，用來做原型配合Blueprint甚至比Unity更快
Unreal的劣勢：
C++
如果要開發PS4游戲需要重新編譯引擎，12核伺服器，24線程編譯大概需要20-30分鍾
如果需要重新編譯引擎，光拉代碼就需要至少一個小時
創建新項目大概又要編譯十多分鍾
如果切換平台，要編譯幾千到上萬個shader
PS4部署不方便，打包編譯同樣非常久
學習成本高，各子模塊功能強大但操作復雜
部分功能沒有任何文檔，已有功能的文檔同樣不夠完善，不如Unity
開發成本高，某國內3A團隊做了個10分鍾的VR Demo，據說已經燒了一千多萬
UI設計器非常之難用
VR下的一些best practice同樣缺乏文檔和例子
㈤ 虛幻4引擎mac版打包ios，出現這個編譯錯誤，到底是為什麼用引擎默認的藍圖也同樣報錯。
虛擬引擎一直以高畫質、華麗的光影等為人稱道，大家一直都在期待虛幻4引擎打造的華麗大作。可是，萬萬沒想到首款由虛幻4引擎製作的手游竟然是這樣一款「渣作」。 近日，《無盡之劍》和虛幻引擎的打造者Epic
㈥ ue4配置多少才不閃退
16G內存。
可能是讀shader編譯後生成的文件出的問題，刪除文件夾，重啟啟動編輯器，編輯器啟動成功後會重新編譯Shader，在重新編譯Shader這個過程，如果編輯器崩潰，就重新啟動編輯器會繼續之前得編譯，重復這個過程直到編譯完成，會出現崩潰的原因，我的理解是內存不足，我用的16G內存的機子，編譯時內存幾乎快用滿。
UE4區域網聯機測試找不到Server端，並且通過OpenID（主機ID）閃退解決辦法，打開Window控制台，跳轉到UE4編輯器安裝目錄，輸入UE4編輯器名稱（帶exe後綴）要打開的測試項目完整路徑（帶項目工程後綴uproject）「game」，打開並運行項目工程，按鍵打開UE4控制台，並輸入「open+要連接主機的IP」即可連接成功進行測試。
㈦ 虛幻4引擎怎麼安裝！急！！！
UE4 也就是虛幻4，那不是安裝的，是需要進行編譯，如果不會去貼吧，搜虛幻4或者是UE4下面都有，去找。
給你推薦一個 http://tieba..com/p/2940701632復制去Google翻譯翻譯結果
㈧ 為什麼unreal4免費開源後，在國內沒有火起來
這個問題可從幾個方面來看：
免費：不是真正的免費，而是盈利達到一定程度的比例分成，越是大的公司對這一點越不能容忍。
開源：整個unreal引擎非常巨大，不論是抄襲，還是修改，都需要巨大的學習付出，而且產出小，投入和付出不成正比。
新功能的藍圖和以前的腳本語言編寫習慣不一樣，大多數程序員是排斥的，意味著他們需要學習新的腳本語言
藍圖還取代了shader，牛逼的shader開發人員不會喜歡這種即時編譯shader，因為藍圖shader的編譯感覺上很慢
以3D為主打的unreal4功能高大全，國內短平快的項目用起來成本高，游戲公司支持的大型端游一般有自己的引擎
本來unity佔領的市場份額就高，unreal4也沒有積極的搶占市場（廣告宣傳）
沒有市場的unreal4沒有教程（完整的實戰教程，啟動器學習上的教程一般是例子，沒辦法拿來培訓），惡性循環
最後一點，unreal4有自己的啟動器，下載引擎需要登錄，登錄經常被牆，下載經常被牆
emmmm~
一不小心發現很久以前的回答，才疏學淺真的慚愧。就幾個答案的問題修正一下。
2.開源：感覺ue4現在在向全方面發展，所以系統多，學習曲線陡，開源不代表彩筆能看懂，emmmm，看懂了層次看不懂命名，看懂命名看不懂實現，看懂了實現看不懂設計的原理。
3.感覺因為藍圖太方便了，所以C++的文檔都不好好維護了（只有declaration沒有description）
4.這個是我孤陋寡聞了，現在VFX業界都是節點式編輯材質了，甚至更進一步houdini全節點流，真的香。
6.單從國內手游看貌似unity占優，再往大了看，ue4根本不是游戲引擎，而是實時3D項目的組裝器，各種目瞪口呆。
7.有教程，但是由於ue4實在太大，全面的教程講不深，單個的教程很零散，強大的教程多油管，方便的藍圖和國內unity開發習慣有相當的區別。地形系統很牛逼嗯，物理很牛逼嗯，API很牛逼嗯。。。。。額，玩了三個月是不是該找工作了
㈨ 這個配置玩虛幻引擎4編譯著色器很慢，怎麼辦
這個過程主要是跑CPU. 你cpu並行能力不足原因，實時渲染才是跑顯卡
㈩ 虛幻4怎麼延遲改變材質
首先在看這個系列之前，你需要具備以下：
（1）至少要敲過簡單的渲染器，不管是拿dx敲還是拿gl敲或者vk之類的。
（2）對虛幻引擎有一定了解，對虛幻的渲染有一定了解。可以看我前幾篇文章，或許可以有所幫助。
（3）C++基礎。其實本人c++水平也是一般般（常常受到公司程序大牛的鄙視，不過我是美術）。
（4）至少一塊RTX顯卡可以用來做實時光線追蹤（2019年）
隨著引擎版本的更新，後續會逐步加入新版本。那麼下面就正式開始吧！
【概覽虛幻4渲染管線】
首先，虛幻有很多個管線的。Mobile管線和Deferred管線。首先找到
在這個函數里你將會看到很多熟悉的函數名稱
虛幻就是通過調用這些函數來一步步繪制的。是不是很眼熟？這個就是各大論壇啦，博客啦講的虛幻渲染流程的真面目。
下面就是官方的DrawOrder了。那麼這個順序是怎麼來的呢。就是上面那個函數的調用順序。
再打開這個Render函數，你就將看到延遲渲染一幀所調用的各個函數。（反正我看了半天就看到個大概的渲染順序之外，還是啥也不知道）
那麼當我們把一個模型托到場景里，這個模型被渲染出來的整個流程到底是什麼樣的呢？這個流程其實是非常龐大的。下面我就來一個一個拆分。
（1）第一步：資源准備階段。這個階段包括頂點緩沖區的准備，索引緩沖區的准備。這一步由場景代理管理完成。當然從磁碟里讀取模型資源這些就涉及到StaticMesh這些了。想了解這一步可以去看我以前的博客，或者直接去看UPrimitiveComponent，UMeshComponent，UStaticMeshComponent，UCableComponent，UCustomMeshComponent。當你把這些源碼全部研究一遍後，這個階段算是了解了。這個階段我不打算再描述了，因為已經有了很多現成的代碼了。
（2）第二步就是shader資源的准備了，這個又是一個非常大的話題了。可以去看我以前關於給改材質編輯器和加shadingmode的文章便可以有個大概的了解。這一步我還會進一步闡述。
（3）第三步就是繪制了。
我們先不看Render函數那些復雜的調用，我們把精力先集中到shader層面來。一張畫面是怎麼開始繪制的呢？
通過這個我們便能知道一個大概的繪制流程（千萬別以為虛幻只有這幾步，不過主要的大概的流程是這樣）。先繪制那些深度啊，初始化視口啦我們先不管。我們來看下這個BasePass。這個BasePass乾的事情就是把GBuffer畫出來。
這里就是像素著色器的入口。繪制完這一步後，我們就有了GBuffer然後再繪制剩下的。環境遮罩驟就先不說了。來看看最重要的光照部分。
光照部分的入口在這里：
虛幻的TiledDeferredLighting的渲染方式。不知道這個的去看毛星雲的RTR3的博客的光照那節，講得特別好。這里給個傳送門：
https://blog.csdn.net/poem_qianmo/article/details/77142101
這里會調用
GetDynamicLighting這個函數會調用
這里會接著調用
看到這里就很熟悉了，看過前面我修改shadingmode的博客應該會對這里很熟悉。
lighting繪制完了之後就會繪制一些反射啊之類的東西了，然後就是透明物體啊後期啊。這些後面會慢慢分析他們。我們先把兩個最重量級的研究了。
接下來我們研究一下fog渲染階段。找到FogRendering.cpp你就會發現，其實繪制fog的是一個globalshader。前面繪制各個物體的是materialshader。
你會發現繪制fog的是一個globalshader。虛幻一共有這么幾種shader：Globalshader materialshader和meshshader。
這篇博客只是一個概述性和引導性的。只是說明一下虛幻繪制的一個大概情況。下一卷我將演示一下怎麼自己寫個shader，引擎識別它，編譯它，然後如何cpu和gpu進行信息交流的
4.20的Unreal渲染模塊有了較大改動。
主要是為了配合引擎新增特性和性能優化。不過大體上的流程還是和上個版本的保持一致。
為了給LTC讓道，所以shader做了大面積重構。
ShadingModel改為了IntergrateBxDF
下面會對繪制流水線詳細寫一遍，由於量巨大所以我會慢慢更新。
（1）【InitView】
引擎代碼注釋寫得非常簡單：Initialize scene's views.Check visibility, build visible mesh commands, etc.
這是渲染管線的開始，這步是為渲染管線准備繪制當前幀所需要各種資源。後面的管線就是判斷一下畫不畫，綁定一下狀態和RT然後就畫畫畫就好了。這一階段做的事情非常多也非常雜。首先來看看一些主要的
ComputeVisibility
可見性剔除有很多種技術，引擎會使用多種方法進行組合剔除，把沒必要渲染的東西剔除干凈，最大限度在渲染之前就做到最省。
虛幻提供了幾種剔除方法
他們各有優劣，可以根據不同平台和情況進行選擇。
VisibilityMap
在後面會把視口中可見性屬性是非可見的物體剔除掉。
PrecomputedVisibilit
在場景中可以使用預烘焙的可見性數據。
如果當前視口場景中有可見性烘焙數據就會啟用可見性烘焙的剔除方式
ViewFrustomCulled
做完前面的步驟後，還會進行視錐體剔除，並且大部分情況下，視口會使用視錐體剔除
進行視錐體剔除後可以減少大部分沒必要繪制的圖元
這時再配合各種其它的剔除方法就可以進一步剔除
而這里的「其它的剔除方法」包括但不限於PrecomputedVisibility，Distance，DynamicOcclusion
DistanceOcclusion
不在距離范圍內就不繪制，非常簡單有效的繪制方式。這種剔除方式挺適合地面上擺的小物件，擺的一些decal或者小道具，對大型建築不適合。
Hardware Occlusion Queries
硬體的可見性剔除。這種方法將每幀的可見性檢查作為每個Actor的查詢發出。 Actor的可見度在一幀之後被回讀 - 如果相機移動得非常快，有時會產生不利影響，導致它們「彈出」。 硬體遮擋的成本隨著在GPU上執行的查詢的數量而變化。 使用距離和預計算可見性方法可以減少GPU每幀執行的查詢次數。
在各種剔除後，在InitView的最後會根據這些數據建立MeshPass
（2）【EarlyZ-PrePass】
EarlyZ由硬體實現，我們的渲染管線只需要按照硬體要求渲染就可以使用earlyz優化了，具體步驟如下：
（1）首先UE4會把場景中所有的Opaque和Mask的材質做一遍Pre-Pass，只寫深度不寫顏色，這樣可以做到快速寫入，先渲染Opaque再渲染Mask的物體，渲染Mask的時候開啟Clip。
（2）做完Pre-pass之後，這個時候把深度測試改為Equal，關閉寫深度渲染Opaque物體。然後再渲染Mask物體，同樣是關閉深度寫，深度測試改為Equal，但是這個時候是不開啟clip的，因為pre-pass已經把深度寫入，這個時候只需要把Equal的像素寫入就可以了。
關於EarlyZ的具體詳解可以去看參考文章【1】
首先渲染prepass的第一步肯定是渲染資源的准備啦。primitive資源會在InitView的時候准備好。
然後會再BeginRenderingPrePass函數中設置各種繪制管線的綁定，包括關閉顏色寫入，綁定Render target
然後再調用draw之前會把各種UniformBuffer和渲染狀態設置好
然後調用draw
最後完成PrePass的繪制
（3）【ShadowDepthPass】
根據不同的燈光類型會繪制不同種類的shadowmap。總的來說繪制shadowmap的時候不會使用遮擋剔除。
Unreal渲染shadowmap目前我就找到個視錐剔除
shadowdepthpass可能是在basepass之前，也可以是之後，具體看EarlyZ的方式
我們的燈光種類繁多大致可以分為兩類，一類使用2Dshadowmap的，一類使用Cubemapshadowmap的
上圖的1部分就是渲染2DshadowMap，2部分渲染的就是Cubemapshadowmap，這一步只是渲染出shadowmap供後面的Lightingpass使用。
（4）【BasePass】
BasePass使用了MRT技術一次性渲染出GBuffer。
再上一次GBuffer的數據分布
BasePass把GBuffer渲染出來之後就可以供後面的LightingPass使用了。我們的材質編輯器再Surface模式下也是在生成MaterialShader為BasePass服務
這部分可以去看看我的材質編輯器篇有詳細介紹。
也是通過一系列設置綁定渲染狀態資源等，最後調用dispatchdraw
可以注意到，MRT0是SceneColor而不是BaseColor
Scene在BasePass中做了簡單的漫反射計算
這一步用到了，這個測試場景我是烘焙過的，我把烘焙數據去掉，SceneColor其實是這樣的：
啥也沒有黑的
BasePass會在這個階段把預烘焙的IndirectLiting計算到SceneColor這張RT上供後面的pass使用
（5）【CustomDepthPass】
上面的圖渲染了一個球的customdepth（在紅圈處可以看到一個球，可能不是很明顯哈）。CustomDepth沒啥特別的，就是把需要繪制CustomDepth的物體的深度再繪制一遍到CustomDepthBuffer上。
（6）PreLightingPass
虛幻封裝了一套方便畫PostPass的機制，後面的繪制SSAO，Lighting，SSR，Bloom等各種pass都是用的這逃Context的機制。
PreLighting這步主要是在用前面的GBuffer算decals和SSAO為後面的Lighting做准備。
SSAO使用的是FPostProcessBasePassAOPS這個C++shader類。
對應的USF是PostProcessAmbientOcclusion
並且使用Computeshader來加速計算。
（7）【DirectLightPass】
LightPass也非常復雜，整個pass的代碼有幾千行，shader代碼也有幾千行非常恐怖的系統。我們先找到入口函數：
（1）方向光
根據不同的情況，使用不同的渲染策略
渲染不同情況下的燈光大體分類如下。還會根據不同的渲染方式分類。
比如一般的方向光：
在渲染方向光的時候因為不需要考慮分塊，所以直接把每盞燈挨個畫出來就可以了
下面我只放了一盞方向光
下面我放三盞方向光：
（2）TileDeferredLighting
如果燈光不渲染陰影，並且燈光沒用IES並且燈光數目達到80盞以上（4.22）並且啟用了TileDeferred管線，那麼虛幻4就會使用TileDeferredLight來計算光照，虛幻實現TileDeferrdLight使用的是一個Computeshader
有很多燈光使用的潛規則。
（8）【ScreenSpaceReflectionPass】
（9）【TranslucencyPass】
透明物體會放在最後渲染，但是在後期的前面。需要看是否在DOF(景深)後合並。
對於這個上圖的那個場景來說，透明物體渲染的buffer是長下面這樣的：
最後在後期中組合
如果沒有啟用r.ParallelTranslucency透明物體只能挨個渲染。
如果啟用了就可以走上面的並行渲染分支。
透明物體的渲染在實時渲染中一直比較迷，會有各種問題。比如排序等等。在默認情況下是走AllowTranslucentDOF的。AllowTranslucentDOF是什麼意思呢，代碼的注釋里有解釋。
Translucent物體的渲染有幾種模式：
這里的代碼我們在BasePassPixelShader.usf里能找到
對於非透明物體來說basepass是渲染GBuffer的，但是對於透明物體來說，BasePass是渲染基礎的+Lighting的，會在這里一次性渲染完，如果我們想改透明物體的shading方式，就需要用在這里改了。