此页面解释了 Celestia 1.6.0 中的一些新功能。它针对的是熟悉为早期版本的 Celestia 制作 SSC 文件的插件创建者。每个功能描述都分为两部分：背景和 1.6.0 更改。背景部分解释了 Celestia 在 1.5.0 中是如何工作的，并提供了一些关于为什么在 1.6.0 中进行增强的原因。在所有情况下，都保持了与 Celestia 1.5.0/1.5.1 的向后兼容性：为 1.5.0 编写的插件在 1.6.0 中将以相同的方式工作。

新的对象类别

背景

SSC 文件中的天体可以分配一个类别，该类别决定它在 Celestia 的太阳系浏览器中的分类。在某些情况下，天体的类别也控制其外观的某些方面。例如，彗星尘埃尾部仅显示在标记为彗星类别的物体上。以下是在 Celestia 1.5.0 中的典型用法

"Ceres" "Sol"
{
    Class "asteroid"
    Radius 487.5
    ...
}

Celestia 1.5.0 中可用的类别为

* planet
* moon
* asteroid
* comet
* spacecraft
* invisible

1.6.0 更改

1.5.0 对象类别保持不变，但 Celestia 1.6.0 添加了一些新的对象类别。

矮行星

2006 年，国际天文学联合会通过了一项关于行星定义的具有争议性的决议。冥王星被剥夺了行星身份，并重新归类为一类名为矮行星的新天体。谷神星，最大的小行星，和阋神星，已知最大的柯伊伯带天体，也被指定为矮行星。到目前为止，这些以及鸟神星和妊神星是国际天文学联合会承认的五颗矮行星，但很可能还有更多。通过为天体分配类别矮行星，可以将其标记为矮行星

"Ceres" "Sol"
{
    Class "dwarfplanet"
    Radius 487.5
    ...
}

在 Celestia 的 3D 视图窗口中，矮行星与行星的区别在于轨道和标签颜色不同。除此之外，矮行星与行星之间没有区别。

小卫星

太阳系中已知有超过一百颗卫星。这些卫星中的大多数是围绕外行星运行的小岩石。虽然能够可视化这些卫星的轨道很有趣，但它们的数量如此之多，以至于打开卫星轨道会导致在外行星周围出现令人困惑的“一团乱麻”。引入了新的对象类别小卫星来解决这个问题。在默认的 Celestia 太阳系文件中，外行星的小卫星现在被指定为小卫星。可以单独切换小卫星的轨道和标签显示，与大卫星的标签和轨道不同。重要的是要注意，与矮行星不同，“小卫星”不是国际天文学联合会认可的术语。该类别添加到 Celestia 纯粹是为了用户的方便。关于什么是小卫星没有硬性的规定，但一般来说，直径小于 100 公里的外行星卫星被标记为小卫星。

以下是用小卫星类别示例

"Sinope" "Sol/Jupiter"
{
    Class "minormoon"
    Radius 19
    ...
}

表面特征

表面特征是针对固定在另一个天体表面的物体（例如建筑物和地形特征）的一种新类别。以前，这些物体根本没有好的分类。由于缺乏更好的选择，SSC 创建者往往将它们归类为小行星或航天器。表面特征类别还有一个有用的属性：表面特征在远处不可见。虽然将非常远的天体渲染为点对于在太空中运行的天体来说是一种现实的效果，但当应用于地面的物体时，它看起来并不美观。除此之外，对适当物体的分类意味着它们将在太阳系浏览器中得到合理的组织。

示例

"Space Needle" "Sol/Earth"
{
    Class "surfacefeature"
    Mesh "needle.cmod"
    OrbitFrame { BodyFixed {} }
    FixedPosition [ ... ]
    ...
}

组件

具有活动部件的天体可以在 Celestia 中使用多个 SSC 对象来实现。例如，一个具有两个可移动太阳能电池板的航天器可以定义为三个对象：一个用于航天器的主体，一个用于每个电池板。与其将所有部件都定义为航天器，不如只将主体定义为航天器，并将其他部件分配给新的类别组件。与表面特征一样，组件在距离观察者很远时不会被渲染为点状光。这避免了多部件物体在远处显得过亮的问题。适当地使用组件类别还意味着物体在太阳系浏览器中得到更好的组织。

