用于处理具有几乎无限细节的场景的编解码器

摘要

描述了用于使用场景编解码器的系统的方法和装置，其中系统是包括场景和场景增量的多路、准时化、仅按需场景数据的提供者或消耗者。使用场景编解码器的示例性系统包括：包含一个或多个数字化场景模型的全光场景数据库，其中表示及表示的组织能够跨多个系统分布，使得所述多个系统能够共同表示具有几乎无限细节的场景。该系统可以进一步包括用于处理这些表示及表示的组织的高效手段，从而提供用于确保通过最少量的新提供的场景信息来实现最大程度的连续用户体验所需的准时化、仅按需子场景和场景增量，其中高效手段包括空间处理单元。

说明书

相关申请的交叉参考

本申请要求2018年5月2日提交的美国临时专利申请号62/665,806的优先权权益，该申请的全部内容通过引用并入本文。本申请与2017年4月11日提交的PCT申请号PCT/US2017/026994相关，该PCT申请的全部内容通过引用结合在此。

技术领域

本公开涉及分布式数字网络中的场景表示、处理和加速。

背景技术

在本领域中众所周知有各种编解码器，并且其通常是压缩数据以实现更快的传输并解压缩接收数据的设备或程序。典型类型的编解码器包括视频(例如，MPEG、H.264)、音频(例如，MP3、ACC)、图像(例如，JPEG、PNG)和数据(例如，PKZIP)，其中该类型的编解码器封装该类型数据并与该类型数据强耦合。尽管这些类型的编解码器对于限于该类型数据的应用是令人满意的，但强耦合所固有的是有限的终端用户体验。

编解码器本质上是“基于文件的”，其中文件是某种真实的或合成的预先捕获的感觉体验的数据表示，并且其中文件(诸如电影、歌曲或书本)必须将用户的体验限制为文件创建者所选的体验路径。因此，我们以创建者所限制的一种基本上有序的体验来观看电影、听歌和看书。

市场上的技术进步为扩展数据类型和体验数据类型提供了更多的手段。数据类型的增加包括通常称为真实世界场景重建的数据类型，其中传感器(诸如相机和测距设备)创建真实场景的场景模型。本发明人在2017年4月11日提交的专利申请PCT/2017/026994“日常生活场景重建引擎”中提出了场景重建的重大进步，该申请的全部内容通过引用结合在此。用于体验数据类型的手段的改进包括更高的分辨率和性能更好的2D和3D显示、自动立体显示、全息显示以及诸如虚拟现实(VR)耳机和增强现实(AR)耳机的扩展现实设备和方法。其他重大的技术进步包括自动机的普及和网络的普及，在这些自动机中，人类不再是真实世界感觉信息的唯一消费者，在这些网络中，信息的流动和获取使新的体验范式成为可能。

为了发展新的基于场景的编解码器，已经完成了一些工作，其中，数据类型是真实世界场景的重建和/或合成场景的计算机生成。为了评价场景编解码器，请读者阅读如由“沉浸式介质应用的光/声场的数字表示的联合特设小组”发布的沉浸式介质应用的光/声场的数字表示的联合特设小组的技术报告，该报告的全部内容通过引用结合在此。

场景重建和分布是有问题的，其中重建在以有效可控且高度可扩展的方式充分描述真实世界物质和光场的复杂性的表示以及表示的组织方面存在挑战，并且其中分布在跨多个交互式客户端(包括人类和自动机)管理活动(甚至实时)场景模型的方面存在挑战，每个客户端潜在地请求几乎无限数量的场景透视图、细节和数据类型中的任一者。

因此，需要通过提供一种解决市场上许多需求和机会的有效且灵活的系统来克服本领域中的缺点和不足。

发明内容

以下概述可以提供对本文所讨论的系统和/或方法的一些方面的基本理解。本概述不是对本文所讨论的系统和/或方法的广泛综述。并不旨在指出所有关键(key/critical)的元件或划定此类系统和/或方法的范围。唯一的目的是以简化的形式呈现一些概念，作为稍后呈现的更详细说明的序言。

本文提供了支持使用了场景编解码器的系统的方法和装置，其中系统是包括子场景和子场景增量的多路、准时化、仅按需场景数据的提供者或消耗者。根据一些实施例，使用了场景编解码器的系统包括：包含一个或多个数字化场景模型的全光场景数据库，其中表示及表示的组织能够跨多个系统分布，使得多个系统可以共同表示具有几乎无限细节的场景。该系统可以进一步包括用于处理这些表示及表示的组织的高效手段，从而提供用于确保通过最少量的新提供的场景信息来实现最大程度的连续用户体验所需的准时化、仅按需子场景和场景增量，其中，高效手段包括空间处理单元。

根据一些实施例的系统可以进一步包括执行操作系统功能以及用户接口功能的应用软件。用户接口功能包括提供用户接口或与外部用户接口通信的任何组合。用户接口确定显式和隐式用户指示，这些指示至少部分地用于确定用户对场景数据(和相关联的其他场景数据)的请求，并且响应于用户的请求而向用户提供场景数据和其他场景数据中的任一者。

根据一些实施例的系统可以进一步包括场景编解码器，其中编解码器包括编码器和解码器中的一者或两者，从而允许系统既是场景数据提供者又是消耗者。系统可以任选地接口连接或任选地包括用于感测真实世界、真实场景数据的任何可用传感器，其中任何此类感测的数据都可以用于由系统重建成全新场景或现有场景的增量，其中感测数据的任一个系统可以将数据重建成场景信息，或者将数据卸载到其他系统以进行场景重建，而执行场景重建的其他系统会将重建后的场景和场景增量返回到原始感测系统。

根据一些实施例的编解码器支持场景模型和与场景模型集成在一起或与场景模型相关联地保存的其他类型的非场景数据。根据一些实施例的编解码器可以支持多个系统的联网，从而交换包括用户请求、客户端状态和场景使用数据的控制分组以及包括请求的场景数据和非场景数据以及可选的由客户端在进行验证时使用的请求标识的场景数据分组。可以提供一对一、一对多和多对多系统联网的支持，其中任何系统都能够再次感测新的场景数据，重建新的场景数据，提供场景数据和消耗场景数据。

根据一些实施例的系统在场景数据的重建和分布期间提供了机器学习的使用，其中新类型信息的关键数据记录为机器学习或确定性算法提供了基础，这些算法既优化了单独系统性能又优化了联网系统性能。例如，追踪消耗场景数据的所有客户端系统的状态，以确保任何可能的服务系统都具有对客户端的现有场景数据和非场景数据的有价值的预先了解。对用户请求(包括场景类型和场景实例)进行分类并进行唯一标识。单独系统都根据其场景感测、重建、提供和消耗的能力进行标识和分类。追踪场景使用的程度，包括使用类型以及场景消耗路径和持续时间。经分类和追踪的信息的多样性为机器学习提供了有价值的新数据，其中基于累积学习的前瞻性预测智能地扩展了用户对场景数据的请求，从而进一步确保由最少量的新提供的场景信息实现最大程度的连续用户体验。

附图说明

通过结合以下附图参考示例性非限制性说明性实施例的以下详细描述，将更好地且更全面地理解这些以及其他特征和优点。

图1A描绘根据一些实施例的使用场景编解码器的系统的框图。

图1B描绘根据一些实施例的包括编码器和解码器的场景编解码器的框图。

图1C描绘根据一些实施例的包括编码器但不包括解码器的场景编解码器的框图。

图1D描绘根据一些实施例的包括解码器但不包括编码器的场景编解码器的框图。

图1E描绘根据一些实施例的连接两个或更多个使用场景编解码器的系统的网络的框图。

图1F描绘根据一些实施例的包括编码器的场景编解码器的框图。

图1G描绘根据一些实施例的包括解码器的场景编解码器的框图。

图2A描绘如由沉浸式介质应用的光/声场的数字表示的联合特设小组在瑞士日内瓦(Geneva，Switzerland)于2016年6月提交的技术公布ISO/IEC JTC1/SC29/WG1N72033、ISO/IEC JTC1/SC29/WG11N16352中描述的现有技术“光/声场概念工作流”的框图。

图2B是根据一些实施例的由代表性真实相机捕获并被提供给诸如图1E所示的网络环境中的诸如图1所示的系统的系统的真实世界场景的组合框和示意图。

图3是根据一些实施例的连接使用场景编解码器的系统的示例性网络的示意图。

图4A是根据一些实施例的具有无限或几乎无限细节的示例性真实世界场景(诸如具有观看室外场景的窗户的内部房子场景)的示意图。

图4B是根据一些实施例的代表诸如图4A所描绘的真实世界场景的示意图，其中该表示可以被认为是全光场景数据库内所包括的数据以及其他对象(诸如解释的对象和无法解释的对象)的抽象模型视图。

图4C是根据一些实施例的全光场景数据库的一些数据集的框图。

图5是根据一些实施例的用例的流程图，该用例包括与远程客户端共享更大的全局场景模型，该远程客户端在消耗各种类型的场景模型信息中的任一者。

图6是根据一些实施例的类似于图5的用例的流程图，但是现在正解决一个变型情况，其中客户端首先创建场景模型或更新现有场景模型。

图7是根据一些实施例的类似于图5和图6的用例的流程图，但是现在正解决一种这样的变型情况：在客户端侧系统和服务器侧系统两者均能够重建和分布真实场景，从而确定并提供子场景和对子场景的增量的情况下，客户端系统首先创建场景模型或更新现有场景模型，然后捕获真实场景的本地场景数据。

图8是复杂全光场景模型(日常生活厨房)的综合生成图像。

图9是根据一些实施例的示出体积元素(“体元”)和立体角元素(“立元(sael)”)的两个视图的几何图。

图10是根据一些实施例的示出日常生活场景的场景模型的俯视平面图的几何图。

图11是根据一些实施例的场景数据库的框图。

图12是根据一些实施例的示出用于表示全光场的基元类型的层次结构的类图。

图13是复杂全光场景模型(具有突出显示的两个点的日常生活厨房)的综合生成图像。

图14包含根据一些实施例的来自外部的图像，该图像示出进入图13所示的厨房中的开放空间中的点的入射光的光立方。

图15包含根据一些实施例的图14所示的光立方的六个另外的视图。

图16是根据一些实施例的从内部视角看的图14所示的光立方的图像。

图17是根据一些实施例的从内部视角看的图14所示的光立方的图像。

图18是根据一些实施例的从内部视角看的图14所示的光立方的图像。

图19是根据一些实施例的来自图13所示的厨房柜台的表面上的一点的出射光的光立方的外部的图像。

图20是根据一些实施例的示出将BLIF施加到垂直偏振光的单个入射射束的结果的光立方的图像。

图21是根据一些实施例的示出八叉树的树结构的图示。

图22是根据一些实施例的示出由图21所示的八叉树中的节点表示的体积空间的几何图。

图23是根据一些实施例的示出立元树(saeltree)的树结构的图示。

图24是根据一些实施例的示出由图23所示的立元树中的节点表示的方向空间区域的几何图。

图25是根据一些实施例的示出以八叉树节点的中心为原点的立元的几何图。

图26是根据一些实施例的示出由2D中的三个立元树的三个立元表示的空间的几何图。

图27是根据一些实施例的示出两个立元树的两个出射立元以及两个立元与两个体积八叉树(VLO)体元的交叉部的几何图。

图28是根据一些实施例的示出附接到由来自投影到VLO节点上的两个立元树的两个出射立元而产生的一个VLO体元的新立元树的两个入射立元的几何图。

图29是根据一些实施例的示出针对VLO体元基于体元的入射立元树和与体元相关联的BLIF生成的来自新立元树的出射立元的几何图。

图30是根据一些实施例的示出空间处理单元(SPU)的功能的示意图。

图31是根据一些实施例的示出空间处理单元的光场操作功能的子功能的示意图。

图32是根据一些实施例的示出立元树的周围立方体的六个面的编号的几何图。

图33是根据一些实施例的示出立元树的周围立方体的四分之一面的几何图，其中突出显示立元树的周围立方体的一面的四分之一面。

图34是根据一些实施例的示出立元树的周围立方体的四分之一面的侧视图的几何图。

图35是根据一些实施例的示出由顶部立元表示的方向空间片段的2D侧视图的几何图。

图36是根据一些实施例的示出立元树的立元在投影平面上的投影如何由其在立元树的周围立方体的一面上的位置处的交叉部表示的几何图。

图37是根据一些实施例的在维持投影平面上的立元投影时以2D展示立元树的移动的几何图。

图38是根据一些实施例的在维持立元树的立元的投影时展示投影平面的移动的几何图。

图39是根据一些实施例的示出立元在投影平面上的跨度的几何形状的几何图。

图40是根据一些实施例的示出顶部和底部交叉点与顶部在投影平面坐标系中在底部下方的指示投影无效(立元的原点的相反侧)的情况之间的关系的几何图。

图41是根据一些实施例的示出将立元树的立元细分成两个子树层级以及由2D中的节点表示的空间区域的几何图。

图42是根据一些实施例的示出新立元边缘与投影平面交叉的位置的几何图，该位置将是子立元的新的顶部边缘或底部边缘。

图43是根据一些实施例的示出来自立元树的出射立元致使在附接到与出射立元交叉的VLO节点的立元树中生成入射立元的几何图。

图44是根据一些实施例的示出在所示的方向空间范围内的呈2D的从前到后VLO遍历顺序的几何图。

图45是根据一些实施例的以2D展示在立元投影到场景中期间将四叉树用作投影掩模的几何图。

图46是根据一些实施例的示出通过多个半空间的交叉而构造的立元的体积空间的几何图。

图47是根据一些实施例的示出立元与三个VLO节点之间的三种交叉情况的几何图。

图48是根据一些实施例的展示作为立元树的旋转的一部分的立元的旋转的几何图。

图49是根据一些实施例的示出在立元树旋转期间在立元边缘之间的中心点与投影平面的几何构造的几何图。

图50是根据一些实施例的示出在使立元树旋转时执行边缘的旋转的几何操作的几何图。

图51是根据一些实施例的示出当推入立元原点节点、投影平面的VLO节点或立元时，立元与投影平面之间的几何关系的计算的示意图。

图52是根据一些实施例的示出当推入立元原点节点、投影平面的VLO节点或立元时(其中同时推入立元原点和投影平面的VLO节点)，立元与投影平面之间的几何关系的计算的示意图。

图53是根据一些实施例的示出电子表格的一部分的表，该电子表格将一系列立元树原点、VLO和立元推入的结果制成表格。

图54是图53的续表。

图55是示出图53和图54中的电子表格的公式的表。

图56是示出在图53和图54中列出的推入操作顺序的开始处的起始几何关系的几何图。

图57是根据一些实施例的示出在图53和图54的电子表格中所示的迭代#1(立元原点SLT节点推入到子节点3)之后，立元与其在投影平面上的投影之间的几何关系的几何图。

图58是根据一些实施例的示出在图53和图54的电子表格中所示的迭代#2(立元原点SLT节点推入到子节点2)之后，立元与其在投影平面上的投影之间的几何关系的几何图。

图59是根据一些实施例的示出在图53和图54的电子表格中所示的迭代#3(投影平面VLO节点推入到子节点3)之后，立元与其在投影平面上的投影之间的几何关系的几何图。

图60是根据一些实施例的示出在图53和图54的电子表格中所示的迭代#4(投影平面VLO节点推入到子节点1)之后，立元与其在投影平面上的投影之间的几何关系的几何图。

图61是根据一些实施例的示出在图53和图54的电子表格中所示的迭代#5(立元推入到子节点1)之后，立元与其在投影平面上的投影之间的几何关系的几何图。

图62是根据一些实施例的示出在图53和图54的电子表格中所示的迭代#6(立元推入到子节点2)之后，立元与其在投影平面上的投影之间的几何关系的几何图。

图63是根据一些实施例的示出在图53和图54的电子表格中所示的迭代#7(投影平面VLO节点推入到子节点0)之后，立元与其在投影平面上的投影之间的几何关系的几何图。

图64是根据一些实施例的示出电子表格的一部分的表，该电子表格将一系列立元树原点、VLO和立元推入的结果制成表格，其中立元树原点不在八叉树节点的中心处。

图65是图64的续表。

图66是根据一些实施例的示出场景编解码器的应用编程接口功能的示意图。

图67是根据一些实施例的示出查询处理器功能的功能的示意图。

图68A是根据一些实施例的用于实现全光投影引擎的过程的流程图。

图68B是根据一些实施例的用于从全光八叉树提取子场景以进行远程传输的过程的流程图。

图69是根据一些实施例的用于出于从多个视点生成图像的目的而从场景数据库提取子场景模型的过程的流程图。

图70是根据一些实施例的用于累加对查询立元贡献光的全光基元的过程的流程图。

图71是根据一些实施例的用于累加介质元素(“介元(mediel)”)及其对查询立元贡献光的有贡献的光场元素(“辐元(radiel)”)的过程的流程图。

图72是根据一些实施例的具有小矩形区域的厨房的图像，该小矩形区域突出显示分析入口。

图73是根据一些实施例的按比例放大的图72的厨房的一部分的图像，其中图72的矩形窗口突出显示分析入口。

图74是根据一些实施例的按比例放大以示出显示在图73的分析入口中的分析元素的图73所示的矩形区域的图像。

图75示出与实施例的有效性的证据有关的示意图。

图76示出与实施例的有效性的证据有关的示意图。

图77示出与实施例的有效性的证据有关的示意图。

图78是示出出于图像生成目的的子场景提取的示意图。

在以下描述中，阐述了许多具体细节，诸如具体部件的实例、使用场景的类型等，以提供对本公开的透彻理解。然而，对于本领域的技术人员将显而易见的是，可以在没有这些具体细节的情况下并且利用替代实现方式来实践本公开，其中一些实现方式也在本文描述。在其他情况下，没有详细描述众所周知的部件或方法，以避免不必要地使本公开变得复杂。因此，阐述的具体细节仅仅是示例性的。具体细节可以与本公开的精神和范围有所不同并且仍被认为在本公开的精神和范围内。

具体实施方式

一种用于提供变化广泛的场景表示的全面解决方案，这些场景表示诸如子场景和子场景的增量，这两者都使用最少的场景数据来满足复杂的用户请求，同时“前瞻”预期足够的缓冲区(扩展到请求的场景数据)，以确保连续的服务质量。根据示例性实施例的编解码器解决与进行中的场景消耗相对应的进行中的场景重建，其中多个实体在任何时刻都在提供场景数据或消耗场景数据，其中提供场景数据包括重建的场景数据和新确定的真实场景未重建数据。

在某些示例性实施例中，场景分布较少“基于文件”(即，较少关注全场景信息的一对一单向管道)，而较多“基于文件段”(即，较多关注准时化、仅按需的子场景和子场景增量信息的多对多双向管道)。在某些示例性实施例中，此多路配置是自学习的、追踪场景数据的提供和消耗，以便确定最佳的负载平衡并在可能更多数量的场景服务器和场景客户端之间共享。示例性实施例中的场景处理考虑了所有类型数据的合并，其中场景模型是可索引、可增强、可转换的对象，具有与几乎所有其他类型的数据的连接，其中场景然后为各种类型的数据提供上下文，并且自身可以基于所有类型的数据进行搜索。

在示例性实施例中，场景可以被认为是物质场和光场在空间和时间上占据的区域。根据一些实施例的示例性系统支持自由视图、自由物质和自由光下的场景可视化，其中自由视图允许用户自我导航场景，自由物质允许用户物化、限定、量化、增强和以其他方式转换场景，并且自由光允许用户重现场景，甚至考虑到各种光源的独特光谱输出以及光强度和偏振方面的考虑，所有这些都增加了场景模型真实感。自由物质和自由光的结合使用户能够将场景重新上下文化为各种设置，例如在冬天的早晨或夏天的夜晚体验布拉格城市之旅。

尽管人类对场景数据的可视化总是很重要，但是根据一些实施例的编解码器提供了一批场景数据类型和功能，包括度量、对象识别、场景和态势感知。场景数据可以包括可在真实世界中确定的数据和元数据的整个范围，该范围仅受限于场景模型中包括的物质场和光场细节的范围，其中然后必须根据消耗者的范围来格式化此数据范围，这些消耗者从人类到AI系统再到自动机，该自动机诸如搜寻和救援自动机，其在实时建模的灾难现场上爬行或飞行，使用高级对象识别搜索特定的对象和人员。这样，根据示例性实施例的编解码器是自由视图、自由物质、自由照明和自由数据。

根据一些实施例的编解码器实现了用于高效子场景以及场景增量、提取和插入的新装置和方法，其中这种效率的技术改进大大降低了计算机处理要求，诸如计算时间以及相关联的电源要求。鉴于对多路、准时化、仅按需的场景重建和分布的市场需求预计会上升，需要包括定制计算机芯片的新型场景处理单元，这些新型场景处理单元嵌入针对真实、复杂和高度详细的场景的新表示和表示组织进行了优化的新种类指令集。

参考图1A，示出了根据一些示例性实施例的描绘使用场景编解码器的系统1A01的关键部件的框图。系统1A01提供了场景模型的重建、分布和处理的重大技术改进，其中通常将真实场景理解为三维空间，但也可以包括时间的第四维，使得真实场景的空间方面可以随时间而改变。场景模型可以是真实场景重建或计算机生成的场景或场景增强中的任何一个或任何组合。系统1A01解决了全局场景模型的重大挑战，其中全局场景模型通常被理解为代表更大的真实世界空间，终端用户以其空间增量完成的体验和探索(在本文中称为子场景)。在一个实例中，全局真实场景是诸如布拉格的主要旅游城市，其中在真实世界中，探索布拉格将需要在包括大量空间详细信息的整个子场景中进行许多天的空间移动。特别是对于较大的真实场景，场景入口点、遍历路径和沿遍历路径的视点的组合创建了几乎无限量的信息，因此需要包括压缩的智能场景建模和处理。

为了以后的有效描述，当本公开涉及场景或子场景时，应将其理解为场景模型或子场景模型，因此与被理解为存在并且该模型至少部分地源自其的真实场景或真实子场景相反。然而，本公开可能不时地将场景描述为真实或真实世界，以讨论真实世界而不会与建模世界混淆。还应理解，术语“观看者”和“用户”可以无区别地互换使用。

系统1A01被配置为以高效的实时或近实时方式智能地向用户提供对几乎无限场景的访问。全局场景可以被认为是本地场景的组合，其中本地场景不那么广泛，但也必须以空间增量的方式进行探索。本地场景以及因此全局场景可以具有入口点，其中首先向用户呈现场景信息。场景入口点本质上是子场景，其中例如，“布拉格”全局场景模型中的场景入口点是“圣克莱门特大教堂的前廊”，其中再次可以理解，系统1A01提供的用于表示“大教堂”子场景的数据通常比“布拉格”全局场景的整个数据要少得多。在一些示例性实施例中，提供的子场景，诸如“圣克莱门特大教堂”由系统确定为足以满足终端使用要求的最小场景表示。在一些示例性实施例中，系统对这种充分性的确定提供了许多优势。通常，充分性的确定至少包括基于请求的或期望的场景观看方向来提供具有变化水平的物质场和/或光场分辨率的子场景模型信息。例如，可以为附近的对象而不是视觉上遥远的对象提供更高分辨率的信息。术语“光场”是指场景中所有区域在所有方向上的光流，并且术语“物质场”是指占据场景中区域的物质。在本公开中，术语“光”是指在包括可见、红外和紫外带的频率下的电磁波。

此外，根据一些示例性实施例，系统1A01出于诸如例如提供“前瞻”场景分辨率的目的而智能地为子场景提供空间缓冲区。在“圣克莱门特前廊”的子场景实例中，最低分辨率可能期望静止站在圣克莱门特大教堂入口处的观看者，但是然后旋转360度，在任何方向上看，例如朝向或远离大教堂。尽管假定观看者仍然站在前廊中，这个最小分辨率就足够了，但是如果观看者希望接近并进入大教堂，这最终将导致大教堂方向上的分辨率降至服务质量(QoS)阈值以下。系统期望观看者请求移动，并且作为响应包括另外的非最小分辨率，使得如果观看者移动其自由视点，则观看者将不会感觉到场景分辨率的任何实质损失。在本实例中，此另外的非最小分辨率可以包括足以在QoS阈值下观看全部布拉格的分辨率，除非这反过来会造成大量过剩且最可能不使用的数据处理和传输，可能会对不间断的实时观看体验造成不利影响。因此，场景缓冲区的概念是基于所有已知信息(包括观看者的可能遍历路径、遍历路径视点和遍历移动速率)智能地确定并提供一定数量的另外非最小分辨率。

系统1A01展现出关于场景以及用户体验和请求访问场景的高度上下文感知，其中在一些示例性实施例中，基于一个或两个机器学习的应用以及由系统1A01执行的场景体验日志记录的累加，增强了这种上下文感知。对于多个用户随时间体验的全局场景(诸如布拉格)，个人用户的至少遍历度量(包括选定的入口点、遍历路径、遍历路径视点和遍历移动速率)的登录为系统1A01的机器学习部件提供重要信息，以帮助调整空间缓冲区的大小，因此，通过最少(或基本上最少)量的提供的场景信息来确保最多(或基本上最多)连续的用户体验，其中在一些示例性实施例中，此最多-最少关系是系统1A01的场景压缩技术的重点。系统1A01解决的场景压缩的另一个关键方面是场景处理时间，该时间高度依赖于代表真实世界场景的场景模型数据的新颖布置，其中在本文中此数据通常是指全光场景模型，并且存储在全光场景数据库1A07中。

熟悉术语“全光”的人会将其识别为场景中特定点的5维(5D)表示，从中可以体验到4π球面度移动，因此场景中的任何点(x,y,z)可以被认为是球体的中心，从该球体可以从中心点向外沿任何方向(θ,

系统1A01还包括空间处理单元(SPU)1A09，用于为了场景重建和场景分布而实质上处理全光场景数据库1A07。如本文将要讨论的，重建通常是添加或建立场景数据库以增加场景的各种数据表示中的任何一种的过程，例如但不限于：1)时空扩展，其为真实场景的三维体积，例如从针对损害被检查的汽车引擎盖到针对旅游被遍历的布拉格；2)空间细节，其至少包括相对于体验场景的用户可感知的空间敏锐度极限的场景的视觉表示，其中视觉空间敏锐度通常被理解为人类视觉系统的功能，并且限定了人类用户可区分的大约0.5至1.0弧分的每立体角最大细节分辨率，使得除非用户通过移近场景区域来更改其空间位置以有效增加立体角内的场景区域，否则任何其他细节对于用户来说是基本无法感知的；3)光场动态范围，其包括代表感知场景的光的强度和色域，其中例如，可以智能地更改动态范围以便为被认为是前景相对于背景的场景部分提供更大的色彩范围；以及4)物质场动态范围，其包括空间特性(例如，表面形状)以及描述物质在一个场景中对场景光场的透射、吸收和反射的影响的光相互作用特性。然后，子场景提取是由系统1A01使用SPU 1A09智能且有效地确定相对于全光场景数据库1A07中代表场景的信息的各个维度的最小场景信息数据集，其中再次对于用户的体验而言，最重要的是，此最小数据集(子场景)提供具有足够场景分辨率(例如，满足预定QoS阈值的连续性和/或分辨率)的基本连续体验。

至少在一些实施例中，系统1A01可以包括场景求解器1A05，其用于在场景重建过程和子场景分布过程中的一个或多个期间提供机器学习。在场景求解器1A05中，在提供具有最小或至少可接受的场景损失的最大场景压缩时，可以考虑辅助场景信息，诸如例如指示场景入口点、遍历路径、视点和有效场景增量步速的信息。

系统1A01还包括请求控制器1A13，其用于接收通过由应用软件1A03实现的用户接口指示的请求。接收到的请求被转换为控制分组1A17，以便使用场景编解码器1A11与另一个联网系统进行通信。因此，系统1A01还能够接收由其他联网系统1A01生成的请求。接收到的请求由系统1A01独立地由请求控制器1A13处理，或者由请求控制器1A13和应用软件1A03组合处理。控制分组1A17可以携带显式和隐式用户请求中的一个或两个，其中显式请求表示用户的有意识决定，诸如为场景选择特定的可用入口点(例如，圣克莱门特大教堂作为游览布拉格的起点)，而隐式用户请求可以表示用户的潜意识决定，诸如检测用户相对于当前场景的头部朝向(例如，由附接到全息显示器上的相机传感器或设置在虚拟现实(VR)耳机内的惯性传感器检测到的)。由于一些用户请求是半意识的，例如，可能由VR系统中的运动控制器的移动指示的场景增量步速，显式和隐式的这种区别意为说明性的而不是限制性的。

场景编解码器1A11被配置为响应于可能包含在控制分组1A17内的用户请求，在并且如果系统1A01用作场景提供者时，优选地提供准时化的场景数据分组。在并且如果系统1A01用作场景消耗者时，可以进一步使场景编解码器1A11能够接收场景数据分组1A15并对其做出响应。例如，系统1A01可以是从全光场景数据库1A07提取到多个其他系统1A01的场景信息的提供者，这些其他系统接收所提供的场景信息以供终端用户潜在消耗。全光场景数据库1A07中包括的场景信息可能不限于严格的视觉信息，因此在一些示例性实施例中还可以包括例如最终由例如用户通过观看某种形式的图像输出设备来接收的信息。应当理解，在一些示例性实施例中，场景信息还可以包括至少部分地从场景的物质场和光场转换的任何数量的元信息，诸如场景计量(例如桌子的大小)或场景识别(例如光源的位置)或相关信息，诸如不是物质场或光场而是与物质场和光场的任何组合或部分相关联的辅助信息。示例性辅助信息包括但不限于场景入口点、场景对象标签、场景增强和数字场景标牌。

