Log Files 日志文件

Introduction 引言

During its execution, Redshift will print out a multitude of useful messages in your 3d app's script/console window. In order to avoid clutter, Redshift's default behavior is to only print out a subset of all the messages it generates. If you want to view all the messages in the script window, the user can set Redshift's verbosity level to "Debug". This option can be found in the System tab.
Apart from the 3d app's script/console window, Redshift stores all messages in log files.

在执行期间，Redshift 会在3d 应用程序的脚本/控制台窗口中打印出大量有用的消息。为了避免混乱，Redshift 的默认行为是只打印它生成的所有消息的子集。如果要查看脚本窗口中的所有消息，用户可以将 Redshift 的详细级别设置为“ Debug”。此选项可在“系统”选项卡中找到。除了3d 应用程序的脚本/控制台窗口，Redshift 将所有消息存储在日志文件中。

Learning the structure and messages of the log file can be useful when diagnosing rendering errors and warnings such as an aborted render, unrecognized shading nodes, missing textures, etc. It can also help better understand the rendering process and know how (and when) to optimize your renders.

学习日志文件的结构和消息在诊断渲染错误和警告时很有用，比如中止渲染、无法识别的阴影节点、丢失的纹理等等。它也可以帮助更好地理解渲染过程和知道如何(以及何时)优化您的渲染。

Log File Location

日志文件位置

Redshift writes log files to a subdirectory of the log root path which is specified as follows:

Redshift 将日志文件写入日志根路径的子目录，该目录如下所示:

Windows

窗户

Linux and macOS

和 macOS

If the environment variable REDSHIFT_LOCALDATAPATH is not defined, the default location is:

如果未定义环境变量红移 localdatapath，默认位置为:

Windows

窗户

Linux and macOS

和 macOS

Within the Redshift log folder you'll find a list of folders that might look like this

在红移日志文件夹中，您将找到一个文件夹列表，它们可能如下所示

Each of these log folders represents a "render session". Assuming Redshift is installed and set to automatically initialize when your 3d app is launched, a new log folder will be generated each time you launch your 3d app. The most recent Redshift session is in the "Log.Latest.0" folder. The other folders will contain previous sessions.

每个日志文件夹表示一个“呈现会话”。假设 Redshift 已经安装，并且在启动3 d 应用程序时自动初始化，那么每次启动3 d 应用程序时都会生成一个新的日志文件夹。最近的红移会话在“日志。最新版本0”资料夹。其他文件夹将包含以前的会话。

The first part of the folder name is the date in Year-Month-Day form and the second part is the time. So, on the list shown above, the first folder with the name Log.20150904_1236.0 was created on 4 Sept 2015 at 12:36.

文件夹名称的第一部分是 Year-Month-Day 格式的日期，第二部分是时间。因此，在上面显示的列表中，第一个名为 log. 201509041236.0的文件夹是在2015年9月4日12:36创建的。

The number at the end of the folder name is used when multiple log files 'conflict' within the same hour:minute time. For example, if you open and close your 3d app very quickly then there will be multiple log files created in the same minute. When Redshift detects that, it will increment this last number of the folder name so you'll see folder names ending in .1 or .2 and so on. Such log folder conflicts can also happen when you're rendering with multiple instances of your 3d app – as example, when simultaneously rendering multiple frames via multiple instances of Maya.

当多个日志文件在同一小时: 分钟内“冲突”时，将使用文件夹名末尾的数字。例如，如果你很快打开和关闭你的3 d 应用程序，那么在同一分钟内会创建多个日志文件。当 Redshift 检测到这一点时，它会递增文件夹名称的最后一个数字，这样您就会看到以. 1或. 2结尾的文件夹名称，以此类推。这种日志文件夹冲突也可能发生在你渲染你的3d 应用的多个实例时-例如，当同时渲染多个框架通过多个实例的 Maya。

Structure of a typical log file

典型日志文件的结构

Initialization

初始化