多部件航天器示例

"Orbiter" "Sol/Mars"
{
    Class "spacecraft"
    Mesh "spacecraft-body.cmod"
    ...
}

"Solar Panel - Left" "Sol/Mars/Orbiter"
{
    Class "component"
    Mesh "spacecraft-leftpanel.cmod"
    ...
}

"Solar Panel - Right" "Sol/Mars/Orbiter"
{
    Class "component"
    Mesh "spacecraft-rightpanel.cmod"
    ...
}

漫射

还有一组对象不适合任何 Celestia 1.5.0 类，例如尘埃云、吸积盘、火山羽流和其他扩展的非固体物体。Celestia 1.6.0 添加了一个名为 diffuse 的新类来处理此类对象。默认情况下，漫射对象不能被用户点击和选择。它们永远不会用标签指示，当启用轨道路径时，也不会显示它们的轨迹。最后，它们不反射光，导致“行星光”。最后一点很重要。由于漫射对象不是固体，它们可能会与其他对象相交；在这种情况下，Celestia 的反射光计算无效，会导致不真实的照明。用 diffuse 类标记一个对象是告诉 Celestia 对象不是固体，并且在照明方面应该被不同地处理的唯一方法。

示例

"Loki Plume" "Sol/Jupiter/Io"
{
    Class "diffuse"
    Mesh "plume.cmod"
    ...
}

可点击属性

背景

Celestia 用户可以通过点击 3D 视图中的对象来选择它。但是，有时这不可取。SSC 作者可能会定义一个扩展的气体对象，例如吸积盘，目的是让观看者可以自由地穿过它。当摄像机在这样的物体内部时，任何方向的点击都会选择它——这种行为很可能让用户感到困惑。

1.6.0 更改

Celestia 1.6.0 提供了一个新的布尔 SSC 属性 Clickable。在 SSC 物体定义中指定 clickable false 可以阻止该物体在被点击时被选中。当用户点击选择时，不可点击的物体被视为不存在；如果点击点下方存在更远的物体，则将选择该物体。

示例

"Accretion Disc" "Fomalhaut"
{
    Mesh "disc.cmod"
    Radius 1e9
    Clickable false
    ...
}

请注意，diffuse 类的对象默认不可点击。因此，上面的示例最好这样写

"Accretion Disc" "Fomalhaut"
{
    Class "diffuse"
    Mesh "disc.cmod"
    Radius 1e9
    ...
}

如果由于某种原因，SSC 作者想要创建一个可以点击选择的漫射对象，也可以通过将 clickable 属性设置为 true 来覆盖默认的不可点击状态

"Dust Cloud" "Sol"
{
    Class "diffuse"
    Mesh "cloud.cmod"
    Clickable true
    ...
}

可见属性

背景

在设计动态 Celestia 物体或调试目录文件时，通常让 Celestia 不绘制物体非常有用。

1.6.0 更改

SSC 指令

 Visible true

和

 Visible false

决定是否绘制物体。

默认值为

 Visible true

例如

"Dust Cloud" "Sol"
{
    Class "diffuse"
    Mesh "cloud.cmod"
    Visible false
    ...
}

导致云被定义，但没有被绘制。

可以通过调用 setvisible 方法在 CELX（Lua）脚本中控制 Visible 属性

 local obj = celestia:find("Sol/Dust Cloud")
 obj:setvisible(true)

OrbitColor 属性

背景

Celestia 允许用户切换行星、恒星、卫星和其他天体的轨道路径显示。在 Celestia 1.5.0 版本中，添加了新的脚本命令来更改为每个类显示的轨道的颜色。但是，在某些情况下，更细致地控制轨道路径的颜色非常有用。例如，如果每个行星都有不同的轨道颜色，行星系统概览可能会更清晰。

1.6.0 更改

可以通过设置 OrbitColor 属性来修改 SSC 对象轨道颜色。在这个例子中，我们将月球轨道的颜色设置为黄色

Modify "Moon" "Sol/Earth"
{
    OrbitColor [ 1 1 0 ]
}

与其他颜色属性一样，OrbitColor 的分量是 0 到 1 之间的值，并且按红色、绿色、蓝色排序。下面的示例更改了所有内行星的轨道颜色