系统1A01可以被配置用于输出和接收场景数据分组1A15中的一个或两个。此外，诸如系统1A01的系统之间的场景数据分组1A15的交换可能不是同步的或同质的，而是最小地响应以最大程度地满足用户的请求，如主要在控制分组1A17中或者以其他方式通过由应用软件1A03提供的用户接口或应用接口表达的。特别是相对于场景数据分组1A15的周期性，与传统的编解码器相反，场景编解码器1A11可以异步操作，其中例如，准时化且仅按需或甚至准时化且仅按预期地提供代表具有给定场景缓冲区大小的场景增量的子场景数据，其中“需要”更多是显式用户请求的功能，而“预期”更多是隐式用户请求的功能。特别是相对于场景数据分组1A15的内容构造，与传统的编解码器相反，场景编解码器1A11可以操作以提供异构场景数据分组1A15，其中例如，准时化分组包括物质场信息、光场信息、辅助信息或其任何转换中的任何一个或任何组合。

还应理解，“用户”不限于人，并且可以包括任何请求者，诸如另一自主系统1A01(例如，参见即将到来的图3中描绘的陆基机器人、UAV、计算机或云系统)。如熟悉自主系统的人会很好地理解的，此类自主系统可以对本质上包含视觉表示信息的场景表示具有重要的用途，例如，自主系统1A01可在搜索和查找操作中使用场景的已知图片，以与自主系统1A01在真实世界场景中捕获的视觉信息进行比较，该真实世界场景对应于或类似于包括在全光场景数据库1A07内的场景。此外，此类自主系统1A01可以优选地用于非视觉信息或准视觉信息，其中非视觉信息可以包括场景和场景对象度量，而准视觉信息可以包括场景照明属性。在一些示例性实施例中，自主或人类操作系统1A01也可以被配置为收集并提供场景的非可视表示，用于全光场景数据库1A07内的可能的空间甚至对象搭配，或者至少用于进一步描述作为辅助信息的场景(例如，参见示出场景数据库视图的即将到来的图4C)。例如，非视觉表示包括其他感觉信息，诸如躯体感觉(触觉)、嗅觉(气味)、试音(听觉)或甚至味觉(品味)。为了本公开的目的，在关注场景表示作为视觉信息的情况下，此关注不应被理解为限制，而应被理解为特性，其中然后至少应理解，全光场景数据库可以包括任何感觉信息或感觉信息的转换，尤其包括人类用户经常要求的音频/视觉数据。

接下来参考图1B，示出了根据一些示例性实施例的包括在系统1A01中的任何一个内的场景编解码器1A11的框图，其中场景编解码器1A11包括编码器1B11a和解码器1B11b。如关于图1A所描述的，编码器的主要功能是确定并提供场景数据分组1A15，大概是通过网络被至少一个其他系统接收，诸如例如另一系统1A01，使该另一系统能够(通过包括解码器，诸如例如解码器1B11b)接收并处理场景数据分组。编码器1B11a可以接收控制分组1A17并对其做出响应。关于下面即将到来的图7描述了包括场景编解码器1A11的系统1A01的用例，这些场景编解码器包括编码器1B11a和解码器1B11b。

接下来参考图1C，示出了根据一些示例性实施例的仅包括编码器1B11a(并因此不包括如图1B所描绘的解码器1B11b)的场景编解码器1A11的框图。关于下面即将到来的图5和图6描述了包括场景编解码器1A11的系统1A01的用例，这些场景编解码器仅包括编码器1B11a。

接下来参考图1D，示出了根据一些示例性实施例的仅包括解码器1B11b(并因此不包括如图1B所描绘的编码器1B11a)的场景编解码器1A11的框图。关于下面即将到来的图5和图6描述了包括场景编解码器1A11的系统1A01的用例，这些场景编解码器仅包括解码器1B11b。

接下来参考图1E，示出了网络1E01的框图，该网络包括用于连接两个或更多个系统1A01的传输层。网络1E01可以表示用于在任何两个或更多个计算系统之间传输信息的任何手段或通信基础设施，其中在示例性实施例中，主要关注的计算系统是系统1A01，但是至少在一些实施例中，不限于此。如熟悉计算机网络的人会很好地理解的，当前有许多网络变型，诸如个人局域网(PAN)、局域网(LAN)、无线局域网(WLAN)、校园局域网(CAN)、城域网(MAN)、广域网(WAN)、存储区域网(SAN)、无源光局域网(POLAN)、企业专用网(EPN)以及虚拟专用网(VPN)，其任何一个及全部可以是目前描述网络1E01的实现方式。如熟悉计算机网络的人也会很好地理解的，传输层通常被理解为网络堆栈中协议分层架构中技术的逻辑划分，例如，相对于开放系统互连(OSI)通信模型被称为第4层。为了本公开的目的，传输层包括传送信息的功能，该信息诸如由任何两个或更多个系统1A01在网络1E01上交换的控制分组1A17和场景数据分组1A15。

仍然参考图1E，诸如通过网络1E01进行通信的系统1A01的计算系统经常被称为驻留在服务器侧(诸如1E05)或客户端侧(诸如1E07)上。典型的服务器-客户端区别最经常用于提供给Web浏览器(客户端侧)的Web服务(服务器侧)。应当理解，在示例性实施例内没有限制，例如，系统1A01内的应用软件1A03使用Web浏览器实现，而不是另一技术诸如桌面应用或甚至嵌入式应用，并且这样在本文中在最通常意义上使用术语服务器侧和客户端侧，使得服务器是确定并提供场景数据分组1A15的任何系统1A01，而客户端是接收并处理场景数据分组1A15的任何系统1A01。同样，服务器是接收并处理控制分组1A17的任何系统1A01，而客户端是确定并提供控制分组1A17的任何系统1A01。系统1A01可以用作服务器或客户端，或者单个系统1A01可以用作服务器和客户端。因此，本文中相对于网络、传输层、服务器侧和客户端侧提供的框图和描述应当被认为对于传送信息有用，而不是作为示例性实施例的限制。图1E还示出了系统1A01的网络1E01可以包括在任何给定时间用作服务器的一个或多个系统1A01以及在任何给定时间用作客户端的一个或多个系统1A01，其中再次应理解，给定的系统1A01可以交替或基本同时用作场景数据的服务器和场景数据的客户端。

在图1E中，还描绘了一个或多个可选传感器1E09和一个或多个可选传感器输出1E11，其可以被包括在一些示例性实施例中。应理解的，系统1A01既不需要一个或多个传感器1E09也不需要一个或多个传感器输出1E11来执行有用的功能，诸如从例如用于场景重建的其他系统1A01接收场景数据分组1A15，或者诸如将场景数据分组1A15提供给其他系统1A01以进行进一步的场景处理。替代地，系统1A01可包括任何一个或多个传感器1E09，诸如但不限于：1)成像传感器，其用于检测针对诸如强度和偏振的光特性中任一者而过滤的诸如紫外光、可见光或红外光的多光谱数据范围中的任何一个；2)距离传感器或通信传感器，其可以至少部分地用于确定距离，诸如激光雷达、飞行时间传感器、超声、超宽带、微波和其他基于射频的系统；以及3)任何非视觉传感器，其例如能够检测其他感觉信息，诸如躯体感觉(触觉)、嗅觉(气味)、试音(听觉)或甚至味觉(品味)。重要的是要理解，要在全光场景数据库1A07中表示的真实世界场景通常包括通常被理解为视觉数据的场景，其中此数据不必限于已知为可见光谱的数据，而是真实世界场景还包括可以使用当今可用传感器中的任一者感知的大量另外信息以及未来传感器可检测的另外已知或未知数据。在示例性实施例的精神上，所有此类传感器可以提供可用于如本文所述的重建、分布和处理场景的信息，并因此是一个或多个传感器1E07。同样，存在许多当前已知的一个或多个感觉输出端1E09，诸如但不限于2D、3D、4D视觉呈现设备，其中这些视觉呈现设备经常包括伴随的1D、2D或3D听觉输出设备。一个或多个感觉输出端1E09还包括任何当前已知的、未来的设备，这些设备用于提供任何形式的感觉信息，包括视觉、听觉、触觉、气味甚至品味。任何给定的系统1A01可以包括零个或多个传感器1E07和零个或多个传感器输出1E09。

接下来参考图1F，示出了根据一些示例性实施例的场景编解码器1A11中的编码器1B11a的框图，该场景编解码器至少包括编码器1B11a。场景编解码器1A11的API接口1F03从API控制主机接收应用接口(API)调用1F01并对其做出响应，其中主机是例如应用软件1A03。API 1F03与各种编解码器部件进行通信，包括分组管理器1F05、编码器1B11a和非全光数据控件1F15。API 1F03提供了：从主机(诸如应用软件1A03)接收控制信号(诸如命令)：至少部分地基于主机控制信号中的任一者向包括1F05、1B11a和1F15的各种编解码器部件提供控制信号(诸如命令)；从包括1F05、1B11a和1F15的各种编解码器部件接收控制信号(诸如部件状态指示)；以及至少部分地基于部件状态指示中的任一者向主机(诸如应用软件1A03)提供控制信号(诸如编解码器状态指示)。API 1F03的主要目的是为外部主机提供用于控制场景编解码器1A11的单点相互作用，其中API 1F03例如是在处理元件上执行的一组软件功能，其中在一个实施例中，用于执行API 1F03的处理元件是场景编解码器1A11专有的。此外，API 1F03可以按照主机1F01的命令执行用于控制进行中的过程的功能，使得单个主机命令在API 1F03与包括1F05、1B11a和1F15的各种编解码器部件之间生成多个信号和通信。在执行场景编解码器1A11的内部处理期间的任何时间，API 1F03至少部分地基于相对于API 1F03实现的接口合约，确定诸如状态更新的响应是否有必要提供给主机1F01，所有如熟悉软件编程尤其是面向对象编程的人会理解的。

仍然参考图1F，各种部件1F05、1B11a和1F15中的每一个按需要彼此通信，以交换与场景编解码器1A11实现的内部处理中的任一者相对应的控制信号和数据。在场景编解码器1A11的正常操作期间，分组管理器1F05接收一个或多个控制分组1A17以供编解码器1A11内部处理，并且基于编解码器1A11的内部处理来提供一个或多个场景数据分组1A15。如熟悉网络系统的人会理解的，在一个实施例中，场景编解码器1A11在所谓的分组交换网络上实现数据传输协议，以用于传输被划分为称为分组的单元的数据，其中每个分组包括用于描述该分组的标头以及是分组内正传输的数据的有效载荷。如关于图1E所讨论的，示例性实施例可以在多种网络1E01类型上实现，其中例如，使用场景编解码器1A01的多个系统通过是分组交换网络1E01的互联网进行通信。诸如互联网的分组交换网络1E01使用传输层1E03协议，诸如TCP(传输控制协议)或UDP(用户数据报协议)。

TCP在本领域中是众所周知的，并且提供了许多优势，诸如消息确认、重传和超时以及已传输数据序列的正确排序，但通常限于本领域中所谓的单播，其中单个服务器系统1A01每个单个TCP流向单个客户端系统1A01提供数据。使用TCP，单个服务器系统1A01仍然可以与多个客户端系统1A01建立多个TCP流，并且反之亦然，这是因为要理解，传输的控制分组1A17和数据分组1A15仅在形成单个TCP连接的两个系统之间交换。已知诸如UDP(用户数据报协议)的其他数据传输协议用于支持本领域中称为多播的内容，或者用于支持称为广播的内容，其中与单播不同，这些协议允许例如多个客户端系统1A01接收同一场景数据分组1A15的流。UDP的局限性在于，客户端一接收到传输的数据就不会对其进行确认，并且不会保持分组的发送顺序。分组管理器1F05可以适于基于用于传送分组1A17和1A15的TCP或UDP传输层协议中的至少一个来实现可用的数据传输协议中的任何一种，其中可能新协议在未来变得可用或者现有协议将被进一步修改，使得实施例不应不必要地局限于数据传输协议或传输层协议的任何单个选择，而是应基于特定实施例的许多特征的期望实现来选择为实现使用场景编解码器1A01的系统的特定配置而选择的协议。

仍然参考图1F，分组管理器1F05解析每个接收到的控制分组1A17，例如通过处理分组的标头和有效载荷中的任何一个，以便确定各种类型的分组1A17内容，包括但不限于：1)对全光场景数据的用户请求；2)对非全光场景数据的用户请求；3)场景数据使用信息；以及4)客户端状态信息。分组管理器1F05向编码器1B11a提供与对全光场景数据的用户请求有关的任何信息，其中编码器1B11a至少部分使用查询处理器1F09处理用户的请求以访问全光场景数据库1A07。查询处理器1F09至少部分地包括子场景提取器1F11，其用于有效地提取包括子场景或子场景的增量的所请求的全光场景数据。然后将所提取的请求的全光场景数据提供给分组管理器1F05，以将其作为有效载荷插入场景分组1A15中，以传输到请求(客户端)系统1A05。在一个实施例中，分组管理器1F05还优选地在包括所请求的全光场景数据的场景数据分组1A15中插入足以标识原始用户请求的信息，使得接收客户端系统1A05接收原使用户请求的指示和提供来满足原始请求的全光场景数据。在操作期间，编码器1B11a、查询处理器1F09、分组管理器1F05中的任何一个并且尤其是子场景提取器1F11可以调出编解码器SPU 1F13以有效地处理全光场景数据库1A07，其中编解码器SPU1F13可以被配置为实现本文描述的用于有效地处理相对于全光场景数据库1A07的表示及表示的组织的各种技术优势。

在示例性实施例中的用于将真实世界场景表示为全光场景模型的表示以及这些表示的新颖组织用于全光场景数据库1A07。用于处理全光场景数据库1A07的装置和方法，以及在示例性实施例中与实施例中使用的表示和组织相结合，提供了重要的技术优势以便然后快速且有效地提取请求的子场景或子场景的增量，这些技术优势诸如有效查询可能表示非常大、复杂且详细的真实世界场景的全光场景数据库的能力。如熟悉计算机系统的人会理解的，场景编解码器1A11可以以软件和硬件的许多组合实现，例如，包括更高水平的编程语言，诸如在通用CPU上运行的C++，或在FPGA(现场可编程门阵列)上运行的嵌入式编程语言，或包括在ASIC(专用集成电路)内包括的基本硬编码的指令集。此外，场景编解码器1A11部件和子部件中的任何一个都可以以软件和硬件的不同组合来实现，其中在一个实施例中，编解码器SPU 1F13被实现为诸如包括在ASIC内的基本硬编码的指令集。替代地，在一些实施例中，编解码器SPU 1F13的实现是与至少场景编解码器1A11通信的单独的硬件芯片，使得实际上编解码器SPU 1F13在场景编解码器1A11的外部。

如熟悉计算机系统的人会理解的，场景编解码器1A11还可以包括存储器或其他数据存储元件，这些其他数据存储元件用于保存全光场景数据库1A07的至少一些或全部，或者数据库1A07的与全光场景模型最相关的复制部分，其中复制的部分可以例如以本领域中称为高速缓存的方式实现。重要的是要看到，尽管目前将全光场景数据库1A07描绘为在场景编解码器1A11的外部，但在本场景编解码器的替代实施例中，全光场景数据库1A07的至少一些部分保留在场景编解码器1A11内或甚至在编码器1B11a内。因此，重要的是要理解，目前所描绘的具有至少一个编码器的场景编解码器的框图是示例性的，并因此不应视为示例性实施例的限制，因为场景编解码器1A11的各种部件和子部件的许多变型和配置是可能的，而不脱离所描述实施例的精神。

仍然参考图1F，分组管理器1F05将场景数据使用信息中的任何一个提供给编码器1B11a，其中编码器1B11a将使用信息或至少部分基于使用信息的其他计算出的信息插入到全光场景数据库1A07中(尤其参见即将到来的全光数据库数据模型视图图4C和即将到来的用例图5、图6和图7，以获得关于使用信息的更多细节)。如将进一步讨论的，使用信息对于优化示例性实施例的功能非常有价值，这些示例性实施例的功能至少包括确定理想地服务用户请求的子场景或场景增量的信息化程度。分组管理器1F05还向编码器1B11a提供任何客户端状态信息，其中编码器1B11a至少部分地基于从客户端系统1A01接收的客户端状态信息中的任一者来维持客户端状态1F07。重要的是要理解，场景编解码器1A11可以支持多个客户端系统1A01，并且对于每个受支持的客户端系统1A01，维持不同的客户端状态1F07。如将尤其关于即将到来的用例图5、图6和图7进一步讨论的，客户端状态1F07至少足以允许编码器1B11a确定已经成功接收并且可用于客户端系统1F07的全光场景数据库1A07信息的范围。

与用于提供一些类型的其他场景数据1F19(诸如电影)的传统编解码器不同，具有编码器1B11a的场景编解码器1A11将全光场景数据1A07或其他场景数据1F19中的任一者提供给请求客户端系统1A01。而且，与传统的编解码器不同，由场景编解码器1A11提供的至少全光场景数据1A07具有这样的性质，即，它在被客户端系统1A01接收和处理时不一定被完全消耗。例如，利用传统的编解码器流式传输电影，该电影包括通常以某种格式(诸如MPEG)编码的一系列图像帧，因为图像的编码流由传统的客户端系统解码，每个下一个解码图像基本上实时呈现给用户，此后解码图像基本上没有其他价值，或至少没有其他即时值，因为然后向用户呈现下一个解码图像，依此类推，直到接收、解码并呈现整个图像流为止。

相反，目前场景编解码器1A11至少提供全光场景数据1A07，诸如子场景或场景增量，该全光场景数据既可立即供客户端系统1A01的用户使用，又保留了另外的实质性未来价值。如将至少相对于即将到来的用例图5、图6和图7进一步讨论的，具有编码器1B11a的编解码器1A11例如在场景数据分组1A15内传输代表服务器的全光场景数据库1A07的一些请求部分的子场景或子场景增量，其中为了两个基本同时的目的，场景数据分组1A15然后由请求客户端系统1A01接收并解码，这些目的包括立即向用户提供数据以及插入客户端全光场景数据库1A07。然后，应该进一步理解的是，通过将接收到的全光子场景或子场景增量插入到客户端数据库1A07中，然后使所插入的场景数据可用于以后直接用于响应来自客户端全光场景数据库1A07的潜在未来用户请求时使用，而不需要来自服务器全光场景数据库1A07的任何另外的场景数据。在将子场景或子场景增量插入到客户端全光场景数据库1A07中之后，客户端系统1A01然后将客户端状态信息作为反馈提供给提供场景编解码器1A11，其中，在控制分组1A17内提供了客户端状态信息，并且其中然后编码器1B11a使用解析的客户端状态信息来更新并维持对应的客户端状态1F07。

通过接收并维持与提供给客户端系统1A01的场景数据分组1A15的流相关联的客户端状态1F07，具有编码器1B11a的编解码器1A11然后能够至少确定满足从对应的客户端系统1A01接收的用户下一个请求所需的新服务器全光场景数据库1A07的信息的最小范围。同样重要的是要理解，在一些用例下，客户端系统1A01正在从两个或更多个服务器系统1A01接收全光场景数据，这些服务器系统包括具有编码器1B11a的场景编解码器1A11。在这些用例中，客户端系统1A01基于从所有服务器系统1A01接收到的场景数据分组1A15，优选地通知每个服务器系统1A01关于客户端的状态信息的变化。在这种布置中，有可能在负载平衡情况下可以使用多个服务系统1A01来通过使用服务系统1A01中的任一者上的全光场景数据库1A07中的任一者来方便地满足从单个客户端系统1A01发出的用户请求，好像所有服务系统1A07共同提供单个虚拟全光场景数据库1A07。

仍然参考图1F，分组管理器1F05将对非全光场景数据的用户请求中的任一者提供给非全光数据控件1F15，其中非全光数据控件1F15与一个或多个非全光数据编码器1F17进行通信。一个或多个非全光数据编码器1F17包括将来自其他场景数据数据库1F19的其他场景数据提供给数据控件1F15的任何软件或硬件部件或系统。重要的是要理解，在一些实施例中，具有编码器1B11a的编解码器1A11不需要访问诸如包括在其他场景数据数据库1F19内的其他场景数据，并因此不需要访问一个或多个非全光数据编码器1F17，或者甚至需要在编解码器1A11内实现非全光数据控件1F15。对于具有编码器1B11a的场景编解码器1A11的实施例，该场景编解码器可能需要或预期需要对包括在服务器全光场景数据库1A07内的全光场景数据和包括在其他场景数据数据库1F19内的其他场景数据的某种组合进行编码，场景编解码器1A11至少部分地使用由非全光数据编码器1F15提供的其他场景数据来确定任何一个或多个场景数据分组1A15的有效载荷中的至少一些。示例性其他场景数据1F19包括不是全光场景数据库1A07信息的任何信息(尤其参见即将到来的图4C以讨论全光场景数据库1A07信息)，包括视频、音频、图形、文本或其他数字信息，其中确定需要此其他数据来对包括在控制分组1A17内的客户端系统1A01请求做出响应。例如，全光场景数据库1A07中的场景可以是待售房屋，其中存储在数据库1F19中的其他场景数据包括相关视频、音频、图形、文本或其他数字信息中的任一者，该数字信息诸如与房子中的对象诸如家具相关的产品视频。

重要的是要注意，全光场景数据库1A07具有用于存储传统视频、音频、图形、文本或其他数字信息中的任一者以与全光场景数据(为了其他细节尤其参见即将到来的图4C)相关联的规定，并因此包括编码器1B11a的场景编解码器1A11能够提供其他数据，诸如从服务器全光场景数据库1A07或其他场景数据数据库1F19接收的视频、音频、图形、文本或其他数字信息。如熟悉计算机系统的人也会理解的，在不同形式的数据库中存储不同形式的数据是有利的，其中不同形式的数据库可以然后也驻留在数据存储和检索的不同手段中，其中例如从数据存储成本角度看一些手段更经济并且从检索时间角度看其他手段更经济，并因此对于本领域技术人员将显而易见的是，至少在一些实施例中，优选地将全光场景数据与任何其他场景数据基本分开。

一个或多个非全光数据编码器1F17包括能够访问至少另一个场景数据数据库1F19并检索至少一些其他场景数据以提供给数据控件1F15的任何处理元件。在本发明的一些实施例中，将场景数据与其他非场景数据相关联的信息维持在全光场景数据库1A07内，使得一个或多个非全光数据编码器1F17优选地能访问服务器全光场景数据库1A07以确定应从其他场景数据数据库1F19检索其他场景数据1F17中的任一者中的哪个来满足用户的请求。在一个实施例中，非全光数据编码器1F17包括处理元件中的任一者，这些处理元件能够检索处于第一格式一些其他场景数据，将该第一格式转换成第二格式，并然后将处于第二格式的转换后场景数据提供给数据控件1F15。在至少一个实施例中，第一格式是例如未压缩的视频、音频、图形、文本或其他数字信息，并且第二格式是用于表示视频、音频、图形、文本或其他数字信息的压缩格式中的任一者。在另一实施例中，第一格式是例如用于表示视频、音频、图形、文本或其他数字信息的第一压缩格式中的任一者，并且第二格式是用于表示视频、音频、图形、文本或其他数字信息的第二压缩格式中的任一者。还期望至少在一些实施例中，一个或多个非全光数据编码器1F17简单地从数据库1F19提取其他场景数据以提供给数据控件1F15而无需格式变换，其中所提取的其他场景数据已经处于压缩格式或者处于未压缩格式。

仍然参考图1F，有可能用户请求例如基于全光场景数据的渲染视图用于全光场景数据和其他场景数据。在这种用例中，分组管理器1F05将初始用户请求提供给编码器1B11a，该编码器提取所请求的全光场景数据并然后将所提取的全光场景数据提供给非全光数据控件1F15。然后数据控件1F15将非全光数据提供给非全光数据编码器1F17，该非全光数据编码器可以将全光场景数据转换成例如所请求的场景渲染视图，其中然后将作为其他场景数据的此渲染视图提供给数据控件1F15，以包括一个或多个场景数据分组1A15的有效载荷。如将尤其关于即将到来的图1G显而易见的，替代地，可以简单地将所提取的全光场景数据传输到一个或多个场景数据分组1A15中的客户端系统1A01，其中在客户端系统1A01上包括解码器1B11b的编解码器1A11然后使用在一个或多个场景数据分组1A15中接收的所提取全光场景数据来渲染请求的场景视图。如仔细考虑将显示的，这种灵活性为使用场景编解码器1A11的通信系统网络提供了多种选择，以最有效地满足任何给定的用户请求。

仍然参考图1F，关于包括编码器1B11a的场景编解码器1A11可以处理的场景数据并发流的数量没有限制，其中应该理解的是，具有编码器的编解码器1A11在这个方面不同于具有编码器的传统编解码器，该传统编解码器通常将单个数据流提供给单个解码器(常常成为单播)或多个解码器(常常称为多播或广播)。尤其是如关于前图1E、图1E描绘的，本发明的一些示例性实施例提供了单个服务系统1A01(包括至少包括编码器1B11a的场景编解码器1A11)与多个客户端系统1A01(包括至少包括解码器1B11b的场景编解码器1A11)之间的一对多关系。本发明的一些实施例还提供了单个客户端系统1A01与多个服务系统1A01之间的多对一关系，以及多个服务器系统1A01与多个客户端系统1A01之间的多对多关系。

接下来参考图1G，示出了至少包括解码器1B11b的场景编解码器1A11的框图。在图1G中描述的许多元件与图1F中的那些元件相同或类似相同，并因此将不再详细讨论。如前面所讨论的，API控制主机1F01例如是在使用场景编解码器的系统1A01上或与其通信执行的应用软件1A03，其中例如软件1A03完全或部分地实现用户接口(UI)或者与UI通信。最终，诸如人或自动机的用户使用UI提供一个或多个显式或隐式指示，其中这些指示至少部分地用于确定对场景数据的一个或多个用户请求1G11。在通常意义上，在本文中将使用确定用户请求1G11的场景编解码器1A01的任何系统称为客户端系统1A01。如尤其关于即将到来的用例图5、图6和图7已经讨论并且将进一步讨论的，可能并甚至期望客户端系统1A01具有甚至足以满足给定用户请求1G11的场景数据。然而，还应理解，可能和有用的场景数据的总数将很可能远远超过任何给定客户端系统1A01的容量，例如，其中用于实现客户端系统1A01的计算平台是嵌入在诸如无人机或机器人的自动机内的移动计算设备或计算元件。因此，一些示例性实施例规定，确定一个或多个用户请求1G11的给定客户端系统1A01通过网络1E01能访问使用场景编解码器1A01的任何数量的其他系统，其中这些其他系统1A01中的任何一个或多个可以访问或包括足以满足给定用户请求1G11的场景数据。如将关于本图进一步讨论的，用户请求1G11可以然后通过网络传送到另一个系统1A01，该另一个系统包括至少包括编码器1B11a的场景编解码器1A11，其中此另一系统1A01在本文中称为服务器系统1A01，并且将最终向客户端系统1A01提供用户满足用户请求1G11的一个或多个场景数据分组1A15。

不存在将使用场景编解码器1A01的任何给定系统限于仅是客户端系统1A01或仅是服务器系统1A01的功能的限制，并且如将关于图5、图6和图7讨论的，给定的系统1A01可以在任何时间作为客户端和服务器中的一个或两个操作，其中客户端包括具有解码器1B11b的编解码器，并且服务器包括具有编码器1B11a的编解码器，使得包括具有解码器1A11b和编码器1A11a的编解码器1A11的系统1A01能够作为客户端系统1A01和服务器系统1A01起作用。

仍然参考图1G，在包括解码器1B11b的编解码器1A11中，API主机1F03与各种编解码器部件进行通信，这些部件包括分组管理器1F05、解码器1B11b和非全光数据控件1F15。分组管理器1F05接收用户请求1G11，这些用户请求处于足以与服务器系统1A01传送用户期望的场景数据的许多可能各种形式中的任一种，其中然后场景数据被广泛理解为包括全光场景数据库1A07内包括的场景数据中的任一者，和/或包括在另一场景数据数据库1G07内的其他场景数据中的任一者。其他场景数据包括视频、音频、图形、文本或其他数字信息中的任何一种。其他场景数据还可以存储在全光场景数据库1A07内并从其检索，尤其是作为辅助信息(参见相对于即将到来的图4C的元件4C21)。在整个本说明书中，提供描述以描述本文通常称为包括全光场景数据库1A07的各种数据类型，这些数据类型包括场景模型和辅助信息，该辅助信息包括场景模型增强、转换、索引和使用历史。场景模型通常可以包括物质场和光场。

应该注意的是，可以将本申请中描述的各种类型的场景数据和其他场景数据分类，其中此分类例如可以呈GUID(全局唯一标识符)或甚至是UUID(通用唯一标识符)的形式。此外，本文描述的用于将真实场景重建为场景模型以与其他场景数据相关联的本结构可应用于几乎无限数量的真实世界场景，其中然后为可用作场景模型的可能真实世界(或计算机生成的)场景的类型提供分类也很有用。因此，还可以分配GUID或UUID来表示各种可能的场景模型类型(例如城市景观、建筑物、汽车、房屋等)。也可以使用另一个GUID或UUID来然后独特地标识场景类型的特定实例，例如将汽车类型标识为“2016Mustang xyz”。也将理解，可以允许请求场景信息的给定用户保持匿名，或者同样被分配GUID或UUID。还可以为使用场景编解码器1A01的每个系统(无论充当服务器和/或客户端)分配GUID或UUID。此外，还可以将用户请求1G11分类成用户请求的类型(诸如“新的子场景请求”、“子场景增量请求”、“场景索引请求”等)，其中用户请求和类型和实际用户请求都可以被分配GUID或UUID。

