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

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