Modify "Mercury" "Sol"
{
    OrbitColor [ 1 0.7 0.2 ]  # brown
}

Modify "Venus" "Sol"
{
    OrbitColor [ 1 1 0.7 ]  # light yellow
}

Modify "Earth" "Sol"
{
    OrbitColor [ 0.5 0.7 1 ]   # light blue
}

Modify "Mars" "Sol"
{
    OrbitColor [ 1 0.6 0.6 ]   # light red
}

三轴椭球体

背景

Celestia 有两种方法来设置物体的形状

可以使用 Mesh 属性指定 3D 网格文件，或者...
如果省略 Mesh 属性，Celestia 将假定该物体是椭球体

在 Celestia 1.5.0 中，椭球体的大小由 Radius 属性控制。椭球体的形状由 oblateness 属性的值给出。扁率是沿极轴的扁平或拉伸量。扁率的默认值为 0.0，表示椭球体是球体。如果扁率大于零，行星将显得扁平。这种扁平球体形状称为扁球体。巨行星的非球体形状非常明显：快速自转会扭曲它们，导致赤道出现明显的隆起。即使是像地球这样的固体天体也会在一定程度上被压扁，尽管比巨行星要小。

扁率计算为 ${\frac {a-b}{a}}$ ，其中 a 是赤道半径，b 是极半径。土星在太阳系中所有行星中扁率最大，为 0.0980。地球的扁率约为 0.00335——从太空中看，从视觉上看不出它与球体有什么区别。

虽然大多数太阳系大型天体可以准确地表示为扁球体，但也有一些天体不能。巨行星的一些卫星在指向行星的赤道轴上明显拉伸。必须给出三个轴长度：极轴和两个不同的赤道轴。术语“三轴椭球体”是指三个轴长度均不同的椭球体。

1.6.0 更改

SSC 天体的 SemiAxes 新属性用于指定三轴椭球体。卡西尼号宇宙飞船拍摄的图像显示土星卫星土卫一具有明显的三轴形状。

其尺寸为 414.8×394.4×381.4 公里。第一个数字是指向土星的轴的长度，第二个数字是沿土卫一轨道的轴的长度，最后一个数字是极轴的长度。在 SSC 文件中，我们将写入

"Mimas" "Sol/Saturn"
{
    SemiAxes [ 207.4 197.2 190.7 ]
    ...
}

请注意，由于我们正在指定 *半轴而不是轴*，因此这些值是轴长度的一半。轴与半轴之间的关系类似于直径与半径之间的关系。SemiAxes 属性的使用非常简单：您实际上是在指定三个半径，而不是仅仅一个。Radius、Oblateness 和 SemiAxes 属性之间的交互有一些细微之处

如果同时指定了这两个属性，则 Radius 将乘以 SemiAxes 长度
如果给出了 SemiAxes，则会忽略 Oblateness
如果既没有指定 SemiAxes，也没有指定 Radius，则会出现错误

如果您遵守以下准则，可以保持简单，并忽略这些技术细节

对于球体，仅指定半径
对于扁体，仅指定半径和扁率
对于具有三轴椭球体形状的行星，仅指定半轴
对于不规则物体，仅指定网格和半径

物体时间线

对象时间线是Celestia 1.6.0 的一项主要新功能。使用时间线，可以描述物体在其整个生命周期中的运动，即使需要多种轨迹类型或参考系也是如此。以前需要使用包含同一物体多个定义的笨拙的 SSC 文件，现在可以用单个物体完成。

背景

在Celestia 中添加时间线的动机最好用一个例子来解释。我们将考虑卡西尼-惠更斯号飞船对土星和土卫六的探测任务，该任务包含在Celestia 的基本软件包中。惠更斯探测器从发射到 2004 年 12 月 25 日一直与卡西尼号飞船相连。在这一天，惠更斯号从卡西尼号分离，然后独自绕土星运行三周，直到 2005 年 1 月 14 日进入土卫六的大气层。现在，我们如何在 SSC 文件中描述惠更斯探测器的轨迹？对于卡西尼号飞船，我们使用一个涵盖航天器整个生命周期的样本轨迹（xyz 文件）。我们可以对惠更斯探测器做类似的事情：xyz 文件将与从卡西尼号分离之前的点完全相同。但是，这会造成很多数据重复。它也增加了维护工作：如果卡西尼号轨迹更新（在分离时间之后），我们也必须更新惠更斯探测器轨迹文件。最后，这种技术只有在卡西尼号没有旋转的情况下才能起作用，而实际上这根本不可能。