在一些实施例中，包括诸如GUID或UUID的一个或多个标识符以及用于提供给分组管理器的特定用户请求1G11，其中然后分组管理器可以包括一个或多个另外的标识符，使得由包括解码器1B11b的场景编解码器1A11发出的控制分组1A17包括重要的用户请求分类数据，并且其中此分类数据中的任一者至少可用于：1)存储在数据库中，诸如由服务用户请求的服务器系统1A01维持的全光场景数据库1A07，或者在外部用户请求数据库中，该外部用户请求数据库通常可用于任何一个或多个系统1A01诸如服务用户请求的服务器系统1A01；以及2)确定用户请求1G11/控制分组1A17路由或场景数据提供负载平衡中的任一者，其中任何一个或多个请求流量处理代理可以通过网络1E01与客户端和服务器系统1A01中的任何一个或多个进行通信，以路由或重新路由控制分组1A17，尤其是为了平衡用户请求1G11的负载与服务器系统1A01的可用性和网络带宽的目的，所有如熟悉联网系统和管理网络流量的人会理解的。

仍然参考图1G，在一个实施例中，客户端系统1A01与服务器系统1A01唯一通信，其中客户端系统1A01提供包括在控制分组1A17内的用户请求1G11，并且服务器系统反过来提供满足用户请求1G11的场景数据分组1A15。在另一个实施例中，客户端系统1A01由两个或更多个服务器系统1A01服务。如关于图1F所讨论的，服务器系统1A01优选地包括场景数据分组1A15内的标识信息以及任何请求的场景数据(或其他场景数据)，使得客户端系统1A01上的编解码器1A11能够追踪接收到的场景数据的状态，包括存储在客户端系统1A01的全光场景数据库1A07内或客户端系统1A01的其他场景数据数据库1G07内的已答复请求。在操作中，分组管理器1F05接收并解析给定的场景数据分组1A15，其中然后将任何非全光场景数据提供给非全光数据控件，将任何全光场景数据提供给解码器1B11b，并且将任何用户请求标识数据提供给解码器1B11b。

非全光数据控件1F15将任何非全光场景数据提供给一个或多个非全光数据解码器1G05中的任何一个或多个以用于以下中的任何一个：解码和/或存储在另一场景数据数据库1G07或客户端系统1A01的全光场景数据库1A07中优选地作为辅助信息(例如，参见图4C)。再次，非全光场景数据包括例如视频、音频、图形、文本或其他数字信息中的任何一种，其中，此类数据的解码器在本领域中是众所周知的，并且正在不断的进一步发展中，因此，应当理解，可用的或即将变为可用的非全光场景数据解码器中的任一者可由一些实施例用作非全光数据解码器1G05。

解码器1B11b接收全光场景数据，并且至少部分使用具有子场景插入器1G03的查询处理器1G01将全光场景数据插入客户端系统1A01的全光场景数据库1A07。如先前相对于图1F提及的，客户端全光场景数据库1A07可以被实现为内部或外部数据存储器或存储区的任何组合，其中例如解码器1B11b包括高速内部存储器，该高速内部存储器用于存储客户端全光场景数据库1A07的最预期被用户需要且请求的实质部分，并且其中以其他方式，将客户端全光场景数据库1A07的另外部分存储在解码器1B11b的外部(但不一定在使用包括解码器1B11b的场景编解码器1A01的系统的外部)。与编码器1B11a相同，在操作期间，解码器1B11b、查询处理器1G01中的任何一个，并且尤其是子场景插入器1G03，可以调出编解码器SPU 1F13来有效地处理全光场景数据库1A07，其中编解码器SPU 1F13旨在实现本文描述的用于有效处理相对于全光场景数据库1A07的表示及表示的组织的各种技术优势。

仍然参考图1G，解码器1B11b接收以下任何一项的用户请求标识数据中的任一者：1)更新客户端状态1F05，以及2)通过API 1F03通知API主机1F01已满足用户请求。解码器1B11b还可以基于解码器1B11b的内部操作中的任一者来更新客户端状态1F05，其中重要的是要看到客户端状态1F05的目的包括至少准确地表示可用客户端系统1A01的全光场景数据库1A07和其他场景数据数据库1G07的当前状态。如将关于用例图5、图6和图7进一步详细讨论的，客户端状态1F05信息至少对客户端系统1A01有用，至少部分地用于使用可用的客户端系统1A01全光场景数据库1A07和其他场景数据数据库1G07中的任一者来有效确定是否可以本地地在客户端系统1A01上满足给定的客户端用户请求，或者需要另外的场景数据或必须由另一服务器系统1A01提供的其他场景数据，在这种情况下，客户端用户请求封装在控制分组1A17中并传输到特定服务器系统1A01或负载平衡部件以用于选择适当的服务器系统1A01来满足用户请求。客户端状态1F05信息对于负载平衡部件中的任一者或最终特定服务器系统1A01也是有用的，以便有效地确定至少最少数量的场景数据或足以满足用户请求的其他场景数据。

在通过API 1F03接收到已满足了特定用户请求的指示之后，API控制主机1F01(诸如应用软件1A03)然后使客户端系统1A01向用户提供所请求的数据，其中再次用户可以是人类或自主的。应当理解，存在用于提供场景数据和其他场景数据的许多可能的格式，诸如用于与用于输出视频和音频的显示器一起使用的自由视图格式，后者诸如用于与已请求场景对象标识信息的自动机一起使用的编码格式，该对象标识信息包括通往对象的本地方向和对象的视觉外观的确认。看到的重要一点是，包括解码器1B11b的编解码器1A11已操作来将用户请求1G11提供给一个或多个服务器系统1A01，并且然后接收并处理场景数据分组1A15，使得终端用户通过一些用户接口手段接收处于某种格式的请求数据。也重要的是要看到，包括解码器1B11b的编解码器1A11已操作来追踪当前客户端状态1F05，使得客户端系统1A01使用客户端状态1F05信息中的任一者来至少部分地确定是否可以本地地在客户端系统1A01上满足给定的用户请求，或者需要场景数据或必须由另一服务器系统1A01提供的其他数据。进一步重要的是要看到，使用包括解码器1B11b的编解码器1A11的客户端系统1A01可选地提供各种可能的唯一标识符(例如，包括分类器)以及任何用户请求1G11(尤其是在控制分组1A17中编码)中的一个或多个，其中客户端系统1A01或服务系统1A01中的至少任一者追踪各种可能的唯一标识符可用于优化任何一个或多个客户端1A01和任何一个或多个服务器1A01的整体性能(诸如通过使用机器学习)。同样重要的是要看到，与包括编码器1B11a的编解码器1A11相同，包括解码器1B11b的编解码器1A11可以访问编解码器SPU1F13以至少分别显着提高了各种提取和插入操作的执行速度，所有将在本文中更详细地讨论。

仍然相对于图1G，在包括解码器1B11b的编解码器1A11处理场景数据分组时，可以提供处理度量或信息中的任一者作为使用数据以及客户端状态1F07的变化，其中使用数据与用户请求的不同之处至少在于，可以通过提供子场景(诸如待售的房屋的场景模型)来满足给定的用户请求，而客户端系统1A01然后追踪用户如何与此提供的场景模型相互作用，例如其中用户是人，并且追踪使用是指房屋场景模型中由用户访问的房间、访问的持续时间、每个房间中的观看点等。应当理解，正如实际上存在代表真实世界和计算机生成的场景的任何组合的无限数量的可能场景模型，也至少存在非常大数量的使用分类以及可以被追踪并且至少对示例性实施例的机器学习方面有价值的其他信息，其中本文描述的机器学习的至少一种功能是在确定如何满足用户的请求时估计子场景或子场景增量的最佳信息化程度。

例如，如果用户请求从某个城市位置(诸如圣克莱门特大教堂的前廊)开始游览诸如布拉格(尤其参见图5)的城市，则系统必须决定将初始前廊子场景提供给用户的信息化程度，其中提供更大程度通常允许用户对场景消耗更多的初始自由，但是其中提供更小程度通常允许更快的响应时间其中传输了更少的场景数据。如将要讨论的，场景自由至少包括自由视图、自由物质和自由照明，并且其中例如自由视图包括子场景中的空间移动，诸如从前廊移动到然后进入圣克莱门特大教堂，或从前廊移动到马路对面，转身并捕获大教堂的虚拟图像。如仔细考虑将显示的，用于消耗提供的子场景的可能用户选择中的每一个可能需要越来越大量的信息范围，包括物质场和光场数据。在这方面，示例性实施例规定，通过追踪多个用户和用户事件的场景使用，累加的使用信息可以由本文描述的机器学习部件使用来估计例如物质场或光场的信息范围，该信息范围将有必要允许用户的“X”量的场景移动，其中然后X可以与Y量的时间相关联以用于通常体验场景移动，使得系统然后能够前瞻并预测用户何时可能基于所有已知的使用和当前追踪的用户场景移动需要新的场景数据，其中这种前瞻可以然后自动用于触发另外的(暗含的)用户请求1G11以供更多的新场景数据被服务器系统1A01提供。

尽管图1G中未描绘，也可以将接收在场景数据分组1A15并由包括解码器1B11b的编解码器1A11处理的任何非全光数据或其他场景数据直接提供给一个或多个适当的感觉输出端1E11(参见图1E)中的任一者以向请求用户提供所请求数据，其中例如感觉输出端1E11是传统显示器、全息显示器或扩展现实设备(诸如VR耳机或AR眼镜)，其中直接提供意指从编解码器1A11而不是从过程提供，该过程在首先通过编解码器1A11存储在相应的数据库1A07或1G07之后，从全光场景数据库1A07或其他场景数据数据库1G07检索等效场景数据。此外，有可能，提供给感觉输出端1E11的此非全光数据或其他场景数据中的任一者既不存储为数据也不存储为客户端全光数据库1A07或其他数据库1G17中的数据，其中该存储操作是在提供之前、与提供基本同时或在提供之后的任任一者，并且其中可以通过进一步处理数据库1A07或1G07中的存储数据中的任一者来替代完成提供给感觉输出端1E11，以便检索与接收在场景数据分组1A15中的场景数据等效的场景数据以提供给感觉输出端1E11。

接下来参考图2A，示出了在由“沉浸式介质应用的光/声场的数字表示的联合特设小组”提供的标题为“沉浸式介质应用的光/声场的数字表示的联合特设小组的技术报告”的出版物第13页上提供的框图，该出版物的全部内容通过引用结合在此。该出版物针对“概念性光/声场”的处理，其中该图描绘了处理流程中的七个步骤。七个步骤包括：1)传感器；2)感测数据变换；3)编码器；4)解码器；5)渲染器；6)呈现；以及7)相互作用命令。该处理流程旨在向用户提供真实世界或计算机合成的场景。

在图2B中，示出了代表一些示例性实施例的示例性用例的组合框图和示意图，以用于通过诸如2π-4π自由试图显示器2B19的感觉输出设备向用户2B17至少提供关于真实场景2B01的视觉信息。在本描绘中，使用诸如真实相机2B05-1和2B05-2的一个或多个传感器来感测真实场景2B01，其中真实相机2B05-1和2B05-2例如能够对真实场景2B01进行成像。在包括整个球形4π球面度(因此为360x 180度)的某些视场上。诸如2B05-1和2B05-2的真实相机以及其他真实世界场景2B01传感器将捕获的场景数据2B07提供给系统1A01，例如驻留在网络1E01的服务器侧1E05上。尽管在本描绘中，场景数据2B07本质上是虚拟的，但如关于图1E先前讨论的，系统1A01的传感器1E09包括但不限于诸如2B05-1和2B05-2的真实相机，其中诸如2B05-1和2B05-2的另外真实相机不限于4P球面度相机(也常常称为360度相机)，但是可以是例如单个传感器窄视场相机。而且，如先前所讨论的，诸如2B05-1和2B05-2的相机可以感测广泛的频率范围，例如包括紫外线、可见光和红外光。然而，在本图中描绘的其中终端用户2B17要查看视觉信息的用例中，优选的传感器是真实相机或者能够感测跨多个场景点的真实场景深度和颜色，所有如熟悉成像系统的人会很好地理解的。

仍然参考图2B，将在本实例中包括相机图像的传感器数据2B07提供给服务器侧系统1A01。如先前关于图1A提及并相对于下面即将到来的图4C进一步描述的，还可以相对于传感器(诸如真实相机2B05-1和2B05-2)向服务器侧系统1A01提供另外的外在和内在信息，其中这种信息包括例如传感器位置和方向，并且可能还包括传感器分辨率、光学和电子滤波器、捕获频率等。使用所提供的信息以及捕获的信息(诸如包括2B07的图像)中的任一者，优选地在应用软件结合场景求解器1A05和SPU 1A09的指导下，服务器侧系统1A01重建真实世界场景2B01，形成全光场景数据库1A07内全光场景模型。即将到来的图4A和图4B提供了关于诸如如2B01(图4A)的示例性真实世界场景和真实世界场景(图4B)的抽象模型视图(或全光场景模型)的其他信息。根据一些实施例，全光场景模型至少以各个维度上的一定预定分辨率描述对应真实世界场景的物质场2B09和光场2B11，这些各种维度包括：1)空间扩展；2)空间细节；3)光场动态范围；以及4)物质场动态范围。

仍然参考图2B，与客户端侧系统1A01相互作用的用户2B17请求查看存储在服务器侧系统1A01上或该服务器侧系统可访问的全光场景数据库1A07内所表示的真实世界场景2B01的至少一部分。在优选实施例中，在客户端侧系统1A01上执行的应用软件1A03呈现并控制用于至少确定用户请求的用户接口。即将到来的图5、图6和图7提供了用户请求类型的实例。在示例性实施例中，客户端侧系统1A01上的应用软件1A03与诸如包括解码器的1B11b的场景编解码器对接，以便通过网络1E01(如图1E所示)将控制分组1A17内的用户请求传送给诸如1A11b的场景编解码器，该场景编解码器具有例如在服务器侧系统1A01上执行的编解码器。服务器侧系统1A01应用软件1A03优选地与服务器侧编码器1B11a通信，至少用于接收明示用户请求，诸如用于接收在空间上在全光场景模型内的给定入口点开始的场景信息(与真实世界场景2B01中的空间入口点位于同一位置)的用户请求。

在处理请求时，服务器侧系统1A01优选地确定相关子场景并且从全光场景数据库1A07中提取该相关子场景，如所请求的场景入口点所指示的。提取的子场景优选地进一步包括子场景空间缓冲区。因此，在本实例中，子场景最少包括代表位于入口点的2π-4π球面度视点的视觉数据，但然后最多包括数据库1A07的另外部分，这些另外部分足以容纳用户相对于入口点和给定最小时间对场景的任何期望路径遍历。例如，如果真实世界场景是布拉格，并且入口点是圣克莱门特大教堂的前廊，则最小提取的场景将实质上允许用户感知位于大教堂的前廊的4π/2球面度(半圆顶)视点。然而，基于用户请求或在服务器侧系统1A01内可用或者可用于该服务器侧系统的辅助信息中的任一者，诸如基于给定入口点的用户的典型步行速度和方向，在服务器侧系统1A01上执行的应用软件1A03可以确定足以提供另外的场景分辨率的场景缓冲区，该场景分辨率足以支持从前廊开始在任何可用方向上的30秒的步行。

仍然参考图2B，在场景流2B13中的一个或多个场景数据分组1A15(参见图1A)的通信中提供确定和提取的子场景。优选地，通信最少数量的场景分组1A15，使得用户2B17感知到可接受的应用响应，其中应当理解，通常传输整个全光场景数据库1A07是禁止的(例如，由于带宽和/或时间限制)，尤其是在场景维度中任一者增加时，这自然至少会是诸如布拉格的全局城市场景的情况。在示例性实施例中用于组织全光场景数据库和处理组织的数据库的技术相对于其他已知技术提供了实质性的技术改进，使得用户体验实时或接近实时的场景入口。

然而，有可能且负担得起的是，用户在初次进入场景时会体验一些延迟，有利于然后感知所进入场景的连续体验，其中连续体验与进入子场景缓冲区的大小以及沿场景遍历的显式或隐式表达的补充场景增量的提供都直接相关。本发明的一些示例性实施例提供了用于平衡初始入口点分辨率和子场景缓冲区以及基于周期性或非周期性事件的子场景增量和分辨率的手段。这种平衡提供了以最少量的场景信息编码的最大连续用户体验，因此提供了可以满足预定服务质量(QoS)水平的新颖场景压缩。在由示例性服务器侧系统1A01确定和提供的异步场景流2B13内，场景数据分组1A15的任何给定传输可以包括任何形式和类型的全光场景数据库1A07信息的任何组合，其中例如，诸如2B13-a或2B13-d的一个场景数据分组至少包括物质场2B09和光场2B11信息的组合(例如，在2B13-a和2B13-d中示出为分别具有“M”和“L”)，而诸如2B13-b的另一场景数据分组至少不包括物质场2B09而包括某一光场2B11(例如，在2B13-b中示出为仅具有“L”)，而诸如2B13-c的又一场景数据分组包括至少某一物质场2B09但无光场2B11(例如，在2B13-c中示出为仅具有“M”)。

仍然参考图2B，场景流2B13通过网络1E01传输层从服务器侧系统1A01发送，以由客户端侧系统1A01接收并处理。优选地，首先在客户端侧系统1A01上由包括解码器的场景编解码器1B11b接收的场景数据分组1A15，其中然后在应用软件1A03的指导下处理解码的场景数据，访问SPU 1A09的功能。优选地在客户端侧系统1A01上使用解码且处理后的场景数据，以便重建本地全光场景数据库2B15并且提供场景信息，诸如2π-4π自由视图中的场景入口点。提供的入口点自由视图允许用户2B17至少相对于视点取向的角度(θ,

接下来参考图3，示出了网络1E01的组合框图和示意图，该网络将使用处于代表多种可能形式的各种形式的场景编解码器1A01的多个系统连接起来，这些形式包括但不限于：个人移动设备(诸如手机)、显示设备(诸如全息电视)、云计算设备(诸如服务器)、本地计算设备(诸如计算机)、陆基机器人、无人自主车辆(UAV)(诸如无人机)以及扩展真实设备(诸如AR眼镜)。如先前所讨论的，所有系统1A01包括场景编解码器1A11，其中包括在系统1A01中的任一者中的编解码器1A11还可以包括编码器1B11a和解码器1B11b，编码器1B11a且无解码器1B11b，或解码器1B11b且无编码器1B11a。因此，如本图的描绘所表示的系统1A01中的任一者可以是全光场景数据提供者和全光场景数据消耗者，仅是提供者，或者仅是消耗者。尽管单个系统1A01(例如未连接到网络1E01的计算机)可能执行本文描述为定义使用场景编解码器1A01的系统的功能中的任一者，但一些实施例可以包括两个或更多个系统1A01，这两个或更多个系统通过网络1E01相互作用，使得它们交换要重建到全光场景数据库1A07中的捕获的真实场景数据2B07中的任一者，或者交换全光场景数据库1A07场景数据中的任一者(尤其参见即将到来的用例图5、图6和图7)。

接下来参考图4A，示出了具有非常高的细节水平(例如，在一些实例中被称为无限或几乎无限细节)的示例性真实世界场景4A01的示意图，该真实世界场景诸如具有观看室外场景的窗户的内部房子场景。场景4A01例如包括但不限于以下中的任任一者或任何组合：不透明对象4A03、精细结构化对象4A05、遥远对象4A07、发射对象4A09、高反射对象4A11、无特征对象4A13或部分透射对象4A15。还描绘了操作使用场景编解码器的系统1A01(诸如移动电话)的用户，该系统单独或结合其他(未描绘)系统1A01操作以给用户提供例如子场景图像4A17以及任何数量的伴随真实世界场景4A01转换，例如对象测量、光场测量或场景边界测量，诸如场景的包括小边界对比不透明边界的部分(尤其参见即将到来的图，例如图4B)。

仍然参考图4A，通常，诸如4A01的任何真实世界场景通过被称为“场景重建”的过程转换为全光场景模型1A07。如先前描述并且如在本公开中将更详细地讨论的，SPU 1A09实现多个操作以最有效地执行场景重建以及其他数据库1A07功能，诸如但不限于场景增强和场景提取，其中场景增强将新的真实或合成场景信息引入到场景模型中，该场景模型以其他方式不一定存在或基本不存在于对应的真实世界场景4A01内，并且其中场景提取提供场景模型的代表子场景的确定和处理。合成场景增强例如包括提供重建的真实世界对象(诸如树或大理石地板)的更高分辨率，使得当观看者从超过给定的QoS阈值观看真实世界对象时，向观看者提供对应于捕获的真实场景的原始全光场景模型中表示的真实场景重建信息。然而，当观看者在空间上接近所提供的子场景内的对象并最终越过QoS阈值时，根据一些示例性实施例的系统在呈现期间智能地增强，或者已智能地在所提供的子场景内包括合成信息(诸如最初并未在真实世界场景中捕获(或甚至呈现)的树皮或大理石地板细节)作为增强。也如前所述，场景求解器1A05是可选的处理元件，其通常进一步应用机器学习技术来扩展场景重建、增强(诸如QoS驱动的合成)、提取或其他形式的场景处理方面的任一者的准确度和精度。

如熟悉计算机系统的人会很好地理解的，包括应用软件1A03、场景求解器1A05、SPU 1A09、场景编解码器1A11以及请求控制器1A13的系统部件中任一者的组合提供了可以实现为部件的各种布置的功能和技术改进，而不脱离示例性实施例的范围和精神。例如，场景求解器1A05的各种新颖功能中的一个或多个可以替代地包括在应用软件1A03或SPU1A09内，使得描述各种系统部件的目前描述的功能描述应被视为示例性的，而不是对示例性实施例的限制，因为软件和计算机系统领域的技术人员将识别系统部件和部件功能的许多可能变型，而不脱离示例性实施例的范围。

仍然参考图4A，由系统1A01重建诸如4A01的真实世界场景包括确定真实世界场景的物质场2B09和光场2B11的数据表示，其中这些表示以及这些表示的组织对场景重建有重要影响，但甚至更重要的是对包括子场景提取的处理速度的效率的影响。示例性实施例提供了场景表示和场景表示的组织，这些场景表示和场景表示的组织本质上使得例如大型全局场景模型可用于实时或接近实时体验的用户。图4A、图4B和图4C共同地定向为以某种详细程度描述这些场景表示和场景表示的组织，然后在本公开的部分中进一步详细说明所有这些场景表示和场景表示的组织。

根据本文描述的示例性实施例的技术可以使用分层、多分辨率和空间排序的体积数据结构以描述物质场2B09和光场2B11。这允许基于由每个用户的位置和观看方向确定或者用户组的统计估计的位置、分辨率和可见性，来标识场景的远程观看所需的部分。通过仅传送必需的部分，最小化了信道带宽要求。体积模型的使用还促进了虚拟世界中的高级功能，诸如碰撞检测和基于物理的模拟(质量属性易于计算)。因此，基于将诸如4A01的真实世界场景的新颖场景重建处理成新颖的全光场景模型表示及表示的组织，以及子场景提取和用户场景相互作用监视和追踪的新颖处理，示例性实施例提供了许多用例优势，其中一些将在即将到来的图5、图6和图7中讨论，其中优势之一包括提供自由视点观看者体验。在自由视点观看者体验中，一个或多个远程观看者可以独立地改变其对传输后子场景的视点。最大的自由视点体验(尤其是较大的全局场景模型)所需要的是系统1A01准时化且仅需要或准时化且仅预期地将子场景提供给自由视点观看者。

仍然参考图4A，代表诸如4A01的真实世界场景的图像和以其他方式捕获的传感器数据包含光的一个或多个特性，诸如颜色、强度和偏振。通过处理这个和其他真实场景信息，系统1A01确定关于物质场2B09的形状、表面特性、材料特性和光相互作用信息，以在全光场景数据库1A07中表示。真实场景的光场2B11的单独确定和表征与物质场2B09结合使用，以便除其他目标之外，消除场景照明(例如，镜面反射、阴影)引起的表面特性和材料属性的歧义。目前描述的将真实世界场景新颖处理成场景模型允许对透明材料、高反射表面以及日常场景中的其他困难情况进行有效建模。例如，这包括物质和表面特性的“发现”，而与场景中的实际照明无关，其中这种发现和伴随的表示及表示的组织然后允许新颖子场景提取，包括与光场2B11不同的物质场2B09的准确分离并提供给自由试点观看者。

因此，自由点观看体验完成了自由照明的另一个关键目标，其中例如在访问对应于诸如4A01的真实场景的场景模型时，观看者能够请求自由点观看可能具有“早晨的阳光”与“傍晚的阳光”或甚至“具有可用房间灯的半月照明”的场景，其中优选地由应用软件1A03提供的用户接口允许允许插入来自一组模板光源的新光源，并且其中然后可以修改新指定的或可用的光源，以更改例如光发射、反射或透射特性。类似地，观看者还可以动态地更改物质场2B09的属性和特性，从而提供自由物质以及自由照明和自由视点，其中尤其重要的是要看到，示例性实施例提供了真实场景的物质场2B09与光场2B11的更准确分离，其中，缺乏分离的准确性反过来限制了用于准确地更改物质场2B09和/或光场2B11的属性和特性的终端使用体验。如本文描述的准确物质场2B09的另一个优势包括在物质场对象内进行干扰和碰撞检测，其中这些和其他生活模拟功能需要物质属性，诸如质量、重量和质心(例如，对基于于物理学的模拟)。如熟悉真实世界场景中的对象识别的人也会很好地理解的，高度准确的物质场和光场提供显著优势。

仍然参考图4A，真实场景4A01的物质场2B09包括介元，介元是光在其中流动或被阻挡的材料的有限体积表示，因此具有不同程度的透光率，可表征为吸收、反射、透射和散射的程度。介元在场景空间中定位并定向，并且具有相关联的属性，诸如材料类型、温度和双向光相互作用函数(BLIF)，该双向光相互作用函数将入射光场与由光与介元的相互作用引起的出射光场关联。光学上、空间上和时间上同质并置的介元形成对象的片段，这些片段包括具有可触及边界的表面，其中可触及边界通常被理解为人可以通过触摸感测的边界。使用这些和其他物质场2B09特性，不仅在空间上而且并重要的是相对于其与光场(2B11)的相互作用来区分图4A中描绘的各种对象，其中这些各种对象再次包括：不透明对象4A03、精细结构化对象4A05、遥远对象4A07、发射对象4A09、高反射对象4A11、无特征对象4A13或部分透射对象4A15。

接下来参考图4B，示出了代表诸如图4A中所描绘的真实世界场景4A01的示意图，其中该表示可以被认为是全光场景数据库1A07内的数据的抽象场景模型4B01视图。真实世界场景4A01的场景模型4B01的抽象表示包括外部场景边界4B03，该外部场景边界包含包括该场景的物质场2B09和光场2B11的全光场4B07。光场2B11与关于图4A描述的物质场2B11中的任何数量的对象以及其他对象(例如，解释的对象4B09和无法解释的区域4B11)相互作用。真实世界场景4A01例如由真实传感器中的任何一个或多个捕获，这些真实传感器诸如捕获真实图像4B13的真实相机2B05-1，而使用例如提供真实世界表示图像4A17的虚拟相机2B03将场景模型4B01转换成真实世界数据表示。

除了如图4A中示出的包括不透明对象4A03、精细结构化对象4A05、遥远对象4A07、发射对象4A09、高反射对象4A11、无特征对象4A13或部分透射对象4A15的对象之外，根据一些实施例的系统可以进一步允许解释的对象4B09和无法解释的区域4B11，其中这些通用对象和区域包括如图4A中所讨论的物质场2B09的特性和属性的变型。重要的一方面是由足以区分多种类型的对象的场景重建来标识物质场2B09，其中然后可以进一步处理模型场景中独特定位的任何单个对象类型，例如通过使用机器学习来执行对象识别和分类，更改各种特性和属性来引起模型呈现效果，诸如对可视化(通常转换)的变化、对象增强和标记(尤其参见相对于图4C的模型增强4C23和模型索引4C27)以及甚至对象移除。与对象移除一起，对象转换(参见即将到来的图4C中的模型转换4C25)可以被指定来基于例如对象碰撞或指定的对象路径执行任何数量的几何转换(诸如设定大小和旋转)或者甚至对象移动，例如通过机器学习分类的不透明对象4A03，该对象然后沿着地板(不透明外部场景边界4B03)滚动，从墙(不透明外部场景边界4B03)反弹。

仍然参考图4B，可以通过对新的真实场景传感器数据进行另外处理来改变任何对象的特性和属性，该新的真实场景传感器数据诸如但不限于新的相机图像，这些图像可能以诸如红外的不可见频率拍摄，从而至少提供新的BLIF(双向光场信息)。诸如图4A和图4B中描绘的对象类型应被认为是示例性的而不是实施例的限制，诶熟悉软件和数据库的人会清楚的，可以更新数据，并且可以调整形成物质场对象的关联数据的标记，至少包括对象的命名(诸如“无特征”对比“精细结构的”)，或者包括对象分类阈值的更改，这些对象分类阈值例如可以用于将对象分类为“部分透射”对比“不透明”。基于本公开，对象类型的其他有用变型对于场景处理领域的技术人员将是显而易见的，通常物质场2B09和光场2B11的其他变型也是这样，使得最重要的是如本文描述的诸如4A01的真实世界场景的表示及表示的组织以及其有效处理，它们的组合可用于提供如本文描述的独特功能，其中再次这些独特功能提供至少使用场景模型来可视化的观看者的自由视点、自由物质和自由光体验。

场景模型还包括外部场景边界4B03，该边界划定了所表示的全光场4B07的最外部范围。因为诸如图4A中描绘的厨房或室外场景(未描绘)的真实世界场景的仔细考虑会揭露，靠近外部场景边界4B03的全光场的一些区域可能基本上不透明(诸如厨房中的墙或工作台，或室外场景中的浓雾)，而靠近(假想的)外部场景边界的其他区域可能基本上是窗状的，表示任意光场边界(诸如室外场景中的天空)。在真实场景中，光可能在与场景模型外边界相关联的空间中来回交叉。但是，场景模型不允许这种透射。相反，窗状光场可以表示真实场景中的光场(像电视可以显示夜间月亮的图片一样)。在场景模型中，靠近外部场景边界4B03的不透明区域不表示在全光场的外部、进入场景的内部的光的实质性透射(在真实场景中)，而靠近外部场景边界4B03的窗状区域不表示在全光场的外部、进入场景的内部的光的实质性透射(在真实场景中)。在一些实施例中，可以将树和其他室外物质表示为被包括在全光场4B07中，其中然后外部空间边界4B03在空间上扩展为至少包括此物质。然而，随着物场中的对象变得越来越远，甚至达到称为无视差极限的距离，其中随着视点的更改，对象上的特征基本上不会改变，有利的是在外部场景边界4B03中终止全光场4B07。使用一个或多个窗状光元件4B05，可以表示沿着外部场景边界4B03的部分入射到真实场景的光场，好像在外部场景边界4B03的那些部分处的全光场4B07无限期地延伸。

例如，参考图4A，而不是将场景边界4B03并因此还有全光场4B07扩展到超出窗户的室外区域从而将树包括在场景的物质场中，可能使场景边界4B03基本上终止于包括工作台、墙壁和窗户的介质和物质的表示，其中然后可以添加沿外部场景边界4B03的一部分(在空间上表示窗户表面)包括的多个窗状光元件4B05，以便将窗状光场有效入射到全光场4B07中。使用包括2D、3D和4D光场的窗状光元件4B05可以实现各种光场复杂性。注意，如本文所使用的，“介质”是指包括一些物质或无物质的体积区域的内容。介质可以是同质的或异质的。同质介质的实例包括：空的空间、空气和水。异质介质的实例包括体积区域的内容，包括镜子的表面(部分空气和部分碎玻璃)、玻璃窗格的表面(部分空气和部分透射玻璃)以及松树的树枝(部分空气和部分有机材料)。光通过包括吸收、反射、透射和散射的现象在介质中流动。部分透射的介质实例包括松树的树枝和玻璃窗格。

在本系统的一个示例性用途和优势中，可以使用处于如图4B中描述的方式并且对应于诸如图4A中描绘的真实场景的场景模型1A07来基于将透射到场景(例如厨房)中的一天中的时间来估算阳光量，其中可以至少部分地基于所估算的透射阳光量来计算基于各种类型的窗帘的所估算一天中时间的室温或季节性节能机会。此类示例性计算至少部分地基于表示包括全光场4B07的光场2B11的数据，其光场表示和其他更基本的计算方法将在本文中更详细地解决。可以说，光场4B07被视为准稳态光场，使得所有光传播相对于场景是瞬时的，尽管使用本文描述的自由光原理，观看者可以通过呈现优选地使用应用软件1A03的视觉场景表示来体验动态状态光场。

仍然参考图4B，示出了例如能够捕获直到并贯穿4π球面度视图的真实相机2B05-1，以及具有小于4π球面度的示例性受限视点4A17的虚拟相机2B03。全光场景数据库1A07内描述的任何场景(诸如具有对应场景模型4B01的真实场景4A01)可以包括任何数量的真实或虚拟相机，分别诸如2B05-1和2B03。诸如2B05-1和2B03的相机中的任一者可以被指定为相对于场景模型固定或相对于场景模型可移动，其中可移动相机例如与遍历路径相关联。重要的是要看到，任何真实或虚拟相机的许多可能的视点以及由此产生的图像，无论是移动的还是固定的，无论是在视场中可调整还是在视场中固定，可以通过处理如关于图4B描述的场景模型4B01来估算。

接下来参考图4C，示出了全光场景数据库1A07的一个实施例内的主要数据集的框图，其中，数据库1A07例如存储代表诸如图4A中描绘的真实世界场景4A01的数据。真实世界场景4A01的全光场景数据库1A07的数据模型视图通常包括例如描述传感器1E07的内在或外在数据4C07中的任一者，这些传感器诸如真实相机2B05-1或2B05-2或者诸如2B03的虚拟相机，其中基于传感器的类型，内在和外在数据在本领域中是众所周知的，并且其中通常内在属性与传感器的数据捕获和处理功能相关，并且其中外在属性与传感器相对于通常本地场景坐标系或至少任何坐标系的物理位置和取向相关，该任何坐标系允许理解传感器相对于包括物质场2B09和光场2B11的场景的空间位置。

数据模型视图还包括场景模型4C09，该场景模型通常包括全光场4C11、对象4C13、片段4C15、BLIF 4C17以及特征4C19。术语“全光场”在当前领域中具有一系列含义，并且此外，本公开提供了全光场4C11的新颖表示，其中这个新颖表示及表示的组织至少部分地是本文描述的许多技术改进的基础，这些技术改进例如包括准时化子场景提取，提供了具有最小数据集(子场景)实现的足够场景分辨率(从而满足QoS阈值)的基本连续视觉自由视图体验。因此，术语和数据集全光场4C11，与本文所述的其他具体描述的术语和数据集一样，应根据本说明书而不是仅参考当前的现有技术来理解。

仍然参考图4C，全光场4C11包括本文称为全光八叉树的表示的组织，其中全光八叉树保持了物质场2B09和光场2B11的表示。在本说明书的剩余部分即将推出总体上相对于场景模型4C09并具体地相对于场景模型的主要数据集(诸如全光场4C11、对象4C13、片段4C15、BLIF 4C17以及特征4C19)对表示及表示的组织的更详细讨论，其中通常如本文描述的全光八叉树表示包括物质场2B09的两种类型的表示以及光场2B11的一种类型的表示。物质场2B09将显示为包括(体积)“中”类型物质表示和“表面”类型物质表示。中型表示形式描述了同质或异质材料，其中光基本上在该材料中流动(或者光基本上被阻挡)。这包括空的空间。光通过包括吸收、反射、透射和散射的现象在包括中型的介质中流动。光的修改的类型和程度包含在全光八叉树的体元中包含的属性值中，或由其引用。表面类型表示描述了物质与空的空间(或另一种介质)之间可触及的(可触摸的)(近似)平面边界，其中平面边界在两侧均包括介质，并且其中两侧上的介质可以是同一或不同介质(其中不同的介质表面被称为“分割表面”或“分割面元(surfel)”)。

包括在空间和时间上都是同质的并置介质的表面类型物质形成片段表示4C15，其中然后并置片段形成对象4C13的表示。表面类型物质对光场2B11的影响(反射、折射等)由与表面类型物质相关联的双向光相互作用函数(BLIF)表示4C17建模，其中BLIF表示4C17的粒度扩展到至少与包括对象4C13的片段4C15相关联但也与特征表示4C19相关联，其中特征被称为位于场景模型4C09所描述的空间中的实体(诸如对象4C13)中的姿势。场景或图像中的特征的实例包括从微观角度看的斑点和闪光或甚至从宏观角度来看的建筑物。BLIF表示4C17基于光场与材料的相互作用，将入射到材料(物质)的光场2B11的变换与从材料中出射的光场2B11关联起来。

仍然参考图4C，一些示例性实施例的至少一个实施例的主要数据集包括辅助信息4C21，诸如以下中的任一者或任何组合：模型增强4C23、模型转换4C25、模型索引4C27以及模型使用历史4C29。模型增强4C23包括要与场景模型4C09的某一部分相关联的任何另外元数据，否则这些其他元数据就不包括在场景模型4C09中，并且不以其他方式指定对场景模型4C09的改变(其中例如，模型变换4C25描述了一些数学函数或类似函数，以归因于场景模型，其属性更改(改变)提取的子场景或场景模型解释(诸如计量))。

模型增强表示4C09包括但不限于：1)虚拟场景描述，这些描述包括文本、图形、URL或其他数字信息，例如可能显示为对已观看子场景的增量(在概念上类似于增强现实(AR))，实例包括房间特征、对象价格或到最近商店以购买例如相对于4A中描绘的真实场景图的对象的链接；2)感觉信息，诸如要与物质场2B09或光场2B11的一部分相关联的当前温度读数，其中感觉信息通常至少部分地不是基于物质2B09或光场2B11，并且包括可从当前已知或还未知的未来传感器获得的任何类型的数据，并且尤其涉及与躯体感觉(触觉)、嗅觉(气味)、试音(听觉)或甚至味觉(品味)相关联的数据；以及3)与描述物质场2B09或光场2B11中的任一者的计算有关的度量，实例包括数量(诸如大小的维度)或质量(诸如温度的维度)的测量，其中优选地，计算至少部分地基于物质场2B09或光场2B11中的任一者。模型增强4C23直接与任何场景模型4C09相关联，或通过模型转换4C25或模型索引4C27中的任一者间接与场景模型4C09相关联。模型增强可以至少部分地基于包括在模型使用历史4C29内的任何信息，其中例如，该增强是关于多个用户的场景模型使用的某些记录方面的最新统计。

