本頁面解釋了 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。

這些新增都不會影響向後相容性。