Stellar Memory:

By /

A Starfleet Science Officer’s Report on Stellaris, ST: New Horizons, and GPU VRAM Utilization

Author: Lt. Cmdr. [Redacted], Science Division, USS [Redacted]

1. Mission Overview

Stardate: Irrelevant to Starfleet Command, highly relevant to modders.

The objective of this analysis is to determine why the simulation environment known as Stellaris – particularly when augmented with the Star Trek: New Horizons (ST:NH) holosuite package – exhibits significantly elevated VRAM utilization on modern graphical processing units.

Two primary hypotheses were evaluated:

  1. Defective Asset Hypothesis
    One or more newly exported 3D models (meshes) are malformed or inefficient, causing disproportionate VRAM usage.
  2. Systemic Engine Hypothesis
    The underlying Clausewitz/Jomini simulation engine aggressively allocates and retains mesh data in GPU memory by design, such that total VRAM usage scales primarily with the aggregate volume of mesh data, irrespective of individual asset age.

This report consolidates multiple measurement series, compares vanilla Stellaris with ST:NH, and derives a quantitative relationship between mesh file size and VRAM utilization.

The conclusion, summarized in Starfleet terms:

The simulation behaves as an engine-level resource management phenomenon, not a single-bad-part anomaly. VRAM usage scales almost linearly with total mesh data mass.

2. Experimental Setup

All measurements were conducted on a standard Federation workstation equipped with a modern GPU and sufficient system memory. While the precise hardware designation is non-critical to the theoretical result, the following protocol was maintained consistently:

  1. Baseline VRAM
    Measure VRAM usage with no simulation running.
  2. Engine-Only VRAM
    Launch Stellaris in a configuration minimizing or excluding mesh assets, capturing VRAM usage for engine, UI, textures, shaders, and general overhead.
  3. Vanilla Asset VRAM
    Enable all vanilla mesh assets and record the resulting VRAM usage.
  4. ST:NH Mesh Analysis
    Activate ST:NH and enable or disable mesh groups in controlled size categories (by file size and count). After each change, measure:
    • total mesh data volume (MB on disk),
    • corresponding change in VRAM usage (MB on GPU).

This approach is functionally equivalent to instrumenting a holodeck program: we do not ask the computer what it believes it is doing; we observe what it actually consumes.

3. Vanilla Stellaris as Control Sample

To understand the engine’s intrinsic behavior, we first analyze unmodified (vanilla) Stellaris.

Observed values:

  • VRAM, system only (no game): 1.8 GB
  • VRAM, Stellaris loaded, minimal/without meshes: 4.0 GB
  • VRAM, Stellaris with all vanilla meshes active: 6.3 GB
  • Vanilla mesh payload: 800 MB across ~2200 mesh files

3.1 Engine Overhead Without Meshes

The first step is to isolate the engine’s own VRAM overhead (UI, shaders, textures, and non-mesh buffers):

Engine Overhead (no meshes) = 4.0 GB − 1.8 GB = 2.2 GB

This 2.2 GB is effectively the “always-on” mass of the simulation before any ship, station, or structure meshes are committed to GPU space.

3.2 VRAM Consumption Attributable to Meshes

Next, we compare VRAM with and without meshes:

VRAM_meshes (vanilla) = 6.3 GB − 4.0 GB = 2.3 GB

Thus, 800 MB of on-disk mesh data translate into approximately 2.3 GB of VRAM usage.

3.3 Deriving the Vanilla Conversion Factor

We define a conversion factor F representing how many MB of VRAM are consumed per MB of mesh data on disk:

F_vanilla = 2.3 GB VRAM / 0.8 GB mesh ≈ 2.9

In other words:

Vanilla Stellaris consumes roughly 2.9 MB of VRAM for every 1 MB of mesh data on disk.

This factor is the control constant against which ST:NH will be evaluated.

4. ST: New Horizons – Mesh Group Measurements

With the reference factor established, the ST:NH mesh assets were examined in aggregated size categories. Exact values are subject to minor measurement noise, but the patterns are robust.

The following representative groupings were used (simplified for clarity):

  1. Group A: Meshes > 10 MB
    • Total mesh data: ~100 MB
    • VRAM change when enabled: ≈ −500 MB
  2. Group B: Meshes > 2 MB
    • Total mesh data: ~650 MB (≈ 100 models)
    • VRAM change when enabled: ≈ −1700 MB
  3. Group C: Meshes > 1 MB
    • Total mesh data: ~300 MB (≈ 200 models)
    • VRAM change when enabled: ≈ −900 MB
  4. Group D: Meshes < 100 KB
    • Total mesh data: ~300 MB (315 models)
    • VRAM change: ≈ +100 MB
      (slight increase despite sizable disk mass – indicative of overhead and fragmentation effects)
  5. Group E: Meshes 100–999 KB
    • Total mesh data initially unknown
    • 500 models
    • VRAM change when enabled: ≈ −700 MB
      (e.g., VRAM moving from 8.4 GB to 7.7 GB as this group is toggled)

For a clean derivation of the general factor, the analysis focuses on Groups A–C (meshes > 1 MB). Group D exhibits atypical behavior due to the extreme abundance of tiny meshes and associated overhead, and is therefore treated separately.

5. VRAM-to-Mesh Ratio for ST:NH (Major Groups)

We now compute the VRAM-per-MB factor for each of the large ST:NH mesh groups.

5.1 Group A: Meshes > 10 MB

F_A = 500 MB VRAM / 100 MB mesh = 5.0

5.2 Group B: Meshes > 2 MB

F_B = 1700 MB VRAM / 650 MB mesh ≈ 2.62

5.3 Group C: Meshes > 1 MB

F_C = 900 MB VRAM / 300 MB mesh = 3.0