仍然参考图4C，模型转换4C25包括但不限于：1)应用到包括场景模型4C09的物质场2B09或光场2B11中任一者的几何变换，其中几何变换将任何物质或光场元件的空间位置映射到新位置，包括空间移动、旋转、放大、缩小等；2)复合几何变换，诸如用于描述场景模型4C09中对象的移动或以其他方式用于物质场2B09或光场2B11中任一者的轨迹路径；3)虚拟场景路径，包括路径点时间，其例如描述虚拟相机(诸如2B03)在场景模型内的移动和视点，使得在整个场景中引导体验场景模型的视觉表示的观看者而不需要自由视图指令，或者例如描述建议的场景模型路径，诸如一组城市旅游目的地位置，其中观看者可能从一个子场景转移到在场景模型4C09中在空间上并置或不并置的另一个子场景；以及4)包括在场景模型4C09内的数据和相关联辅助信息4C21中任一者的预编译，该辅助信息例如包括布拉格圣克莱门特大教堂的jpeg图像。模型转换4C25直接与任何场景模型4C09相关联，或通过模型增强4C23或模型索引4C27中的任一者间接与场景模型4C09相关联。可以由模型使用历史记录4C29引用模型转换，其中例如，在多个用户之间记录给定转换的使用。

模型索引4C27包括用于向人类或自主用户呈现索引元件中的任一者的数据，这些元件用于选择尤其包括场景模型4C09或辅助信息4C21中任一者的任何场景数据库1A07的一部分，其中数据包括但不限于：1)包括文本、图像、视频、音频或其他数字信息的索引元件列表，其中列表中的每个索引元件与至少一个部分相关联，该至少一个部分诸如要给请求用户(人类或自主的)提取的场景数据库1A07的子场景；或者2)索引元件的编码列表，包括可用于通过执行的计算机算法选择场景数据库1A07的一部分的加密或未加密信息中的任一者，其中例如，作为使用场景编解码器1A01的系统的远程计算机访问可提取场景信息的加密模型索引，该可提取场景信息包括用于期望类型的场景信息的算法比较的场景信息类型，其中算法然后至少部分地基于算法比较选择用于提取的场景信息。给定模型索引4C27可以包括相关联的许可信息，用于允许或拒绝任何给定用户(人类或自主的)访问索引4C27(并因此通过索引4C27访问场景模型4C09)，其中许可信息包括允许的给定用户类型、与访问凭证(诸如用户名和密码)相关联的特定给定用户、以及与付款或销售交易相关的任何信息，包括与远程销售交易提供商(诸如PayPal)相互作用的链接。

模型索引4C27直接与任何场景模型4C09相关联。模型索引4C27可以与模型增强4C23(例如，在诸如对应于场景模型的自然灾害场景的整个真实场景中获取的某种类型的当前传感器读数)或模型转换4C25(例如，在早晨、白天或傍晚设置中重新照明的场景，或者自动进入特定子场景中的场景，然后根据规定的路径在整个场景中自动移动)相关联或触发它们的使用。模型索引4C27或其索引元件中的任一者可以与任何模型使用历史4C29相关联，其中关联被广义地解释为包括模型使用历史4C29的任何公式，诸如统计由多个用户(人类或自主的)选择索引元件的百分比，以及相关联的场景模型的经过时间使用，其中然后使用统计百分比对给定模型索引4C27进行索引元件的排名或表示。

仍然参考图4C，模型使用历史4C29包括使用场景编解码器1A01对系统已知的任何数据，这些数据代表用户的请求或指示，其中用户是人类或自主的。请求和指示包括但不限于以下任何一项：1)模型索引和模型索引元件选择；2)至少部分地基于显式或隐式用户指示中的任一者的场景模型自由视图、自由物质或自由光调整；3)用户的显式或隐式用户指示中的任一者，包括对人类用户追踪的身体运动、面部表情或可听见的声音；4)概括场景模型传播信息，包括在子场景内花费的经过时间，或者至少在子场景的增量(诸如用于包括更多总场景的空间增加)之前或者在切换到替代子场景的请求之前以子场景的提供开始的经过时间；或者5)记录模型增强4C23(例如，使用URL以访问场景数据库1A07外部的信息)或模型转换4C25(例如，使用预定场景路径，诸如表示特定场景的游览，该场景是城市景观或待售房屋)的使用的任何信息。

此外，相对于图4C，如熟悉计算机数据库的人会很好地理解的，存在当前市场上可用或在未来时间会变得可用的许多类型的数据库技术，其中可以以任何数量的这些数据库技术或甚至这些技术的组合来实现目前描述的全光场景数据库1A07，每种技术具有权衡优势并且每种技术由如本文描述的至少场景模型4C09表示及表示的组织的技术改进加强。如熟悉计算机数据库的人也将了解的，尽管数据库1A07的一个实施例已被描述为包括各种数据集4C07；包括4C11、4C13、4C15、4C17和4C19的4C09；以及包括4C23、4C25、4C27和4C29的4C21，可以将本文描述为属于数据集的数据重新组织为数据集的不同布置，或者可以将一些描述的数据集进一步划分为其他数据集或组合为其他数据集，而不脱离示例性实施例的真实范围和精神。还应该理解，在本文中描述了在至少图4C的呈现中未专门查看的其他数据，其中此其他数据也包括在全光数据库1A07内，但是可以形成不包括附图中描绘的那些数据集的它自己的数据集。仔细阅读本公开还将清楚，并非所有附图中描述的数据集都必须存在于数据库1A07中，以便使用场景编解码器1A01的系统执行有用且新颖的功能，或者以其他方式提供本文所述的许多技术改进中的任一者。因此，如关于图4C描述的全光场景数据库1A07应将视为示例性的而不是对示例性实施例的限制，因为许多变型是可能的，而不脱离本文提供的实施例的范围。

接下来共同参考图5、图6和图7，根据一些示例性实施例描绘了一系列三个流程图，这三个流程图描述了使用场景编解码器1A01的系统的通用用例的三种变型。这三个流程图中的每一个描绘了是盒子、椭圆形或菱形的一系列相连的过程形状，其中应该理解，这些过程形状中的每一个表示专门计算机过程的更高级功能，该计算机过程包括示例性实施例中提供的计算改进的一部分，其中然后所有的形状和其互相连接共同进一步描述本文指定的技术改进。菱形表示一功能，该功能在通用用例内确定系统相对于处理用户请求的重要分支决策。通常，每个形状可以理解为表示用于在计算设备上处理的一组可执行指令，其中这些计算设备可以是许多可能变型的任何布置，诸如具有多个核的单个CPU，这些核中的每一个执行一个或多个功能，或者具有单个或多个核的多个CPU，其中这些多个CPU可以分布在如先前讨论的任何类型的网络上。另外，如先前所讨论的，存在用于本文描述的某些新颖技术的某些计算机操作，这些计算机操作可以使用某种形式的硬件专用处理单元来进一步优化，例如FPGA或ASIC或执行常常称为嵌入式代码的其他众所周知的硬件。特别地，一些示例性实施例包括空间处理单元(SPU)1A09(参见图1A)，该空间处理单元优选地是在嵌入式系统上执行的一组操作，甚至包括为本公开描述的关键全光场景处理功能优化的定制数字电路。

仍然共同参考图5、图6和图7，示例性实施例提供场景模型的重建、分布和处理的重要益处，其中应理解，传统上，大多数编解码器传输视觉信息(诸如电影)，该视觉信息并不能提供本文所述的许多益处，诸如自由视图和按需的子场景，不是例如非视觉场景数据的传输(诸如场景计量、物质场或光场)，不是例如场景数据交替服务给人类用户和自主用户，每个访问相同的模型以寻求场景数据的不同形式和方面。存在用于传输场景模型的一些系统，尤其是包括虚拟现实(VR)系统，但是通常，VR系统基于缺乏显着真实性的计算机建模，诸如图4A中描绘的真实世界场景。还存在用于传输已重建为场景模型的真实世界场景的其他系统，然而，本系统提供了真实场景的独特全光八叉树表示，其中物质场2B09和光场2B11的分离程度比现有系统高，并且其中在其他方面的表示的组织，物质场2B09和光场2B11提供了对基础功能的重大技术改进，使得能够实时或接近实时地访问和消耗大型真实世界的重建场景。因此，本系统提供了作为全光八叉树数据库1A07的真实场景的表示及表示的组织，该数据库使系统能够处理分布式网络中的大型全局场景，其中场景甚至正在进行间歇或连续重建，并且其中信息的基本传输是准时化异质、异步全光数据的流，而不是例如仅是视觉数据(诸如传统编解码器)，或甚至是整个重建模型(诸如其他最新的场景模型编解码器)。

即将到来的图5、图6和图7将显而易见，存在多种方式来使用利用场景编解码器1A01的两个或更多个系统来处理场景，其中例如，第一系统1A01驻留在服务器上并且将场景模型信息按需提供给人类或自主消耗者(客户端)，其中客户端然后使用第二系统1A01来接收和处理场景模型信息(例如，参见图5)。在其他变型中，客户端正在使用第一系统1A01，该客户端希望捕获可能被视为“本地”与“全局”场景，诸如在最近冰雹风暴中受损的他们的汽车，或者在暴风雨中受损或只是准备出售的他们的房屋。在这种类型的用例中，客户端系统1A01还适于包括用于捕获本地场景的原始数据(尤其参见图6)的一个或多个场景传感器1E09。然后，有可能将此原始场景数据通过网络传输到在服务器上运行的第二系统1A01，该服务器承担重建本地客户端场景并且将重建的子场景和场景增量重新传输回客户端系统1A01的的主要责任。在再其他变型中，客户端在共享场景(诸如灾难现场或工业仓库)使用的第一系统1A01和在网络上运行的第二系统1A01共享将客户端捕获的场景数据重建到子场景和场景增量中的责任，其中然后通过编解码器功能在第一与第二系统1A01之间共享这些重建的子场景和场景增量，使得由第一系统1A01本地捕获的共享场景被编译成更大的场景模型(通过第一和第二系统1A01的共同操作)，该更大的场景模型然后也可用于与再第三系统1A01共享，其中然后这个第三系统可以对共享场景是本地的并也捕获原始数据，或者远离第一和第二系统1A01，并因此也远离共享场景。

共同相对于图5、图6和图7，描绘了一些矩形以表示编解码器1A11编码器功能(图5中的505、515、517；图6中的505、515、517；和图7中的505和517)，一些表示编解码器1A11解码器功能(图5中的507、511；图6中的507和511；图7中的507和511)，并且一些表示应用软件1A03(图5中的501a、501b、503、509、513a-d；图6中的501a、501b、503、509、513a-d；图7中的501a、501b、503、509、513)。如熟悉计算机系统和软件架构的人会很好地理解的，表示为图5、图6和图7中的形状的各种操作和功能的部署实现方式具有许多变型，包括使用任何一个或多个处理元件来执行任何一个或多个功能，其中例如处理元件是CPU、GPU或本文定义的SPU 1A09中的任一者，这些SPU作为嵌入式处理器与编解码器1A11或应用软件1A03功能中的任一者通信或者支持其。因此，相对于即将到来的图5、图6和图7的描绘和规定应被视为示例性的而不是对示例性实施例的限制，因为描述的功能可以被进一步组合或进一步划分，并且其中可以以各种组合实现并以许多变型部署这些功能，而不脱离示例性实施例的范围和精神。对于软件系统、网络、传统压缩、场景建模等领域的技术人员来说还将显而易见的是，为清楚起见，省略了一些其他功能，但基于现有知识这些功能可以显而易见(诸如，如果要使用网络并且取决于网络的类型，传输层1E03会起作用)。图5、图6和图7还示出了一些比其他连接线粗的连接线，其中这些较粗的线(图5中的505-507、517-507；图6中的501b-505、505-517、517-507；图7中的501b-505、505-517、517-507)表示全光场景数据库1A07信息的任何组合的传输，诸如通常相对于图2B描述的流2B13，或为了场景重建或注释目的的诸如由一个或多个场景传感器1E09(诸如真实相机2B05-1和2B05-2)捕获的场景数据2B07(参见图2B)的传输。

现在仅参考图5，示出了实施例的流程图，例如包括与远程客户端共享更大的全局场景模型，该远程客户端是人类或自主的并且在消耗如本文描述的各种类型的场景模型信息，包括自由视图、自由物质、自由照明、计量、传统2D、3D或4D可视化中的任一者，相关联(五种)感觉信息、辅助信息或包括在全光场景数据库1A07或与全光数据库1A07相关联的其他相关场景模型信息中的任一者(例如，其中数据库1A07包括嵌入在空间场景内的URL链接，这些链接连接到其他互联网可访问内容，诸如当前天气条件、支持视频、产品信息等)。在这个示例性实施例中，可以假设全局场景模型不仅远离消耗客户端而且过大，因此排除了将整个全局场景模型简单地传输给客户端的可能性。为了清楚和说明的目的，将相对于许多可能的特定用例中的仅一个描述图5的流程图，也就是说，相对于在服务器上可用的场景模型城市游览的全局存储库，作为远程客户端的人类用户请求城市游览。

仍然参考图5，人类客户端操作优选地由在诸如移动设备的客户端系统1A01上的应用软件1A03上执行的客户端UI(用户接口)501。而且，零个或多个传感器1E09(参见图1E)包括在客户端系统1A01内或者与该客户端系统通信，用于至少感测与人类用户相关的一些数据，这些数据可至少部分地用于确定用户请求中的任一者。示例性传感器包括鼠标、操纵杆、游戏控制器、网络相机、运动检测器等，其中示例性数据优选地包括显式或隐式指示期望的场景移动或视图改变的数据，该视图改变包括相对于进行中场景内追踪的当前位置/视点的方向、路径、轨迹等，其可由系统1A01使用来至少部分地帮助确定视点改变和/或当前子场景的下一个场景增量，如不久将更详细解释的。客户端系统1A01还包括一个或多个感觉输出端1E11(图1E)，这些感觉输出端用于向人类用户提供数据，例如2D显示器、VR耳机或甚至全息显示器。

在本实例的第一步中，人类用户访问客户端UI 501以确定全局感兴趣的场景(SOI)501a，其中例如，选择是包括世界主要城市在内的众多世界各地的旅游景点，其中例如，用户选择在布拉格进行城市游览。操作501a与从全局SOI确定并提供场景索引的操作503进行通信，其中例如在用户选择进行城市布拉格的虚拟游览之后，操作503提供多个可能游览(并因此具有连接路径的场景入口点，尤其参见图4C模型转换4C25)的索引以及相关联的辅助信息，该辅助信息诸如图像、短视频、消耗者评级、评论者评级、文本、指向网站的URL链接、酒店和餐厅信息以及网站等，其中此辅助信息以及其他场景索引信息可以使用基于数据类型众所周知的传统技术和编解码器进行传输，并因此不必要包括在全光流2B13中(参见图2B)。虽然操作503可以在存储或访问全光场景数据库1A07(参见图2B)的服务器侧1E05系统1A01上执行，但操作501a以及客户端UI 501的其他处理优选地在客户端侧1E07系统1A01上执行，包括确定全局SOI操作501b内的初始子场景。在操作501b中，用户查看并从操作503提供的场景索引中选择用于进入场景模型的子场景，其中例如，用户选择在圣克莱门特大教堂的前廊开始的城市大教堂之旅。

仍然参考图5，操作501b与来自全局SOI模型操作505的提取初始子场景进行通信，并且向操作505传输用户选择的子场景的指示，例如圣克莱门特的前廊。至少部分地基于用户选择的子场景，并且还部分地基于确定的子场景缓冲区大小信息，操作505访问全光场景数据库1A07以确定一组至少初始物场2B09和光场2B11数据，以用于作为第一独立子场景提供给客户端系统1A01。在一个实施例中，操作505主要是场景编解码器1A11的功能，其中操作505直接地或通过诸如应用软件1A03的中间系统部件与操作501b通信。在另一个实施例中，应用软件1A03提供的操作远不止操作501b与505之间的通信服务，其中软件1A03实现例如操作505的主要负责确定缓冲区大小的部分，并且然后还使场景编解码器1A11然后通过将各种应用接口(API)调用调出到场景编解码器1A11中来提取并传输初始子场景。在可能并将由熟悉软件系统的人理解的这些或其他可能的实施例的任一者中，然后作为场景编解码器1A11的一部分执行的过程也可以将各种API调用调出到SPU 1A09中。

在再另一实施例中，在确定例如优选的缓冲区大小时，例如由应用软件1A03或场景编解码器1A11调出场景求解器1A05，其中场景求解器1A05执行包括机器学习算法的确定性或非确定性(例如统计或概率)算法，以便优选地至少部分地基于包括在数据库1A07内的辅助信息4C21(参见图4C)来提供或预测缓冲区大小，其中辅助信息4C29尤其可用作机器学习的基础，至少部分地基于指示先前缓冲区大小的数据和如记录用于其他用户的先前客户端会话的场景移动，访问同一子场景或不同子场景。如软件系统和架构领域的技术人员会了解的，包括机器学习算法的这些相同的确定性或非确定性(例如统计或概率)算法也可以是场景编解码器1A11、SPU 1A09、应用软件1A03或甚至一些其他部件(本文中未具体描述但基于本文的描述会明显的)的功能，其中例如，使用场景编解码器1A01的系统包括例如使用任何专用机器学习硬件实现的另一场景使用学习部件，该学习硬件当前可用且市场中已知或者将变得已知。

在市场上已知为NVIDIA的至少一个技术公司当前提供被称为“AI芯片”的技术，这些AI芯片是所谓的“基础设施3.0”的一部分，并且在还包括NVIDIA称为“张量核”的专用GPU上实现。本文中的公开内容提供了场景模型的新颖表示及表示的组织，并且更具体地，全光场景模型包括辅助信息4C21，该辅助信息传统上不被视为场景数据，而是诸如模型使用历史4C29的数据，该数据直接涉及任何人或自动机如何以任一或所有方式使用场景模型。如熟悉机器学习的人会了解的，尽管示例性实施例提供了用于实现场景学习的一些新颖方法，但其他方法和实现方式可以是显而易见的，尤其是相对于确定缓冲区大小，其中这些实现方式可以是在通用计算硬件上执行的软件和/或在专用机器学习硬件上执行的软件，其所有解决方法被认为处于本公开的精神和范围内。

仍然参考图5，相对于至少有效(准时化)子场景提取提供了描述，该子场景提取基于一些确定的或提供的场景入口点以及一些确定的或提供的场景缓冲区大小或者其他信息，这些其他信息可预见地将子场景限制为从整个SOI(例如全局)场景模型提取，使得相对于空间缓冲区所提取的子场景基本上确保由最小量的提供的场景信息提供最大连续用户体验。在从代表用户选择的子场景的数据库1A07确定了全光场景数据之后，全光场景数据作为包括在数据库1A07内的物质场2B09和光场2B11数据的任何组合的异步准时化流2B13进行传输，其中例如，使用场景编解码器1A01的客户端1E07系统接收流2B13以将该流处理成感觉输出端，诸如例如通过能够向人类用户提供2π–4π自由视图操纵的感觉输出设备2B19提供给用户2B17的图像和对应音频，其中输出设备2B19是通过客户端UI 501可用的任何感觉输出设备1E11的特定实例。

作为由包括在编解码器1A01中的解码器接收流2B13的第一步，执行了将下一场景数据插入客户端SOI模型507的功能，从而导致客户端SOI(即，全光场景数据库1A07)镜像的重建或更新，但不等同于从中提取并提供子场景的全局场景模型(即，全光场景数据库1A07)。重要的是要看到，可能并在示例性实施例的范围内考虑，将包括基本上全光场景模型数据的提供的流2B13转换为请求的用户数据，而无需先存储在客户端(“本地”)数据库1A07中，或者甚至根本没有存储在客户端数据库1A07中，其中例如，场景转换是通过渲染并呈现到自由视图或满足用户请求的其他场景数据的步骤进行的。然而，优选的并且在本文为了提供显着益处而示出的是，通过首先或另外地重建客户端数据库1A07，并且不仅将流2B13转换成诸如用户自由视图可视化的所请求的场景数据，还可以允许进行中的基于客户端侧的场景数据提供基本上独立于全局场景模型或者至少是半独立的，其中，有时需要基于用户的请求来更新或进一步“增长”本地客户端场景数据库1A07，其中这种增长被称为提供要简短讨论的子场景增量。