一种更方便、更不浪费的方法将利用惠更斯探测器和卡西尼号飞船在从地球到土星的整个旅程中连接在一起的事实。在Celestia 1.5.0 中，唯一的方法是定义两个不同的惠更斯探测器版本：一个与卡西尼号飞船相连，另一个绕土星运行。以下是与卡西尼号飞船相连的版本

"Huygens (with Cassini)" "Sol/Cassini" 
{
    Class "spacecraft"
    Mesh "huygens.3ds"
    Radius 0.00135

    Beginning 2450736.893877314 # 1997 Oct 15 09:27:11
    Ending    2453364.5847      # 2004 Dec 25 02:01:58

    OrbitFrame { BodyFixed { Center "Sol/Cassini" } }
    BodyFrame { BodyFixed { Center "Sol/Cassini" } }
    FixedPosition [ -0.0013 0 -0.0002 ]
    FixedRotation { }

}

Ending 属性设置为分离时间。在那一刻，与“卡西尼”号相连的“惠更斯”版本将消失。这个“惠更斯”的位置和方向相对于“卡西尼”号固定：“惠更斯”将跟随卡西尼号航天器的每一次移动和旋转。分离后，“惠更斯（与卡西尼）”被此版本替换

"Huygens (free flight)" "Sol" 
{
    Class "spacecraft"
    Mesh "huygens.3ds"
    Radius 0.00135

    Beginning 2453364.5847 # 2004 Dec 25 02:01:58
    Ending    2453384.8750 # 2005 Jan 14 09:00:00

    SampledOrbit "huygens.xyz"

    UniformRotation
    {
        Inclination 70
        Period 0.01
    }
}

现在，惠更斯探测器拥有了自己的轨迹和旋转。它的运动是相对于太阳而不是相对于卡西尼号飞船定义的。但是，也存在一些缺点

我们必须复制与轨迹或方向无关的关于惠更斯探测器的所有数据：网格、类别、半径、infoURL 等。
用户可能会对太阳系浏览器中存在两个惠更斯探测器实例感到困惑。
跟踪惠更斯探测器从卡西尼号飞船分离的过程将不起作用；相机在“惠更斯（与卡西尼）”消失后不会跟踪“惠更斯（自由飞行）”。

我们想要的是一种方法，可以为惠更斯探测器提供两个不同的参考系和轨迹，而无需创建探测器的两个实例。这正是物体时间线所允许的。

1.6.0 更改

在Celestia 1.6.0 中，我们可以将两个惠更斯探测器版本合并成一个物体。

"Huygens" "Sol/Cassini" 
{
    Class "spacecraft"
    Mesh "huygens.3ds"
    Radius 0.00135

    Timeline [
      # Phase 1: With Cassini
      {
         Beginning "1997 19 15 09:27:11"
         Ending    "2004 12 25 02:02:34"

         OrbitFrame { BodyFixed { Center "Sol/Cassini" } }
         BodyFrame { BodyFixed { Center "Sol/Cassini" } }
         FixedPosition [ -0.0014 0 0.0002 ]
         FixedRotation { Inclination 90 AscendingNode 90 } 
       }

       # Phase 2: Free flight to Titan
       {
         Ending "2005 01 14 09:07:00"

         OrbitFrame { EclipticJ2000 { Center "Sol/Saturn" } }
         BodyFrame { EclipticJ2000 {} }

         SampledTrajectory { Source "huygens.xyz" }
         UniformRotation
         {
           Period 0.125            # 7.5 revolutions per minute
         }
       }
     ] # End Timeline
}

观察时间线块的内部，有两组帧和轨迹。时间线中的每一部分都称为阶段。在阶段中唯一允许的是开始时间、结束时间、轨迹、旋转模型、物体帧和轨道帧。时间线并非旨在成为动画的通用系统，因此无法通过在每个阶段中放置不同的模型来影响物体在时间线阶段中的外观变化。一些其他技术最终将被实现，以允许在Celestia 中进行动画。