The first part of the log file prints out info about the Redshift version, the path locations and some basic CPU and GPU information. These messages are printed as part of Redshift's initialization stage.
A quick diagnostic is run on each GPU to measure its PCIe (PCI express) performance. PCIe (also known as 'the bus') is the computer component that connects your GPU with the remaining computer, so it can affect rendering performance. A bad motherboard driver or a hardware issue can adversely affect PCIe performance which, in turn, can reduce rendering performance. Ideally, the pinned memory bandwidth should be close to 5 or 6GB/s or higher.
The last line printed during initialization stage is also very important! It tells us how much GPU memory (aka "VRAM") Redshift will be able to use while rendering. If you have other 3d apps running at the same time, Redshift will be able to use less VRAM. As we can see here, even though our videocard is equipped with 4GB of memory, only 3.2GB of these could be used by Redshift. This is because this computer had other 3d apps as well as the Chrome web browser running – both of which can consume big quantities of VRAM. For more information about VRAM usage, please read this document.

日志文件的第一部分打印出关于红移版本的信息、路径位置以及一些基本的 CPU 和 GPU 信息。这些消息作为 Redshift 初始化阶段的一部分打印出来。在每个 GPU 上运行一个快速诊断程序来测量其 PCIe (PCI express)性能。PCIe (也称为“总线”)是连接 GPU 和其余计算机的计算机组件，因此它可以影响渲染性能。糟糕的主板驱动程序或硬件问题可能会对 PCIe 性能产生不利影响，从而降低呈现性能。理想情况下，固定的内存带宽应该接近5或6GB/s 或更高。在初始化阶段打印的最后一行也非常重要！它告诉我们多少 GPU 内存(又名“ VRAM”)红移将能够使用的时候渲染。如果你有其他的3 d 应用程序在同一时间运行，Redshift 将能够使用更少的 VRAM。正如我们在这里看到的，即使我们的视频卡配备了4gb 的内存，只有3.2 GB 的这些可以被红移使用。这是因为这台电脑有其他的3d 应用程序和运行的 Chrome 浏览器——这两者都会消耗大量的 VRAM。有关 VRAM 使用的更多信息，请阅读此文档。

Scene Extraction

场景提取

Scene extraction is the process during which Redshift is getting data from your 3d app into its own memory. That data includes your polygons, lights, materials, etc. If the scene has lots of objects or polygons the extraction stage can be long. If that's the case with your scene, we recommend using Redshift proxies.
Redshift also prints out the frame number which can be useful if the log file contains messages from several frames.
Redshift for Maya 2015 Version 1.2.90, Sep 3 2015 Rendering frame 1 Scene extraction time: 0.01s

场景提取是 Redshift 将数据从你的3 d 应用程序中提取到自己的内存中的过程。这些数据包括你的多边形、灯光、材料等。如果场景中有很多物体或多边形，提取阶段可以很长。如果你的场景是这种情况，我们建议使用红移代理。Redshift 还打印出帧号，如果日志文件包含来自多个帧的消息，则可以使用该帧号。2015版本1.2.90,2015年9月3日渲染帧1场景提取时间: 0.01秒

Rendering – Preparation Stage

绘制-准备阶段

This is the first step of Redshift's rendering stage. Redshift does a first-pass processing of the scene's meshes for the ray tracing hierarchy. The ray tracing hierarchy is a data structure used during ray tracing in order to make rendering fast. Therefore, the building of the ray tracing hierarchy is a very important stage! If the scene contains many objects and/or polygons, the ray tracing hierarchy construction can take some time. Certain stages of tessellation/displacement can also happen here.
After the initial ray tracing hierarchy construction, Redshift does a pass over the scene textures and figures out if it needs to convert any of them. Redshift, by default, will convert all textures to its own internal format. If you want to avoid this kind of automatic processing, please use the texture processor and preprocess your textures offline.
For information on the GPU memory allocation, please read the next section.

这是红移渲染阶段的第一步。Redshift 为射线跟踪层次结构对场景的网格进行首次处理。射线追踪层次结构是射线追踪过程中为了快速绘制而使用的一种数据结构。因此，光线追踪层次结构的建立是一个非常重要的阶段！如果场景包含许多对象和/或多边形，那么射线追踪层次结构的构造可能会花费一些时间。镶嵌/移位的某些阶段也可以发生在这里。在初始的光线追踪层次结构构建之后，红移通过场景纹理并计算出是否需要转换其中任何一个纹理。默认情况下，红移会将所有纹理转换为自己的内部格式。如果您想避免这种自动处理，请使用纹理处理器和预处理您的纹理离线。有关 GPU 内存分配的信息，请阅读下一节。