仍然参考图5，熟悉软件系统和架构的人会理解，尽管操作507优选地被实现为场景编解码器1A11内的解码器的一部分，但操作507的至少某一部分可以由实现客户端UI501的应用软件1A03执行。例如，在操作509中实际提供所请求的场景数据之前，应用软件1A03可以包括向客户端UI 501提供指示和改变。在传统场景处理中，如果请求的数据例如是自由视图可视化，则操作509包括所谓的渲染。相对于当前的渲染技术，由于全光场景数据库1A07，示例性实施例提供了增加的自由物质和自由照明选项，这些选项提供了甚至更真实的自由视图。如熟悉软件架构的人会理解的并且基于对本公开的仔细阅读，插入操作507和提供请求的数据操作509均可将各种应用接口(API)调用调出到场景处理单元(SPU)1A09中。与传统的编解码器不同，示例性实施例提供了确认场景数据被接收511到场景数据的服务器中，在考虑到将来提供的场景增量依赖于最初提供的独立子场景以及任何然后提供的场景增量时，这一特征尤其重要。

仍然参考图5，重要的是看到客户端SOI数据库1A07可以足以提供操作509中所需的SOI数据中的任一者和所有。第一独立子场景足以满足所有未来数据请求的程度与初始子场景的大小成正比，并且与要请求的场景数据的范围成反比。随着所请求的或期望的场景数据的范围增加，传输具有足够的场景缓冲区的预期初始子场景的负担和成本最终变得令人望而却步。例如，如果初始子场景是圣克莱门特大教堂的前廊，仅期望用户从该前廊进入大教堂并站在大厅中，则子场景的可以是受限的大小。然而，如果用户期望进入大教堂或穿过马路进入另一座建筑物，则该子场的大小必定会增大。因此，示例性实施例规定，初始子场景包括智能地确定的场景缓冲区，该场景缓冲区平衡高达一定数量的场景数据的期望的用户请求，有需要最小化传输的场景数据并从而减少任何感知的场景或UI滞后，其中在系统提供从全局模型传输子场景的其他增量以用于基于显式或隐式用户指示中的任一者满足其他请求或期望的其他请求之后。再次，优选地，该平衡至少部分地基于类似用户请求的历史而基于机器学习和其他确定性方法，使得通过最小量的初始提供以及之后增量提供的场景信息来提供最大连续用户体验。

如熟悉各种类型的预测系统的人会清楚的，随着“前瞻”(面向未来)时间增加，可能的场景移动变化的数量呈几何或甚至指数级增长，而不是线性增长。例如，如果为用户提供了圣克莱门特大教堂的前廊的初始子场景，则1分钟对1小时的前瞻时间至少导致场景缓冲区大小的几何增长，使得如果计算得出的缓冲区大小为X持续1分钟，则Y的缓冲区大小为1小时可能会远远大于60*X。在这方面，某些实施例的另一个关键技术优势在于，将示出全光场景模型的表示和这些表示的组织来显著减少提取任何初始子场景或场景增量所必需的处理时间，给定任何选择的缓冲区大小，相对于当前已知的场景处理技术。因此，从对平衡权衡的仔细考虑中可以清楚，子场景或场景增量提取和处理时间的显著减少既支持相同系统响应时间的更大初始子场景缓冲区又支持有利于更频繁场景增量的更小子场景增量缓冲区，其中在用户请求前瞻时间减少时，更小更频繁的方法实际上减少了总传输的场景数据。

仍然参考图5，剩余的处理客户端请求操作513记录消耗操作515提供追踪用户的场景使用，并且在确定或期望初始子场景缺少足以满足当前用户请求或可能的未来用户请求的场景数据的情况下，智能地增加客户端SOI模型。在用户与UI 501相互作用例如以接收更新的场景数据时，这些相互作用提供了场景数据值和消耗的指示。此外，客户端UI 501优选地允许用户表达可解释为对更多场景数据的请求的指示，诸如通过移动鼠标、操纵杆、游戏控制器或VR耳机，其中使用传感器1E09来检测指示。这些使用或期望使用指示中的任何一个或多个允许系统追踪客户端SOI模型内的用户消耗(作为操作513a)，其中将追踪的使用作为模型使用历史4C29(参见图4C)保存在服务器和客户端全光场景数据库1A07中的一个或两个中。

在用户指示由客户端UI 501处理时，处理客户端请求操作513包括操作513b，该操作用于确定用户指示中的任一者是否可解释为场景数据的下一个请求，并且然后确定是否仅基于已经包含在现有本地客户端SOI模型内的场景数据可以满足下一个请求。如果仅基于现有客户端SOI模型可以满足下一个请求，则通过操作509将所请求的场景数据提供给用户。如果仅基于现有客户端SOI模型不能满足下一个请求，则操作513c确定该下一个请求是否是客户端SOI模型内的现有子场景(或子场景)的增量，或者下一个请求是否用于完全新(并因此独立)的子场景。如果该请求用于新的子场景，则操作513c传输控制或者以其他方式调出客户端UI 501来有效地确定正被请求的新的子场景是什么(例如，切换到圣劳伦斯大教堂)，或者即使用户可能在请求完全新的全局场景(例如切换到威尼斯之旅)。如果请求不用于新的子场景，而是以需要对当前子场景增加增量的方式继续探索现有子场景，则操作513d确定该子场景的下一个增量向量。下一个增量向量表示场景模型的任何维度，诸如时空扩展、空间细节、光场动态范围或物质场动态范围，其中，该向量是指示满足用户请求最少需要的新场景数据的范围。在确定向量时，操作513d优选地访问由记录消耗操作515追踪的用户历史，其中确定用于最少满足用户的请求的向量以及使用历史(当前和所有其他追踪用户的)可以组合起来至少部分地由系统在估算下一个场景增量和增量缓冲区大小时使用，其中再次缓冲区大小将场景增量扩展到最小满足向量场景增量以包括期望的“前瞻”子场景使用。

仍然参考图5，如熟悉软件系统的人会理解的，其他操作布置是可能的，同时仍执行追踪和记录用户指示和场景模型消耗中的至少一些的优选步骤。此外，在仍确定用户是显式还是隐式地请求另外场景数据，以及在客户端场景模型数据库1A07内是否已经存在此另外场景数据时，其他操作布置是可能的。如果另外场景数据还不存在，而是对客户端SOI数据库1A07中已经存在的子场景的扩展，则用于确定下一个场景增量和缓冲区大小的再其他操作布置是可能的。这样，在附图中为处理客户端请求513和记录消耗515提供的功能应被认为是示例性的，而不是对实施例的限制。此外，操作513、513a，513b，513c，513d和515中的任一者可以被实现为在它们自己的处理元件上同时执行，或者被实现为在单个处理元件上顺序地执行。例如，可以与请求追踪操作513b和513c的顺序处理并行地执行追踪用户消耗操作513a和记录用户消耗操作515。在另一考虑中，记录消耗操作515可以在用于更新客户端SOI数据库1A07使用历史4C29的客户端系统1A01上以及在用于更新全局SOI数据库1A07使用历史4C29的服务器系统1A01上运行。还可能在客户端系统1A01或服务器系统1A01上执行以下中的一些或全部：确定子场景513d的下一个增量向量(包括确定缓冲区大小)。

重要的是要注意，追踪并汇总了用户对场景模型的使用，并且客户端系统首先仅基于客户端系统1A01当前驻留的或可访问的客户端SOI模型来尝试满足对新场景数据的请求，并且如果全局SOI模型需要另外的子场景增量，则进行计算以便确定相对于期望的前瞻使用量和确定的服务质量(QoS)水平提供最大连续用户体验所必要的最小量的子场景增量，其中确定期望的前瞻使用量至少部分基于追踪使用的历史。

接下来参考图6，示出了基于图5的描述构建的一些示例性实施例的流程图，但是现在正解决一种这样的变型情况：客户端首先创建场景模型或更新现有场景模型，而不是访问现有模型。相对于图5，操作507、509、511、513(包括513a、513b、513c和513d)、515和517基本上保持如图5中所描述的，并因此将相对于本图6进行最少的另外讨论。图6的示例性用例是用诸如蜂窝电话的移动设备工作的用户，该移动设备是使用场景编解码器1A01来创建(或更新)例如在冰雹风暴中受损的他们的汽车引擎盖的场景模型的系统。许多其他用例可应用于除了示例性用例之外的图5、图6和图7中的流程图中的每一个，诸如相对于图6的建模汽车损坏。例如，本图6的用例同样可应用于用户捕获其资产或财产(包括例如房屋)中的任一者的场景模型，或者可能其中用户是需要捕获资产或财产模型的代理商，诸如保险或房地产代理商。工业和工程公司也可以使用相同的用例来捕获关键资产或财产的场景模型以便与他人共享，其中这些资产或财产可以是任何大小且几乎无限制的视觉细节。

仍然参考图6，客户UI 501包括与图5相同的传感器1E09和感觉输出端1E11，其中用例的一个不同之处在于，对于图6中例证的，传感器1E09包括一个或多个传感器，这一个或多个传感器用于感测要重建到全光场景模型和数据库1A07中的资产、财产或其他真实场景。典型的传感器1E09将是诸如图2B中描绘的2B05-1和2B05-2的一个或多个真实相机，但是可以是多个传感器和传感器类型中的任何一种。客户端UI 501允许用户实例化新的客户端SOI或选择现有的客户端SOI，例如他们的汽车或甚至汽车引擎盖。示例性实施例可以规定，例如，可以预先存在用户的资产、财产或其他场景的全光场景模型，或者用户将要创建(实例化)新的场景模型。例如，如果用户是租车代理商，并且租车者刚刚将租车退还给扫描站，则客户端UI 501可能允许代理商扫描租车者协议中的条形码，并且然后至少部分地使用此信息来在开始租赁之前调出同一车辆的现有全光场景模型。因此，可以通过自主的但仍被认为是传感器1E09的设备来重新扫描汽车，其中新的扫描图像或以其他方式感测到的数据可用于更新车辆的现有场景模型。

如前所述，使用这种方法，全光场景存在于所有四个维度中，包括三个空间维度以及时间维度。因此，对现有全光场景模型的任何完善都可以永久性地更改全光场景，使得原始基线物质和光场数据被覆盖或丢失，或者将该完善组织为另外的表示，例如与特定时间(像美国东部时间2019年4月25日上午10:44)或事件名称(像租赁协议970445A)中的任一者相关联。假设按照全光场景数据库1A07的时间维度组织物质和光场，那么至少可以：1)基于时间/事件之前或之后创建任何场景数据，以进行任何真实场景的重建和完善；2)测量或以其他方式描述全光场景数据库1A07中任何两个时间点之间的差异；3)对全光场景数据库1A07变化的历史进行编目，这些变化由数据库1A07特征中的任一者过滤掉，诸如场景模型的包括物质场和光场的任何部分的一些或全部。

在用户扫描自己的汽车引擎盖以例如记录并测量冰雹损坏的实例中，还期望用户可以访问汽车的全光场景模型的远程数据库，这样，用户将首先为自己的汽车选择适当的基线品牌和模型，并且然后以此为基础，再扫描其独特的数据以重建并完善基线模型，而不是在没有任何基线全光场景的情况下实例化新模型。进一步期望在这种情况下，客户端UI501还将为用户提供智能功能，这些功能将允许用户调整例如与基线模型相关联的物质场，例如以便将汽车的颜色改变为用户添加的自定义绘画颜色，或者基线与独特真实场景之间的任何类似类型的差异。进一步期望可以对物质场的任何部分进行命名或标记，例如“汽车外观”，其中此标记是辅助信息4C21，诸如被认为是模型增强4C23的辅助信息(参见图4c)。如仔细考虑将显示的，通过提供标记的基线全光场景模型，系统为创建并完善新的自定义场景模型提供了重要的杠杆作用。

一些示例性实施例还提供了多种标记的全光物质和光场类型和实例以及基线全光场景模型，其中例如汽车制造商创建了代表其任何汽车模型的构造中使用的各种材料的各种全光物质场类型，其中汽车模型再次被表示为基线全光场景。在这种布置中，汽车销售人员能够快速更改基线汽车以选择不同的材料(物质场)类型代入基线，使得这些模型转换4C25(参见图4C)然后可以作为全光场景模型进行探索(像图5的通用用例)。如细心的读者将理解的，图5、图6和图7中呈现的每个通用用例的用途几乎是无限的，更不用说从本文提供的描述中讨论的、暗示的或以其他方式显而易见的其他用例变型，这使得尤其关于图5、图6和图7描述的用例应被视为示例性的，而不是限制。

仍然参考图6，在将客户端SOI建立为数据库1A07之后，将信息传输到例如第二服务器侧系统1A01，其中在服务器侧上的操作503实例化/打开对应于客户端SOI模型的全局SOI模型。如将变得清楚的是，全局模型和客户端模型要被更新以包括由客户端系统1A01传感器1E09捕获的基本上相同的新场景模型信息，虽然没有要求，否则全局模型和客户端模型相对于场景数据是基本相同的。优选地，操作503与客户端UI 501通信，使得在实例化或基本实例化全局SOI模型之后，客户端UI 501向用户指示并允许用户开始捕获场景数据(参见图2B的2B07)，诸如有损坏的用户的汽车引擎盖的图片和视频。在捕获诸如图像的新场景数据时，优选地使用适当的传统编解码器(诸如用于图像数据的视频编解码器)来压缩并传输捕获的数据。将压缩的新场景数据传输到服务器侧系统1A01，其中操作505解压并然后至少部分地使用新的场景数据来重建或完善全局SOI模型，其中重建更多地参考全新的场景，并且完善更多地参考现有的场景(像已经存在但现在正在更新的汽车的全光场景模型)。在重建操作505正在创建全局场景模型的新部分时，服务器侧系统1A01操作517提供来自全局SOI模型的(新部分的)下一个子场景增量，以传送给客户端侧系统1A01。在接收新的子场景增量之后，客户端侧的操作507将下一个场景数据(子场景增量)插入到客户端SOI模型中。如仔细考虑将显示的，客户端侧系统1A01正在捕获数据，而服务器侧系统1A01正在进行所有场景重建，其中场景重建可能是计算密集型的，使得服务器侧系统1A01有效地将这一计算密集型任务从客户端系统1A01中卸载。

仍然参考图6，由于客户端SOI模型是基于从全局SOI模型提供的接收到的子场景增量(基于客户端传感器数据重建)而构建的，客户端系统1A01然后能够通过UI 501向用户提供场景模型信息，所有这些都根据与提供请求的SOI数据操作509和处理客户端请求513相关的先前描述。另外，如先前所讨论的，客户端系统1A01优选地在操作513a中追踪用户指示和使用，以通过操作515向全局SOI数据库1A07记录。

接下来参考图7，示出基于图5和图6构建的一些示例性实施例的流程图，但是现在正解决一种这样的变型情况：在客户端侧系统1A01和服务器侧系统1A01两者均能够重建真实场景并提供场景增量的情况下，客户端首先创建场景模型或更新现有场景模型，然后捕获真实场景的本地场景数据，这与图6不同，在图6中，真实场景仅在服务器侧系统1A01上被重建成场景模型。关于图5，操作507、509、511、513(包括513a、513b、513c和513d)、515和517保持基本上如在图5中所描述的，并且因此将关于本图7进行最少的另外讨论。关于图6的描述，操作501(包括501a、501b和传感器1E09、1E11)以及操作503保持基本上如在图6中所描述的，并且因此将关于本图7进行最少的另外讨论。图7的示例性用例是利用诸如工业平板电脑的移动设备的用户，该工业平板电脑是使用场景编解码器1A01来创建(或更新)救灾现场的场景模型的系统(其中可以想象的是，许多用户或自主车辆(未描绘)充当客户端1A01以基本上同时捕获场景感觉数据)。除示例性用例外，许多其他用例适用于图5、图6和图7中的每个流程图，诸如关于图7对灾难现场建模。例如，本图7用例同样适用于捕获任何共享场景的场景模型的用户，诸如工业设置中的工人或城市设置中的通勤者和行人。

仍然参考图7，像图6一样，服务器侧系统1A07接收由或至少部分地基于客户端侧系统1A07捕获的压缩的原始数据，在操作505中，将该压缩的原始数据重建成全局SOI模型或完善现有的全局SOI模型。当前用例还包括服务器侧系统1A07上的操作517，该操作用于将下一个子场景增量从全局SOI模型提供给客户端侧系统1A01操作507，其中操作507然后使用所提供的子场景增量来更新客户端SOI模型，以便在操作509中通过UI 501向用户提供请求的SOI数据。与图6的用例不同，客户端侧系统1A01还包括用于重建客户端SOI模型的操作505，然后还包括用于向服务器侧系统1A01提供子场景增量的操作517，其中服务器侧系统1A01然后还包括用于重建或完善全局SOI模型的插入操作507。客户端和服务器侧系统两者均包括用于确认任何接收到的和已处理的场景数据的操作511。重要的是要注意，优选地，在服务器侧系统1A01和客户端侧系统1A01中的任一者上运行的应用软件1A01的指导下，并且优选地，在共享通信中，在任何给定时间，对于由或在任何一个或多个客户端系统1A01的命令下捕获的任何给定真实场景数据，服务器侧或客户端侧系统1A01中的一者或两者可以由相应的应用软件1A01指导来重建任何真实场景数据，然后还共享重建后的场景数据作为其他系统1A01中任一者的场景增量，或者不重建任何真实场景数据，然后还接收并处理由其他系统1A01中任一者重建的场景增量中的任一者。

在具有多个客户端侧系统1A01以及甚至多个服务器侧系统1A01的大型用例中，这种操作安排的价值变得更加明显，其中熟悉计算机网络和服务器的人将理解的是，跨多个系统1A01进行通信的应用软件1A01正在执行场景重建和分布负载平衡。一些客户端可能是利用移动设备1A01的用户，而其他客户端则是自主的陆基或空基系统1A01。这些不同类型的客户端1A01中的每一个都期望具有不同的计算和数据传输能力。这些单独客户端1A01中的每一个还期望具有一定范围的可能不同的真实场景传感器1E09，并且需要全光场景数据。软件1A01的负载平衡确定至少部分地考虑了以下中的任一者或其任何组合：所收集的传感器1E09数据的整体多样性、场景重建的优先级、跨所有服务器侧和客户端侧系统1A01的计算能力的可用性、跨网络1E01(参见图1E)在各种系统1A01之间的数据传输能力、以及每个系统对场景数据的期望和按需请求。像图5和图6的用例一样，图7的用例还优选地跨多个客户端侧系统1A01捕获指示和场景数据使用，并且跨多个系统1A01将这些指示和使用数据记录在适当的场景数据库1A07中的任一者中，其中示例性实施例的机器学习(或确定性)部件除先前已经描述的其他益处和使用之外，然后能够访问该记录的场景使用以优化负载平衡。还期望将服务器侧场景重建度量(诸如但不限于接收到的原始数据类型和量的波动以及场景重建处理时间)与客户端侧使用一起另外记录下来，其中该另外的服务器侧记录然后也至少部分地由机器学习(或确定性)部件使用来确定或提供负载平衡需求。

场景数据库

图8示出具有与日常生活(每天)场景相关联的关键属性的厨房场景：透射介质(例如，玻璃水壶和窗户玻璃)、高反射表面(例如，金属罐)、精细结构化对象(例如，右侧盆栽植物和室外树木)、无特征表面(例如，橱柜门和洗碗机门)、以及有效的无边界体积范围(例如，通过窗户看到的室外空间)。图8中的场景是示例性场景，该场景可以被存储在使用场景编解码器1A01的系统的场景数据库1A07中以在各种用例中进行处理。这种处理的一个关键方面是将体积和方向(角度)的空间细分成可寻址容器，这些可寻址容器用于容纳场景的全光场元素。

图9示出体积和方向空间容器的示例性表示。体元901是界定场景体积空间区域的容器。简称为“立元”的立体角元素903界定了源自立元顶点的角度空间区域。(从两个不同的视点示出了立元903，以帮助传达其3D形状。)尽管立元903被示出为有限范围的金字塔，但是立元可以从其原点无限远地向外扩展。一个实施例中所使用的容器可以具有或可以不具有图9所示的确切形状。例如，不排除使用非立方体体元或不具有正方形横截面的立元。下面参考图21至图65给出有关体元和立元的有效分层布置的其他细节。

图10示出在不同于上面参考图4B所描述的实施例的示例性实施例中的日常生活场景的示例性场景模型1001的俯视平面图。与图4B实施例更关注整体编解码器操作相反，此处所描述的实施例更窄地关注与子场景提取和插入有关的方面。全光场1003被外部场景边界1005包围。全光场1003包含表示所建模场景的物质场和光场的全光基元实体(“全光基元”或简称为“基元”)。全光场1003在体积上由体元的一个或多个大体分层布置索引，并且在方向上由立元的一个或多个大体分层布置索引。全光场中的物质表示为一个或多个介质元素(“介元”)，诸如1027，每个介元都包含在体元中。体元也可以是空的，在这种情况下，该体元被称为“空隙”或“类型为空隙”。外部场景边界之外的体元类型为空隙。尽管根据定义，这些空隙体元不包含全光基元，但它们可能与(指向)除全光基元之外的实体相关联。全光场中的光表示为一个或多个辐射元素(“辐元”)，诸如1017，每个辐元都包含在位于介元(例如，包含介元的体元)处的立元中。

介元处的光场(包括仅表示可忽略的光相互作用的光场)包括这四个分量光场：入射光场、响应光场、发射光场和窗状光场。入射光场表示从其他介元(包括紧邻所讨论的介元的那些)传输的光。响应光场表示响应于介元与入射光相互作用而从介元出射的光。发射光场表示由于除与入射光相互作用之外的某个物理过程(例如，从另一种能量形式变换，如在灯泡中)而从介元出射的光。窗状光场表示由于全光场外部未指定的过程而入射到介元中的光。这样的一个实例是表示阳光的窗状光场，当全光场没有足够远地扩展以在体积上将太阳本身表示为发射源时，该阳光会入射在全光场的外部场景边界处。重要的是要注意，在一些实施例中，窗状光场可以由被视为“窗状层”的多个窗状光子场组成，这些窗状层表示，例如一层为来自太阳的光且另一层为来自月亮的光。介元以其与入射光场相互作用的相同方式来与入射的窗状光场相互作用。在以下有关BLIF的讨论中，有关入射光场的陈述等效地应用于窗状光场。(响应光场由入射光场和窗状光场两者确定。)

在全光场1003中，介元1027与所有介元一样具有相关联的BLIF。BLIF表示准稳态光场中入射辐元和响应辐元的感兴趣特性之间的关系，此类特性通常包括辐射和/或光谱和/或极化信息。在某些示例性实施例的上下文中，BLIF很有用，因为它可以务实地表示光与物质的相互作用，而无需在分子/原子层级上进行此类相互作用的计算密集型建模。在高度通用的BLIF表示中，感兴趣特性的响应入射比可以以适当的精细立元粒度以采样/表格形式存储。当实践时，实施例可以使用一个或多个压缩的BLIF表示。一种这样的表示是低维模型，该低维模型产生响应辐射率作为入射辐照度的分析函数，在入射和出射方向、光谱带以及入射和响应光的偏振状态上进行参数化。这种低维模型的实例包括常规的分析BRDF，例如Blinn-Phong和Torrance-Sparrow微小面反射率模型。BLIF信息的这种压缩是本领域技术人员众所周知的，并且在本发明的一些实施例中将被用于压缩和解压缩BLIF数据。实施例可以允许表示空间上(体积上)变化的BLIF，其中一个或多个BLIF参数在体积场景区域的范围内变化。

外部场景边界1005是闭合的、分段的连续二维流形，从而将全光场中的介元与位于全光场外部的空隙体元分开。空隙体元也位于内部边界1007和1009内部。场景模型1001既不表示外部场景边界外部的光传输也不表示内部边界内部的光传输。与空隙体元相邻放置的介元被称为“边界介元”。除从全光场中的其他介元传输的入射光场之外，边界介元的光场还可以包括表示由于全光场外部的未指定现象而入射到全光场中的光的窗状光场。通常可以将场景中一个或多个边界体元处的窗状光场视为体积上位于由边界限定的分段连续流形上的四维光场。

外部场景边界的一个实例是室外日常生活场景中的天空。在场景模型的全光场中，空气介元试图存在某个合理距离(例如，视差分辨率极限)，超过此距离则存在空隙体元。例如，晴朗的天空或月亮的光以外部场景边界处的空气介元的窗状光场表示。同样，由于内部场景边界内部的未指定现象而产生的光以与内部场景边界接界的介元的窗状光场表示。内部场景边界的一个实例是尚未进行完全重建的体积区域周围的边界。相邻边界介元的4D窗状光场包含有关有界空隙区域的所有(当前)可用光场信息。如果后续重建操作成功地发现了位于先前空隙区域内的物质场模型，则该情况将改变，该模型现在将先前的窗状光场解释为从新发现的(分辨出的)介元传输的入射光。

除全光场1003之外，场景模型1001还包括其他实体。介元1027和其他附近的非空气介元在显示、操纵、重建以及由使用场景编解码器1A01的系统执行的其他潜在操作中有用的各种分组中进行了引用。一个分组被称为特征，其中全光基元按照其感兴趣特性(可能包括空间姿势)通过某种图案分组在一起。1029是形状特征，这意味着该特征的构成介元根据其空间布置进行分组。在一个实施例中，使用场景编解码器1A01的系统可能出于某个目的而将特征1027视为突出部或凸起。1021是BLIF特征，这意味着该特征的构成介元基于其相关联的BLIF的图案进行分组。使用场景编解码器1A01的系统可能将特征1021视为对比度边界、颜色边界、材料之间的边界等。

全光片段是由某组特性中的相似性(而不是任意图案)定义的特征的子类型。片段1023和1025是物质场片段，在这种情况下，这些片段是由每个片段的介元的BLIF中的均匀性(在某个公差范围内)定义的。一个对象(诸如1019)是物质场的特征子类型，它是由一个或多个人类将其识别为自然语言和认知中的“对象”而定义的。示例性对象包括厨房桌子、玻璃窗户和树。

相机路径1011是特征子类型，其表示由观察全光场1003的相机追踪的6-DOF路径。相机路径的潜在有用实施例的方面包括运动学建模和球面线性插值(slerp)。在沿着相机路径1011的位置处，诸如1013的焦平面存在于记录光场的相机视点处。入射在焦平面上的辐元集合通常称为图像。示例性实施例不将相机表示限制为具有像素(感光元件)的平面阵列。像素的其他布置也是可表示的。焦平面1013记录光出射对象1019。可以在物质场、光场或两者的组合上定义特征。项目1015是光场的示例性特征，在这种情况下，其包括在焦平面1013处的辐元。在这种情况下，辐元的图案定义了特征。在常规的图像处理术语中，使用场景编解码器的系统可以将1015视为检测为图像像素中2D图案的特征。

图11示出与上面参考图4C描述的实施例不同的实施例中的场景数据库的框图。与图4C实施例更关注整体编解码器操作相反，此处所描述的实施例更窄地关注与子场景提取和插入有关的方面。场景数据库1101包括一个或多个场景模型、BLIF库、活动日志和相机校准以及其他未示出的实体。场景模型1103包括一个或多个全光场(诸如1105)、以及多组特征(诸如1107)，这些特征可能包括类型片段(诸如1109)、对象(诸如1111)和相机路径(诸如1113)的特征。另外，一个或多个场景图(诸如1115)指向全光场中的实体。场景图也可指向当前在全光场中未显示的分析实体。场景图被布置成节点的层次结构，从而定义所提及实体之间的空间关系和其他关系。如果使用场景编解码器的系统期望在某个适当的时间点处将多个全光场和/或场景图注册到公共时空参考框架中，则多个全光场和/或场景图通常一起存在于某个单一场景模型中。如果没有这种期望，则多个全光场和/或场景图通常会存在于单独的场景模型中。

BLIF库1119保存BLIF模型(表示)。如上所讨论，场景数据库可以多种形式存储BLIF，这些形式从分光极化出射入射比到有效的低维参数模型。BLIF库1119包括材料子库1125，该材料子库表示光相互作用特性和可以在物质场中存在的介质的其他特性。材料库1125中条目的实例包括电介质、金属、木材、石材、雾、空气、水和接近真空的外部空间。BLIF库1119还包括表示介质的粗糙度特性的粗糙度子库1127。粗糙度库1127中条目的实例包括各种表面微小面分布、砂纸的粒度类别、以及体积散射介质中的杂质分布。全光场中的介元可以是指BLIF库条目，或者可以具有未包括在任何BLIF库中的“本地”定义的BLIF。

活动日志1121保存感测(包括成像)活动日志1129、处理活动(包括与编码、解码和重建有关的活动)日志1131、以及其他相关活动/事件。相机校准1123保存补偿参数和与在基于场景模型的成像、显示或其他分析操作中使用的相机的校准有关的其他数据。

图12示出在全光场中发现的基元实体的类型的层次结构的类图1200。根全光基元1201具有子类型介元1203和辐元1205。介元1203表示物质场中被解析为由特定体元包含的介质。同质介元1209是一种这样的介元，其介质的一个或多个感兴趣特性在其整个体元中是均匀的、在某个公差范围内。同质介元1211的实例包括适当均匀的固体玻璃、空气、水和雾。同质介元1211是在感兴趣特性上不具有这种均匀性的介元。

