UDN
Search public documentation:

UnrealPackagesCH
English Translation
日本語訳
한국어

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

虚幻引擎中的包

文档概述:虚幻引擎中的包及资源展现的概述。

文档变更记录:由Warren Marshall创建。由 Richard Nalezynski? 进行维护。

简介

虚幻引擎中 的概念是一个包含一些可以通过虚幻引擎进行操作和访问的二进制数据的文件。

内容包含有各种类型的游戏资源。这些资源包括贴图、静态网格物体、骨架网格物体、物理资源、UI Scenes等等! 任何添加到游戏引擎中的东西都可以放入到一个包中。使用虚幻编辑器中的内容浏览器,您可以把资源导入到包中,到处移动资源、重命名资源以及再次把最终的包导出等等。

关卡是作为一种特殊类型的包出现的。关卡一般不包含资源。相反,它包含着到包文件内的资源的引用。这允许多个关卡来共享资源,并允许美术工作人员仅需将包文件中的资源改变一次,所有引用该资源的关卡将会自动地进行更新。把资源直接插入到您的关卡文件中是可能的;但是一般不建议这样操作,因为它会加大您关卡文件的大小,同时也消除了其它关卡可以共享那个资源的可能性。关卡也可以充分地利用在 UnrealScript 类中定义的 Actor。

UnrealScript 类被编译为单独的包。UnrealScript 包也可以包含到内容及关卡包中的引用。

包类型

包可以有不同的扩展名,但是它们在内部是完全一致的。虚幻引擎只关心包中的内容,而不包含任何处理特定扩展名的特殊情况。 然而,有一个大多数授权用户都会遵守的通用习惯:

扩展名 包含内容
U 编译过的 UnrealScript 代码。 这些文件由 UCC 编译器生成,它们不包含任何资源;仅包含引用。
UDK 关卡的默认扩展名;包含着在编译后的脚本包中定义的 Actor 和存储在内容包中的资源。
UPK 其中包含着各种资源的内容包的通用扩展名。

授权用户可以在授权用户文件扩展名?页面注册唯一的关卡扩展名。

包可以包含多层的组。可以把它们想象成您硬盘上文件结构中的子目录。 这些组的使用完全是为了使人们可以搞清包内容的意思;引擎不会关心您是否使用这些组。

虚幻引擎支持多层次的组结构;但是,尽管您可以按照您的意愿设计组层次的深度,但通常推荐最多建立 3 或 4 层。否则,当使用内容浏览器包的树结构时,它将会变得特别不实用。以下是使用多个组来组织装甲资源的例子:

CB_Packages.PNG

这个例子中的包是 Pickups (可能在硬盘的 pickups.upk 包中)。在那个包内可能有很多组用于组织它内部的资源。比如,假设这个选中的像,获得指定资源的路径将是 Pickups.Armor.Materials 。这类似于访问您的硬盘(也就是:"c:\pickups\armor\materials")。每个组都可以包含资源,就像那个任何目录可以包含文件一样。

命名

当命名您的资源和包时,我们强烈推荐您为它们使用唯一的名称。把多个东西命名为同一个名称有时会导致引擎不能精确地决定您所要加载或者引用的资源,从而可能找到了一个错误资源。这样导致的一些难以发现的问题,并且这些问题很难调试解决。

所以只要直接彻底地避免这样的问题,为您的 资源/包 进行唯一的命名。已经说过,组的名称可以是您想象的任何东西。它们不需要是唯一的,因为它们永远不会被直接地引用或搜索。

组织结构

内容包一般存储在您的软件版本的 Content(内容)目录内。它们可以包含代表各种类型内容比如贴图或 UI Scenes 的子目录。再次说明,这仅是为了更有利于人类的可读性和可维护性。

关卡包存储在您的软件版本中的 Maps(地图)目录中。

编译完成的 UnrealScript 包存储在您的软件的 Scripts(脚本)目录中。

请查看资源通道页面来获得关于命名及组织包的更多信息。

限制

对于一个包文件中可以出现的资源的数量没有限制,但是对于整个包的大小的限制为 2GB。超出这个限制将会导致包不能在某些平台上加载。如果包已经接近 2G 的一半,那么尝试把包中的各个部分抽出来并分为多个较小的包是一种明智的做法。

管理

另外,如果包中包含着不同团队人员使用的各种类型的内容,那么包可能会变得很大。这样在 Source Control(代码控制)中为了存储每个修订本将会创建一个非常大的文件拷贝。为了避免这些问题,可以考虑一个策略:您扫描查看您所拥有的一组包文件,并识别出大于 200-300 兆的包。取出这些较大的包,并把它们分裂开为较小的包。这可以在磁盘应用方面提供很多帮助。

烘焙将会做很多工作,来把所有需要的数据“组合”到 seek-free(不用寻道)的包中。另外,当只有较少的内容循环的时候,稍后仅在设备循环中把包结合回较大的包中是非常容易的。为了完成这个工作,简单地把来自一个包中的资源重命名为另一个。这将会创建一个指向新位置的重定向物体。您不能删除旧的(空的)包,直到您已经运行了 FixupRedirects 命令行开关来把所有到旧的内容位置的引用重新映射指向新的位置为止。

加载

加载 Native 包,以便包中定义的可以影响 native C++类(通过 defaultproperties )的任何数据都可以在运行代码时被应用。有一些类定义在 C++ 和脚本中,它们需要保持同步。

包加载是一个非常复杂的系统,事实上大多数授权用户都不需要在底层上对其进行处理。

Exports(导出) 是存在于包中的物体。

Imports(导入) 是到其它包中的物体的引用。

所以,如果您在包 A 中有一个材质 MatX,并且它引用包 A 中的 TexY 和包 B 中的 TexZ,那么您将会有:

Package A:
        Exports:
                MatX
                TexY
        Imports:
                B.TexZ

Package B:
        Exports:
                TexZ

编辑器加载 native 脚本包,即列在配置文件的 EditPackagesPackagesToBeFullyLoadedAtStartup 关键字中的包及它们的所有引用。

当您加载一个包(编辑器或游戏),它将会从其它包中加载物体来解决所有的引用。它将 不会 加载被引用包中的所有物体。它仅从其它包中加载所需的少量物体。

在编辑器中,内容浏览器中所列出的呈现为灰色的包进加载了一部分资源,因为它们是由于加载其它包而加载的。您可以右击这个包来完全加载它。 每次您启动编辑器将会自动扫描您的游戏的内容目录来获得包。 任何找到的包将会显示在内容浏览器的包的树结构中。

通过点击内容浏览器左下角的文件夹图标,您可以加载外部包(不是在引擎的搜索路径之内能找到的包)。 然而,我们强烈推荐您不要在关卡中引用外部包或者其它包的任何资源,因为这些资源在运行游戏或者命令开关时不能找到。