Rendering – Prepasses

渲染-预通道

Before Redshift can render the final frame, it has to execute all the prepasses. In this example, it computes the irradiance point cloud.
Other possible prepasses are:

在红移渲染最终帧之前，它必须执行所有的预传。在这个例子中，它计算辐照度点云。其他可能的预通道有:

• Photon mapping 光子映射
• Irradiance Cache 辐照度缓存
• Subsurface scattering 次表面散射

At the start of each prepass, Redshift has to configure the GPU's memory (VRAM). Notice that, in this case, Redshift can use roughly up to 2.8GB of VRAM. You might ask "hold on, a few paragraphs above you said Redshift could use up to 3.2GB!". Well, the lower VRAM is because of two reasons:

在每个预置的开始，红移必须配置 GPU 的内存(VRAM)。注意，在这种情况下，Redshift 可以使用大约2.8 GB 的 VRAM。你可能会问“等等，上面有几段你说过 Redshift 可以使用3.2 GB!”.VRAM 低是因为两个原因:

• Redshift doesn't use 100% of the GPU's free VRAM. By default, it uses 90%. But you can grow or shrink that percentage in the 红移不使用100% 的 GPU 的免费 VRAM。默认情况下，它使用90% 。但是你可以增加或者减少这个百分比Redshift Memory tab 红移内存选项卡.
• Once Redshift initializes, it needs to use some VRAM (a few tens of MBs) for its operation. That memory is not counted here. 一旦 Redshift 初始化，它需要使用一些 VRAM (几十个 mb)来进行操作。这段记忆在这里不算数

After VRAM has been allocated, Redshift prints out how much VRAM it didn't allocate and is now free. In this case it's 336MB. It's important to leave some VRAM free so that the 3d app and the operating system can function without issues.
At the end of each prepass, Redshift prints out how long the prepass took. In this case, the irradiance point cloud took 1.36 seconds.
Irradiance point cloud... Allocating VRAM for device 0 (Quadro K5000) Redshift can use up to 2860 MB Geo/Tex: 2028 MB / 256 MB NRPR: 262144 Done! (0.03s). CUDA reported free mem: 336 MB Total num points before: 55 (num new: 55) Total num points before: 85 (num new: 37) Total num points before: 144 (num new: 59) Total num points before: 209 (num new: 65) Total num points before: 318 (num new: 109) Total num points before: 442 (num new: 124) Total num points before: 560 (num new: 118) Total num points before: 678 (num new: 118) Total num points before: 799 (num new: 121) Total irradiance point cloud construction time 1.36s

在分配了 VRAM 之后，Redshift 打印出它没有分配的 VRAM 数量，现在是空闲的。在这个例子中是336mb。让一些 VRAM 空闲是很重要的，这样3 d 应用程序和操作系统就可以正常运行。在每次准备的末尾，Redshift 打印出准备时间的长短。在这种情况下，辐照点云需要1.36秒。辐射点云... 为设备0(Quadro K5000)分配 VRAM 红移可以使用高达2860 MB Geo/Tex: 2028 MB/256 MB NRPR: 262144完成！(0.03 s).CUDA 报告免费 mem: 336 MB Total num points before: 55(numnew: 55) Total num points before: 85(numnew: 37) Total num points before: 144(numnew: 59) Total num points before: 209(numnew: 65) Total points before: 318(new: 109) Total num points before: 442(numnew: 124) Total points before: 560(新: 118) Total num points before: 678(新: 118) Total points before: 799(新: 121) Total irradiance point construction time: 1.36 s

Rendering – Final image

渲染-最终图像

This is the final rendering stage where Redshift renders the image block-by-block. Blocks are also known as "buckets".
Notice that Redshift has to reallocate VRAM for this stage too, similar to what it did for the prepasses.
While blocks are rendered, Redshift will print out a line for each block so you can track the general progress. It also prints the time it took to render the block. Depending on the scene complexity, some blocks can take a longer time to render than others.
Like with the prepasses, Redshift finishes by printing out the total time taken to render the final image.