面元1225是异质介元，其具有由分段的连续二维流形分隔的不同介质的两个不同区域。在示例性实施例中，流形具有由法向向量表示的平均空间取向，并且具有由流形与包含面元的体元的体积中心之间的最接近点表示的空间偏移。面元1225的子类型包括简单面元1227和分割面元1229。简单面元1227就像其超型面元1225所述。简单面元1227的实例包括墙的表面、玻璃雕塑的表面和平静的水面。对于分割面元1229，在介元内面元边界的一侧上，将介元另外划分成由另一个分段的连续二维流形分隔的两个子区域。分割面元1229的一个实例是棋盘表面的黑色正方形和白色正方形会合的区域。

平滑变化的介元1211表示一种这样的介质，对于该介质而言，一个或多个感兴趣特性在介元的体积范围内平滑变化。通常会采用空间变化的BLIF来表示平滑变化的介元1211的整个体积中光相互作用特性的平滑变化。平滑变化的介元1219的实例包括以平滑的颜色渐变绘制的表面以及在地面上的薄雾层让位于其上方的较干净空气的区域。

辐元1205表示场景的光场中被解析为由特定立元包含的光。辐元1205具有子类型各向同性辐元1213和各向异性辐元1215。各向同性辐元1213表示在辐元的方向范围内在一个或多个感兴趣特性(诸如辐射、光谱或极化)上均匀的光。各向异性辐元1215表示在感兴趣特性上不具有这种均匀性的光。分割辐元1221是各向异性辐元，其具有由分段的连续一维流形(曲线)分隔的不同光内容的两个不同区域。分割辐元1221的实例是包括高度准直的光束的边缘的辐元。平滑变化的辐元1223表示在辐元的方向范围内在一个或多个感兴趣特性上平滑变化的光。平滑变化的辐元1223的实例是来自笔记本电脑屏幕的像素的光，随着出射角偏离垂直方向，该光表现出辐射衰减。

图13所示的图像是日常生活场景(真实世界厨房)的计算机化模型的渲染。在图13中指示了厨房场景中的两个3D点，以用于随后的附图和讨论中。点1302是厨房开放空间中的典型点(为了使其位置更清晰，示出了垂直于地板的虚线)。点1304是大理石柜台表面上的点。

本文所描述的示例性实施例能够现实地表示诸如图13所示的场景。之所以如此，是因为根据示例性实施例的技术不仅对场景的物质场建模，而且对光场以及两者之间的相互作用建模。进入或离开体积空间区域的光由入射到区域中表示该空间的指定点或从该点离开的一个或多个辐元表示。因此，该组辐元称为“点”光场或PLF。PLF的入射光和出射光由一个或多个辐元表示，该一个或多个辐元与以代表点为中心的“环绕”立方体上的指定区域交叉。

这可以通过显示一个立方体来可视化，该立方体具有穿过立方体面、在来去中心点途中、在面上显示的光。这种“光立方”在图14的图像中为1401。光立方以图13中的点1302为中心。该光立方示出了入射光进入点1302。因此，在立方体表面上的一个点或区域处所示的光强度是来自厨房(或更远处)的项目和光源的光，它们穿过该点或区域，也与立方体的中心(点1302)交叉。图15示出光立方1401的六个另外的外部视图。还可以从立方体内部观看光立方。图16、图17和图18中的图像从光立方1401的内部示出了多种视图。

光立方还可以用于可视化从某个点(出射PLF)发出的光。这种光立方是针对点1304(如图像13所示的厨房中大理石柜台上的点)的图19所示的1902。立方体的表面示出从该点发出的与立方体的面或立方体面上的区域交叉的光。这就像通过吸管从位于围绕单个点的球体上的所有方向看该点。注意，光立方的下半部的表面为黑色。这是因为PLF的中心在不透明材料(在这种情况下为大理石)的表面上。没有光沿柜台内部的方向离开该点，因此在光立方中那些方向是黑色的。

光立方还可以用于可视化其他现象。图20中的图像示出光立方2001。它示出BLIF函数在基于入射PLF生成出射PLF时的作用。在这种情况下，入射光是入射光元件(辐元)2002中的单个垂直偏振光束。由该单个光束产生的出射光示出在光立方2001的面上。基于所使用的BLIF的细节，出现了复杂的出射光图案，如光立方2001所示。

一些示例性实施例提供了用于计算所建模场景中的光传输及其与物质的相互作用的技术。这些和其他涉及空间信息的计算是在空间处理单元或SPU中执行的。该计算利用由两种类型的数据结构组成的全光八叉树。第一数据结构是八叉树。一个实例是如图21和图22所示的体积八叉树2101。八路划分分层树结构用于表示有限立方体全域中的立方体空间区域。在树结构的顶部处的是第0层级处的根节点2103，该根节点恰好表示全域2203。根节点具有八个子节点，诸如第1层级处的节点2105。该节点表示体元2205，这是恰好填充全域的八个相等大小的不交叉的立方体中的一个。利用相同的细分空间方法，该过程将继续进行到下一个层级。例如，第2层级处的节点2107表示立方体空间2207。全光八叉树的八叉树部分将被称为“体积八叉树”或VLO。

全光八叉树中所使用的第二数据结构是立元树。立元是“立体角元素”，并且用于表示从“原”点投影的方向空间区域。立元通常用作辐元(从原点出射的光或从由立元表示的方向落到原点的入射光)的容器。立元树通常表示围绕原点的某个体积空间区域(例如，体元)的方向空间。

由立元表示的空间由立方体面上的正方形区域确定。该立方体是“周围立方体”，并且以立元树的原点为中心。该立方体可以具有任何大小，并且确实可以包围或限制立元树。该立方体仅指定了立元树中立元的具体几何形状，每个立元从原点延伸到无限距离(但通常仅在由全光八叉树表示的体积内使用)。类似于八叉树，立元树是一种分层树结构，其中节点表示立元。

立元树2301在图23和图24中展示。根节点2303在第0层级处，并且表示从其原点(在周围立方体2403的中心处的点)出现的所有方向。尽管立元和立元树包围了从原点开始延伸的无限体积空间，但是它们通常仅在其全光八叉树(其通常是其VLO的全域)的全域内限定和使用。如在图23中可以注意到，立元树根节点具有六个子节点，而下面子树中的所有节点都具有四个子节点(或没有子节点)。节点2305是根节点的六个可能子节点中的一个(仅示出一个)。该节点在第1层级处，并且表示从原点投影的与立元树的周围立方体的面2405交叉的所有空间。注意，当立元树的中心位于全域的中心处时，其限定面将是全域的面。当立元树在不同位置时，其原点将在全光八叉树内的另一位置，并且其周围立方体将以原点为中心移动。周围立方体将不再是全域。由于周围立方体仅确定立元相对于原点的方向，因此它可以是以原点为中心的任何大小的立方体。

在下一个细分层级处，节点2307是节点2305的四个第2层级子节点中的一个，并且表示面正方形2407，其是全域的相关联面的四分之一。在第3层级处，节点2309表示由面正方形2409限定的方向空间，该面正方形是将正方形2407分成四个相等的正方形中的一个(面2405的十六分之一)。下面在图41中以2D针对原点在点4101处的立元树4100展示立元树的分层性质。节点4102是立元树中第n层级处的非根节点(根节点将具有六个子节点)。该节点表示方向空间片段4103。在向下的下一个层级处，四个第n+1层级节点4104中的两者表示两个立元4105(另两者表示另两个3D)。在第n+2层级处，节点4106表示2D中的四个区域4107(3D中的16个)。在全光八叉树中使用的立元树将被称为SLT。

注意，与八叉树一样，如果子树中的属性由附接到节点的属性充分表示，则立元的细分会终止(没有子树)。在已达到足够水平的分辨率或出于其他原因的情况下也是如此。像八叉树一样，立元树可以用多种方式表示。节点通常通过单向链接(父到子)或双向链接(父到子和从子到父)连接。在某些情况下，八叉树或立元树的子树可以在同一树结构中多次使用(在这种情况下，从技术上讲，它成为图结构)。因此，可以通过使多个父节点指向同一子树来节省存储区。

图25示出全光八叉树2501中的一个VLO和三个SLT的组合。整体结构是VLO结构，其中立方体体元2505由第1层级VLO节点表示，并且体元2502由第2层级VLO节点表示。立元2507是第3层级立元，其原点在VLO全域的中心(第0层级)处。然而，立元2503具有不同的原点。该原点位于第1层级VLO节点的中心处，该节点用作其周围立方体。由于其限定正方形是周围立方体的面的四分之一，因此它是第2层级立元。

而不是单个VLO，如上所述，全光八叉树可以由表示多个对象或属性的多个VLO组成，这些对象或属性共享同一全域，并且通常使用设置操作进行组合。它们就像图像中的层。以这种方式，可以针对相同空间区域定义多组属性，并根据需要进行显示和采用。如果原点是同一点并且节点具有相同的对齐方式，则可以相同的方式组合多个立元树中的立元。例如，这可以用于维持可以根据需要组合的多个波长的光。

全光八叉树中的SLT和VLO具有相同的坐标系并且具有相同的全域，不同的是SLT的原点可以位于全光八叉树内的不同点处，而不必位于VLO节点中心处。因此，SLT的周围立方体虽然与全光八叉树中的一个或多个VLO处于相同的取向，但不一定与VLO全域或任何其他节点完全重合。

在图26中(以2D)展示在全光八叉树中使用透视全光投影(或简称为“投影”)，如由全光投影引擎计算的。全光八叉树2600包含附接到VLO的三个SLT。SLT A 2601的原点在点2602处。根据SLT A 2601，一个立元2603被示出为沿正x和正y方向投影穿过全光八叉树。SLT B 2604具有伸入全光八叉树中的立元2606，而SLT C 2607具有沿另一方向投影的立元2608。

这在图27中继续，其中示出两个VLO体元，包括VLO体元2710。SLT A 2601的立元2603和SLT B 2604的立元2606是出射立元。这意味着它们表示从其相应原点的中心发出的光。针对每个SLT仅示出一个立元。在使用中，通常会从每个SLT的原点投影许多不同分辨率的立元。在这种情况下，两个立元穿过两个VLO节点。SLT C 2607不具有与两个VLO节点中的任一个交叉的立元，因此未在图27中示出。

在操作中，SLT立元和VLO节点的交叉部将导致立元和VLO节点的细分，直到达到某个分辨率极限(例如，空间分辨率和角度分辨率)为止。在典型情况下，细分将一直发生，直到立元的投影在由数据特性和请求过程的迫切需求确定的某个分辨率层级处接近VLO节点的大小为止。

在图28中，落在体元2710上的一些出射光通过立元2603从点2602捕获，并且通过立元2606从SLT的原点2604捕获。取决于应用，可以采用许多方式捕获光。击中体元2710的该光由入射SLT D 2810表示。当光落在体元上时会生成此光，或者如果该光已存在，则将其添加到现有体元。在这种情况下，结果是两个入射立元2811和2806。现在，这表示落在体元上的光，如由击中节点中心的光表示。

SLT在全光八叉树中的代表性使用是使用进入体元的光(如由入射SLT表示)来计算从体元发出的出射光。图29展示这种情况。针对体元2710已知或假定的BLIF函数用于生成第二SLT，即出射SLT。这是出射SLT D 2910。它的原点位于与立元D 2810相同的点处。因此，来自场景中多个位置的出射光已向外投影，然后落在在入射SLT中捕获的体元上，并且然后用于计算该体元的出射SLT。

图30示出根据一些示例性实施例的SPU在全光八叉树上生成和操作时的功能。SPU3001可以包括一组模块，诸如集合操作模块3003、几何形状模块3005、形状变换模块3007、图像生成模块3009、空间过滤模块3011、表面提取模块3013、形态学操作模块3015、连接性模块3017、质量属性模块3019、注册模块3021以及光场操作模块3023。SPU模块3003、3005、3007、3009、3011、3013、3015、3017、3019和3021在八叉树上的操作是本领域技术人员众所周知的。他们知道可以通过许多方式来实现此类模块，这些方式包括软件和硬件。

在SPU功能中，已经扩展了若干功能以应用于全光八叉树和SLT。修改集合操作模块3003以在SLT上进行操作是对八叉树上的节点集合操作的直接扩展。多个SLT的节点必须表示相同的立元(方向空间区域)。然后以同一顺序遍历节点，从而为操作算法提供SLT中所包含的相关联属性。如文献中众所周知的，与八叉树一样，通过使用“全节点推入”(FNP)操作将一个SLT中的终端节点与其他SLT中的子树进行匹配。

由于SLT的性质，当应用于SLT时，几何形状3005过程的操作受到限制。例如，转换不适用，因为全光八叉树中一个点处的入射或出射立元通常与在另一原点处不相同。换句话说，一个点处的光场通常会不同于另一个点，并且因此必须在该点处重新计算。在光场操作模块3023中执行的立元插值和外推的光场操作完成了该任务。不需要这种情况的例外是当在整个区域中应用相同的照明(例如，来自视差边界的照明)时。在此类情况下，可以在区域内的任何点处简单地使用同一SLT。

功能3005内的几何缩放也不适用于SLT。单独的立元表示无限扩展的方向，并且不具有可缩放的大小。可以使用下面描述的方法将由过程3005执行的几何旋转应用于SLT。

3015中的形态学操作(诸如膨胀和收缩)可以通过将其极限扩展到例如重叠照明来应用于SLT中的立元。可以通过在SLT的周围立方体的面上使用大小过小或过大的矩形来实现。在某些情况下，可以通过将属性添加到VLO节点来扩展连接性功能3017以合并SLT，从而指示包含诸如照明的属性的立元与这些节点交叉。然后，可以将其与连接性一起使用，以标识与投影属性具有特定关系的连接部件(例如，由特定光源照射的材料或从空间中特定点看不到的材料)。

如图31所示，光场操作处理器3023的操作被划分成特定操作。位置不变光场生成模块3101用于生成来自视差边界之外的光的SLT，并且因此可以在视差边界有效的区域内的任何地方使用。光可以进行采样(例如，从图像中)或者根据对真实世界(例如，太阳或月亮)的建模或者根据视差边界之外的对象和材料的计算机化模型综合生成。

出射光场生成模块3103用于生成呈位于全光八叉树场景模型中特定点处的SLT形式的点光场信息。这可以来自采样照明或综合生成。例如，在某些情况下，图像中的像素值可以追溯到表面上的某个位置。然后，将这种照明附接到表面点，作为在图像的相机视点方向上附接到该位置(或对它们有贡献)的一个或多个出射立元。

出射入射光场处理模块3105用于生成场景中称为“查询”点的点(例如，对象上的点)的入射SLT。如果尚不存在SLT，则针对该点生成SLT，并且通过将其投影到场景中的照明信息来填充其立元。当找到该方向上的第一物质时，将访问其出射立元，以获取有关投影回起点的照明的信息。如果在所讨论的方向上不存在立元，则可能借助已知或期望的BLIF函数访问相邻的立元以生成一组内插或外推的照明值。对于查询点处入射SLT中所包含的其他立元，此过程继续进行。因此，入射SLT从所有方向或方向子集对着陆在查询点上的光的估计进行建模(例如，可能不需要来自包含表面查询点的不透明对象内部的光)。

然后，入射出射光场处理模块3107可以用于基于一点处的入射SLT生成该点处的出射SLT，该入射SLT可能由模块3105生成。通常使用应用于入射SLT的BLIF函数来计算出射SLT。光场操作模块3123中所包含的子模块的操作采用下面介绍的立元投影和立元旋转方法。

图32示出立元树的周围立方体3210。SLT的周围立方体的六个正方形面编号为1至6。坐标系的原点位于SLT全域的中心处。面0 3200是与-x轴(在图中隐藏)交叉的SLT面。面13201是与+x轴交叉的面，而面2 3202与-y轴(隐藏)交叉。面3 3203与+y轴交叉，面4 3204与-z轴(隐藏)交叉，而面5 3205与+z交叉。

SLT中的第0层级包括立元中表示围绕SLT原点的球体(4π球面度)的整个区域的所有者。在SLT的第1层级处，六个立元恰好与六个面中的一个交叉。在第2层级处，每个立元表示一个面的四分之一。图33展示面5 3205的编号。四分之一面0 3300沿–x、-y方向，而四分之一面#1 3301沿+x、-y方向，四分之一面2 3302沿–x、+y方向，而四分之一面3 3303沿+、+y方向。以下将关注面3 3303沿+x、+y、+z方向的四分之一面，如图33中突出显示。图34示出从+z轴看原点的面5 3205。从该视点观看，四分之一面3401被视为垂直线，即四分之一面正方形的边缘。

与第2层级四分之一面交叉的立元被称为顶部立元。由于存在六个面，并且每个面有四个四分之一面，因此总共有24个顶部立元。在3D中，顶部立元是由四个与SLT原点交叉的平面所包围的空间，并且每个平面与第2层级四分之一面的边缘交叉。在2D中，这减少为与四分之一面(诸如3401)的中心和两端交叉的两条射线。顶部立元的一个实例是图35中具有原点3501的3502。