开始和结束

开始和结束属性定义了时间线阶段所覆盖的跨度。总的来说，这些阶段覆盖一个连续的时间跨度：不允许存在任何间隔。连续性得到保证，因为对于除第一个阶段以外的所有阶段，阶段开始时间会自动设置为前一个阶段的结束时间。时间线中开始时间和结束时间的规则总结如下

第一个阶段: 可以指定开始时间，如果未指定，则默认为 -infinity; 如果存在多个阶段，则必须指定结束时间
最后一个阶段: 如果存在多个阶段，则必须指定开始时间; 可以指定结束时间，如果未指定，则默认为 +infinity
其他阶段: 不允许指定开始时间；它将自动设置为前一个阶段的结束时间; 必须指定结束时间；没有默认值

一些示例将说明时间线可以被划分为阶段的各种方式。在第一个示例中，只有一个无限阶段

"Satellite1" "Sol/Earth"
{
    Radius 0.001
    Timeline [
      {
          EllipticalOrbit { ... }
      }
    ]
}

卫星 1 被分配了一个在所有时间内都有效的轨道，因为开始时间和结束时间被省略了，并且它们具有默认值 -infinity 和 +infinity。在这种情况下，实际上根本不需要使用时间线。物体的行为将与这个更简单的版本相同

"Satellite1" "Sol/Earth"
{
    Radius 0.001
    EllipticalOrbit { ... }
}

当只有一个阶段时，没有必要将帧和轨迹放在时间线中。一个更有用的时间线示例是月球着陆器的定义，该着陆器于 2010 年 2 月 25 日从地球发射，并于同年的 3 月 12 日降落在月球上

"Lunar Lander" "Sol/Earth"
{
    Radius 0.001
    Timeline [
      # Phase 1: Launch and cruise
      {
        Beginning "2010 2 25 12:30"
        Ending    "2010 3 12 15:30"
        OrbitFrame { EquatorJ2000 { Center "Sol/Earth" } }
        SampledTrajectory { Source "traj.xyzv" }
      }

      # Phase 2: Landed on the Moon
      {
        OrbitFrame { BodyFixed { Center "Sol/Earth/Moon" } }
        FixedPosition [ ... ]
      }
    ]
}

着陆时间在第一个阶段定义，因此在第二个阶段中没有给出（或允许）开始时间。由于在第二个阶段没有指定结束时间，因此着陆器将一直停留在月球表面，直到时间结束。

位置 + 速度轨迹（xyzv 文件）

使用新的轨迹文件格式可以同时提高定位精度并减少内存使用量。

背景

当物体的轨迹不能用椭圆或 Celestia 的内置轨道计算方法充分描述时，会使用样本轨迹。通常，样本轨迹用于星际飞船，但它们对其他物体也很有用。在 ssc 或 stc 文件中使用样本轨迹有两种方法。旧方法使用 SampledOrbit

SampledOrbit "trajectory.xyz"

1.5.0 中添加的新方法使用 SampledTrajectory

SampledTrajectory { Source "trajectory.xyz" }

SampledTrajectory 应该优先于 SampledOrbit，因为它提供了控制精度（双精度或单精度）和插值类型（三次或线性）的选项。SampledOrbit 始终使用单精度位置，这对于 Celestia 的严肃航天应用来说并不足够。

样本轨迹文件是时间和位置记录的列表。通常，这些文件是由 SPICE 内核或 JPL 的 [[1]] 系统生成的。以下是伽利略号飞船轨迹文件的一部分

2447818.615972 134114700.2612462193 64912642.6984842718 39861.799941
2447819.615972 133153386.7785827518 66969511.3118158504 237125.784089
2447820.615972 132137795.3581911474 69024279.8844281882 418499.867572
2447821.615972 131079666.1268854141 71061806.8872888833 596914.157647

每行上的第一个值是儒略日，最后三个值是公里单位的位置。位置的参考系在 ssc 文件中给出。默认情况下，Celestia 使用一种称为三次埃尔米特插值的技术来实现点之间的平滑运动。对于本次讨论，具体的数学公式并不重要。重要的是为了在点之间进行插值，Celestia 需要物体的速度及其在每个时间的位置。可以通过查看两个连续点之间位置的差异来估计速度，但是通过在轨迹文件中保存速度，可以实现更高的精度。