这是 Redshift 逐块渲染图像的最后渲染阶段。积木也被称为“桶”。注意，Redshift 也必须为这个阶段重新分配 VRAM，类似于它对预通道所做的。在渲染块时，Redshift 将为每个块打印一行，以便您可以跟踪常规进度。它还打印渲染块所需的时间。根据场景的复杂程度，有些区块渲染时间会比其他区块长。与 prepass 类似，Redshift 完成方法是打印出渲染最终图像所需的总时间。

Statistics

统计数字

This is a very important part of the log file! It provides various scene statistics such as the number of proxies, meshes, lights, unique polygons, polygons with instancing, etc.Knowing such statistics can be useful when profiling a scene. As an example, scenes with many lights can take a longer time to render than scenes with few lights. Using the statistics, you can quickly find out if the scene contains many lights.

这是日志文件中非常重要的一部分！它提供了各种场景统计数据，例如代理、网格、灯光、独特的多边形、实例化的多边形等等。了解这些统计数据在分析场景时非常有用。例如，有很多灯光的场景渲染时间比只有很少灯光的场景要长。使用统计数据，你可以很快地找出场景是否包含许多灯光。

You can also quickly find out how many unique polygons or strand segments (for hair) there are in the scene. Please note that "unique" means "non-instanced". Say you're modelling a forest and you have the same 1-million-polygon tree instanced 1000 times, you will see something like "1 million unique triangles" and "1 billion total triangles".

你也可以很快地发现场景中有多少独特的多边形或者发丝段。请注意，“独特”的意思是“非实例”。假设你正在建立一个森林模型，你有同样的100万个多边形树实例1000次，你会看到“100万个独特的三角形”和“10亿个总三角形”。

Perhaps the most important data entries are the ones referring to GPU memory.

也许最重要的数据条目是那些涉及到 GPU 内存的。

At the very bottom of the log file we can see the "Ray acceleration and geometry memory breakdown". These figures refer to the polygons and splines (primitives) in our scene. The sum of these figures is how much GPU memory would be required to fit all the primitives without requiring any out-of-core-access.

在日志文件的最底部，我们可以看到“光线加速度和几何内存故障”。这些图形指的是我们场景中的多边形和样条(原语)。这些数字的总和是需要多少 GPU 内存，以适应所有的原语，而不需要任何外核访问。

A few lines higher, we can see the "GPU Memory" section. The "uploads" figures in it tell us how much PCIe traffic was required to send the data to the GPU. Those figures might be smaller than the "Ray acc. And geometry memory breakdown" total. This is because Redshift only sends data it absolutely needs to the GPU. In this example, less PCIe traffic was required because there were was a percentage of polygons that wasn't visible by the camera. There are other cases, however, where data might have to be re-sent to the GPU due to out-of-core access (or for other reasons). In such cases, the 'uploads' can potentially be (much) larger than the sum of 'Ray acc. And geometry memory breakdown'.

再往上几行，我们可以看到“ GPU 内存”部分。其中的“上传”数字告诉我们需要多少 PCIe 流量才能将数据发送到 GPU。这些数字可能比“ Ray acc”小。和几何内存分解”合计。这是因为红移只发送它绝对需要的数据到 GPU。在这个例子中，需要较少的 PCIe 流量，因为有一定百分比的多边形不能被摄像头看到。然而，在其他情况下，由于外部访问(或其他原因) ，数据可能必须重新发送到 GPU。在这种情况下，“上传”可能会比“ Ray acc”的总和大得多。还有几何记忆的分解。

When profiling performance, you should mostly worry about the 'upload' figures, especially if they go into the "many gigabytes" range. This applies for both geometry and texture uploads.

在分析性能时，您最应该担心的是“上传”数字，特别是当它们达到“许多千兆字节”范围时。这既适用于几何图形也适用于纹理上传。

End Of Frame

画面结束

When Redshift has finished rendering the frame, it saves the image and prints out how much time the frame took in total. The total time includes extraction, preparation, prepasses and final rendering times.

当 Redshift 完成渲染帧时，它保存图像并打印出帧总共花费的时间。总时间包括提取时间、准备时间、预通道时间和最终渲染时间。