Redshift System
Feedback Display反饋顯示
Redshift can show important statistics about the scene (such as GPU memory usage and certain errors/warnings) in its 「Feedback display」 window. The 『Show behavior』 option determines when the window should pop up. By default, it only pop ups when there is an important error or warning that the user should know about. But it can also be configured to appear always (when the user renders a new frame) or only when important errors are triggered (but not warnings).
Redshift可在Fedback Display窗口顯示關於場景的重要統計數據（如顯示內存使用情況和一些錯誤和警告信息）。Show behavior（顯示方式）決定窗口該何時彈出。默認情況下，它只在用戶應該知道的Error or Warning（重要錯誤和警告）信息時才會彈出。但它也可設為Always一直出現（當用戶在渲染新一幀的時候）或者只在重要錯誤（而不是警告）被觸發時出現。
Log日誌
Defines the path of the Redshift log file and the verbosity (detail level) or the log messages printed out within the 3d app. Setting the verbosity to 「Debug」 will make Redshift print out all messages to the 3d app.
定義Redhisft日誌文件的輸出路徑以及Verbosity(錯誤級別)，以及在3D軟體中輸出的消息級別。設置Verbosity為Debug表示讓Redshift在三維軟體中輸出所有級別的信息。
Material Override
Redshift has the ability of overriding every material in the scene with a gray lambert material. This is also known as a 『clay render』. This can be a useful feature when diagnosing lighting/shading issues.
Redshift能用灰色的Lambert材質覆蓋場景中所有的材質。這也叫作「黏土渲染」。這在診斷閃爍、著色問題時很有用。
Ray Tracing Acceleration Structure
Do Complete Scene Construction Before Rendering
渲染前對場景進行結構重組
By default, Redshift loads and optimizes geometry data during the rendering process. This has the benefit of only loading/processing data that is actually visible by rays. The drawback is that, in certain cases, the CPU utilization might be less than ideal which means that geometric data processing might take longer than needed.
在默認情況下，Redshift會在渲染進載入並優化幾何體的數據結構。這樣做的好處是可以讓渲染器只載入可見的物體，而期缺點，表現在某些情況下，是cpu的利用率不是很理想，這也就意味著幾何體數據整理速度會比預期的慢。
This option forces Redshift to load and process all geometry upfront, before actual rendering starts. For certain scenes this can have a positive performance impact.
這個選項會強制Redshift在實際渲染開始前首先載入並整理幾何體數據結構。對於特定的場景，這樣處理可以優化渲染速度。
Max Num Leaf Primitives最大子物體數
This option determines the accuracy of the ray tracing acceleration structures. Lower values can speed up difficult-to-ray-trace scenes such as ones that contain lots of hair, leaves or grass. However, reducing the number of leaf primitives also increases the GPU memory requirements. We, therefore, advise using lower values (such as 4, instead of the default 8) on fairly lightweight scenes or if your GPU already has plenty of VRAM. You can diagnose the ray tracing acceleration structure memory requirements by looking in the Redshift log file, at the memory usage statistics printed at the end of each frame.
這一選項控制光線跟蹤加速運算時射線的採樣精度。數值越低，那些難於用光線追蹤處理的場景就運算越快（比如包含大理的毛髮、樹葉、草等場景）。但是，減少Max Num Leaf Primitives數量也會提高GPU顯存的佔用率。因此對於場景光照環境比較均勻的場景或者你的GPU擁有足夠的緩存的時候，我們建議把數值改為4（默認是8）。您可以通過查看Redshift的渲染報告，在報告每一幀的結尾處的顯存統計部分可以找到相應信息來確定光線跟蹤加速結構需要多大顯存空間。
Hair Tessellation毛髮細分
Mode模式
Determines how hair should be tessellated at render time. Render-time hair tessellation improves the smoothness of hair without requiring more VRAM. However, it can increase render times.
控制毛髮將在渲染時使用那種細分方式。渲染的實時毛髮細分可以在不佔用更多顯存的情況下平滑毛髮效果，但是，這會增加渲染時間。
Below we show a hair mesh using only 2 segments per strand. Notice the angular artifacts on the 「None」 image and how render-time hair tessellation fixes them.
下面的例子中，每根毛髮曲線使用了二級細分。可以看到，設定None的一邊，毛髮彎曲顯得更硬。而誰定了4-Steps的一側啟用了實時細分來修正這一問題。
IMPORTANT NOTE 特別注意
Please keep in mind that, from a performance point of view, it』s best for each strand to contain a few segments and not rely solely on render-time tessellation. Depending on the length of the strands, we recommend using 3-8 strand segments and then using 4 render-time tessellation steps to essentially 「multiply」 the strand segments. On the following example, we intentionally used only 2 strand segments in order to be able to show the benefits of 8-steps. Having each strand use using 4-5 segments instead, the 4-steps hair tessellation option was producing pristine results and the rendering was significantly faster, too!請記住這一點，從效率上考慮，最好是讓每個髮絲真正的幾段細分，而不是使用實時細分方式。基於髮絲的長度，我們推薦細分的段數為3-9.然後設定實時細分到4，從而在渲染時提到加倍的細分數。在下面的例子中，我們有意只使用2作為髮絲段數，這是為了展示最終8-Step細分的作用。如果將髮絲段數設為4-5，而實時細分設為4-Setps，渲染出來的結果同樣好，而速度快很多。
Mode set to 「None」. Lots of angular artifacts are visible.
模式設為None可以看到許多髮絲硬折
Mode set to 「4-steps」
Mode set to 「8-steps」
Experimental Options經驗選項
Render in camera space在相機空間渲染
When a scene has large extents (for example a space battle scene), precision problems might appear far away from the scene origin, i.e. the (0, 0, 0) coordinate. These precision problems might look like triangles being warped, lighting leaking through geometry or gaps appearing between polygons.
當場景中縱深很大時（比如一個宇宙飛船場景），可能在遠離場景原點比如（0，0，0）的地方遇到精度問題。這些精度問題表現出的特點是三角面出現彎曲，從幾何體中漏光，或者在多邊形之間出現空槽。
The 「render in camera space」 option eliminates this type of issue by moving the scene around the camera so that numerical precision is maintained as much as possible.
使用Render in camera sapce選項可以通過將場景位置設定到攝像機的附近來儘可能提高精度，以消除此類問題。
Render Two Passes For Denoising
Generates pairs of all active AOVs, with the filenames post-fixed with _denoise0 and _denoise1. These two images can be used by Innobright』s Altus Denoising System.
Disable Bump Smoothing On Lighting Silhouettes
Redshift by default smooths bump and normal maps on the light silhouettes of objects. I.e. there the surface normal and the light direction are perpendicular to each other. This is done to avoid faceting artifacts that can arise on those areas, especially if the object is low-poly. However, this can also produce loss of surface detail that might be necessary in some cases. For this reason, Redshift allows the user to turn off the light silhouette bump smoothing.
Bucket Rendering分割渲染
When Redshift renders in non-progressive mode, it renders the image in square tiles. These tiles are also known as 『buckets』.
當Redshift進行低強度模式的渲染時，它就會用正方形渲染圖片。這些塊叫Buckets。
The size of each bucket can be important to GPU performance! By default Redshift uses 128x128 buckets but the user can force Redshift to use smaller ones (64x64) or larger ones (256x256). We recommend that the users leave the default 128x128 setting. Please keep in mind that, when rendering with multiple GPUs, using a large bucket size can reduce performance unless the frame is of a very high resolution. This is due to the 『last bucket effect』 where the frame』s last bucket has been assigned to a GPU and is currently rendering while the other GPUs have finished with their buckets and waiting for that last bucket to be rendered. This effect, in essence, reduces parallelism and can waste several seconds of rendering time per frame. For this reason, we recommend using 128x128 buckets. Please refrain from using small 64x64 buckets as these can underutilize the GPU.
Buckets大小對於GPU性能而言很重要！默認情況下，Redshift使用128x128的Buckets，用戶可強迫Redshift使用更小塊的Buckets(64x64)或者更大塊的(256x256)。我們建議用戶保持默認的128x128設置不變。請記住，全名用GPU渲染時，使用較大的Bucket Size會降低渲染效率。除非這一幀的解析度非常高。這是因為Last Bucket（最後分割效應）。也就是說，當前幀的最後一塊被指定給了一個GPU並正用於渲染，而其它他GPU此時已經完成了其分塊任務，並等待最後一塊Buckets渲染完畢。這一效應在實質上，降低了GPU並行利用率，渲染每幀都會浪費幾秒的渲染時間。因此，我們推薦使用128x128的Buckets。盡量避免使用64x64的Buckets，因為這樣Buckets，GPU的利用率會降低。
The order that the buckets are rendered can also be configured. There are three available options:
我們還可以控制分塊渲染的順序。這裡有一些可用的選項。
1、Horizontal, where buckets are rendered left to right, top to bottom
Horizontal水平方向。此時分塊從左到右，從上到下渲染
2、Hilbert, where the buckets are rendered using a zig-zag pattern that is designed to pick the next closest bucket to the current one
Hilbert方式。此時分塊按鋸齒的形狀進行渲染。
3、Spiral, where rendering starts at the center of the frame and then gradually covers the outer parts
Spiral螺旋方式。此時渲染從每一幀的中間開始，逐漸向外擴展。
Debug Capture錯誤捕捉
If the user gets a GPU crash, they will see a message recommending that they re-rendering their frame using the 『debug capture』 option enabled. This option allows Redshift to produce a lot of extra information during rendering which, when sent to the developers, can help them diagnose and fix issues.
如果用戶遇到GPU崩潰，他們將會看到一條信息，這條信息建議他們啟用「調試器」選項重新渲染幀。這一選項允許Redshift在渲染時產生許多額外信息，這些信息會發給Redshift的開發者們，他們將對錯誤進行診斷並解決問題。
推薦閱讀：