1.6.0 更改

Celestia 1.6.0 添加了对位置和速度轨迹文件的支持。这些文件扩展名为 xyzv，可以在 SampledTrajectory 中以与 xyz 文件完全相同的方式使用

SampledTrajectory { Source "trajectory.xyzv" }

xyzv 文件中的记录与 xyz 文件中的记录具有相同的布局，只是在每个位置之后附加了三个速度值。速度的单位是公里每秒。对于给定文件大小，xyzv 文件提供更准确的物体定位。因此，如果可以获取物体的速度和位置，则应该始终优先使用 xyzv 文件而不是 xyz 文件。Celestia 1.6.0 仍然支持 xyz 文件以实现向后兼容，并涵盖无法获取速度的情况。

HORIZONS 的网络界面可用于生成具有速度和位置的轨迹。Celestia 还提供了一个名为 spice2xyzv 的新工具，可以从一个或多个 SPICE 内核生成 xyzv 文件。有关该工具的文档即将发布。

SSC 物体的多个名称

SSC 文件中定义的物体现在可以分配多个别名。

背景

在 Celestia 1.5.1 中，可以为恒星或深空物体分配多个名称。这很重要，因为恒星和星系通常有多个常用名称。例如，红巨星参宿四通常被称为其拜耳名称猎户座 α。仙女座星系也称为 NGC 598 和其梅西耶编号 M 33。DSC 文件中仙女座星系的定义可能如下所示

"Andromeda Galaxy:M 33:NGC 598"
{
    ...
}

这些名称用冒号分隔。

1.6.0 更改

1.6.0 只是为 SSC 物体添加了相同的多名称功能。与恒星和深空物体一样，名称用冒号分隔。多名称有用的常见情况是小行星。首次报告时，小行星会被分配一个临时名称。经过进一步观测，它将获得一个小行星编号，国际天文联合会最终可能会批准一个适当的名称。因此，在 SSC 文件中，你可能有一个这样的定义

Body "136199 Eris:Eris:2003 UB313" "Sol"
{
    ...
}

列表中的第一个名称将是出现在标签和太阳系浏览器中的名称。当选中该物体时，所有名称都将在屏幕左上角显示。任何名称在路径中都有效，因此您可以将厄里斯的卫星迪斯诺米亚称为“Sol/136199 Eris/Dysnomia”、“Sol/Eris/Dysnomia”或“Sol/2003 UB313/Dysnomia”。

自定义旋转

简化表面放置

SurfaceObject "name" "path/parent" { ... }

使用 SurfaceObject 关键字会调用一些有用的默认值

物体的默认 OrbitFrame 是父物体的 BodyFixed 框架
物体的默认 BodyFrame 是地心坐标系，其 Z 轴指向天顶，其 Y 轴指向父物体的北极，其 X 轴指向东方。
物体的默认 Class 是 "surfacefeature"

添加/修改/替换恒星

网格放置和缩放

背景

Celestia 插件创建者在尝试将网格物体精确地彼此放置时遇到了一些困难。Celestia 的“规范化”网格物体是造成这些问题的原因之一。当网格被规范化时，它会被缩放和居中，以便其最长轴适合于具有指定物体半径的球体。常见的解决方法是在彼此靠近的物体上添加大小相同的不可见边界框。这将确保模型有效地共享相同的坐标系。

虽然有效，但创建这些边界框会给插件创建者带来额外的工作量。这也意味着网格最终会被错误地标记为半透明，以用于深度排序。

1.6.0 更改

两个新的 ssc 属性解决了网格放置的问题，而无需添加边界框。

# defaults to true for backward compatibility
NormalizeMesh <boolean>

# defaults to 1
MeshScale <number>

当物体具有 NormalizeMesh false 指定时，不会进行自动缩放和网格重新居中。插件创建者必须确保将物体的半径设置为足够大的值以包含它。

MeshScale 将模型的内部单位转换为 Celestia 所需的公里。例如，在单位为一米的系统中构建航天器比在单位为一公里的系统中构建航天器要方便得多。对于这样的模型，您将 MeshScale 指定为 0.001。

这些新增功能都不会影响向后兼容性。