While the individual factors vary slightly, this is expected due to overlapping sets and measurement imprecision. To estimate the general ST:NH factor, we compute a weighted average based on the total mesh mass in each group:

F_STNH = (500 + 1700 + 900) / (100 + 650 + 300) = 3100 / 1050 ≈ 2.95

Result:

ST:NH consumes roughly 2.95 MB of VRAM per 1 MB of mesh data.

This is effectively identical to the vanilla factor of ≈ 2.9.

From a Starfleet science perspective, we would call this a confirmed correlation across two independent datasets.

6. Estimating the 100–999 KB Mesh Group (Group E)

Group E contained 500 meshes in the 100–999 KB range. Its exact total size was not initially measured; instead, we observed the VRAM change.

Measured:

  • VRAM change when (de-)activating Group E: ΔVRAM ≈ −700 MB
  • Previously derived factor for ST:NH: F ≈ 2.95

Assuming Group E follows the same general behavior, we can estimate the total mesh mass of this group:

mesh mass_E ≈ 700 MB VRAM / 2.95 ≈ 237 MB

Average size per mesh:

avg mesh size_E ≈ 237 MB / 500 ≈ 0.474 MB ≈ 474 KB

This places the average squarely within the defined 100–999 KB band, and once again matches the previously derived factor. Even when using a more conservative VRAM delta of −500 MB, the estimated mass (≈ 170 MB total) still lies within a plausible range.

In short, Group E aligns with the same linear scaling law: VRAM usage is proportional to mesh mass.

7. Vanilla vs. ST:NH – A Comparative View

At this point we can directly compare the VRAM-to-mesh ratios:

  • Vanilla Stellaris:
    F_vanilla ≈ 2.9 MB VRAM per 1 MB mesh
  • ST: New Horizons:
    F_STNH ≈ 2.95 MB VRAM per 1 MB mesh

Within experimental tolerance, these factors are identical.

The implications are significant:

  • The engine treats vanilla and ST:NH meshes in a fundamentally similar manner.
  • The scaling behavior is consistent across:
    • old ST:NH meshes (long in service),
    • newer meshes,
    • and a wide range of file sizes.
  • There is no statistical evidence that a few new or “broken” meshes dominate the VRAM footprint.

From a Starfleet analytical standpoint, the data strongly favor the Systemic Engine Hypothesis.

8. Interpreting the Engine’s Behavior

The most consistent interpretation of the evidence is as follows:

  1. Upon loading a game, the Clausewitz/Jomini engine parses available mesh assets.
  2. For each mesh, it allocates GPU-side structures:
    • vertex buffers,
    • index buffers,
    • and various auxiliary data (normals, tangents, skinning/bone influences, etc.),
      which together occupy significantly more space than the compressed mesh file on disk.
  3. These GPU resources are then retained in VRAM to enable rapid rendering of scenes without constant streaming.
  4. As a consequence, the additional VRAM requirement due to meshes grows approximately linearly with the total mesh data volume, at a rate of roughly 3:1.

In concise Starfleet language:

The engine effectively inflates mesh data from disk by a factor of about 3 when materializing them into GPU buffers, and then keeps this inflated representation resident in VRAM.

The fact that both vanilla and ST:NH exhibit the same factor confirms that this is a general property of the engine, rather than an anomaly introduced by the mod.

9. Implications for ST:NH and Large Mods

For mod authors and technically inclined captains, the operational consequences are clear:

  1. Total Mesh Mass is the Primary Driver
    The more meshes you have, and the larger those meshes are, the more VRAM the engine will consume. The relationship is approximately: VRAM_meshes ≈ 3 × mesh mass on disk
  2. ST:NH vs. Vanilla
    ST:NH, by design, introduces:
    • more models,
    • and generally larger, more detailed meshes than vanilla.
    Therefore, the higher VRAM usage is an expected outcome of the engine’s behavior, not an indicator of catastrophic asset failure.
  3. Defective or Inefficient Meshes
    Individual meshes may still be suboptimal – for example:
    • excessively high vertex counts,
    • redundant vertex attributes (multiple UV sets, vertex colors, unused bones),
    • many separate submeshes causing extra overhead.
    Such assets can worsen the situation locally, but they do not explain the global linear pattern observed across thousands of meshes and multiple measurement series.
  4. Optimization Levers
    From a Starfleet engineering standpoint, the following optimizations are strategically valuable:
    • Reduce polycount where possible.
    • Remove unnecessary vertex attributes (extra UV channels, vertex colors, unused bone weights, etc.).
    • Consolidate submeshes to reduce draw-call and buffer overhead.
    • Where feasible, utilize LODs (Level of Detail) to reduce complexity for distant objects.
    Every 1 MB of mesh mass removed translates to ~3 MB of VRAM saved.

In brief: VRAM is a finite resource in this sector of the galaxy, and mesh mass directly determines how quickly it is consumed.

10. Final Assessment

Based on the data and computations presented in this report, the final conclusion for Starfleet records is:

The elevated VRAM usage observed in Stellaris with ST: New Horizons is primarily a consequence of the engine’s resource management strategy combined with the total volume of mesh assets, rather than a few faulty or newly added models.

Both vanilla and ST:NH exhibit an almost identical scaling factor of approximately 3 MB VRAM per 1 MB of mesh data on disk, derived from independent measurement series.

The behavior is therefore systemic and predictable, not anomalous.

For mod teams, this means that VRAM optimization is less about hunting a single malfunctioning component and more about holistic resource engineering: managing total mesh mass, simplifying assets where possible, and respecting the engine’s inherent 3:1 inflation factor.

Starfleet would summarize it as follows:

“The simulation is operating within expected parameters. The problem is not that it is broken – the problem is that it is honest about the cost of detail.”

End of report.

Post Views: 343
Scroll to Top