立元是可用于表示光投影的空间区域。它们由包围体积空间的平面确定。从技术上讲，它们是具有无限高度的倾斜(或不正确)矩形金字塔。在2D中，平面表现为射线。例如，射线3601在图36中示出。该射线起源于SLT原点3602。特定射线由原点及其与投影平面3603的交叉部限定，该投影平面是平行于立元的周围立方体的一个面(在这种情况下垂直于x轴)的平面(2D中为线)。投影平面通常附接到VLO中的一个节点，并且将用于确定立元是否与该节点交叉，并在适当时用于执行照明计算。交叉点3604(t(t

SLT锚定到全域中的特定点，即其原点。锚点可以位于具有针对该点计算的相关联的投影信息自定义的显式限定的点处。或者，如此处所述，SLT原点可以在全域的中心处开始，并且使用VLO推入操作移动到其锚点，同时维持与投影平面(其也以类似的方式四处移动)的几何关系。这样做的优势是，当遍历八叉树以定位SLT中心时，可以将多个SLT附接到VLO节点并共享简化的投影计算。定位SLT中心的VLO八叉树也包含表示一个统一数据集(全光八叉树)中的物质的节点。

当实现全光八叉树投影时，可以在单独的处理器中独立处理单独24个顶部立元。为了减少VLO存储器访问带宽，每个这样的处理器可以具有一组半空间生成器。这些生成器将用于本地(对于每个顶部立元处理器)构造要与VLO交叉的立元金字塔。因此，将消除对VLO存储器的不必要请求。

底部层级VLO节点的中心可用作SLT原点。或者，如果需要更高的精度，则可以使用针对几何计算而计算的投影校正来指定相对于节点中心的偏移。

在下文中，通过遍历VLO(具有或不具有偏移校正)来定位STL的原点，从而将SLT定位在全光八叉树中。针对VLO的根节点设置STL相对于附接到全域的中心的投影平面的投影信息，然后在每个向下推入到SLT原点位置的情况下更新投影信息。在图37中，SLT(未示出)的中心在点3702处，即VLO根节点的中心(仅示出第1层级处的VLO节点3701)。为了移动SLT，中心3702随着VLO节点的推入一起移动。在所示情况下，这是指向+x和+y方向的VLO子节点。因此，它在+x和+y方向上移动到第1层级节点中心3703(对于此顶部立元而言)。因此，原始射线3704(表示立元的任一边缘)在推入之后变为3705。该新射线的斜率保持与原始射线3704的斜率相同，但是与投影平面3706的交叉点移动。相对于投影平面3707的原点的原始交叉点3708(t(t

以y计的步长是通过考虑到新原点的步骤和射线的斜率来计算的。第1层级VLO节点的边缘为1，如3701的e

e'

e'

由于原点的y值移动了e'

t'

该计算可以许多方式执行。例如，不是每次都进行乘积运算，而是可以将斜率和VLO全域的边缘的乘积保存在移位寄存器中，并且对于每个VLO推入，可以使用右移位操作来将其除以二。这表明可以通过在VLO上进行推入操作、同时维持立元在投影平面上的投影来移动SLT的中心。

下一操作将移动投影平面，同时维持与SLT的几何关系。投影平面通常将附接到不同的VLO节点的中心，该节点通常将位于VLO的不同层级处。当投影平面所附接的节点被细分时，投影平面及其原点将在全域中移动。这在图38中示出。当发生到第1层级VLO节点3801的推入时，投影平面3802附接到VLO根节点的中心。投影平面3802移动到成为投影平面3803的新位置。投影平面原点从全域3804的中心移动到子节点的中心(点3805)。原始立元边缘射线交叉点3806(t(t

e'

e'

交叉点相对于新原点的y分量变为：

t'

e'

“跨度”是(在一个维度上)限定立元的极限的两条射线之间的投影平面中的线段。这在图39中针对托管立元3902的第1层级节点3901示出。它由三个点(SLT的原点3903、“顶部”边缘3904和“底部”边缘3905)限定。边缘由它们与投影平面3906交叉的位置限定，该投影平面的原点在点3907处。交叉部是上边缘的点t 3909和下边缘的点b 3910。

仅在底部边缘与顶部边缘之间限定从SLT原点发出立元。它不限定在原点的另一侧上。在处理期间，对于如图40所示的包含原点在4003处的立元4002的第1层级VLO节点4001，可以针对立元检测到这种情况。投影平面4004移动到SLT原点的另一侧，以变为不存在立元的4005。b

通过计算新的顶部和底部偏移量，可以使用立元推入操作将立元细分成四个子立元。如上所讨论，立元细分过程在图41中展示。图42示出第1层级VLO节点4201，其托管由起点4203、顶部点t 4204和底部点b 4205定义的立元。根据立元要推入的子节点(通常基于在推入过程中执行的几何计算)，新的子立元可以是上部子立元或下部子立元。上部子立元由原点4203、顶部点4204和底部点4206、最高点4204与最低点4205之间的中心限定。在所示情况下，下部子立元是推入的结果，由原点4203、原始底部点b 4205和新的顶部点t'4206定义。新的顶部点t值(t')的计算如下：

t'

新的底部边缘与原始边缘相同，并且具有相同的斜率。由t'定义的顶部边缘具有新的斜率lope_t'，其可以通过以下计算：

slope_t'＝(slope_t+slope_b)/2。

尽管特定层级处的所有立元都具有相同的面区域，但它们并不表示相同的立体角区域，因为原点相对于该面区域移动。可以通过移动一定层级处的每个立元的面上矩形的边缘来校正此问题。虽然这简化了照明计算，但几何计算变得更加复杂。通过优选的方法，使用了SLT“模板”。这是一个静态的、预先计算的“阴影”SLT，它与SLT同时遍历。对于光投影，它包含每个立元的立体区域的精确测量值，以用于照明传输计算。

立元表示进入或离开某个空间点(SLT中心)(通常为由该点表示的空间)的入射或出射照明。虽然全光八叉树可以许多方式用于光传输，但是优选的方法是首先以位于VLO的中心处的SLT的原点初始化几何变量。然后，当SLT移动到其在全域中的位置时，维持几何关系。然后，从SLT原点开始以从前到后(FTB)次序从根节点开始遍历VLO，以便沿从立元原点出发的方向前进。以这种方式，通常以离立元原点的距离的一般次序遇到一些包含物质的VLO节点，并且对这些节点进行相应的处理。通常，这可能需要执行多次，以说明不同方向组中的多组立元(顶部立元)。

当以与从SLT原点投影的立元相对应的FTB顺序遍历VLO时，然后检查遇到的第一相互作用(与光)的VLO物质节点，以确定所需的下一步。例如，可以通过以下方式确定将来自立元的照明传输到VLO节点：移除来自立元的部分或全部照明，并将它或其一部分附接到包含物质的VLO节点所附接的立元。这通常是附接到VLO节点的入射SLT。传输可以来自可能根据对光场进行采样的图像生成的属性。或者它可以来自附接到照明源的出射立元。入射照明可以与表面的光相互作用特性模型一起使用，以确定例如要附接到现有或新创建的立元的出射光。

如图43所示，从附接到VLO节点4301的出射立元到附接到VLO节点4302的入射立元进行了立元到立元传输。当出射立元4303的投影(其原点在4304处)相对于VLO节点4302具有适当的大小并且通常包围其中心时，开始传输。否则，将出射立元或包含入射SLT的VLO节点(或两者)细分，并且针对所得的子树重新检查情况。

如果要进行传输，则然后沿着入射立元树4305中的原点到原点片段4307以某个立元分辨率访问或生成对映立元。如果VLO节点太大，则可以根据需要将其细分以增大投影的相对大小。如果进入的立元太大，通常将其细分以减小投影的大小。

特定遍历顺序用于实现VLO节点访问的FTB排序。这在图44中针对VLO节点4401的遍历示出。原点在4403处并且边缘(顶部和底部)与四分之一圆(3D中的第八球体)区域4404交叉(在底部边缘极限4405与顶部边缘极限4406之间)的立元。边缘4407是该范围内的典型边缘。顺序0至3 4408将在VLO节点4401中生成FTB顺序。其他顺序用于其他范围。在3D中，存在八个子节点的等效遍历顺序。在VLO的情况下，遍历将递归地应用。遍历顺序排序不是唯一的，因为多个排序可以生成一个区域的FTB遍历。

当将立元细分时，在一些算法中，需要追踪包含被遇到的包含物质的VLO节点消耗(例如，吸收或反射)的光的立元。与八叉树图像生成一样，四叉树将用于标记“已使用”立元。这在图45中展示，其中原点在4503处的立元4502投影在VLO节点4501上。四叉树4504(仅所示边缘)用于追踪立元树中的部分或完全未激活或先前已使用的立元。

多个处理器可以同时在不同的立元上操作。例如，24个处理器可以各自计算不同顶部立元及其后代的投影。这可能会对容纳全光八叉树(尤其是VLO)的存储器提出大量带宽需求。通常可以针对每个处理器综合生成SLT中心树，并且可以将顶部立元及其后代划分呈单独的存储器片段，但是将从多个立元处理单元访问VLO存储器。

如上所述，可以针对每个单元使用一组半空间生成器来减少存储器带宽需求。如图46所示，在2D中，将针对限定立元的侧边的两个边缘(在3D中为四个平面)在本地(在每个处理器内)生成半空间八叉树。边缘4602是顶部立元边缘。该边缘下面的区域是半空间4603。边缘4604是限定上部半空间4605的底部边缘。在2D中，立元的空间是两个半空间4606的交叉部。在3D中，立元的体积是四个占据体积的半空间的交叉部。

然后，将本地立元形八叉树用作将与VLO交叉的掩模。如果本地生成的八叉树中的节点为空，则不需要访问存储器中的VLO八叉树。在图47中，这由在其子树中包含多个下部层级节点的上部层级VLO节点4701展示。节点A 4703与立元4702完全不相交，因此不需要进行访问。立元4702占据节点B 4704的部分空间。需要访问VLO存储器，但是其任何子节点(诸如0、2和3)都与立元不相交，因此不需要进行存储器访问。节点C 4705完全由立元包围，因此需要该节点及其后代节点以便进行处理。根据需要，需要从VLO存储器访问这些节点。通过以对应于8个第1层级八叉树节点的八个片段来交错VLO存储器以及以其他方式，可以减少存储器访问问题。

“前沿”在此被定义为距全光八叉树中的区域一定距离的表面，使得等距离或更大距离处的任何事物在该区域内的任何点处都不会表现出视差。因此，不管全光八叉树区域内的位置如何，来自特定方向的光都不会改变。对于来自前沿之外的光，可以使用整个全光八叉树的单个SLT。在操作中，对于指定点，针对该点累加入射SLT以免向外投影。当已确定所有此类照明(来自前沿内的所有照明)时，对于未找到此类照明的任何立元，都将使用来自前沿SLT的立元来确定其属性。例如，在全光八叉树之外但在前沿内的照明可以由例如全光八叉树的面上的SLT(不是单个SLT)表示。

在许多操作(诸如使用诸如BLIF的表面属性的计算)中，使SLT旋转可能很重要。这在图48中以2D展示，并且可以类似的方式扩展到3D。4801是包含立元4804的原始VLO节点。节点4802是旋转的VLO节点，其包含从其生成的4804的旋转版本即立元4805。两个SLT共享同一原点，即VLO中心点4803。该算法从原始立元和子立元生成新的旋转的立元和子立元。可以对所有原始立元进行此操作，或者，例如，可以使用全光掩模或如此处使用的简单“掩模”来阻止新SLT中一些立元的生成，通常因为它们出于某个原因是不需要的(例如，从表面点、进入不透明实体的方向、不需要的方向，诸如镜面的BLIF，其中某些方向对出射光的贡献很小或没有贡献)。掩膜也可以指定感兴趣的属性值(例如，忽略辐射值低于某个指定阈值的立元)。如图所示，新SLT周围立方体的面(2D中为边缘)变为投影平面(2D中为线)，诸如4806。新SLT中的跨度是原始SLT立元的投影。

图49示出点t(t

t'

t'

顶部点与底部点之间的以x计的距离为d

图50展示如何维持跨度信息。原始立元由顶部边缘5005和底部边缘(未示出)界定。从点t到t原始的以y计的距离是在开始时计算的，然后随着细分的继续维持不变。这是图中的d

计算涉及两个斜率，即原始立元的边缘和投影边缘(在3D中为平面)的斜率。在任一情况下，在这种情况下，对于以x计的步长(在这种情况下为d

如图所示，在这种情况下，可以通过首先针对步长d

当将该距离扩展到3D时，需要使用新维度中的斜率信息来计算z方向上步长的附加值，这是2D SLT旋转的直接扩展。

SLT是分层的，因为更高层级的节点表示比其后代更大的空间体积。父节点的SLT中心在此体积内，但通常不会与其任何子节点的中心重合。如果从例如图像生成SLT，则可以针对该图像生成四叉树。然后可以将其以多个层级的分辨率投影到节点中心处的SLT上。

在其他情况下，上部层级来源于下部层级。SLT归约是用于根据下部层级立元中所包含的信息生成上部层级立元的值的过程。这可能会生成平均值、最小值和最大值。另外，可以计算覆盖率的量度(例如，具有值的子立元中方向空间的百分比)，并且可以对其进行累加。在一些实现方式中，可以使用一个或多个“特征向量”。这些特征向量是立元的某个属性在某种意义上在空间上保持平衡的方向。

通常假定SLT在局部平面表面上或附近。如果已知，则可以整体上表示SLT的局部表面法向向量，并且可以将该法向向量用于改进归约过程中的值。

在某些情况下，尤其是在照明梯度较大的情况下，改进的归约过程是将下部层级立元投影到某个平面(例如，平行于穿过SLT空间的表面的已知平面)或表面上，将结果在表面上过滤(例如，对较大父立元的中心进行插值)，然后将新的值投影回到SLT上。可以基于较早的训练集使用机器学习(ML)来分析照明，以改进归约过程。

可以从光场样本(例如，图像)聚集表示包含与光相互作用的物质的体积区域的空间中的点的出射SLT。如果有足够的信息来确定多个方向的照明，则有可能估计(或“发现”)所表示材料的BLIF。如果可以估计入射SLT，则可以简化此过程。ML可用于BLIF发现。例如，可以堆叠(来自多个SLT的)包含呈2D阵列(两个角度)的SLT的立元照明值的“图像”，并且将该图像用于识别BLIF。

SLT插值是基于SLT的某个其他立元集中的值确定未知立元的值的过程。有很多种方法可以做到这一点。如果BLIF是已知的、可以估计或可以发现的，则可以将其用于智能地估计其他立元的未知立元值。

光源通常可以用来表示真实或合成照明。理想点光源通常可以由单个SLT表示，也许在所有方向上都具有均匀的照明。可以通过使用掩模SLT来表示封闭点光源或定向光源，以防止在遮挡方向上进行照明。可以使用“照明”的几何挤压来表示平行光源，以生成八叉树。挤压可以例如表示不均匀照明(例如，图像)的正交投影。

图51示出可能的全光八叉树投影处理器。该处理器实现了SLT到全光八叉树中的VLO节点上的投影。可以发生三种推入操作：推入中心(将SLT的中心推入到子节点)、推入VLO(将VLO节点推入到子节点)和推入立元(将父立元推入到子节点)。此处未明确包括弹出操作。假定在每次操作开始时将所有寄存器推入到堆栈中，然后将它们简单地弹出。替代地，仅将特定推入操作(而不是值)存储在堆栈中，并且通过反转推入计算撤消以执行弹出。

处理器用于将“顶部”立元朝向x＝1处的面投影。此单元在x-y平面中执行投影计算。重复单元将在y-z平面中计算计算结果。

为了简化操作，将首先执行所有SLT中心推入操作，以将SLT放置到其位置(同时维持投影几何形状)中。两个增量寄存器将被重新初始化，然后将执行VLO推入操作。然后执行SLT推入操作。例如，可以通过复制增量寄存器来同时执行这些操作。

上部寄存器5101将投影立元的上部平面的y位置维持在投影平面(在这种情况下平行于面1)上。下部寄存器5102维持下部平面的y位置。增量移位寄存器保存斜率值，即上部平面的DDelta_U 5103和下部平面的Delta_L 5104。它们具有向右的“lev”(用于层级)位，足以在推入到可能的最低层级之后执行弹出操作时维持精度。用x-y平面中相关联平面的斜率来使增量寄存器初始化。它包含针对为1的以x计的步长时y的变化。对于每个推入(SLT中心或VLO)，它向右移位1。因此，对于在x方向上到子节点的步长，它变为y的变化。

边缘移位寄存器维持VLO节点的边缘的距离。它们是在VLO遍历期间节点边缘的VLO_Edge 5105。SLT_Edge 5106在遍历期间用于VLO节点，以定位全光八叉树中的立元。两者在VLO中通常处于不同层级。边缘寄存器还具有向右的“lev”位以维持精度。其他要素是选择器(5107和5108)加上五个加法器(5110、5111、5112、5113和5114)。根据以下规则，选择器和加法器由信号A至D控制。结果是VLO细分信号5109。

SLT投影单元的操作可以通过许多方式来实施。例如，如果特定实现方式中的时钟速度足够低，则可以按串行配置复制处理器实例，以形成可以在单个时钟周期内执行多层级移动的推入操作的级联。

替代设计在图52中示出，使得可以同时执行VLO和SLT推入操作。添加了两个新的增量寄存器，V_Delta_U 5214(用于VLO增量，上部)和V_Delta_L5215(用于VLO增量)。现在，图51中的增量寄存器仅用于SLT推入操作。它们现在是S_Delta_U 5203和S_Delta_L 5204。

图56示出图51中的处理器的启动情况。顶部立元5602位于全域的原点5603(0,0)处。平行于面1的投影平面与同一点交叉，并且其原点位于同一点处。注意象限子编号5610和子立元编号5611。

寄存器的初始化如下：

上部＝下部＝0(上部边缘和下部边缘均在原点处与投影平面交叉。

Delta_U＝1(上部边缘斜率＝1)

Delta_L＝0(下部边缘斜率＝0)

VLO_edge＝SLT_edge＝1(均从第1层级节点的边缘距离开始)

投影单元的操作如下：

SLT中心推入

将SLT_edge和Delta_U右移一位

对于SLT子0或2：A是+；否则–

对于SLT子0或1：C是–；否则+

B是0

D是1

E是空载(Delta_U和Delta_L寄存器不改变)

VLO节点推入

将VLO_Edge和Delta_U右移一位

对于VLO子0或2：A是–；否则+

对于VLO子0或1：B是+；否则–

C是0

D是1

E是空载

SLT立元推入

新立元是上部：D是1；否则0

E是负载

可能期望将SLT的中心定位在除全光节点中心之外的其他位置。例如，这可用于将代表性点定位到某个基础结构的特定点，而不是空间中由节点表示的本地立方体体积的中心。或者它可能是点光源的特定位置。

这可以通过将SLT位置合并到投影处理器的初始化中来完成。由于上部斜率从1开始，并且下部斜率从0开始，因此简化了此过程。因此，初始的顶部投影平面的交叉点将在y处，将为立元中心的y值减去x值。底值将是立元中心的y值。

然后，投影计算将像以前一样进行。可以利用最终推入将偏移量的偏移值添加到SLT的节点中心，但这通常是不期望的，至少在SLT中心推入和VLO推入同时发生时不期望。跨度值用于选择下一个要访问的SVO子级，因此在VLO遍历期间需要正确的跨度。

三种类型的多个推入的寄存器值包含在图53和图54的Excel电子表格中。将第5行中的两个偏移值设置为0，以简化计算。所使用的Excel公式在图55中呈现(为了便于阅读，将行和列颠倒)。偏移值位于第5行中(x为F5，y为H5)。

为了清楚起见，电子表格值是呈具有几何图解的浮点格式。在实际处理器中，登记表可以使用仅整数操作来缩放整数。电子表格列如下：

A.迭代(推入操作的顺序数。)

B.SLT推入(SLT中心子节点正被推入。)

C.VLO推入(VLO子节点正被推入。)

D.立元推入(立元子节点正被推入。)

E.SLT向Lev(在推入之后新的SLT位置层级。)

F.VLO向Lev(在推入之后新的VLO节点层级。)

G.立元向Lev(在推入之后新的立元层级。)

H.SLT边缘(用于定位SLT中心的八叉树中的节点的大小。

I.SLT步长x(当定位SLT中心点时向子节点推入的以x计的当前步长。取决于子位点数目。)

J.SLT步长y(当定位SLT中心点时向子节点推入的以y计的当前步长。取决于子位点数目。幅度与SLT步长x相同，除了符号取决于正推入的子位点数目。)

K.SLTx(正用于定位SLT的当前节点中心的x位置。)

L.SLTy(正用于定位SLT的当前节点中心的y位置。)

M.VLO边缘(在VLO中在推入期间当前节点的长度。)

N.VLO步长x(用于移动到VLO子节点的以x计的当前步长。符号取决于子位点数目。)

O.VLO步长y(用于移动到VLO子节点的以y计的当前步长。在此实现方式中幅度与VLO步长x相同但符号取决于子节点数目。)

P.VLO x(VLO节点中心的以x计的位置。)

Q.VLO y(VLO节点中心的以y计的位置。)

R.TOP斜率(立元的顶部(上部)边缘的斜率。注：这是实际斜率，而不是当前x步长的值。)

S.BOT斜率(立元的底部(下部)边缘的斜率。注：这是实际斜率，而不是当前x步长的值。)

T.t_y(在投影平面上跨度的端点的顶部(上部)y值。)

U.b_y(在投影平面上跨度的端点的底部(下部)y值。)

V.comp_t_y(独立于与t_y的比较而计算的t_y的值。)

W.comp_b_y(独立于与b_y的比较而计算的b_y的值。)

X.注(关于迭代的注解。)

第一列中的初始化值(第一列中的“(启动)”)。这些值如上文所列出(并且示出在图56n中)。然后接着14个涉及SLT中心、VLO和SLT立元的推入操作的迭代。前七个迭代以几何方式示出在图56至图63。

前两个迭代将是SLT推入，紧接着是两个VLO推入并且然后是两个立元推入。这然后接着两个VLO推入(迭代7和8)、一个SLT推入(迭代9)以及最后一个VLO推入。

迭代#1的结果示出在图57中，为从VLO根节点至子节点3的SLT推入。在第1层级VLO节点5701中，立元5702从VLO的原点5706移动到第2层级的子节点3的中心即点5703。新立元原点的位置在(0.5，0.5)处的。投影平面5707保持在相同位置并且斜率保持不变(对于底部边缘5704为0并且对于顶部边缘5705为1)。

迭代#2示出在图58，为到子节点2的SLT推入。这类似于最后一次操作，除了它是到第2层级的子节点2，因此除了不同方向之外，步长是先前距离的一半。在节点5801中，5802移动至(0.25，0.75)处的点5803。底部边缘5804的斜率保持为0并且顶部边缘5805的斜率保持为1。投影平面5807保持在同一位置中。顶部边缘与投影平面的交叉部处低于底部交叉部(图表未示出)。立元因此实际上同时交叉投影平面并且投影是闲置的。

迭代#3是从根VLO节点至子节点3(第1层级)的VLO推入。这在图59中示出。在VLO节点5901中，立元5902并不移动。投影平面5907从VLO根节点的中心移动到第1层级的子节点3的中心即点5906。注意，投影平面的原点现在移动至此点，即子节点3的中心。5902的边缘与投影平面的交叉部由于投影平面的移动及其原点的改变而重新计算。

迭代#4示出在图60中。这是到子节点1的VLO推入。立元6002不会移动，但投影平面6007会移动并且因此底部边缘6004和顶部边缘6005的交叉部必须重新计算。投影平面在+x中移动，其新原点在6006处。边缘的斜率不会改变。

图61展示迭代#5，即到子节点1的立元推入。立元6102的原点不会改变，但其分成两个子立元，其中下部子立元将保留。底部边缘6104保持相同，但新顶部边缘6105移动，因此其与投影平面的交叉部是在先前顶部与底部交叉部之间的中间或者距投影平面原点0.75的距离。底部距离保持为0.5。底部斜率保持为0，而顶部斜率减小至平均斜率0.5。

迭代#6示出在图62中。这是到子节点2的立元推入。再次，立元6202被分成两个子立元，其中上部子立元保留。因此，顶部边缘保持相同，斜率相同。底部边缘远离投影平面的原点向上移动并且其斜率重设定为0和0.5的平均值或0.25。

迭代#7示出在图63中。该操作是到子节点0的VLO推入。投影平面在–x方向中移动并且其原点在–x和–y方向中移动。立元6302保持在相同位置并且边缘未改变，除了与投影平面的交叉点改变以适应该移动。

再次运行Excel电子表格模拟，其中SLT中心偏差设定为非零值(在第5行，对于单元F5中的x偏差值为0.125并且对于H5中的y为0.0625)。结果示出在图64和图65的电子表格中。

体积测量技术用于代表物质，包括对象、在场景内、VLO。它们也用于代表在使用SLT的场景(光场)中的光。如上文所述，高质量显示和其他用途所需的信息可使用场景重建引擎(SRE)从真实世界场景获得。这可与综合生成的对象(通过SPU形状转换模块3007生成)组合以形成复合场景。在一些示例性实施例中，该技术对于物质和光以及其在SPU 3001中的交互作用使用分层、多分辨率和空间分选的体积数据结构。这允许基于如例如通过每个用户的位置和观看方向确定的或对于几组用户统计学评估的位置、分辨率、可见度和其他特性来快速鉴定对于远程使用所需的场景的部分。在其他情况下，应用程序可基于其他考虑因素请求数据库的子集。通过仅通信需要的部分，使通道带宽要求最小化。体积模型的使用也促进在虚拟世界中的高级功能，诸如碰撞检测(例如，使用设定操作模块3003)和基于物理的模拟(例如，通过质量属性模块3019容易计算的质量属性)。

根据应用程序，可能期望将通过单个SRE或通过多个SRE生成的物质和光场模型组合成用于例如由一个或多个用户(例如，置于远程舞台的音乐家或舞蹈家)远程可视化并交互的复合场景模型。由于对发光和材料属性进行建模，可以应用来自一个场景的照明来置换另一个场景中的照明，确保观看者经历一致点燃的场景。光场操作模块3023可用于计算光照，而图像生成模块3009生成图像。

场景图或其他机构用于代表个别场景要素之间的空间关系。一个或多个SRE可生成真实世界模型，这些模型保存在全光场景数据库1A07中。另外，以其他格式(并非全光八叉树)表示的其他真实世界或综合空间模型保存在数据库中。这可几乎是可容易由形状转换模块3007转换成全光八叉树表示的任何表示。这包括多边形模型、参数模型、实体模型(例如，CSG(构造立体几何法)或边界表示法)等等。SPU 3001的功能是执行一次转换或者在模型改变或要求改变(例如，观看者移动靠近对象并需要更高分辨率转换)时执行多次转换。

除了光场和材料属性之外，SRE还可以发现场景中的多种额外特性。这可以用于例如识别场景中的视觉属性，这些属性可用于将先前采集或合成的模型并入场景中。例如，如果远程观看者目视移动太靠近对象，则与SRE从真实世界(例如，树)采集模型相比需要更高分辨率。替代性模型(例如，参数树皮)可平滑地“接通”以生成用于用户的更高分辨率视觉信息。

经常当场景图通过应用程序诸如响应于用户请求而修改时，3001中的SPU模块可用于转换并操纵模型以完成应用要求。这个和其他SPU空间操作可用于实施高级功能。这包括如通过设定操作模块3003计算的干扰和碰撞检测加上需要如通过SPU质量属性模块3019计算的质量属性诸如质量、重量和质心的属性。全光场景数据库中的模块因此被修改以反映如由用户和应用程序确定的实时场景改变。

两种类型的信息物质(VLO)和光(SLT)可以对于所选空间区域(在SLT情况下的方向空间)并以指定分辨率层级(用于SLT的角分辨率)进行访问和传输。另外，特性值通常保存在代表节点子树中的属性的树结构中的较低分辨率节点(树中的上部节点)中。这可以例如是八叉树节点的子树中的颜色的平均值或最小值/最大值或者立元树节点的子树中的一些代表性照明测量。

根据远程过程(例如，一个或多个用户)的需要，仅需要传输场景模型的必需子集。为了观看，这通常意指发送由模块3009当前正以高于其他区域的分辨率观看(或预期观看)的场景部分的高分辨率信息。对于邻近对象传输的分辨率信息高于目视距离远的对象的分辨率信息。追踪或预测的移动将用于预料将需要的场景部分。它们将以增加的优先级传输。3009中八叉树模型的高级图像生成方法可以在渲染图像时确定堵塞区域。这指示场景的区域不需要或可表示为较低保真度层级(以解释可能的未来展望)。此选择性传输能力是编解码器的固有部分。仅场景在不同分辨率下的部分从存储器访问并传输。在需要时传输对照信息以维持与远程用户同步。

当大量远程观看者同时操作时，可以汇总其观看参数以设定传输优先级。替代方案将是基于概率、可能基于经验的模型预期观看者偏好。由于整个场景的模型的版本一直是每个观看者在一些、可能有限的分辨率层级下可用的，不预期的观看将仍导致场景视图，但图像质量层级更低。

图像生成所需的信息维持在本地数据库中，该本地数据库通常为来源场景模型数据库的子集。场景的组成通过本地场景图控制，该场景图可以是来源的总体场景图的子集。因此，尤其对于大的“虚拟世界”，本地场景图可以进维持对象和光场信息以及用户可见或潜在可见的或可能对于应用程序重要的其他项目(例如，用户的经验)。

在场景服务器与客户端之间通信的信息由对照信息和呈全光八叉树形式的模型以及可能其他模型的部分(例如，呈其他格式的形状、BLIF功能)组成。全光八叉树包含呈VLO形式的物质和呈SLT形式的光场。每个八叉树是分层、多分辨率和空间分选的体积树结构。这允许它们由建模空间的指定区域访问并以可由空间区域(立元树的方向空间)指定的可变分辨率访问。在场景空间内每个用户的位置、观看方向和所需分辨率(通常基于在观看方向中距视点的距离)加上预料的未来改变可因此用于基于各种考虑因素(例如，视点可移动多远和多快、通信通道的带宽特性、场景不同区段的图像质量的相对重要性)确定需要传输的场景的子集和每个子集的优先级。

根据可在远程位点专用的计算能力，与通信通道的服务器侧相关联的功能可以在远程位点实施。这允许例如仅物质模型(VLO)传输到具有在此重建的光场信息(SLT)的远程位点，而不是也使其在通道上传输。当然，潜在通信效率将取决于态势的详情。将固体材料的简单模型传输到远程位点随后在本地计算光场和显示，可以比完全光场信息的传输更有效。这对于场景中的静态对象可能尤其如此。在另一方面，改变形状或具有复杂移动的对象可受益于按照要求仅传输光场SLT。

在全光八叉树中，SLT是在场景内的空间的一些位置处(或者在一些情况下，超过该场景)的5D分层表示。五维是中心的所有立元都符合的三个位置分量(x、y和z)加上定义立元的两个角度。立元树可以定位在VLO体元的中心处或体元内指定的一些位置处。VLO节点因此包含如通过属性限定的物质并且可任选地还包含立元树。在一些实施例中，包含基本上不透光(透射)介质并邻近场景边界(空体元)的空间内体元可以被称为“窗状”体元。

情况可能是，立元的集合在场景内的多个点(在具有相同反射特性的表面上的邻近点)处可为类似的。在此类情况下，具有不同中心的立元的集合可独立于中心位置来表示。如果对于多个中心点而言是相同的，则它们可以参考多个中心位置。如果差异足够小，则多个集合可由与一个模型立元或模型立元集合的个别偏差集合表示。或者它们可通过将系数应用于预先计算的基础函数集合(例如，由使用主成分分析得到的代表性数据集生成的立元数据集)来生成。另外，其他转换可用于将单个立元模型改变成特定集合，诸如通过围绕中心旋转。一些类型的SLT，诸如点光源可以通过将额外位置给予模型来重复(不需要插值或外推)。

场景编解码器在具有数据源和数据接收器的数据流模式中操作。通常，这采用请求/响应对的形式。请求可以定向至本地编解码器，其中响应被生成(例如，电流状态)或传输到远程编解码器以在此以返回的响应起作用，从而提供请求作用的结果。

请求和响应通过场景编解码器的应用程序接口(API)通信。基础编解码器API6601的核心功能汇总于图66中。编解码器通过操作参数模块6603来初始化。此功能可用于指定或读取操作模式，从而控制编解码器的参数和状态。在已建立与另一场景编解码器的链接之后，如果给定特定权限，此功能也可用于控制并查询远程编解码器。

编解码器API建立链接模块6605，当触发时，试图建立与指定的远程场景编解码器的通信链接。这通常启动“信号交换”顺序以建立通信操作参数(协议、证书、预期网络带宽等)。如果成功，则两个编解码器报告至它们为通信操作准备的呼叫例程。

下一个步骤是建立场景会话。这通过API打开场景模块6607来设定。这涉及建立与远程端上的场景数据库的链接以访问或更新远程场景数据库并且还建立与通常在本地端上的场景数据库的链接。例如，为了由远程场景数据库建立本地子场景数据库或者与远程场景数据库同时更新本地场景数据库。

一旦建立与一个或多个场景的连接，则可以使用两个代码API模块来访问并改变场景数据库。远程场景访问模块6609用于请求关于远程场景及其不涉及子场景移动穿过通信通道的改变的信息。使用本地场景访问模块6611执行待在本地场景数据库上进行的操作。使用查询处理器模块6613进行涉及子场景移动的场景数据库查询。通过会话记录模块6615记录编解码器所采取的所有动作。

查询处理器模块6613的主要功能是从远程场景数据库传输子场景或请求子场景并入它(或从它移除)。这可以涉及例如关于全光八叉树节点的状态的问题、用于计算质量属性的请求等等。这通常涉及子场景提取以及全光八叉树的压缩、系列化和可能加密的子树和相关信息的传输。待提取的子场景通常被定义为以一些场景图形式指定的几何形状、八叉树和其他几何实体的集合，其可产生空间的区域，即体积空间或方向空间或两者的区域。另外，指定体积或方向空间的各个区域中所需的分辨率(例如，在渲染情况下从视点开始减小)。也将指定信息的类型以不传输额外信息。在一些情况下，子场景提取可用于进行一些形式的空间查询。例如，对区域的子场景提取但仅至第0层级的请求将返回单一节点，如果发现该节点是无效的，则指示在该区域中没有物质。这也可以延伸到搜索全光场景中的特定特性。

查询处理器模块6613的子功能示出在图67中。这由状态和属性查询模块6703组成。其用于获得关于全光场景诸如进行写入它中的能力或存在于其中的属性或在可以定义新属性的情况等等的信息。子场景掩模对照模块接受一些形式的子场景提取请求并且构建完成该请求的掩模计划。这通常是进化掩模的集合，其将递增地发送子场景至请求系统，如通过计划子场景掩模模块6705所计划的。

子场景掩模生成器6707构建全光八叉树掩模，其将用于从场景数据库选择节点以传输回到请求系统。其连续建立用于提取的下一个掩模。子场景提取器模块6709进行场景全光八叉树的遍历以选择如通过掩模所确定的节点。然后使它们系列化并进一步处理并且然后输入到传输到请求系统的数据包流中。子场景插入器模块6711由请求系统使用以使用传输的全光节点请求流修改场景模型的本地子树。

编解码器可进行子场景提取或子场景插入或两者。如果仅实施一种操作，则可消除仅另一种操作所需的模块和功能。因此，仅编码器单元将需要子场景提取器6709，但不需要子场景插入器6711。仅解码器单元将需要子场景插入器器模块6711，但不需要子场景提取器模块6709。

如上文所讨论的，从全光场景模型提取子场景使得能够将仅场景数据库的部分有效传输到客户端，如对于立即或近期可视化或对于其他用途所需的。在一些实施例中，全光八叉树用于场景数据库。此类数据结构的特性促进子场景的有效提取。

多种类型的信息可包含在全光八叉树中，作为单独的VLO或作为包含在全光八叉树、辅助数据结构、单独数据库或一些其他方式中的八叉树或立元树节点中或附接到这些节点的属性。初始子场景提取请求指定客户端将需要的信息类型。这可以正服务的应用程序所特有的多种方式进行。

以下是一种示例性用途，其中客户端正请求子场景提取以由显示设备诸如VR或AR耳机远程观看。大全光八叉树维持在服务器侧上。在客户端上仅需要子集以生成图像。全光八叉树掩模将在此用作一个实例。许多其他方法可用于完成此实例。掩模为全光八叉树形式，其用于使用集合操作选择全光八叉树中的节点。例如，大八叉树的子部分可使用更小八叉树掩模和交叉操作来选择。两个八叉树共享精确相同全域和取向。两个树同时从根节点遍历。大八叉树中也不会作为占据的节点存在的任何节点在存储器中简单略过并忽略。它们仅仅不会在遍历中出现。它们有效地消失。以这种方式，节点的子集可通过遍历来选择并使其系列化以用于传输。然后在接收侧上重新创建该子集并将其应用于全光八叉树。此概念容易延伸至立元树。

在下文中，掩模概念使用递增掩模来延伸。因此，开始掩模可增加或减少或以其他方式修改以选择额外节点，以传输到接收侧。掩模出于此目的可以多种方式修改。膨胀腐蚀的形态学操作可使用SPU形态学操作模块3015来应用。几何形状可以添加或使用以移除掩模总线(mask buy)的部分，使用SPU形状转换模块3007和SPU集合操作模块3003来转换这些几何形状。通常，新掩模将从旧掩模中减去，以生成递增掩模。这将用于遍历大场景模型，以定位新节点，以使其系列化并传输以在接收端添加或以其他方式处理。根据情况，可进行相反提取，从旧掩模减去新掩模，以确定待移除的节点集合。这可系列化并直接传输以在接收侧上进行移除(不涉及子场景提取)。在接收侧可使用类似方法来移除出于一些原因不再需要的节点(例如，观看者移动，并且高分辨率信息在一些区域中不再需要)，从而通知服务器侧当前掩模的改变。

全光投影引擎(PPE)的目的是在全光场景模型中从一个位置有效投影光至另一个位置，从而导致光传输。这可以是从例如由出射点光场(PLF)表示的光源到附接到介元的入射PLF。或者其可以是导致出射光添加到出射PLF的入射PLF。

全光投影利用分层、多分辨率树结构，其在空间上分选以有效进行投影过程。使用三个此类树结构：(1)VLO或体积八叉树，其保持介元(虽然这被视为单一八叉树，但其可为联合在一起的多个八叉树)，SOO或立元树原点八叉树(这是全光八叉树中包含立元树的原点的八叉树)，以及(3)SLT，全光八叉树中一些数目的立元树(原点位置是在SOO处)。

全光投影引擎在每个SLT的原点处开始的从前到后顺序中将SLT中的立元投影到VLO中的节点上。当立元交叉介元节点时，将投影的大小与介质体元的大小相比较。该分析是基于多种因素，诸如当前需要的空间或角度分辨率、介元的相对大小和在其上的立元投影、在树结构中在较低层级下较高分辨率信息的存在以及其他信息。需要时，介元或立元或两者可细分成由其子代表示的区域。然后在较高分辨率下继续同一种分析。

当完成细分过程时，可发生光传输。立元树中的立元可例如导致形成或修改附接到介元的立元树中的一个或多个立元。在典型应用程序中，入射辐元信息可以在附接到介元的入射PLF中累加。当入射SLT填入足够时，可以应用介元的BLIF，从而产生介元的出射PLF。

投影过程通过维持将立元投影到附接到遍历中拜访的每个VLO节点的投影平面上来操作。投影平面垂直于轴，这根据正投影的立元所属于的顶部立元。

该过程通过在全域中心处开始VLO和SOO树结构来开始。因此，SOO中的位置在全域中心处开始。它将向下遍历至待投影的第一SLT的位置，如通过所应用的任何掩模和任何指定的遍历顺序来确定。投影平面作为穿过全域原点、根据第一立元垂直于适当轴的平面开始。在操作中，可以限定并追踪所有三个轴，以解释所有顶部立元方向。

全光投影引擎的主要功能是在VLO遍历时连续维持斜金字塔投影的投影，该投影是在附接到介元的投影平面上的立元投影。在三个树结构遍历以通常将所有SLT中的所有立元投影到场景中时，这通过在开始时使几何形状初始化并且然后继续维持初始化来完成。这可创建额外SLT，这些SLT在此过程期间或随后创建时可进一步遍历。

因此，该方法的典型流程是使这些树结构初始化，然后遍历TOO以使用一系列TOO推入操作将第一SLT置于其原点，从而维持每个步骤的投影几何形状。接着，遍历VLO以封闭第一SLT的原点。接着，以从前到后顺序遍历VLO，以在顶部立元方向中从SLT原点增加距离的一般次序拜访节点。在VLO的每个推入时，检查连接至节点的投影平面上的投影，以查看立元是否继续与VLO节点交叉。如果不交叉，则遍历中忽略所有子树。

如果碰到介元VLO节点，则分析确定要采取的下一个动作，如上文所概述，通常涉及拜访VLO和/或SLT的子树。当完成时，这些树备份到下一个立元可以相同方式投影的位置。当第一或后续SLT的最后立元已得到处理时，将树结构呈现(POPed)至可以开始下一个SLT的处理的点。继续此过程，直到由于上代立元的处理，所有SLT中的所有立元已被处理或非必要地使其得到处理。

总体程序示出在图68A的去逛投影引擎流程图中。这是许多可能的程序的取样程序。该过程以在操作68A02中使投影机构初始化开始。如上文所呈现，VLO遍历在其根节点开始。目标投影平面因此附接到全域中心(实际上可追踪三个)。也使SSO初始化至其根节点。初始SLT点因此在全域原点处开始并且将被推入到SLT的原点。待拜访的初始立元是顶部立元0。

在操作68A04中，使用推入操作使SOO树结构遍历至全光八叉树全域中的下一个SLT的原点。在第一种用途中，这将是从全域的原点开始。在其他时候，它将是从停止最后一个操作的位置开始。对于每个操作，维持将当前顶部立元投影到附接到当前VLO投影平面(第一次附接到全域中心)的投影平面以达到下一个SLT原点。如果在SOO中不存在额外SLT(通常通过试图从根节点呈现来检测)，则决策操作68A06终止该操作并使控制返回至请求例程。

另外，操作68A08遍历当前SLT的立元至第一非空节点(非空体元)，其为表示辐元的立元。而且，维持立元与投影平面之间的投影几何形状。如果未保留具有辐元的立元，则通过决策操作68A10使控制转回到操作68A04以查找并遍历下一个SLT。

如果需要投影立元，则操作68A12遍历VLO树至封闭当前SLT原点的节点。基本上，如果找到具有投影平面的第一VLO节点，其中立元投影与VLO节点交叉，该VLO节点与其投影平面交叉。如果没有发现此类VLO节点，则通过决策操作68A14使控制返回至操作68A08，以进行至待处理的下一个立元。如果立元的投影不会与节点交叉，则通过决策操作68A16使控制转回到操作68A12以进行至待研究的下一个VLO节点。

另外，使控制转到操作68A18，其中分析当前投影平面上的当前立元的投影。如果满足此操作的当前规则，则通过决策操作68A20使控制传输至操作68A22，其中发生辐亮度传输或重新取样。这通常意味着已达到足够分辨率层级，这可能是基于立元的辐亮度的变化，并且投影的大小在一定意义上相当于VLO节点的大小。在一些情况下，传输一些或所有辐亮度至附接到该节点的SLT中的适当立元(在需要时创建)。在其他情况下，可在节点中以一些其他方式采用辐亮度。

如果分析确定立元或VLO节点需要更高分辨率层级，则操作68A24确定VLO节点是否需要细分。如果需要，则使控制转到操作68A26，以进行推入。关于情况的信息通常将被推入到操作堆叠上，以便随后拜访所有同级节点。如果不需要，则使控制转到决策68A28，其中处理对细分当前立元的需要。如果需要，则使控制转到操作68A30，其中执行立元推入。另外，到当前VLO节点上的立元投影不需要额外处理并且使控制转回到操作68A12，以遍历至下一个VLO节点进行检查和可能辐亮度传输。

来自全光八叉树的子场景提取的综合流程示出于图68B的流程图中。该过程在接收到子场景请求时开始。初始步骤68B02使无效子场景掩模初始化。这通常是单节点全光八叉树和相关参数。然后在步骤68B04中分析该请求。对于图像生成情况，这可包括观看者在场景中的3D位置和观看方向。额外信息将是视野、屏幕分辨率和其它观看参数和相关参数。

对于观看，这然后将用于限定第一图像的初始视锥体。这可表示为几何形状并且使用SPU形状转换模块3007转换成八叉树。在其他情况下，可使用每个像素生成立元树，从而产生立元。距视点的距离作为掩模数据结构的一部分并入或者以一些其他方式计算(例如，在子场景提取期间邻近备用设备计算的距离)。这将在子场景提取期间使用以确定待选择用于传输的场景模型(体积或方向空间)的分辨率。

由模块68B04进行的次分析，构建用于一系列子场景掩模的计划。总体策略是以将在接收端生成初始子场景模型的掩模开始，这将非常快速产生观看者的可用图像。这可例如使用于传输的更小初始数据集的分辨率请求减小。下面的步骤通常添加逐渐更高的分辨率详情。并且来自观看客户端的请求的信息可用于预料观看需要的未来改变。这可包括例如观看者的定向和旋转移动的方向和速度。这将用于扩展掩模以解释未来预期的需要。这些扩展将并入到未来掩模改变的计划步骤中。

此计划接着转到操作68B06，其中如通过该计划中的当前步骤限定的子场景掩模与完整全光场景模型交叉。然后将由全光八叉树的特定遍历得到节点收集到系列格式中以用于传输到请求程序。可以进行节点压缩、加密和其他处理操作，之后转到进行传输。

下一个流程操作由接受下一个请求的68B08决策进行。如果它是不能通过修改当前子场景掩模来调节并计划的新子场景，则废除当前掩模计划并在操作68B02中使新子场景掩模初始化。在另一方面，如果请求是已经由当前计划预期的子场景，如通过决策操作68B10所确定的，在操作68B12中执行该计划的下一个步骤。修改子场景掩模并且使控制转回到操作68B06，以实施下一个子场景提取。如果由决策68B10碰到子场景掩模结束，如果存在新子场景提取请求，如通过决策操作68B14确定的，则下一个请求用于启动操作68B02中的新子场景掩模。如果没有搁置新请求，则子场景提取操作68B00置于等待状态，直到新请求达成。

图69示出过程6900的流程图，在一个实施例中，从场景数据库中提取子场景(模型)以由场景中的多个视点生成图像。第一步骤操作6901是建立与包含待从中提取子场景的完整场景模型的数据库的连接。在操作6903时，使待输出的新子场景初始化以使全光场缺乏基元。换言之，在此时在子场景中不存在物质场也不存在光场。在操作6905时，基于图像生成参数确定“查询立元”集合，包括6-DOF位姿、固有参数和在每个视点处虚拟相机的图像大小。查询立元是在全场景的SLT中以一些层级定义的立元，其将用于在空间上查询(探测)位于查询立元的立体角体积内的全光基元的场景。查询立元集合通常是每个视点的立元集合联集。每个视点的立元集合通常覆盖FOV(相机的视锥体)，使得每个图像像素被包括在至少一个查询立元中。查询立元可适应性地设定大小以匹配位于场景内的不同距离处的基元的大小。查询立元集合也可以刻意制成为覆盖比FOV的紧密联集稍微更多或甚至多得多的5D全光空间。此类非最小全光覆盖的一种示例性原因是，过程6900可预料由客户端用于生成图像的虚拟相机的6-DOF路径。

在操作6907中，通过使用过程7000将每个查询立元投影到全场景中来将全光场中的基元累加到新子场景中，在光场被解析至由图像生成参数指定的目标精度时，通常导致一系列递归的投影。目标精度可包括辐射测量、频谱和极化的目标精度的表示。下文参考图70给出过程7000的描述。

在操作6909中，过程6900确定保留在子场景中的累加的基元的子集。下文在操作6915的描述中给出了关于此确定的详情。在一种简单但实用的示例性情况下，如果基元至少部分落入在子场景请求的图像生成参数中指定的一个相机FOV内，则保留该基元。在操作6911中，子场景的外场景边界被限定为封闭在至少一个FOV中部分或完全包含的至少那些累加的基元。在操作6913中，将目标辐元投影到限定的外场景边界上。此投影通常可从边界内部和外部的场景区域发生。边界光场通常被实现为在与边界相邻的边界介元处的窗状光场。

在操作6915中，过程6900进一步简化对于当前使用情况和QoS阈值适当的子场景。当使子场景数据大小最小化为重要的时，子场景简化的一个显著实例为完全或部分移除由BLIF交互作用或从其它介元传递(投影)得到的介元的辐元。也就是说，通过移除并非窗状或发射性光场的一部分的辐元，子场景采用更“标准”形式，该形式通常具有比非标准形式更小的数据大小，尤其是当使用压缩的BLIF表示时。在当前描述的上下文中，场景模型的全光场的标准表示(“标准形式”)是在一定实际程度上根据使用情况包含少量保存的在光场的非窗状和非发射性部分中的光场信息的表示。这通过保存物质场(包括介元BLIF)和窗状和发射性光场辐元的足够准确的表示来实现。然后在需要时，可以例如通过如下文参考图70和71描述的那些过程来计算总准稳态光场的其他部分。

一定简化(压缩)程度可通过使BLIF表示适应子场景提取客户端的需要来实现。在客户端旨在生成子场景图像的当前示例性情况下，例如汽车表面的光滑BLIF可导致从一个视点极其复杂地反射树，而从另一个视点仅反射一块均匀的天空。如果在操作6905中在图像生成参数中仅包括第二视点，那么在其镜面瓣中具有更低精度的更紧密BLIF表示可在子场景模型中满足。

应注意，在许多使用情况下，子场景数据稀疏可能是比使提取的子场景的体积程度最小化更重要的目标。根据操作6905中指定的视点，子场景的物质场可主要由空间对象和面向视点联集的表面“外壳”组成。除了BLIF压缩，可使非全光基元的其他场景模型实体压缩、适应性重新取样、重新参数化等等，以便使子场景模型的数据大小最小化。通常预期，提取的子场景的光场和BLIF数据将具有类似于其物质场的稀疏性。

存在与最小子场景数据大小的目标相反的其他潜在目标。例如，在服务器至客户端网络流通量较高但客户端计算能力有限的情况下，使图像生成时间最小化可为期望的。在3D游戏或虚拟旅游中，客户端可能需要较少标准子场景，这些标准子场景反而出于以有限计算成本维持高显示帧率的目的使更多光场信息“烘焙到”其中。在与下文描述的图70和图71相关的另一个实例中，仅间接有助于查询立元的基元被包括在输出子场景中。间接反射到请求的FOV中的强光源可出于从预料之外的视点在图像中如实地再现其作用的目的而作为具有发射性光场的实际介元包括在内。在简化之后，在操作6917中将提取的子场景输出到所需场景数据库中，从而结束过程6900。注意，在其他实施例中，过程6900中示出的操作次序可以是不同的。

图70示出过程7000的流程图，在一个实施例中，累加(一个或多个)全光基元，这些基元使光直接或间接有助于投影到场景的全光场中的指定查询立元。在此上下文中，“累加”意指在子场景中通过值、参考、处理或其他合适手段保存累加的基元。在操作7001中，使用上文参考图21-65所述的力学，将查询立元投影到全光场中。在操作7003中，过程7000确定使光直接有助于查询立元的第一介元，其中“第一”的含义通过取决于使用情况的场景基元的优先排序来确定。典型示例性排序给予位于查询立元原点更近处(当投影被认为从立元原点向外进行时更早碰到的那些)的介元更高优先级。其他优先级排序是可能的，例如其中具有某些应用程序特定的属性(可能在目标频谱带中产生光的那些)的介元的优先级高于其他介元的排序。在多个介元具有等同的优先级(连结)的情况下，如果实施例缺乏并行处理连结的介元的足够并行计算能力，可采用一些打破连结的标准。

在操作7005中，过程7000使用过程7100来累加当前介元及其有助于查询立元的辐元。在操作7007中，过程7000检查当前介元是否成角度地朝向整个查询立元。如果是，则过程7000结束。如果否，则过程7000在操作7009中将查询立元细分成由介元朝向的子立元和不由介元朝向的子立元。在一个或多个SLT层级下细分成子立元在达到一些停止标准时停止。典型停止标准包括实现目标光场精度和时间耗尽、计算或数据大小预算。在操作7011中，不由介元朝向的查询子立元送回操作7001，从而有效调用过程7000的下一个迭代(尾递归)。

图71示出过程7100的流程图，在一个实施例中，累加单个介元及其使光有助于查询立元的辐元，其中“累加”具有上文参考过程7000给出的含义。在操作7101中，累加介元本身。在操作7103中，过程7100确定哪个介元的输出辐元有助于查询立元。这通常由包含立元的辐元是否与查询立元全光重叠来决定，这意味着查询立元和辐元的立元各自包含另一者的原点。在操作7105中，过程7100检查有贡献的输出辐元是否已经以由调用7100的呼叫过程(例如，过程7000，其在此实例中进而从过程6900获得其目标精度要求)指定的精度保存在介元的光场中。如果操作7105产生肯定的回答，那么过程7100进行来在操作7115中累加那些辐元。如果操作7105产生否定的回答，那么过程7100进行来在操作7107中确定所要求的输入辐元集合。此确定受到介元的BLIF的严重影响。具有窄镜面瓣的BLIF例如指示在入射镜面瓣的方向中需要入射辐元的更高精度/分辨率。较宽瓣指示所要求的入射辐元精度的更等方性分布。

在当前描述的上下文中，“输出”辐元是针对下游查询立元的那些，而“输入”辐元是针对上游的那些。在介元的情况下，在其BLIF映射的相对侧上是输入和输出辐元。在查询立元到达不透明面元边界空气处的示例性情况下，输出辐元将从面元出射，而输入辐元将入射在面元上。在查询立元起源于透射介元内的示例性情况(例如，从玻璃块内生成图像)下，输出辐元将入射在介元上，而输入辐元将从介元出射。

在操作7109中，过程7100检查所要求的输入辐元是否已经保存在介元的光场内(以要求的精度)。如果是，则在操作7113中通过将介元的BLIF应用于输入辐元来计算每个有贡献的输出辐元。如果否，则过程7100调用过程7000(通常递归地)以在操作7009中将每个要求的输入辐元的查询立元投影到场景中。一旦控制从潜在深入递归的呼叫返回至7000，则流程进行到如7109的肯定分支中的操作7113。在操作7113中通过应用介元的BLIF来计算有贡献的输出辐元，然后过程7100如在7105的肯定分支中的操作7115中累加输出辐元。过程7100在7115中累加之后结束。应注意，在一些示例性实施例中，操作7113可调用场景解析器(重建)过程在需要时评估或改善介元的BLIF。这不在此进一步详细描述。

在适当实施例中，过程7000和7100的许多情况(调用)可并行进行，例如包括具有大量离散逻辑核心的FPGA计算架构。无论并行程度如何，递归将倾向于在过程7000中投影连续查询立元时变得更窄。存在此倾向，因为每个查询立元投影在操作7113和7115中导致入射和响应性辐元的计算和保存(潜在地实施为缓存)。在由于后续查询立元的过程7100的调用中，因此将更经常遵循7105和7109的肯定分支，从而产生更窄递归。在过程6900的上下文中，递归立元投影链(堆叠)的此从深到浅顺序可被认为是子场景的全光场中准稳态光场的相当快速的计算。而且，在一些实施例中，在上游和下游方向中可小心进行子场景光场信息的此填充。例如，可来自已知(或发现的)强光源的光可向下游传递至场景区域中以经历严重立元查询活动。这可在到达讨论的区域的上游方向查询立元之前发生，从而在其达到时产生更窄的递归深度。还应注意，可以延期方式执行过程7000和7100中的各种操作，例如当硬件加速资源可用时置于列表中用于后续处理。

关于上文参考图69描述的全光场表示的标准形式，当场景模型缺乏实现所需标准程度所需要的足够准确的物质场和BLIF信息时，使用场景编解码器1A01的系统通常可条用场景解析器1A05，例如其指定目标为解析物质场至高精度，以便提供所需要的物质场信息。在一些示例性实施例中，使用场景编解码器1A01的系统，尤其在充当服务器时可连续运行解析器1A05，使得当供应新光场数据(例如，使用相机从客户端系统获得的新图像)时，光场信息立即传播到物质场表示中，服务器场景数据库的适当全光场中。

在一个实施例中，关于子场景插入操作，子场景插入模块6711在场景表示的全光八叉树层级下处理子场景插入(通过修改进入子场景所插入的全光八叉树的本地子树)。在场景模型1001和场景数据库1101表示层级中，子场景插入(包括递增子场景插入)也可涉及包括全光场合并、场景图合并、特征至基元映射(包括片段和特征的目标子类型)的更改以及BLIF库合并的操作。在一些示例性使用情况下，全光场的合并可使用过程7000和7100触发在合并的全光场的目标区域中的准稳态光场的重新计算。

某些实施例的另一个新颖方面在本文中为“分析入口”。这是提供引起全光场景模型的渲染的表示详情和方法的目视显示的机构。此入口也可用于添加、移除、改变或编辑全光场景和渲染的要素和参数。入口可以是任何形状。例如，矩形2D窗口可通过作图显示在“入口”后面的每个事物的详情。它也可以是3D中限制正检查的体积空间的区域。这可以与2D窗口组合以增强可视性和理解。此类入口可以按需要交互地修改(例如，展开、旋转)。另外，观看者可相对于入口移动。观看者可以例如“飞”过入口并且然后四处走动并观看入口区域内的分析场景。分析入口也可以是智能的，它们可以自动生成以突显触发其使用的一些情况或事件的发生。多个入口可以此方式形成并且可能目视地或以一些其他方式连接，以提供增强的理解。

分析入口展示在图72的图像、图8的厨房中。其显示具有小矩形区域7202的厨房。图73示出厨房的放大图像。可以更清楚地看到该矩形以封闭位于柜台上靠近炉具的金属锅的底部部分。在此图像内是分析入口7304的视图。这是个别基元要素极其放大地显示的3D矩形区域。物质场和光场的表示及其产生图像的交互作用是复杂的且难以直接从图像本身分析并理解。通过指定场景要素和查看特性(例如，比例因子)的类型以及如何渲染要素(例如，线框对比阴影)，可以根据观看者的即时需要定制所显示的信息。

区域7302内的分析入口7304示出在图74中。分析入口由示出3D矩形区域与锅表面7404和柜台表面7405的交叉部的黑色边缘指示。可以看到放大的个别体元，诸如表示锅的体元7406和表示大理石柜台的体元7408。在这种情况下，其示出为线框立方体。示出体元中包含的面元，诸如表示柜台的部分的面元7410。还示出一些面元上的代表性点，作为小白色球，其在该表面上的该点处在本地法向量方向上延伸。点7412为一个实例。

使用分析入口可有助于理解在现实场景渲染中产生目视特性或异常的表示和机构。但是它们也支持超过查看交互以得到图像的物质场和光场要素的大量应用。这可包括增强对所涉及的动力学场景和物理的理解以及修改控制参数的结果。这将延伸到研究和教育学使用以及此外的使用。

图75、图76和图77示出由一个示例性实施例产生的经验数据，以便证明一些实施例在表示并重建高度非朗伯表面的物质场和光场方面的效用。在图75和图76的情况下，该实施例重建黑色表面和白色表面，两者均包含浅人工凹陷。重建的3D表面概况有利地与由最先进的光学3D数字转换器进行的参考重建相比较。在图77的情况下，该实施例重建包含天然冰雹凹陷的几种汽车车体面板。重建结果通常与凹陷位置和大小一致，如通过训练的人检查员使用专业的检查设备来评定。这些实证结果证明在高度非朗伯的且缺乏紧密定位的外观特征的表面区域上的有用的准确操作，如在使用常规摄影测量法重建此区域所要求的。可使用本发明方法表示并重建的场景的其他特性包括表面凹度、高度自遮挡、紧密相邻的多种介质类型、金属介质、透射介质(包括玻璃)、投射阴影、光源的明亮反射、移动对象以及包含异质介质集合的整个环境。

参考图75，将4个浅凹陷人为引入到铝测试面板的区域7501中。随后将该区域涂黑。小点注释7502示出一个凹陷的中心位置。为了产生用于评价本发明方法的可靠参考重建，将防眩光喷雾粉应用于未涂色面板，然后通过计量级光学3D数字转换器GOM ATOS三重扫描III扫描该面板。

在完成参考扫描后，移除防眩光粉，并且应用黑色喷雾涂料的3个薄膜。完成此操作以便由该实施例证明具有低弥散反射率(例如，<1％)的表面的重建。将涂黑面板安装在三脚架上并在距面板中心大约0.5米的平均距离处从极化相机(例如，PX 3200-R)的12个向内视点获得图像。除了向内视点之外，还记录周围环境的86个额外向外图像。完成此操作以便取样并重建在凹陷区域处入射的光场。7511是向内(顶部2)图像和向外(底部2)图像的子集。使用本发明方法，在凹陷区域内的表面位置例如7502处重建半球形入射光场。重建的光场(入射和出射)的定量特性包括辐射测量功率、偏振状态和入射光半球内每个辐元的频谱信息。在该示例性实施例中，使用面板表面处的BLIF，以便发现凹陷区域的3D形状概况。

在一个示例性实施例中，在组合的C++和

参考图75，3D表面曲线图7521是通过本发明的示例性实施例产生的凹陷区域重建与通过最先进的光学3D数字转换器产生的重建的比较。通过从其凹陷图减去每个重建的平均凹陷值来进行简单的垂直对齐。两个凹陷图之间的RMS偏差为约21微米。2D曲线图7531是穿过4个重建凹陷之一的凹陷值的横截面。两个凹陷横截面之间的RMS偏差为约8微米。因此，在此示例性实施例中，发现本发明方法产生大约等同于当代计量级光学3D数字转换器的3D表面概况精度。

参考图76，在黑色凹陷区域上进行重建工作之后，将白色涂料的3个薄层应用于凹陷区域7601。完成此操作以便由本发明方法证明与涂黑的情况相比在具有高得多的弥散反射率(例如>20％)的表面上的重建。当在场景重建方法中使用极化特性时，白色表面的情况尤其显著，因为白色表面倾向于使反射的光极化的强度远小于更暗外观的表面。用于白色区域重建情景的成像和重建过程在所有关键方面都类似于黑色区域上使用的过程。3D表面曲线图7611中可查看的比较具有约45微米的RMS偏差。在实施例中通过系统性减少场景模型参数、光场要素、相机补偿以及场景中介质的光学交互参数的错误可实现更大精度。

黑色凹陷和白色凹陷重建的精度可以相对术语表示为(好于)千分之一份，因为包含4个凹陷的体积场景区域在X、Y和Z方向中延伸大约50毫米。将绝对RMS偏差除以重建区域的线性程度，得到指示相对RMS偏差的比率。下表包含黑色凹陷和白色凹陷重建情况的经验数据。

参考图77，准备汽车面板7701和额外面板，总量编号至17，并且将其置于明亮光场7711并使用极化相机成像。7711中的光场并未设计成具有照明的任何精确结构或分布。其主要目的为提供足够光能，使得当对具有黑色表面粗糙度的面板成像时可以避免非常长的相机曝光时间。成像的面板集合跨越一系列涂料颜色，包括在弥漫反射和极化行为的极端值下的黑色和白色成像包括如上文参考测试面板成像情景描述的向内和向外相机视点。

在示例性实施例中，在成像操作之后，检查每个面板并通过进行车辆冰雹损伤评定专业训练的人检查员注释7721。将不同颜色的贴纸应用于面板，以指示如由检查员使用工业标准检查灯和其他设备判断的具有不同大小的凹陷。使用本发明方法重建每个面板表面区域，并且借助于更大的编码的光学目标(正方形贴纸)，在与人检查员的物理注释一致的参考7731的空间框架内解析这些面板表面区域。将重建的凹陷图与检查员的注释相比较7741，其结果汇总于下表中。

图78示出用于图像生成目的的子场景提取的示例性情况7800。提取目标为传输使头戴式显示器7805屏幕能够再现描绘的场景模型的图像的子场景，其示出为具有保持面元的相对粗糙的体元以及还有边界体元，从而保持表示来自太阳和邻近天空的光的窗状光场。显示器7805的最顶行中的像素7801直接从所表示的太阳的窗状光场接收阳光。显示器7805的中间行中的像素7803接收图中指示的从接地面元反射的阳光。在子场景提取期间在过程6900、7000和7100中，覆盖两个像素7801和7803的一个或多个查询立元将碰到图中示出的两个光传递路径。如果中间像素7803碰巧比顶部像素7801更早触发其查询，那么经由2个全光投影的间接链可达到表示其窗状光场内的阳光的边界介元。如果顶部像素7801反而碰巧比中间像素7803更早触发其查询，那么经由从像素7801到边界体元的单次投影可直接达到该相同边界介元。如果场景包含接地面元的足够准确的BLIF信息(与场景模型的“标准”形式相关)，则无论查询立元处理次序如何都将得到相同像素内容。

在本文所述的实例中，出于解释和非限制性的目的，陈述特定详情，诸如特定节点、功能性实体、技术、协议、标准等，以便提供对所述技术的理解。本领域技术人员将明白的是，除了下文所述的具体详情，也可以实践其他实施例。在其他情况下，省略熟知的方法、设备、技术等的详细描述，以便不以不必要的细节模糊该描述。个别功能框示出在图中。本领域技术人员将了解的是，那些框的功能可以使用个别硬件电路、使用软件程序和数据连同适合编程的微处理器或通用计算机、使用专用集成电路(ASIC)和/或使用一个或多个数字信号处理器(DSP)来实施。软件程序指令和数据可保存在计算机可读存储介质中并且当由计算机或其他适合处理器控制执行这些指令时，该计算机或处理器执行这些功能。尽管在本文中可将数据库描绘为表格，可使用其他格式(包括关系数据库、基于对象的模型和/或分布式数据库)来存储和操纵数据。

尽管过程步骤、算法等可以按特定的顺序次序来描述或要求保护，但是这类过程可被配置成按不同的次序进行。换句话说，可明确描述或要求保护的步骤的任何顺序或次序并不一定指示要求按这个次序执行这些步骤。本文所描述的过程的步骤可以按任何可能的次序执行。此外，一些步骤可以同时执行，尽管被描述为或被暗示为不同时发生(例如，因为一个步骤是在另一个步骤之后描述)。另外，通过在附图中描绘过程来展示这个过程并不意味着所展示的过程不包括这个过程的其他变化和修改，并不意味着所展示的过程或其步骤中的任一个步骤对于本发明是必需的，并且不意味着所展示的过程是优选的。

上文标注的处理器、存储器、网络接口、I/O接口和显示器为或者包括硬件设备(例如，电子电路或电路的组合)，这些硬件设备被配置为执行计算设备的各种不同功能。

在一些实施例中，每个或任何处理器为或者包括例如单核处理器或多核处理器、微处理器(例如，其可称为中央处理器单元或CPU)、数字信号处理器(DSP)、与DSP核相联的微处理器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路或芯片系统(SOC)(例如，包括CPU和其他硬件部件诸如存储器、网络接口等的集成电路)。和/或，在一些实施例中，每个或任何处理器604使用指令集架构诸如x86或高级RISC机器(ARM)。

在一些实施例中，每个或任何存储器设备为或包括随机存取存储器(RAM)(诸如动态RAM(DRAM)或静态RAM(SRAM))、闪速存储器(例如，基于NAND或NOR技术)、硬盘、磁光介质、光学介质、超速缓冲存储器、寄存器(例如，保持指令)或执行数据和/或指令的易失性或非易失性存储的其他类型的设备(例如，在处理器上或由处理器执行的软件)。存储器设备为非易失性计算机可读存储介质的实例。

在一些实施例中，每个或任何网络接口设备包括一个或多个电路(诸如基带处理器和/或有线或无线收发器)，并且实施一种或多种有线通信技术(诸如以太网(IEEE802.3)和/或无线通信技术(诸如蓝牙、WiFi(IEEE 802.11)、GSM、CDMA2000、UMTS、LTE、LTE高级(LTE-A)和/或其他短范围、中间范围和/或长范围无线通信技术)的第一层、第二层和/或更高层。收发器可包括用于变送器和接收器的电路。变送器和接收器可共享共同外壳并且可共享外壳中一些或全部电路以执行传输和接收。在一些实施例中，收发器的变送器和接收器可不共享任何共同电路和/或可处于相同或单独外壳中。

在一些实施例中，IO接口中的每个或任何显示接口为或包括从处理器104接收数据、基于所接收的数据生成(例如，经由离散GPU、集成式GPU、执行图像处理的CPU等)对应数据和/或将所生成的图像数据输出(例如，高清晰多媒体接口(HDMI)、显示端口接口、视频图形阵列(VGA)接口、数字视频接口(DVI)等)到显示图像数据的显示设备的一个或多个电路。替代地或另外地，在一些实施例中，每个或任何显示接口为或包括例如视频卡、视频适配器或图形处理单元(GPU)。

在一些实施例中，I/O接口中的每个或任何用户输入适配器为或包括从包括在计算设备中、附接到计算设备或以其他方式与计算设备通信的一个或多个用户输入设备接收用户输入数据并处理并且基于所接收的输入数据将数据输出到处理器的一个或多个电路。替代地或另外地，在一些实施例中，每个或任何用户输入适配器为或包括例如PS/2接口、USB接口、触屏控制器等；和/或用户输入适配器有利于从用户输入设备例如键盘、鼠标、触控板、触屏等输入。

各种形式的计算机可读介质/变速器可涉及将数据(例如，指令序列)运送到处理器。例如，数据可以(i)从存储器递送到处理器；(ii)通过任何类型传输介质(例如，有线、无线、光等)进行运送；(iii)进行格式化和/或根据多种格式、标准或协议(诸如以太网(或IEEE 802.3)、ATP、蓝牙以及TCP/IP、TDMA、CDMA、3G等)进行传输；和/或(iv)以本领域熟知的各种方式中的任一种进行加密，以确保隐私或防止欺诈。

将了解的是，如本文所用，术语系统、子系统、服务、程式化逻辑电路等可实施为软件、硬件、固件和/或类似物的任何合适组合。还将了解的是，存储位置在本文中可以是磁盘驱动设备、存储器位置、固态驱动器、CD-ROM、DVD、磁带备份、存储区域网(SAN)系统和/或任何其他适当的有形计算机可读存储介质的任何合适组合。还将了解的是，本文所述的技术可通过使处理器执行可有形存储在计算机可读存储介质上的指令来完成。

如本文所用，术语“非暂时性计算机可读存储介质”包括寄存器、超速缓冲存储器、ROM、半导体存储设备(诸如D-RAM、S-RAM或其他RAM)、磁性介质诸如闪速存储器、硬盘、磁光介质、光学介质(诸如CD-ROM、DVD或蓝光光盘)或用于非暂时性电子数据存储的其他类型的设备。术语“非暂时性计算机可读存储介质”不包括暂时性传播电磁信号。

当在本文件中描述为“可以(may/can/could)”执行动作，在给定上下文中“可以”包括特性或部件或者特性或部件适用于给定上下文，给定项目“可以”具有给定属性时，或者无论何时使用涉及术语“可以”的任何类似短语时，应理解的是，给定的动作、特征、部件、属性等存在于至少一个实施例中，尽管不一定存在于所有实施例中。

虽然已经结合目前被认为是最实用和优选的实施例描述了本发明，但是应理解，本发明不限于所公开的实施例，而是相反地，本发明意图覆盖包括在所附权利要求书的精神和范围内的各种修改和等效布置。