本页面解释了 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 年，IAU 通过了一项关于行星定义的争议性决议。冥王星被剥夺了行星地位，并被重新归类为一个名为矮行星的新类别的成员。谷神星，最大的小行星，和阋神星，已知最大的柯伊伯带天体，也被指定为矮行星。迄今为止，除了鸟神星和妊神星，IAU 只认可了这五个天体为矮行星，但很可能还有更多。可以通过将天体分配给 dwarfplanet 类来将其标记为矮行星。

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

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

小卫星

太阳系中已知的卫星超过一百颗。这些卫星中的大多数是围绕外行星运行的小岩石。虽然能够可视化这些卫星的轨道很有趣，但它们的数量非常多，以至于打开卫星轨道会导致围绕外行星出现令人困惑的“线团”。新对象类小卫星被引入来解决这个问题。在默认的 Celestia 太阳系文件中，外行星的小卫星现在被指定为小卫星。小卫星的轨道和标签显示可以分别切换，与主卫星标签和轨道分开。重要的是要注意，与矮行星不同，“小卫星”不是 IAU 认可的术语。该类是纯粹为了用户的方便而添加到 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 为此类物体添加了一个名为漫射的新类。默认情况下，漫射物体不可点击，用户也无法选择它们。它们永远不会用标签标记，也不会在启用轨道路径时显示其轨迹。最后，它们不反射光，会导致“行星光”。最后一点很重要。由于漫射物体不是固体，因此它们可能会与其他物体相交；在这种情况下，Celestia 的反射光计算无效，会导致不真实的照明。将对象标记为漫射类是告诉 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
    ...
}

请注意，class diffuse 的物体默认情况下不可点击。因此，上面的示例最好写成这样

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

如果由于某种原因，SSC 作者希望创建一个可以点击选中的 diffuse 物体，也可以通过将 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
    ...
}

会导致云被定义但不会被绘制。

可见属性可以通过在 CELX (Lua) 脚本中调用 setvisible 方法来控制

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

轨道颜色属性

背景

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 文件中描述 *惠更斯* 探测器的轨迹？对于 *卡西尼* 探测器，我们使用一个覆盖了航天器整个生命周期的 SampledTrajectory (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中进行动画。

开始和结束

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

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

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

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

Satellite1被分配了一个在所有时间内有效的轨道，因为开始和结束时间被省略，并且具有默认值−无穷大和+无穷大。在这种情况下，实际上没有必要使用时间线。该对象的运行方式与以下更简单的版本完全相同

"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的Web界面可用于生成具有速率和位置的轨迹。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”。

CustomRotation

简化的表面放置

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

使用 SurfaceObject 关键字会调用几个有用的默认值。

对象的默认 OrbitFrame 是父对象的 BodyFixed 框架。
对象的默认 BodyFrame 是地心坐标系，其 Z 轴指向天顶，Y 轴指向父天体的北极，X 轴指向东方。
对象的默认类别是 "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。

这些添加都不会影响向后兼容性。