System
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在三维软体中输出所有级别的信息
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一直出现（当用户在渲染新一帧的时候）或者只在重要错误（而不是警告）被触发时出现。
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 eachstrand 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 beconfigured. 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的开发者们，他们将对错误进行诊断并解决问题。
推荐阅读：