arXiv CSopen access

GS-NFS: Bandwidth-adaptive Streaming of Dynamic Gaussian Splats and Point Clouds

GS-NFS: Bandwidth-adaptive Streaming of Dynamic Gaussian Splats and Point Clouds∗ Rajrup Ghosh Haodong Wang Haoran Hong Eduardo Pavez Amartya Chaudhuri Weiwu Pang Harsha V. Madhyastha Antonio Ortega Ramesh Govindan University of Southern California [email protected] learned by training on a set of camera images capturing a scene from multiple perspectives. For this reason, we refer to the set of Gaussians and their attributes as a 3DGS model. More precisely, a 3DGS model is a collection of 𝑁 3D Gaussians, each with the following attributes: • Mean (∈ R3 ) represents the position of the Gaussian in 3D space (i.e., the center of the ellipsoid). • Scales (∈ R3 ) define the size of the ellipsoid along its three axes. • Rotation (∈ R4 ) defines the orientation of the ellipsoid in 3D space, typically represented as a quaternion. • Opacity (∈ R) represents the transparency of the Gaussian. • Colors: In 3DGS, spherical harmonics (SH), which are functions defined on a surface, represent view-dependent color, capturing realistic lighting effects, material properties, and reflections. Each SH function is represented by three coefficients corresponding to three colors (RGB). The coefficients of a degree 𝑑 = 0 SH—the DC coefficients—represent the overall color of the Gaussian. Higher degree (𝑑 > 0) AC coefficients capture more complex lighting and shading effects. A common choice of SH degree is 3, which results in 48 SH coefficients per Gaussian. Given a 3DGS model and a viewpoint, a rendering algorithm [18] produces an image of the view of the scene from the given perspective. While training a 3DGS model can take minutes, rendering only requires milliseconds. Dynamic 3DGS. A sequence of 3DGS frames constitutes a dynamic 3DGS video, often referred to as 4DGS (time being the fourth dimension). In this paper, we focus on delivery of 4DGS content. This delivery is challenging, because each 3DGS frame can be large. Each Gaussian requires about 236 bytes to represent its attributes. 3DGS frames with a million Gaussians are not uncommon, so a single frame can be 236 MB in size. By contrast, a single frame of 4K UHD video requires 24-30 MB, an order of magnitude less.

arXiv:2606.05650v1 [cs.MM] 4 Jun 2026

Abstract Dynamic 3D Gaussian Splatting (3DGS) holds great promise as a 3D video streaming technology since it can represent complex 3D scenes with high fidelity. In this approach, every frame in a 3D video represents the environment as a collection of Gaussians with position and other attributes such as scale, rotation, opacity, and color. Frames capture fine details, permit views from any arbitrary perspective, but are an order of magnitude, or more, larger than 2D video frames. A line of recent work has explored how to compress dynamic 3DGS frames, but these approaches are often slow, in part because their compression techniques are not amenable to efficient acceleration. GS-NFS accelerates dynamic 3DGS compression and decompression on a GPU, to the point where it can encode and decode at full frame rate. It achieves this by developing novel GPU-based parallelizations of existing algorithms for encoding both positions and attributes of Gaussians. As a result, it is 1-2 orders of magnitude faster than the state-of-the-art in encoding and decoding a frame, while offering competitive compression performance and rendering quality.

1

Introduction

Video over the Internet has effected societal and economic transformations. A technology with potentially similar transformative power, 3D video, is on the horizon. In 3D video, each frame depicts a representation of a scene in three dimensions, and viewers can view the scene from any perspective. This technology will enable entirely new ways of viewing sporting events, and new modes of instruction delivery, as well as new visual story-telling paradigms. 1.1

Gaussian Splatting

At the core of any 3D video technology is a technique to represent a 3-D scene. While many representations exist, 3-D Gaussian Splats [18] (or 3DGS) have been the subject of recent research interest. 3DGS represents a scene as a collection of 3-D Gaussians. Each Gaussian represents a small, ellipsoidal volume, and is defined by its position in 3-D and a set of attributes. The Gaussians and their attributes are

1.2

4DGS Compression

To reduce the size of 4DGS, recent work has explored compression techniques. In addition to reducing size, compression can be used to encode 4DGS at different bitrate levels for streaming, as for 2D video. Two complementary approaches have emerged (§6 discusses related work in detail).

∗ Patent Pending.

1

GS-NFS Compression

GS-NFS Decompression

SH Decorrelation (§4)

Quantization (§3.4)

Entropy Coding: RLGR (§3.4)

Attribute Codec

Octree Decoding (§2.3)

Entropy Decoding: RLGR (§3.4)

Dequantization (§3.4)

Position

RECEIVER

RAHT Encode (§3.3)

Position Bitstream

Color (DC+AC)

Training Views

RAHT Prelude (§3.2)

Scales, Rotation, Opacity

Entropy Decoding: ANS (§2.3)

Attribute Bitstream

Trained 3DGS Frame

Position Codec Entropy Coding: ANS (§2.2)

Compressed Bitstream

Position

Voxelize + Merge(§2.1)

Octree Encoding (§2.2)

Compressed Bitstream

SENDER

3DGS Training (QUEEN or V3)

Position Codec Morton Coding (§2.2)

Morton Codes

RAHT Prelude (§3.2) All attributes

RAHT Decode (§3.3)

Inverse SH Decorrelation (§4)

Attribute Codec

Reconstructed 3DGS Frame

Novel View Synthesis

Figure 1: GS-NFS Architecture. Blocks in yellow are GPU-resident components.

During-training compression techniques reduce information in a variety of ways. QUEEN [10], 4DGC-Pro [49], and CompGS++ [23] reduce the number of Gaussians by using temporal prediction between key frames and their immediately following frames. A frame following a key frame is represented using residuals—differences with respect to the key frame. Other approaches exploit human tolerance for small color distortions. Vega [19] compresses SH (color) coefficients aggressively by first grouping semantically-related Gaussians, then training an MLP for each Gaussian group. QUEEN [10] and 4DGC-Pro [49] also train a quantizer that can learn optimal quantization levels for SH coefficients. Quantization reduces the number of bits required to represent SH coefficients at the expense of information loss. Post-training compression techniques take a sequence of 3DGS frames as input and encode Gaussian attributes using 2-D or 3-D video codecs. For example, V3 [44] encodes Gaussian attributes in images and compresses the image sequence using a H.264 codec. MesonGS [46] and LTS [39] extend point-cloud compression techniques, such as G-PCC [35] or Draco [1], to compress 4DGS. Post-training compression has two advantages: (a) it can be faster than during-training compression ([10] reports about a 20% increase in training time with a during-training quantizer), and (b) it can help encode 4DGS videos at different bitrates without re-training. 1.3

to find the best quality to encode a video, by repeatedly encoding and decoding frames at different qualities. A fast encoder/decoder like GS-NFS’s can enable similar optimizations for 4DGS. Third, recent work in feed-forward 3DGS networks [50] can generate Gaussian frames within tens of milliseconds. This can generate Gaussian frames at nearly full frame rate, and GS-NFS can help encode and transmit these frames in real-time. Approach. To achieve this goal, GS-NFS uses a compression approach similar to a point-cloud compression technique, G-PCC [35]. This is a more natural starting point than the 2D compression used in V3 [44], since a 3DGS frame’s representation resembles that of a point-cloud. The latter contains a set of points, each with one or more attributes; 3DGS is similar, except that each Gaussian has more attributes (§1.1). Next, we describe the G-PCC pipeline for encoding 3DGS frames; MesonGS [46] has used such an approach. G-PCC [35]’s encoder takes a set of positions and associated attributes as input, then serializes (produces a bitstream) this set for transmission. Its decoder reconstructs the positions and attributes from the bitstream. To do this, G-PCC (a) encodes positions and associated attributes in such a manner that they can be decoded efficiently, and (b) compresses these encodings (either with or without information loss) to ensure bandwidth and storage efficiency. G-PCC encodes position and attributes using qualitatively different approaches. It represents positions of Gaussians using a spatial data structure, an octree. Usually, 3DGS Gaussians are spatially sparse, so not all parts of the octree are occupied. G-PCC serializes the octree such that the bitstream only contains information for occupied octree parts. For attributes, G-PCC provides several alternatives. We use Region-Adaptive Hierarchical Transform (RAHT [6, 33]), which organizes the Gaussians into a hierarchy of levels and predicts attributes at finer levels from attributes at coarser levels. The output of RAHT is a set of coefficients, which can be quantized (this introduces loss) and then entropy-coded (a lossless step that removes redundancy). G-PCC’s decode pipeline inverts these operations, deserializing Gaussians from the encoded bitstream. Unfortunately, G-PCC and MesonGS have high encode and decode times (§5.2). GS-NFS achieves frame-rate encode/decode by

Approach, Challenges, and Contributions

Goal. We present GS-NFS (or GS-NFS)1 , a post-training compression method for 4DGS which can encode and decode at full frame-rate, 30 frames per second (fps). It is also mobilefriendly; on a mobile GPU, it can decode some 4DGS sequences at 25 fps. No prior work on post-training compression has achieved full frame rate encode and decode. Full frame-rate decoding is obviously useful; without that, it will not be possible to play 4DGS videos at frame rate. We argue that full frame-rate encoding is useful for three important reasons. First, for on-demand streaming, it will be necessary to encode 4DGS videos at different bitrates. At scale, an efficient encoder can reduce dollar costs significantly for encoding in the cloud. Second, today, 2D video providers use per-title encode optimization [14]. This approach seeks 1 NFS, or Need for Speed, is a popular car racing game.

2

running the entire encoding and decoding pipeline on a GPU . Beyond accelerating encoding, executing the encoder on a GPU is efficient when the encoder takes input from a training method that emits 3DGS frames. These frames are already in GPU memory, since 3DGS training requires a GPU, thereby avoiding memory copy costs. Challenges and Contributions. Unfortunately, accelerating G-PCC’s algorithms on a GPU is non-trivial. Unlike 2D video frames, where pixels exhibit regularity, 3DGS training can produce irregularly-spaced Gaussians. Mapping this to a single-instruction, multi-threaded (SIMT) GPU is difficult. CPU-resident algorithms for octree encoding and RAHT manage this irregularity by imposing a spatial hierarchy on the data. Unfortunately, GPUs are a poor fit for computations on hierarchical data. Traversing the hierarchy requires following pointers; this pointer chasing is known to be highly inefficient on a GPU, since if the referenced memory is not in the cache, all warps in a GPU thread must wait for the data to be loaded (sometimes from relatively slow DRAM), resulting in poor performance. This problem is well-known for GPUbased computations on irregular data in general [36, 47], and for parallelizing point-cloud algorithms in particular [22, 51]. Against this backdrop, GS-NFS is, to our knowledge, the first post-compression encoder/decoder for 4DGS in which all components (Fig. 1) execute on a GPU and can encode and decode at full frame rate. To achieve this, the paper makes the following novel contributions: • A GPU-based parallelization of octree encoding (§2). • A GPU-based parallelization of RAHT (§3). • A technique to improve the compression of 4DGS (§4). Our evaluations (§5) on two different popular 4DGS datasets demonstrate that GS-NFS: (a) can encode an order of magnitude faster than the state-of-the-art; (b) dominates MesonGS [46], a GPCC [42] variant modified for 4DGS, and LTS [39] both in quality and compression performance, and performs comparably or better than V3 [44] on large scenes; (c) can decode 4DGS at up to 25 fps on a Jetson Orin; and (d) can encode and decode point clouds and live 4DGS videos at full frame rate, a capability that, to our knowledge, has not been demonstrated in the literature.

2

3

24 25 26 27 28 29 30 31

Compressed byte stream

00011000

4

Level 1

33

35 36

11111111

Level 2

01011000

Figure 2: An example of an octree with some occupied voxels.

Then, it maps each Gaussian’s 3-D position to one of the cubes, by quantizing the position coordinates to use 𝐽 bits. Multiple Gaussians might fall into a single voxel; GS-NFS replaces those Gaussians with a single Gaussian whose position is at the center of the voxel and other attributes are the average of the original Gaussians.2 The Octree Data Structure. After voxelization, many voxels are often empty and only a small fraction of voxels are occupied by Gaussians. An octree [26] efficiently encodes the positions of occupied voxels to exploit sparsity and spatial locality. It recursively partitions the 3D space into octants (8 equally-sized child nodes), creating a tree structure where each node represents a cubic region of occupied space. Consider the octree in Fig. 2. The root node represents the entire 3D space, and its 8 child nodes represent the 8 equally-sized children. The child nodes that are occupied (i.e., contain at least one Gaussian) can be further subdivided into their own child nodes. The process continues until we reach a leaf node that contains a single occupied voxel. This structure can efficiently encode occupancy. Each internal tree node uses a byte, where each bit indicates whether the corresponding child node is occupied (1) or empty (0). For example, if the fourth and fifth bits are set to 1, it means that the fourth and fifth child nodes are occupied, while the rest are empty (Fig. 2). Recursive Octree Encoding. 3-D compression must construct the octree (i.e., determine octants and their occupancy), then encode (i.e., serialize) the octree into a bitstream. Both of these can be accomplished with a single sequential level-order traversal from the root to the leaves; a reference implementation of G-PCC [27] uses this approach. This algorithm starts from the root, determines the occupancy of its child octants, then writes out the occupancy byte of the root. It then recursively repeats the process for each child in a fixed sequence (i.e., if children are numbered 0..7, it visits the children in that order), and stops when all occupied voxels form the leaves. The output of this algorithm is a sequence of bytes representing occupancy at various nodes of the octree. The total

GPU-Accelerated Octree Encoding/Decoding

We first describe our GPU-accelerated octree encoding algorithm, which encodes Gaussian position attributes efficiently. 2.1

Level 0

0

Background

Voxelization. Gaussians can be positioned irregularly in space, and all 3-D compression algorithms first voxelize Gaussian positions to regularize the data. Voxelization discretizes the cuboid bounding all the Gaussians into a regular grid of 2 𝐽 × 2 𝐽 × 2 𝐽 cubes, where 𝐽 is a voxelization parameter which controls the resolution of the 3DGS frame.

2 This may not be ideal for small 𝐽 , but suffices for the range of 𝐽 we consider

in this paper.

3

Works Zhou [51]

GROOT [22]

Quote “Creating an octree for point clouds directly on the GPU, however, is very difficult, mainly because of memory allocation and pointer creation.” “While the tree structure efficiently handles the sparsity of 3D data and subdivides only the volumes where the point exists, the irregularity requires traversing the serialized byte stream and recursively calculating the child node geometry. The exact positions that represent intermediate nodes depend on the occupancy of their ancestors, which cannot be parallelized.”

Figure 3: This figure shows the Morton codes of the occupied voxels in Fig. 2.

Another line of work [17, 41, 51] has achieved GPUaccelerated parallelization of octree construction. They linearize the positions in 3D to a 1D list using a space-filling curve (the Morton code, described below) while preserving spatial locality [3]. Thus, the generated octree is not explicitly represented as a tree structure, but rather as arrays of indices in the space-filling curve for each node at a certain level. In these approaches, however, encoding is still sequential, since that requires an in-order tree traversal. GS-NFS uses a similar space-filling curve, but parallelizes both construction and encoding on a GPU. Morton Codes. The key to our GPU-accelerated octree encoder is to never build explicit tree pointers. Rather, we represent each occupied voxel by its Morton code [3], which is a bit-interleaving of its integer voxel coordinates. For a voxelized coordinate 𝑣ˆ = (𝑥, 𝑦, 𝑧) ∈ {0, . . . , 2 𝐽 − 1}3 , the Morton code is a bit string 𝑧 𝐽 −1𝑦 𝐽 −1𝑥 𝐽 −1 . . . 𝑧 0𝑦0𝑥 0 where 𝑥𝑏 , 𝑦𝑏 , 𝑧𝑏 are the 𝑏-th least-significant bits of 𝑥, 𝑦, 𝑧. For example, consider the voxelization shown in Fig. 3, which depicts a 4 × 4 × 4 voxel grid (𝐽 = 2) with 11 occupied voxels. The occupied voxel with ID 33 has coordinates (1, 0, 2) so its Morton code is 100001. The Morton code is obtained by first taking the most significant bits of the 3 coordinates (100) in the order from 𝑧 − 𝑥, followed by the next most significant bits (0 for the z-coordinate value of 2, 0 for the y-coordinate value of 0, and 1 for the x-coordinate value of 1), and so on. The Morton code has three properties crucial for GPUacceleration of octree construction, encoding, and decoding. First, it preserves spatial locality: when we sort the voxels by their Morton code, voxels near each other in space will be near each other in the sorted order [3]. For example, if in Fig. 3, the voxel with ID 33 and coordinate (1, 1, 2) is also occupied, it would have the Morton code 100011. This differs from the Morton code of its neighboring voxel (1, 0, 2) only in the last 3 digits. This property ensures memory locality if voxels are laid out in GPU memory in Morton order, and avoids non-local memory access overheads. Second, the Morton code for the parent of a voxel is a prefix of the voxel’s Morton code. In Fig. 3, the parent of (1, 0, 2) (ID 33) has the code 100, which can be obtained by shifting the voxel’s Morton code three bits to the right. Conversely, to obtain the Morton code of, say, the 5th child of an octree node, we simply append 101 to the node’s Morton code. Third, given the Morton code for a voxel, we can obtain its voxelized coordinates using the definition of the Morton code.

Table 1: Parallelization challenges for octree encoding reported in prior work.

number of bytes in this sequence is proportional to the number of occupied voxels 𝑁ˆ 𝑣 , which is often more compact than recording the occupancy of all 23𝐽 voxels. In Fig. 2, for example, only two children of the root node (the 4th and the 5th) contain at least one occupied voxel, so its occupancy byte is 00011000. This forms the first byte of the output bitstream. The second byte corresponds to the root’s 4th child, all of whose children are occupied, so its occupancy byte is 11111111, and so on. 2.2

GPU-accelerated Octree Encoding

GS-NFS parallelizes octree construction and encoding on the GPU. Before describing this algorithm, we explain why this is a challenge, and how prior work has attempted to accelerate octree construction and encoding. The next subsection describes GPU-accelerated octree decoding. Challenges. Recursive octree construction is inherently sequential. State-of-the-art point cloud compression algorithms [1, 2, 35] implement sequential CPU-based octree construction and encoding. Constructing the octree requires traversing the tree top-down and creating nodes and pointers. This is difficult to efficiently parallelize on a GPU since the memory layout of the tree can be irregular, and treetraversal might require pointer-chasing, resulting in GPU thread stalls while waiting for memory accesses to complete [20, 22, 51]. Generating the occupancy bitstream also requires a tree traversal in level-order and pointer-chasing to determine the occupancy byte of a node depending on existing children, which can be inefficient on a GPU. Table 1 includes quotes from prior work [22, 51] that illustrate the difficult of parallelizing octree encoding. Prior Work on Parallelization. One line of work has explored CPU parallelism for octree construction and encoding. ViVo [12], MeshReduce [15], and MetaStream [11] use coarsegrained CPU parallelism by partitioning the 3D points into separate blocks, generating the octree encoding independently for each block and concatenating these encodings. Others [20, 22] employ slightly more sophisticated hybrid CPU-GPU strategies. For example, Groot [22] sequentially constructs the octree top-down up to a certain depth 𝑑, then generates encodings in parallel for each occupied voxel (on a GPU) by traversing the tree bottom-up up to level 𝑑. 4

In our example, given the code 100011, the first coordinate is obtained by concatenating every third bit starting from position 3, the second coordinate by doing so from position 2, and so on, resulting in the coordinate (1, 1, 2). Thus, if given the Morton code for an occupied voxel, it is an 𝑂 (1) operation to determine its parent. Conversely, if all octree nodes are sorted in Morton order, then a parent can in an 𝑂 (1) operation determine its child’s Morton code, and look up its occupancy status. Finally, in 𝑂 (1), given a node’s Morton code, we can obtain its voxel coordinates. Before explaining how we use these properties to construct, encode and decode octrees, we describe how we parallelize voxelization (§2.1). This is important since voxelization precedes octree construction. We require all steps in GS-NFS to be GPU-resident to avoid data movement costs (§1.3). Voxelization. Voxelization (a) discretizes Gaussian positions and (b) merges Gaussian attributes (by averaging them) of Gaussians at the same discretized positions. The input to this step is an 𝑁 × 𝐶 tensor for a 3DGS frame with 𝑁 Gaussians, with each Gaussian having 𝐶 attributes. Step (a) is simple to parallelize on a GPU by launching one thread per Gaussian, which computes the voxel coordinates (§2.1) of the Gaussian. This step also computes the voxel’s Morton code, and creates an array sorted by the Morton code that contains a pointer to the Gaussian. We use a 64-bit Morton code to support octree depths up to 𝐽 = 21, which is sufficient for all scenes of interest [46]. If 𝐽 ≤ 21, we set to zero the unused mostsignificant bits in the Morton code. In this array, Gaussians belonging to the same voxel are contiguous; we identify these clusters using standard PyTorch operations. Then, we launch one GPU thread for each cluster to average the attributes of Gaussians in that cluster. The output of this process is an 𝑁 𝑣 × 𝐶 tensor, where 𝑁 𝑣 is the number of occupied voxels. This is sorted by Morton order, and forms the input to the next step. Octree construction. In contrast to the recursive top-down approach (§2.1), our construction identifies, bottom-up, occupied parents of occupied voxels, and occupied internal nodes up the octree (Fig. 2). Let 𝐿 𝐽 be an array of occupied voxels, sorted by Morton order, obtained directly from the input tensor. We launch one GPU thread per occupied voxel; this thread computes the parent’s Morton code and writes this to a new list 𝐿 𝐽 −1 . This array contains parents of occupied voxels in Morton order, but can have duplicates, since multiple occupied voxels can have the same Morton code. We use CUDA’s unique primitive to compact duplicates in parallel, so 𝐿 𝐽 −1 has exactly one instance of an occupied parent. We can now repeat this process to find the next-level occupied parents (i.e., parents of occupied parents) up to the root level. The output of this process is a list of Morton codes for the occupied nodes at each level, i.e., 𝐿0, . . . , 𝐿 𝐽 , where

𝐿0 has the root node, 𝐿 𝐽 has the leaf nodes, and 𝐿𝑑 has the occupied nodes at depth 𝑑. Bitstream generation. From these lists, the encoder must emit the octree occupancy bitstream. Each internal node contributes exactly one occupancy byte, whose 𝑖-th bit is set if child 𝑖 exists. This step requires us to compute the occupancy byte for each internal node. To compute this, a node must: (a) determine the Morton codes of its children and (b) identify which children are occupied. Given a parent code 𝑝𝑚 ∈ 𝐿𝑑 , the Morton prefix of its children can be obtained by 𝑐𝑚 = 𝑝𝑚 ≪ 3. The eight possible children are therefore the contiguous code range [𝑐𝑚 , 𝑐𝑚 + 7]. To compute the occupancy byte for 𝑝𝑚 , we need to check which of these eight candidate child codes exist in the child list 𝐿𝑑+1 . This requires searching for the child codes in 𝐿𝑑+1 . We make 2 observations that make this search efficient. First, all children with Morton codes in the range [𝑐𝑚 , 𝑐𝑚 +7] must appear contiguously in the sorted list 𝐿𝑑+1 . Second, we can perform a binary search for the first occupied child code ≥ 𝑐𝑚 in 𝐿𝑑+1 , since that listed is sorted. To compute the occupancy bytes for all octree nodes, we use a top-down approach. We compute occupancy bytes for nodes in 𝐿𝑑 before doing so for nodes in 𝐿𝑑+1 . At level 𝐿𝑑 , our octree encoder launches a custom CUDA kernel3 with one thread per parent node 𝑝𝑚 in 𝐿𝑑 . It initializes 𝑝𝑚 ’s occupancy byte to 0. Then, the thread for 𝑝𝑚 performs the following steps:. (i) compute 𝑐𝑚 = 𝑝𝑚 ≪ 3; (ii) binary-search 𝐿𝑑+1 to find the first occupied child code ≥ 𝑐𝑚 ; (iii) scan forward over at most 8 entries until the child code exceeds 𝑐𝑚 + 7; (iv) set bit for every child code 𝑐𝑚 found. The thread then writes its occupancy byte to a known location in the GPU buffer. We present the detailed algorithm in Algorithm A.1. At the end, all the occupancy bytes are written in order, similar to Fig. 2. To improve compression efficiency, GS-NFS then runs a GPU-based entropy encoder (Fig. 1), ANS [5]. 2.3

GPU-Accelerated Octree Decoding

Inputs and Output. The input to this algorithm is a sequence of occupancy bytes in the octree. We obtain this from the output of the ANS entropy decoder. The output of the algorithm is a list of voxelized positions of occupied voxels. Each such position corresponds to a Gaussian, whose attributes we obtain as described in §3. This algorithm also needs to know 𝐽 , the depth at which the 3DGS frame was encoded, and the number of occupied nodes 𝑛𝑑 at each level 𝑑 in the tree. Such information is encoded in the bitstream as metadata. Prior work. GROOT and [20] try to decode lower levels of the octree in parallel on a CPU, but most tree levels are still 3 For efficiency, when necessary, we replace PyTorch operations with custom

CUDA kernels to improve encoding speed. 5

decoded sequentially on the CPU top-down. We know of no other work that has GPU-accelerated decoding. Octree decoding. Our octree decoding algorithm relies on properties of the Morton code. We note that the first byte is the occupancy byte of the root. From this, we can determine (a) which children are occupied, and (b) the Morton code of the children (both 𝑂 (1) operations). We can repeat this process to obtain the Morton codes of all nodes in the tree, and eventually, the Morton codes of all occupied voxels. From these, we can obtain the voxelized positions of the occupied voxels using the definition of the Morton code. To parallelize this, we use a top-down level-synchronous approach (similar to the encoder), where, at each level 𝑑, we launch one thread per octree internal node. For level 𝑑, we can determine from the metadata where the occupancy bytes for that level start and end. But each node at that level can have a variable number of occupied children. To determine the offset of the 𝑘-th occupied node, we first create an array per internal node that counts the number of occupied children (using the population count CUDA primitive), then do a CUDA prefix sum on that array to find the offset of this node’s children in the occupancy bytes at level 𝑑 + 1. The 𝑘-th occupied node writes the Morton codes of its occupied children into a separate array starting at the corresponding offset. Then, the decoder launches one thread for each occupied thread at level 𝑑 + 1, and the process repeats. After processing all levels, the decoder’s output is a list of Morton codes for the leaf nodes, which correspond to the occupied voxels. The decoder launches a final CUDA kernel to decode the Morton codes back into integer voxel coordinates by reversing the bit interleaving. §C contains a detailed listing of this algorithm.

3

Octree

Octree Node IDs

3

8

3

1

4 2

2

Level 1

3

4

Transform along y-axis Transform along x-axis

8

8

Transform along z-axis

2

2

1

2 1

1

RAHT weights propagate additively

1

1

1

1

1

1

1

1

1

1

1

Level 2

24

25

26

27

28

29

30

31

33

35

36

Leaf nodes have RAHT weight = 1

Figure 4: Example to illustrate the RAHT algorithm.

to voxels, and in Fig. 4 we only show branches in the binary tree leading to occupied voxels, for simplicity. If a node has a sibling (e.g., nodes 35 and 36 in Fig. 4), RAHT decomposes the attribute into: (1) Low-frequency Coefficient: A weighted average representing coarse signal information. (2) High-frequency Coefficient: A weighted difference representing the signal details. More precisely, if two siblings 𝑙 and 𝑟 have attribute values 𝑎𝑙 and 𝑎𝑟 , then computing these coefficients requires a 2 × 2 matrix-vector multiplication:  0 √ √   1 𝑎 𝑤𝑙 𝑤 𝑎𝑙 √ √ 𝑟 =√ , (1) 𝑎1 𝑤 𝑤 − 𝑎 𝑤𝑙 + 𝑤𝑟 𝑟 𝑟 𝑙 In this equation, 𝑎 0 represents the low-frequency (coarse) coefficient, 𝑎 1 the high-frequency coefficient, and 𝑤𝑙 and 𝑤𝑟 represents weights associated with 𝑎𝑙 and 𝑎𝑟 respectively. The weight at any node is the number of occupied voxels in the octant below that node; attributes at leaf nodes have unit weights. Fig. 4 shows node weights next to the node. RAHT propagates the low-frequency coefficient to the parent, while storing the high-frequency coefficients at the right sibling. (If a node does not have a sibling such as node 33, it passes its attribute value up to its parent). RAHT then repeats this procedure level by level, bottom-up, on this tree. At the end of this computation, the octree root stores the low-frequency component, and internal nodes and leaves store high-frequency coefficients.4 Smoothly varying spatial signals (e.g., point clouds can have smoothly varying color, just like images) have near-zero high-frequency coefficients, especially close to the leaves, which can be quantized and entropy-coded, resulting in significant compression. In GSNFS, we use RAHT to encode all 3DGS attributes (§1.1) other than positions. RAHT decoding inverts this operation; for brevity, we discuss only the RAHT encoder and leave the decoder (inverse-RAHT) to §D.

GPU-Accelerated Attribute Encoding/Decoding

In this section, we describe how we GPU-accelerate the encoding and decoding of Gaussian attributes, such as opacity, scale, rotation, and spherical harmonics. 3.1

Level 0

11

Background: RAHT

Region-Adaptive Hierarchical Transform (RAHT) is an algorithm for encoding and decoding the attributes of sparse, spatially non-uniform data (such as point clouds [6] and 3DGS frames). The algorithm is complex to explain in its entirety, so we use an example to explain the algorithm; details can be found in [6, 33]. To further simplify the description, we describe how it encodes a single attribute, say opacity. RAHT exploits the octree structure derived from voxel positions (Fig. 4). It operates on a binary tree derived from the octree; in this binary tree, each octree level is represented by 3 levels in the binary tree, each of which corresponds to one of the directional axes. The leaves of the tree correspond

4 This computation can be intuitively thought of as an extension of the Haar

wavelet transform to a sparse 3D grid [6].

6

for octree construction (§2.2), for example, which performs computations only occupied nodes at each level. This suggests that we can compute RAHT coefficients using the following design elements from those algorithms. (a) Those algorithms use properties of Morton codes to mitigate compute stalls due to pointer chasing. (b) They proceed sequentially level-by-level bottom-up or top-down, but within a level, they launch one GPU thread for every node in the tree involved in the computation. (c) The set of nodes at a level involved in the computation is of variable length, so these algorithms employ PyTorch [32] operations to convert fixed length vectors to variable length ones. For example, the octree construction algorithm first creates a list of all occupied parents, then uses the unique operation to identify exactly the set of nodes at the next higher level involved in determining occupied nodes. Our second observation is that P-RAHT is an ideal starting point for parallelization. In particular, the pre-computed lists from the RAHT prelude greatly simplify applying the design elements described above. Our third observation is that GPUs allow us to trivially parallelize RAHT coefficient computation across attributes. We can simply vectorize the attributes, and compute the coefficients in one bottom-up pass. Computing RAHT coefficients on the GPU. GS-NFS computes RAHT coefficients bottom-up, exactly like P-RAHT. Unlike P-RAHT, at each level, it launches multiple GPU threads. Specifically, at level ℓ, it launches a GPU kernel with one thread per entry in the list 𝐼 ℓ . For example, at the lowest level in Fig. 4, GS-NFS will launch 11 threads, and at the next level up, 7. Only threads whose flag 𝐹 ℓ is valid execute the 2 × 2 transform; each such thread reads indices of a sibling pair (current and next element in 𝐼 ℓ ), looks up their weights in 𝑊ℓ , and then applies Eq. 1 to the attributes. Parallelizing the RAHT Prelude. At each step ℓ, GS-NFS maintains the current active list 𝐼 ℓ as a flat GPU tensor of indices. We launch one GPU thread per element of 𝐼 ℓ to compute 𝑊ℓ and 𝐹 ℓ . Each thread compares the Morton code of its current element with the next element (adjacent in Morton order) to decide whether they form a sibling pair. After 𝐹 ℓ is computed, GS-NFS obtains the next active list 𝐼 ℓ+1 by removing right siblings. It implements this efficiently using boolean shift and masked select of tensors which are available in PyTorch (Alg. A.5). The output of this is a compacted list containing exactly the set of nodes at ℓ + 1 that should run the RAHT coefficient computation at that level. Especially for accelerating RAHT on a mobile GPU, we have found it essential to implement some of these steps using CUDA ( (§5),

3.2 Background: A Re-formulated RAHT Algorithm Pavez et al. [33] describe a re-formulation (henceforth PRAHT) of the original RAHT algorithm [6] that exploits properties of the Morton code. P-RAHT takes as input occupied voxels and their associated Morton codes. It pre-computes, in a step called the RAHT prelude, the constructs needed for the hierarchical RAHT computation, the sibling relationships and the node weights, since these are a function of voxel occupancy alone, not of the attribute. Then, it re-uses these when encoding each attribute. The RAHT prelude. This step computes three lists at every level ℓ ∈ {1, . . . , 3𝐽 }: (i) an index list 𝐼 ℓ indicating those nodes in the binary tree at level ℓ that are either left siblings, or singletons (those with no occupied siblings); (the binary tree in Fig. 4 shows only the nodes in these lists) (ii) a weight list 𝑊ℓ for those nodes (indicated by numbers inside nodes in Fig. 4, and (iii) a flag list 𝐹 ℓ indicating which nodes are left siblings (not shown in the figure for brevity). P-RAHT computes these lists bottom-up. Consider a node 𝑛 at level ℓ. Its weight is the sum of the weights of its children at level ℓ + 1. If either of its children is in 𝐼 ℓ+1 , node 𝑛 must be in 𝐼 ℓ . Finally, if 𝑛’s sibling at level ℓ is also in 𝐼 ℓ , it is the left sibling if it has a lower Morton code. For example, the rightmost node at the second level from the bottom has a weight of 2, because its children are both occupied. For that reason as well, it belongs in the 𝐼 ℓ list for that level. But, it does not belong in the corresponding 𝐹 ℓ list, since it is not the left sibling at that level. Computing RAHT Coefficients. Using these lists, P-RAHT computes the RAHT coefficients using another bottom-up pass for each attribute. If a node 𝑛 at level ℓ is a left sibling (i.e., its flag is set in 𝐹 ℓ ), then it computes the low-frequency and high-frequency coefficients using Eq. (1). Nodes 24 and 35 in Fig. 4 are examples of left siblings. It then passes the low-frequency coefficient to its parent and stores the highfrequency attribute in its right sibling. For this, it uses the pre-computed weights in 𝑊ℓ . If 𝑛 is a singleton, such as node 33 in Fig. 4, it simply passes its attribute to its parent. 3.3

GPU-Accelerated RAHT

Inputs and Outputs. GS-NFS’s GPU-accelerated RAHT takes as input occupied voxels, their Morton codes, and the attributes of the merged Gaussian in the voxel. It outputs RAHT coefficients for all attributes. Key Ideas. Our GPU-accelerated RAHT relies on three observations. First, we observe that the basic RAHT algorithm is similar to the octree construction, encoding and decoding algorithms (§2). RAHT proceeds bottom-up on a tree, performing one or more computations at some but not all nodes (e.g., only siblings), at each level in the tree. The same is true 7

After obtaining the RAHT coefficients for each attribute, GS-NFS quantizes these coefficients. Quantization trades off visual quality by reducing the number of bits required to represent a coefficient. We quantize coefficients of different 3DGS attributes to different levels, similar to [42, 46]. GSNFS uses dead-zone quantization [38], which is simple to implement on a GPU, using one thread per coefficient, and vectorizing the attributes. GS-NFS uses an entropy coder to efficiently serialize quantized coefficients into a bitstream. We use the Run-Length Golomb-Rice (RLGR) [25] entropy coder, which uses runlength coding for consecutive zeros, and Golomb-Rice coding for non-zero magnitudes using an adaptive parameter. RLGR is inherently sequential, but GS-NFS parallelizes this by dividing the vector of coefficients, and entropy coding blocks (e.g., 2K or 4K successive coefficients) using one GPU thread per block. This ensures fast entropy coding at the expense of a slight loss in compression efficiency. We have omitted a discussion of de-quantization and entropy decoding for brevity; GS-NFS also parallelizes this. Thus, in GS-NFS, all steps in octree and attribute encoding are GPU-accelerated.

4

KLT

1.00

1.00

0.75

0.75

0.50

0.50

0.25 0.00

0.25 0.00

Pearson correlation

RGB

Quantization and Entropy Coding

Pearson correlation

3.4

0.25

0.25

0.50

0.50

0.75

0.75

1.00

1.00

Figure 5: Heatmaps that plot Pearson correlation across SHs in RGB domain (left) and after YUV conversion and KLT (right).

heatmap of the Pearson correlation coefficients for the original RGB SH coefficients. On the right is the corresponding heatmap after applying RGB to YUV conversion followed by KLT; notice how the figure on the right has significant white-space (white corresponds to zero correlation). By decorrelating color across AC SH coefficients, KLT reduces redundancy, concentrates energy, and thereby improves compression. We apply KLT before RAHT (Fig. 1). KLT requires a matrix multiplication, which we implement on the GPU with minimal overhead.

5

Evaluation

In this section, we compare GS-NFS against the state of the art, using two popular 4DGS data sets.

Improving 4DGS Compression

5.1 In many 4DGS videos, especially those that generate SH coefficients of degree 3, SH coefficients dominate the size of each 3DGS frame. Some post-training compression techniques have realized this, and have developed specialized techniques to compress SH coefficients. For example, MesonGS [46] devises a vector quantization codebook for each frame, in order to compress SH coefficients. This is extremely computeintensive, so GS-NFS uses a different approach. In 3DGS, each SH function has 3 RGB color channels. GSNFS exploits the fact that RGB colors can be correlated [4]. It first transforms RGB to YUV for each SH function. In YUV, since Luma (Y) has more energy and it is more perceptually important than Chroma (UV), this transformation improves compression. GS-NFS applies this RGB to YUV transformation, a simple matrix multiplication, which is fast on a GPU, to all SH coefficients (both DC and AC). While RGB to YUV conversion is common in image and video compression, because 3DGS represents color with high dimensional SH coefficients, there are additional opportunities to remove redundancy. After YUV conversion, GS-NFS applies a decorrelating transform, Karhunen-Loève transform (KLT [34]), only to the AC coefficients (i.e., to SH coefficients of degree greater than 0). More specifically, we apply three different KLTs, one to each channel in YUV color space. The KLT effectively concentrates signal energy on the first few coefficients. Fig. 5 illustrates this. On the left is a

Methodology

Implementation. We have implemented GS-NFS in Python. It uses custom CUDA kernels for the octree encoder/decoder (§2), RAHT (§3), and RLGR (§3.4). It compresses position using the ANS entropy coder from NVIDIA’s nvCOMP library [5] and implements KLT decorrelation and quantization in PyTorch [32]; these run on the GPU. Most of the data and intermediate tensors use PyTorch. Hardware. Most experiments run on a PC equipped with an NVIDIA RTX 4500 Ada Generation GPU (24 GB VRAM), 128 GB system RAM, and Intel(R) Xeon(R) w7-2475X with 20 physical cores (40 threads with hyperthreading). Mobile decoding runs on an NVIDIA Jetson. Baselines. We compare GS-NFS against four post-training compression baselines: V3 -2D [44] maps Gaussian attributes to 2-D image stacks, one per attribute channel, and compresses the resulting images with a H.264 codec using x264 from FFmpeg [8]. It compresses each channel of attributes into a single MP4 stream, where frames for that attribute form a group of pictures (GOP), and a single quantization parameter (QP) controls the quality-size tradeoff. It splits the position of Gaussians into MSB and LSB, where QP for MSB is 0 (lossless) and QP for LSB is the QP passed to the encoder (default: 25). V3 -2D caps QPs for rotation and scale attributes to 22, and quantizes all other attributes (position LSB, color, opacity) with the same 8

QP (default: 25). It compresses each attribute channel using one call of the H.264 encoder, resulting in 62 MP4 files per GOP (default: 20). MesonGS [46] is a partly GPU-accelerated codec that uses an octree for geometry, RAHT and block quantization for attributes, vector quantization for higher-degree SH coefficients, and LZ77 for entropy coding. We use the authors’ default parameters. G-PCC [35] Wang et al. [42] use G-PCC to compress static 3DGS, and adapt octree depth for voxelization to preserve quality. This requires fine-tuning of Gaussians after voxelization to reach high quality. To obtain a baseline that directly extends G-PCC to 4DGS videos, we implement a simplified version of [42] (without adaptive voxelization and fine-tuning). The approach uses RAHT for color and opacity (lossy, depending on QP) and hierarchical neighborhood prediction for rotation and scale (lossless). LTS-Draco [39, 40] uses modified Draco to independently compress each 3DGS frame on the CPU. The number of quantization bits per attribute is configurable (default: 16 bits for all attributes, compression level 10). In each case, we use the implementations provided by the authors. Moreover, these baselines use qualitatively different compression techniques for 4DGS: 2D codecs [44], Draco [39], and G-PCC [42, 46]. Datasets. We evaluate on two widely-used 4DGS video datasets spanning diverse content types: HiFi4G (7 sequences) contains person-centric captures of actors performing various actions, with 200 frames per sequence. We use 3DGS models trained using V3 [44] with SH coefficient degrees 0..3 (∼120K–300K Gaussians per frame). Neural 3D Video (N3DV) (6 sequences) contains fullscene captures of indoor table-top activities with day and night lighting, each with 300 frames. We use models trained with QUEEN [10] (without its in-training compression) with SH degrees 0..2 (∼150K–400K Gaussians per frame). Metrics. For each approach, we report measures of: (1) visual quality based on PSNR computed on rendered test views of the decompressed frames against the uncompressed ground truth (we use the test views used by V3 and QUEEN); (2) per-frame encode and decode latency in milliseconds (ms); and (3) compression efficiency in terms of 3DGS frame size after compression. We describe the precise metrics below. 5.2

Pipeline GS-NFS V3 -2D LTS-Draco G-PCC MesonGS

N3DV (QUEEN) Enc. (ms) Dec. (ms) 23 370 400 8804 28996

21 290 158 6928 1096

HiFi4G (V3 ) Enc. (ms) Dec. (ms) 18 1098 156 6101 144953

14 341 91 3650 535

Table 2: Per-frame encode and decode latency (ms).

first frame of a sequence as the default setting for each approach. For instance, if, on the first frame of sequence 𝑆, V3 -2D has a PSNR of 𝑝, we find a parameter setting for GSNFS (using the technique described in §5.3) whose PSNR for the first frame on 𝑆 is close to 𝑝. This results in a pair-wise comparison between GS-NFS and each baseline. We use these settings to encode, decode, and estimate PSNR and compression sizes for every 10th frame5 of every sequence in the two datasets listed above. We do this primarily because some of the baselines [42, 46] have exceedingly high encode/decode latencies, rendering an exhaustive evaluation intractable. Then, we compute, for each sequence: (a) the average per-frame encode latency, (b) the average per-frame decode latency, (c) the average per-frame PSNR difference between GS-NFS and the baseline (the ΔPSNR), (d) average per-frame size ratio between GS-NFS and the baseline (the relative compression ratio, or RCR). 5.2.1 Encode-Decode Latency Table 2 summarizes per-frame encode and decode times aggregated across all sequences within each dataset. We do this because, within a dataset (e.g., HiFi4G), there is little variability in encode and decode times across sequences, since all sequences are person-centric. §A contains a more detailed breakdown. GS-NFS achieves ∼23 ms encode and ∼21 ms decode on N3DV, and ∼18 ms encode and ∼14 ms decode on HiFi4G— well under the 33 ms budget for 30 frames-per-second (fps). LTS-Draco, the next fastest baseline, is 9–17× slower than GS-NFS for encoding and 7–8× slower for decoding. Draco encoding and decoding could potentially be made faster using coarse-grained CPU parallelism [11, 12, 15], but this trades off compressibility. Though 2D video codecs are fast, V3 -2D’s several hundred milliseconds to encode decode, due to the overhead of calling video encoder sequentially for each channel6 ; It is 16–61× slower than GS-NFS for encoding and 14–24× slower for decoding. V3 -2D could offload H.264 encoding to an NVIDIA GPU using nvenc/nvdec [29]; however, nvenc allows only 8 parallel encoders on a desktop-class GPU [30],

Baseline Comparison

Methodology. This section compares GS-NFS against all baselines at a single operating point. For competing approaches, we select the default parameters for compression, such as QP, octree depth, bit-depth, etc., that we either found in the corresponding paper or source code. For GS-NFS, we use parameters that give us the same quality (PSNR) on the

5 For V3 -2D, we compute the size of a frame as the average size of the GOP

that it belongs to. 6 V3 -2D encodes and decode the full scene N3DV dataset faster than the HiFi4G person-centric dataset, because, on the former dataset, QUEEN does not produce degree-3 SHs. 9

Sequence

V3 -2D ΔPSNR (dB) RCR

Actor1 Actor2 Actor3 Actor4 Actor5 Actor6 Actor7 Mean

0.02 0.03 -0.01 -0.05 0.07 -0.07 0.02 0.00

0.52 0.31 0.64 0.56 0.53 0.81 0.50 0.55

-0.02 -0.03 0.01 -0.02 0.05 -0.18 -0.08 -0.04

2.00 2.11 1.74 1.77 1.60 2.07 2.05 1.91

-0.04 -0.04 -0.02 -0.07 -0.07 -0.09 -0.04 -0.05

3.01 3.05 3.18 2.84 2.91 2.87 3.01 2.98

-0.03 -0.01 0.05 0.01 0.01 0.01 0.00 0.01

4.91 5.08 4.52 4.98 5.06 4.66 4.77 4.85

cook_spinach 0.05 coffee_martini 0.39 cut_roasted_beef 0.06 flame_salmon 0.74 flame_steak -0.08 sear_steak -0.11 Mean 0.18

0.48 0.67 0.35 0.61 0.38 0.31 0.47

0.04 -0.06 -0.01 0.09 -0.03 -0.01 0.00

1.68 1.52 1.34 1.44 1.30 1.45 1.46

-0.19 0.01 -0.08 -0.02 -0.16 -0.17 -0.10

4.27 6.38 3.72 8.17 4.04 4.04 5.10

-0.02 -0.04 -0.19 -0.01 0.39 0.20 0.06

6.46 3.26 6.60 3.40 7.35 5.54 5.44

MesonGS ΔPSNR (dB) RCR

LTS-Draco ΔPSNR (dB) RCR

G-PCC ΔPSNR (dB) RCR

evaluated their approach on person-centric datasets, not on the larger scenes in this data set. We discuss this in greater detail in §5.3, where we show that this approach fails to achieve high quality on some N3DV sequences. However, V3 -2D has better compression performance than GS-NFS. On HiFi4G, for example, GS-NFS’s frame sizes can be 1.2–3× larger than V3 -2D. On N3DV, GS-NFS’s frame sizes can be 1.2–2.6× larger than V3 -2D. On average, for both datasets, V3 -2D’s frame size is about half that of GS-NFS. By using a 2D codec, V3 -2D can exploit inter-frame compression techniques in those codecs. In contrast, all other techniques, including GS-NFS only use intra-frame compression, so have lower compression performance. MesonGS. For this approach, ΔPSNR is uniformly near zero for all sequences, as expected. However, it is less compression-efficient than GS-NFS. On the HiFi4G, data set, MesonGS’s frame size is nearly 2× that of GS-NFS, and on N3DV it is 1.46×. MesonGS uses similar algorithms as ours, but with two important differences. They use vector quantization for SH coefficients7 , but we apply KLT (§4) and then quantize RAHT coefficients. They also use LZ77 for encoding attributes and positions, we use ANS and RLGR entropy encoders. We conjecture that these differences contribute to MesonGS’s lower compression performance and to its higher encode-decode latencies (Table 2). LTS-Draco. For this approach, ΔPSNR is near zero, except for a few sequences in N3DV, where LTS-Draco exhibits a 0.16–0.19 dB PSNR drop. In conducting this experiment, we sought settings for GS-NFS whose PNSR matched that of LTS-Draco, but this is not always possible, so we selected the configuration that provided the closest match. This is likely the reason for the discrepancy. LTS-Draco, however, has much worse compression performance; its frame sizes are nearly 3× GS-NFS’s for HiFi4G and 5× for N3DV. G-PCC. Of all the approaches, G-PCC has the highest RCR; its compression performance is 3.4× to 7.35× worse than GS-NFS. Although GS-NFS uses similar components, the adaptation [42] of G-PCC to 4DGS that we use compresses SH AC coefficients far less aggressively than GS-NFS. That adaptation also applies lossless compression to scales and rotations (that is, it does not quantize coefficients before entropy coding), while GS-NFS applies lossy compression by quantizing those attributes. These two factors contribute to the significant differences.

Table 3: Per-frame PSNR difference and compression ratio difference between GS-NFS and the baseline. For every metric, higher is better for GS-NFS.

and V3 -2D needs to encode 62 videos, so it is unlikely to achieve full-frame rate performance with offloading. G-PCC has the next-highest encode and decode latencies; on both data sets, its encode and decode latencies are at least 260× larger than GS-NFS’s. Although GS-NFS’s design borrows heavily from G-PCC elements, its GPU-acceleration results in a significant performance difference. MesonGS is the slowest baseline. It also borrows heavily from G-PCC, and uses some GPU acceleration, but takes several seconds or minutes to encode and decode each 3DGS frame, mostly because of the time to learn the vector quantization codebook for AC coefficients [46]. Its decoding time is dominated by RAHT decoding which takes up to 200–600 ms. Overall, GS-NFS can encode and decode one or two orders of magnitude faster than the baselines on our datasets. 5.2.2 Quality and Compression Performance Table 3 shows the ΔPSNR and RCR performance for each sequence from both datasets, across all baselines. To understand the results, recall that: (a) ΔPSNR captures the PSNR difference between GS-NFS and a baseline, and RCR the relative frame sizes after compression between the baseline and GS-NFS; (b) when we do this experiment, we find a setting for GS-NFS which has approximately the same PSNR on the first frame as the baseline’s default setting; and (c) the values in the table average these quantities across measured frames. Finally, a positive value of ΔPSNR indicates that GS-NFS has better quality, and a value > 1 for RCR indicates that GS-NFS has better compression performance. Given this, we expect ΔPSNR to be close to zero for all sequences, for all approaches. This is because the sequences do not have significant scene changes, so a parameter setting from the first frame is likely to give mostly similar PSNR values for all other frames, for all baselines. V3 -2D. For this approach, ΔPSNR is near zero for all sequences in HiFi4G. However, even though we roughly equalized PSNR, V3 -2D has nearly 0.4 dB lower PSNR in the coffee_martini sequence, and a 0.74 db lower PSNR in the flame_salmon sequence in the N3DV data set. V3 -2D has 10

35

25.0

32

22.5

30

34 33 32 31 0

2

4

6 8 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (36.29 dB) 10 12

20.0 17.5 15.0 12.5 10.0

0

2

4

6 8 10 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (28.27 dB) 12 14

PSNR (dB)

27.5

PSNR (dB)

PSNR (dB)

34

36

28 26 24 22

0

2

4

6 8 10 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (33.97 dB) 12 14 16

Figure 6: R-D curves for (Left) Actor1 from HiFi4G, (Middle) flame_salmon from N3DV, and (Right) sear_steak from N3DV.

5.3

performance was better in our baseline comparisons (§5.2.2), and is likely due to its use of 2D codecs’ ability to do interframe compression. The same is true for frame_salmon, except for this fullscene sequence, V3 -2D’s R-D curve is closer to, but still dominates GS-NFS’s. For this sequence, both these approaches dominate MesonGS, Draco-LTS, and G-PCC. On the other hand, for sear_steak, V3 -2D does not dominate GS-NFS. In fact, for this sequence, and for three other sequences in N3DV out of a total of six (cook_spinach, cut_roasted_beef, and flame_steak, Fig. A.2), V3 -2D’s R-D curve shows that there is no parameter setting for which its quality reaches close to the ground-truth PSNR (we explored QP values from 1 to 40, where 1 is the best quality). In each case, GS-NFS has a parameter setting that can provide 0.5–2 dB higher PSNR for the same rate. Moreover, for all of these sequences, GS-NFS has parameter settings that can reach ground-truth (GT) quality. Put another way, if GS-NFS were used to encode videos for DASH-based 4DGS streaming, for these sequences, it would provide much better quality at higher bandwidth-availability. To our knowledge, V3 -2D has only been evaluated on person-centric datasets and not on full-scene ones. Now, V3 2D must map 3D Gaussian positions to a 2D image. There are many possible 3D-to-2D mappings; V3 -2D applies a fixed criterion to determine where an attribute corresponding to a Gaussian in 3D should be located in the 2D. Consider two consecutive frames in 3D; the 3D-to-2D mapping algorithm is applied independently to each frame, which means that even if motion in the 3D scene is smooth, Gaussian attributes close to each other on the first 2D frame may not be close to each other in the second 2D frame. As a sequence, because the location of the same 3D attributes may change from one 2D frame to another, motion-compensated prediction in the 2D frames may not work well, potentially resulting in a higher rate than an intra-only approach. We conjecture that, for this reason, V3 -2D does not perform well in some N3DV sequences, where inter-frame coding becomes inefficient. On the other hand, GS-NFS does not exhibit this degradation because it uses a 3D codec.

Rate-Distortion Curves

To understand quality and compression trade-offs of different designs, we can also use a rate-distortion curve or R-D curve. Such a curve plots rate on the x-axis, quality or distortion on the y-axis, and the curve represents the best quality one can obtain for a given rate. To obtain this curve, practitioners explore a large space of codec parameters, obtain the rate and quality for each parameter, and plot these as points on the R-D plot. The R-D curve is the convex hull of those points. R-D curves can also help encode videos at a given bitrate 𝐵. To do this, we find the point on the convex hull whose rate is closest to 𝐵, and use its configuration to encode at the target bitrate. We also used R-D curves to find the GS-NFS configuration with the nearest PSNR in §5.2.2. Methodology. We computed R-D curves for the first frame of all sequences, for all our baselines. To do this, we sweep the space of parameters of each baseline and GS-NFS, plot rate and distortion and compute the convex hull as discussed above. §F discusses the parameters we used for each baseline and for GS-NFS. For some approaches like MesonGS and G-PCC, we could not explore all parameter combinations because of their high encoding latency, and exploring the entire space would have taken hours or days. In contrast, for GS-NFS, we were able to evaluate 1000 combinations in about 12 minutes. R–D curves. Fig. 6 shows the R–D curves for one HiFi4G sequence (Actor1) and two N3DV sequences (flame_salmon_1 and sear_steak). Fig. A.1 and Fig. A.2 depict the R-D curves for the remaining sequences for the two datasets respectively. If the R-D curve for approach 𝐴 is entirely to the left of the curve for 𝐵, for a given sequence, we say that 𝐴 dominates 𝐵. If the two curves intersect, then one is better in some bitrate regimes, and worse in others. Consider the R-D curves for Actor1. Clearly, GS-NFS dominates MesonGS, Draco-LTS, and G-PCC. However, V3 -2D dominates GS-NFS: it can, for a given quality, encode at a lower rate than GS-NFS. This explains why its compression 7 MesonGS [46] was designed to encode static scenes and we have used it to

encode 4DGS. Most video codecs would only retrain the vector quantization codebook every few frames, so our approach slightly over-estimates MesonGS frame sizes 11

Table 4: Decode latency on Jetson Orin, averaged across frames.

points/frame; ∼17–21 MB). Point clouds are voxelized at octree depth 𝐽 =10 and GS-NFS’s codec uses a quantization step 0.1 for color attributes. GS-NFS can encode each frame in 12–14 ms and decode in 9–12 ms while achieving lossless geometry and color Y-PSNR of 31–37 dB. It can compress 8i sequences to 270–370 KB and CMU Panoptic sequences to 660–780 KB, 26–64× smaller than the original size.

5.4

5.6

Sequence

SH degree

Actor1 Actor1 flame_salmon flame_salmon sear_steak sear_steak

0 3 0 2 0 2

# channels

Decode latency (ms)

11 56 11 35 11 35

40 57 59 120 49 113

Mobile Performance

GS-NFS supports 4DGS playback on resource-constrained devices. To demonstrate this, we evaluate GS-NFS’s decode performance on an NVIDIA Jetson Orin, a mobile GPU with compute comparable to those in in AR/VR headsets and edge devices [31]. Table 4 shows end-to-end decode latency on Jetson Orin. We observed that many 3DGS mobile implementations can support 30 fps 3DGS rendering for Gaussians with only SH DC coefficients (SH0), but not at higher SH degrees [44]. At SH0, GS-NFS achieves 40–59 ms across all sequences, allowing about 17–25 fps decoding. Latency scales sub-linearly with channel count: going from SH0 to SH3 (5.1× more channels) increases average decode latency across all sequences by ∼ 2×. At higher SH degrees, scene complexity dominates for full-scene content (more Gaussians): flame_salmon at SH2 (35 ch) is 2× slower than Actor1 at SH3 (56 ch), despite having fewer channels. 5.5

Ablations

KLT color decorrelation. GS-NFS decorrelates SH coefficients using a YUV transform followed by a per-channel KLT (§4). Table A.8 shows the impact on compressed size. RGB inflates the attribute bitstream by 43% compared to raw RGB, while YUV is larger than KLT by 36% for flame_salmon. For others, the reductions are smaller, but still significant. The additional latency for computing and applying the KLT matrix is less than 1 ms per frame, a negligible overhead. CUDA vs. PyTorch RAHT decode on Jetson. RAHT takes about ∼50% of the per frame decode latency, particularly on Jetson Orin. An efficient implementation of RAHT is crucial for mobile decode. GS-NFS’s custom CUDA RAHT kernels achieve 2.0–3.9× speedup over a PyTorch baseline on Jetson, with larger gains for lower SH degrees (Table A.7). We see a reduction of about 4–5× for SH0 and 2–4× for higher SH degrees for RAHT decode, which is the main bottleneck for mobile decode; prelude has ∼2× of speedup, since it doesn’t depend on the number of channels. These gains also reduce encode latency, since both forward and inverse RAHT perform the same work. Other Ablations. §H describes the cost of CPU octree coding (§2), and explores RLGR parameter sensitivity of (§3.4).

Novel GS-NFS Use Cases

So far, we have discussed using GS-NFS to compress stored 4DGS videos. In this section, we demonstrate that GS-NFS can compress, on-the-fly, live 4DGS videos generated by feed-forward Gaussian generators and point-clouds as well, both at full frame-rate. §G also demonstrates GS-NFS’s ability to quickly compress large static 3DGS scenes. Live 4DGS Compression. GPS-Gaussian [48] generates Gaussian at ∼25 fps (∼270K Gaussians per frame) using captures from 2 views of a person. We adapted GS-NFS to compress these frames on-the-fly. Specifically, our approach repeatedly takes 2 views of a person per frame (pre-loaded from disk), generates a 3DGS frame using GPS-Gaussian, compresses the frame using GS-NFS, and finally decompresses the frame to reconstruct the 3DGS frame. This pipeline can achieve 22 fps and an end-to-end latency (from capture to after decode) of 75 ms. While GS-NFS’s encoder and decoder takes only 15 ms each, the GPS-Gaussian generator takes ∼43 ms, and is the bottleneck in this pipeline. Point cloud compression. Since GS-NFS builds upon GPCC, it can compress point clouds (3DGS with only DC attribute). So, we evaluate its performance on popular point cloud-based volumetric video datasets. We use six sequences from two datasets: four single person sequences from 8i [7] (∼700K–1M points/frame; ∼17–26 MB) and 2 multi-person full-scene sequences from CMU Panoptic [16] (∼700K–850K

6

Related Work

During-training 3DGS compression. Recent research has focused on integrating compression directly into an optimization loop within training to enhance model sparsity. Compact3DGS [21] identifies prunes redundant Gaussians (as do [9, 24]) and replaces spherical harmonics with hashbased grids. CompGS [28] utilizes quantization-aware training and opacity regularization. 4D-GS [45] trains an MLP to predict motion across frames, while QUEEN [10] learns quantized attribute residuals and uses a gating module to sparsify positions. LapisGS [37] trains 3DGS in a layered progressive representation. Relative to GS-NFS, these methods incur significantly higher overhead for compression. Post-training 3DGS compression. MesonGS [46] prunes insignificant Gaussians and then applies octree and RAHT. Some schemes [13, 43] use learning based methods to find the compression parameters for position and attributes. Others [39, 42] use point cloud compression techniques to compress trained 3DGS. To address this, V3 [44] encodes 4DGS 12

in multiple 2D videos. GS-NFS encodes and decodes much faster than these techniques.

7

ICASSP 2026 - 2026 IEEE International Conference on Acoustics, Speech and Signal Processing (ICASSP). [14] Netflix Inc. 2015. Per-title Encode Optimization. https://netflixtechblog. com/per-title-encode-optimization-7e99442b62a2. [15] Tao Jin, Mallesham Dasa, Connor Smith, Kittipat Apicharttrisorn, Srinivasan Seshan, and Anthony Rowe. 2024. MeshReduce: Scalable and Bandwidth Efficient 3D Scene Capture. In 2024 IEEE Conference Virtual Reality and 3D User Interfaces (VR). 20–30. doi:10.1109/VR58804.2024. 00026 [16] Hanbyul Joo, Tomas Simon, Xulong Li, Hao Liu, Lei Tan, Lin Gui, Sean Banerjee, Timothy Scott Godisart, Bart Nabbe, Iain Matthews, Takeo Kanade, Shohei Nobuhara, and Yaser Sheikh. 2017. Panoptic Studio: A Massively Multiview System for Social Interaction Capture. IEEE Transactions on Pattern Analysis and Machine Intelligence (2017). [17] Tero Karras. 2012. Maximizing parallelism in the construction of BVHs, octrees, and k-d trees. In Proceedings of the Fourth ACM SIGGRAPH / Eurographics Conference on High-Performance Graphics (Paris, France) (EGGH-HPG’12). Eurographics Association, Goslar, DEU, 33–37. [18] Bernhard Kerbl, Georgios Kopanas, Thomas Leimkühler, and George Drettakis. 2023. 3D Gaussian Splatting for Real-Time Radiance Field Rendering. ACM Transactions on Graphics 42, 4 (July 2023). https: //repo-sam.inria.fr/fungraph/3d-gaussian-splatting/ [19] Gunjoong Kim, Seonghoon Park, Jeho Lee, Chanyoung Jung, Hyungchol Jun, and Hojung Cha. 2025. Vega: Fully Immersive Mobile Volumetric Video Streaming with 3D Gaussian Splatting. In Proceedings of the 31st Annual International Conference on Mobile Computing and Networking (Kerry Hotel, Hong Kong, Hong Kong, China) (ACM MOBICOM ’25). Association for Computing Machinery, New York, NY, USA, 1106–1120. doi:10.1145/3680207.3765267 [20] Naimin Koh, Pradeep Kumar Jayaraman, and Jianmin Zheng. 2020. Parallel Point Cloud Compression Using Truncated Octree. In 2020 International Conference on Cyberworlds (CW). 1–8. doi:10.1109/CW49994. 2020.00009 [21] Joo Chan Lee, Daniel Rho, Xiangyu Sun, Jong Hwan Ko, and Eunbyung Park. 2024. Compact 3D Gaussian Splatting for Static and Dynamic Radiance Fields. arXiv:2408.03822 [cs.CV] https://arxiv.org/abs/2408. 03822 [22] Kyungjin Lee, Juheon Yi, Youngki Lee, Sunghyun Choi, and Young Min Kim. 2020. GROOT: a real-time streaming system of high-fidelity volumetric videos. In Proceedings of the 26th Annual International Conference on Mobile Computing and Networking (London, United Kingdom) (MobiCom ’20). Association for Computing Machinery, New York, NY, USA, Article 57, 14 pages. doi:10.1145/3372224.3419214 [23] Xiangrui Liu, Xinju Wu, Shiqi Wang, Zhu Li, and Sam Kwong. 2025. CompGS++: Compressed Gaussian Splatting for Static and Dynamic Scene Representation. arXiv:2504.13022 [cs.GR] https://arxiv.org/abs/ 2504.13022 [24] Tao Lu, Mulin Yu, Linning Xu, Yuanbo Xiangli, Limin Wang, Dahua Lin, and Bo Dai. 2024. Scaffold-gs: Structured 3d gaussians for viewadaptive rendering. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 20654–20664. [25] H.S. Malvar. 2006. Adaptive run-length/Golomb-Rice encoding of quantized generalized Gaussian sources with unknown statistics. In Data Compression Conference (DCC’06). 23–32. doi:10.1109/DCC.2006.5 [26] Donald Meagher. 1982. Geometric modeling using octree encoding. Computer Graphics and Image Processing 19, 2 (1982), 129–147. doi:10. 1016/0146-664X(82)90104-6 [27] MPEG. 2023. GPCC - mpeg-pcc-tmc13. https://github.com/ MPEGGroup/mpeg-pcc-tmc13. [28] K L Navaneet, Kossar Pourahmadi Meibodi, Soroush Abbasi Koohpayegani, and Hamed Pirsiavash. 2024. CompGS: Smaller and Faster Gaussian Splatting with Vector Quantization. In Computer Vision

Conclusions

GS-NFS is a frame-rate GPU-accelerated encoder and decoder for 4DGS videos. To our knowledge, it is the first to demonstrate frame-rate encoding and decoding performance not just for 4DGS, but also for point clouds. It achieves this performance using novel parallelization algorithms for position and attributes. Its compression performance is also better than many state-of-the-art approaches due to a novel decorrelation approach. Future work can develop rate-adaptive codecs that can dynamically adapt compression levels in response to bandwidth changes, using GS-NFS’s ability to quickly encode and decode frames.

References [1] [n. d.]. Draco 3D Compression. https://github.com/google/draco. [2] [n. d.]. Point Cloud Library. https://pointclouds.org/. [3] Michael Bader. 2012. Space-filling curves: an introduction with applications in scientific computing. Vol. 9. Springer Science & Business Media. [4] Li-Heng Chen, Christos G. Bampis, Zhi Li, Joel Sole, and Alan C. Bovik. 2021. Perceptual Video Quality Prediction Emphasizing Chroma Distortions. IEEE Transactions on Image Processing 30 (2021), 1408–1422. doi:10.1109/TIP.2020.3043127 [5] NVIDIA Corporation. 2025. NVIDIA nvCOMP - A CUDA library for Fast Lossless Compression. https://developer.nvidia.com/nvcomp [6] Ricardo L De Queiroz and Philip A Chou. 2016. Compression of 3D point clouds using a region-adaptive hierarchical transform. IEEE Transactions on Image Processing 25, 8 (2016), 3947–3956. [7] E d’Eon, B Harrison, T Myers, and PA Chou. 2017. 8i Voxelized Full Bodies—A Voxelized Point Cloud Dataset, document WG11M40059/WG1M74006. ISO/IEC JTC1/SC29 Joint WG11/WG1 (MPEG/JPEG), Geneva, Switzerland (2017). [8] FFmpeg Developers. 2026. FFmpeg. http://ffmpeg.org/ [9] Jiaye Fu, Qiankun Gao, Chengxiang Wen, Yanmin Wu, Siwei Ma, Jiaqi Zhang, and Jian Zhang. 2025. ReCon-GS: Continuum-Preserved Gaussian Streaming for Fast and Compact Reconstruction of Dynamic Scenes. In Advances in Neural Information Processing Systems (NeurIPS). [10] Sharath Girish, Tianye Li, Amrita Mazumdar, Abhinav Shrivastava, david luebke, and Shalini De Mello. 2024. QUEEN: QUantized Efficient ENcoding for Streaming Free-viewpoint Videos. In The Thirty-eighth Annual Conference on Neural Information Processing Systems. https: //openreview.net/forum?id=7xhwE7VH4S [11] Yongjie Guan, Xueyu Hou, Nan Wu, Bo Han, and Tao Han. 2023. MetaStream: Live Volumetric Content Capture, Creation, Delivery, and Rendering in Real Time. In Proceedings of the 29th Annual International Conference on Mobile Computing and Networking. Association for Computing Machinery, New York, NY, USA, Article 29, 15 pages. https://doi.org/10.1145/3570361.3592530 [12] Bo Han, Yu Liu, and Feng Qian. 2020. ViVo: Visibility-Aware Mobile Volumetric Video Streaming. In Proceedings of the 26th Annual International Conference on Mobile Computing and Networking (London, United Kingdom) (MobiCom ’20). Association for Computing Machinery, New York, NY, USA, Article 11, 13 pages. doi:10.1145/3372224. 3380888 [13] Yuning Huang, Jiahao Pang, Fengqing Zhu, and Dong Tian. 2026. EntropyGS: An Efficient Entropy Coding on 3D Gaussian Splatting. In 13

New York, NY, USA, 1–7. doi:10.1145/3672196.3673394 [41] Hari Sundar, Rahul S. Sampath, and George Biros. 2008. BottomUp Construction and 2:1 Balance Refinement of Linear Octrees in Parallel. SIAM Journal on Scientific Computing 30, 5 (2008), 2675–2708. arXiv:https://doi.org/10.1137/070681727 doi:10.1137/070681727 [42] Chenjunjie Wang, Shashank N. Sridhara, Eduardo Pavez, Antonio Ortega, and Cheng Chang. 2025. Adaptive Voxelization for Transform Coding of 3D Gaussian Splatting Data. In 2025 IEEE International Conference on Image Processing (ICIP). 2414–2419. doi:10.1109/ICIP55913. 2025.11084522 [43] Kangli Wang, Shihao Li, Qianxi Yi, and Wei Gao. 2025. A Novel Benchmark and Dataset for Efficient 3D Gaussian Splatting with Gaussian Point Cloud Compression. arXiv:2505.18197 [cs.GR] https: //arxiv.org/abs/2505.18197 [44] Penghao Wang, Zhirui Zhang, Liao Wang, Kaixin Yao, Siyuan Xie, Jingyi Yu, Minye Wu, and Lan Xu. 2024. Vˆ 3: Viewing Volumetric Videos on Mobiles via Streamable 2D Dynamic Gaussians. ACM Transactions on Graphics (TOG) 43, 6 (2024), 1–13. [45] Guanjun Wu, Taoran Yi, Jiemin Fang, Lingxi Xie, Xiaopeng Zhang, Wei Wei, Wenyu Liu, Qi Tian, and Xinggang Wang. 2024. 4D Gaussian Splatting for Real-Time Dynamic Scene Rendering. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). 20310–20320. [46] Shuzhao Xie, Weixiang Zhang, Chen Tang, Yunpeng Bai, Rongwei Lu, Shijia Ge, and Zhi Wang. 2024. MesonGS: Post-training Compression of 3D Gaussians via Efficient Attribute Transformation. In European Conference on Computer Vision. Springer. [47] Kai Zhang, Kaibo Wang, Yuan Yuan, Lei Guo, Rubao Lee, and Xiaodong Zhang. 2015. Mega-KV: a case for GPUs to maximize the throughput of in-memory key-value stores. Proc. VLDB Endow. 8, 11 (July 2015), 1226–1237. doi:10.14778/2809974.2809984 [48] Shunyuan Zheng, Boyao Zhou, Ruizhi Shao, Boning Liu, Shengping Zhang, Liqiang Nie, and Yebin Liu. 2024. GPS-Gaussian: Generalizable Pixel-wise 3D Gaussian Splatting for Real-time Human Novel View Synthesis. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). [49] Zihan Zheng, Zhenlong Wu, Houqiang Zhong, Yuan Tian, Ning Cao, Lan Xu, Jiangchao Yao, Xiaoyun Zhang, Qiang Hu, and Wenjun Zhang. 2025. 4DGCPro: Efficient Hierarchical 4D Gaussian Compression for Progressive Volumetric Video Streaming. arXiv:2509.17513 [cs.CV] https://arxiv.org/abs/2509.17513 [50] Boyao Zhou, Shunyuan Zheng, Hanzhang Tu, Ruizhi Shao, Boning Liu, Shengping Zhang, Liqiang Nie, and Yebin Liu. 2024. GPS-Gaussian+: Generalizable Pixel-wise 3D Gaussian Splatting for Real-Time HumanScene Rendering from Sparse Views. arXiv preprint arXiv:2411.11363 (2024). [51] Kun Zhou, Minmin Gong, Xin Huang, and Baining Guo. 2011. DataParallel Octrees for Surface Reconstruction. IEEE Transactions on Visualization and Computer Graphics 17, 5 (2011), 669–681. doi:10. 1109/TVCG.2010.75

- ECCV 2024: 18th European Conference, Milan, Italy, September 29October 4, 2024, Proceedings, Part XXXII (Milan, Italy). Springer-Verlag, Berlin, Heidelberg, 330–349. doi:10.1007/978-3-031-73411-3_19 [29] NVIDIA. 2024. NVIDIA Video Codec SDK. https://developer.nvidia. com/video-codec-sdk. [30] NVIDIA. 2024. Video Encode and Decode GPU Support Matrix. https://developer.nvidia.com/video-encode-and-decode-gpusupport-matrix-new. [31] NVIDIA Corporation. 2024. NVIDIA Jetson AGX Orin Developer Kit. https://www.nvidia.com/en-us/autonomous-machines/ embedded-systems/jetson-orin/ Accessed: 2024-05-20. [32] Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Bradbury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Köpf, Edward Yang, Zach DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, Lu Fang, Junjie Bai, and Soumith Chintala. 2019. PyTorch: an imperative style, high-performance deep learning library. Curran Associates Inc., Red Hook, NY, USA. [33] Eduardo Pavez, Philip A. Chou, Ricardo L. de Queiroz, and Antonio Ortega. 2018. Dynamic polygon clouds: representation and compression for VR/AR. APSIPA Transactions on Signal and Information Processing 7 (2018), e15. doi:10.1017/ATSIP.2018.15 [34] K. Rao and N. Ahmed. 1976. Orthogonal transforms for digital signal processing. In ICASSP ’76. IEEE International Conference on Acoustics, Speech, and Signal Processing, Vol. 1. 136–140. doi:10.1109/ICASSP. 1976.1170121 [35] Sebastian Schwarz, Marius Preda, Vittorio Baroncini, Madhukar Budagavi, Pablo Cesar, Philip A. Chou, Robert A. Cohen, Maja Krivokuća, Sébastien Lasserre, Zhu Li, Joan Llach, Khaled Mammou, Rufael Mekuria, Ohji Nakagami, Ernestasia Siahaan, Ali Tabatabai, Alexis M. Tourapis, and Vladyslav Zakharchenko. 2019. Emerging MPEG Standards for Point Cloud Compression. IEEE Journal on Emerging and Selected Topics in Circuits and Systems 9, 1 (2019), 133–148. doi:10.1109/JETCAS.2018.2885981 [36] Anil Shanbhag, Samuel Madden, and Xiangyao Yu. 2020. A Study of the Fundamental Performance Characteristics of GPUs and CPUs for Database Analytics. In Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data (Portland, OR, USA) (SIGMOD ’20). Association for Computing Machinery, New York, NY, USA, 1617–1632. doi:10.1145/3318464.3380595 [37] Yuang Shi. 2025. 3D Gaussian-based Immersive Media Streaming in Networked Extended Reality. In Proceedings of the 16th ACM Multimedia Systems Conference (Stellenbosch, South Africa) (MMSys ’25). Association for Computing Machinery, New York, NY, USA, 356–360. doi:10.1145/3712676.3719673 [38] Gary J. Sullivan and Shijun Sun. 2005. On dead-zone plus uniform threshold scalar quantization. In Visual Communications and Image Processing 2005, Shipeng Li, Fernando Pereira, Heung-Yeung Shum, and Andrew G. Tescher (Eds.), Vol. 5960. International Society for Optics and Photonics, SPIE, 596033. doi:10.1117/12.631550 [39] Yuan-Chun Sun, Yuang Shi, Cheng-Tse Lee, Mufeng Zhu, Wei Tsang Ooi, Yao Liu, Chun-Ying Huang, and Cheng-Hsin Hsu. 2025. LTS: A DASH Streaming System for Dynamic Multi-Layer 3D Gaussian Splatting Scenes. In Proceedings of the 16th ACM Multimedia Systems Conference (Stellenbosch, South Africa) (MMSys ’25). Association for Computing Machinery, New York, NY, USA, 136–147. doi:10.1145/ 3712676.3714445 [40] Yuan-Chun Sun, Yuang Shi, Wei Tsang Ooi, Chun-Ying Huang, and Cheng-Hsin Hsu. 2024. Multi-frame Bitrate Allocation of Dynamic 3D Gaussian Splatting Streaming Over Dynamic Networks. In Proceedings of the 2024 SIGCOMM Workshop on Emerging Multimedia Systems (Sydney, NSW, Australia) (EMS ’24). Association for Computing Machinery, 14

A

Coding Latency

Algorithm A.1: GPU Octree’s Encoding from Voxelized Positions Input : Voxelized integer positions 𝑁ˆ 𝑣 𝑉ˆ = {(𝑥ˆ𝑖 , 𝑦ˆ𝑖 , 𝑧ˆ𝑖 )}𝑖=1 on GPU; octree depth 𝐽 Output: Serialized octree bitstream 𝐵𝑜𝑐𝑐

In Table A.1, we report the actual encoding and decoding latencies for all sequences in the HiFi4G and N3DV datasets.

B

GS-NFS Octree Encoding

Algorithm A.1 summarizes our GPU octree encoder. Starting from voxelized integer coordinates, we first compute Morton codes for all occupied leaf voxels, then radix-sort and deduplicate them to obtain the leaf set 𝐿 𝐽 . The upper octree levels are constructed bottom-up by repeatedly mapping child codes to their parents and removing duplicates, 𝐽 yielding level-wise node sets {𝐿𝑑 }𝑑=0 . After the hierarchy is built, we serialize a compact occupancy bitstream. The header stores the number of levels and the node count of each level. The payload is then generated in breadth-first order: for each parent in level 𝐿𝑑 , we produce one occupancy byte indicating which of its eight children are present in 𝐿𝑑+1 . As shown in Algorithm A.1, this is done by locating the base child Morton code and setting the corresponding bits for all valid children in the next level. This construction avoids explicit pointer-based octree data structures and operates directly on sorted Morton codes, which is well suited to parallel primitives such as radix sort, deduplication, and batched searches. The resulting bitstream is a level-synchronous octree representation that can be decoded with the same breadth-first traversal order.

C

// Step 1: Morton codes for leaf voxels ˆ 𝑣 do in parallel 1 for 𝑖 ← 1 to 𝑁 2 𝑚𝑖 ← Morton(𝑥ˆ𝑖 , 𝑦ˆ𝑖 , 𝑧ˆ𝑖 , 𝐽 ) 3 end 4 𝐿 𝐽 ← Unique(RadixSort({𝑚𝑖 })) // leaf nodes // Step 2: Level-synchronous octree construction 5 for 𝑑 ← 𝐽 − 1 to 0 do // bottom-up parents 6 𝐿𝑑 ← Unique({ Parent(𝑐𝑚 ) | 𝑐𝑚 ∈ 𝐿𝑑+1 }) // Parent(𝑐𝑚 ) = 𝑐𝑚 ≫ 3 7 end // Step 3: Bitstream header 8 𝑛𝑢𝑚_𝑙𝑒𝑣𝑒𝑙𝑠 ← 𝐽 + 1 9 𝑙𝑒𝑣𝑒𝑙_𝑠𝑖𝑧𝑒𝑠 ← (|𝐿0 |, . . . , |𝐿 𝐽 |) 10

// Step 4: Breadth-first occupancy bitstream. 11 for 𝑑 ← 0 to 𝐽 − 1 do in parallel 12 𝐵𝑑 ← OccKernel(𝐿𝑑 , 𝐿𝑑+1 ) 𝐵𝑜𝑐𝑐 ← Append(𝐵𝑜𝑐𝑐 , 𝐵𝑑 ) // contiguous bytes for level 𝑑 13 end 14 return 𝐵𝑜𝑐𝑐

GS-NFS’s Octree Decoding

The GPU decoder reconstructs voxelized geometry by replaying the serialized occupancy stream in a levelsynchronous manner, without building any explicit tree pointers. Starting from the implicit root Morton code (𝐿0 = {0}), for each depth 𝑑 it reads the |𝐿𝑑 | occupancy bytes, counts the number of occupied children per parent (population count), and performs an exclusive prefix-sum to compute disjoint write offsets for the next-level array. It then launches expand_children_kernel (Alg. A.3), which generates each occupied child Morton code in 𝑂 (1) via (𝑝𝑎𝑟𝑒𝑛𝑡 ≪ 3) + 𝑖 and writes all children contiguously into 𝐿𝑑+1 , avoiding atomics despite variable fan-out. Repeating this from 𝑑 = 0 to 𝐽 −1 yields the leaf Morton codes 𝐿 𝐽 , which are finally decoded into integer voxel coordinates (and optionally interleaved) in a parallel post-pass. Overall, decoding preserves the same breadth-first structure as the encoder while turning the key sequential dependency (unknown next-level size) into a standard GPU pattern: count → prefix-sum → parallel scatter. Full algorithm can be found here A.2.

D

𝐵𝑜𝑐𝑐 ← Append(𝐵𝑜𝑐𝑐 , 𝑛𝑢𝑚_𝑙𝑒𝑣𝑒𝑙𝑠, 𝑙𝑒𝑣𝑒𝑙_𝑠𝑖𝑧𝑒𝑠)

Kernel OccKernel (𝐿𝑑 , 𝐿𝑑+1 ): for 𝑝 ∈ 𝐿𝑑 do in parallel 𝑏 ←𝑝 ≪ 3 17 𝑐𝑚 // base child code 18 𝑜𝑐𝑐 ← 0 // occupancy byte 𝑏 ) for 𝑘 ← 0 to 7 19 𝑐𝑚 ← BinarySearch(𝐿𝑑+1, 𝑐𝑚 do 𝑏 + 7 then 20 if 𝐿𝑑+1 [𝑐𝑚 + 𝑘] ≤ 𝑐𝑚
𝑏 ) 21 𝑜𝑐𝑐 ← 𝑜𝑐𝑐 | 1 ≪ (𝐿𝑑+1 [𝑐𝑚 + 𝑘] − 𝑐𝑚 22 end 23 end 24 Write 𝑜𝑐𝑐 into 𝐵𝑑 at parent’s index 25 end 15

16

voxels, and a transform stage that applies the weighted orthonormal rotations using that schedule. This separation

GS-NFS’s RAHT Implementation

We implement RAHT as a two-stage GPU pipeline: a prelude that builds the merge schedule from Morton-sorted occupied 15

Table A.1: Encode and decode latency (ms) for video sequences.

Actor1 Actor2 Actor3 Actor4 Actor5 Actor6 Actor7

V3 -2D Enc Dec 443.1 312.5 4808.9 362.8 542.5 331.9 554.1 358.9 435.7 330.0 483.5 367.4 421.3 323.4

MesonGS Enc Dec 144950.2 487.4 144363.5 368.8 145057.5 529.3 145351.6 622.6 145003.4 559.3 145344.3 674.9 144602.4 504.7

LTS-Draco Enc Dec 136.8 84.4 103.5 60.8 156.3 95.1 182.8 104.6 158.2 91.9 201.9 113.1 151.8 88.2

G-PCC Enc Dec 5063.9 2986.5 3679.6 2205.4 6027.0 3474.0 8070.4 4858.2 5992.8 3693.7 8579.4 5163.9 5294.2 3174.0

GS-NFS (Ours) Enc Dec 17.4 12.8 15.6 12.0 17.6 13.2 19.1 15.0 17.8 13.4 19.6 15.7 17.7 13.2

Coffee Martini Cook Spinach Cut Roasted Beef Flame Salmon Flame Steak Sear Steak

473.6 316.8 313.3 488.0 316.9 312.8

30228.0 28719.5 28781.4 29692.5 28877.8 28826.4

1059.4 229.7 229.4 413.8 222.4 247.9

12540.2 7467.1 8162.4 11327.0 6364.7 6966.3

24.9 21.7 21.5 27.7 22.2 22.2

Sequence

352.0 262.8 261.0 340.3 262.3 263.2

1415.6 1012.1 978.2 1335.9 1080.6 1061.6

isolates the octree-dependent control flow from the perattribute transform, allowing the latter to be executed with simple parallel kernels. Algorithm A.4 gives the reference non-parallel prelude. For each of the 3𝐽 binary merge steps induced by a depth-𝐽 octree, it constructs the active index list 𝐼 ℓ , the corresponding run-length weights 𝑊ℓ , and the sibling flags 𝐹 ℓ . Here, 𝑊ℓ records the number of original voxels represented by each active entry, and 𝐹 ℓ marks whether an entry is the left element of a valid sibling pair. The sibling relation is tested directly from Morton codes using XOR and a level-dependent mask, without explicitly materializing the octree. Algorithm A.5 shows the GPU version of this schedule construction. At each level, one thread computes the weight and sibling flag for one active entry. The next active list is then obtained by removing right siblings while keeping left siblings 3𝐽 and singletons. This produces the schedule [(𝐼 ℓ ,𝑊ℓ , 𝐹 ℓ )] ℓ=1 used by the transform. Algorithm A.6 applies the forward or inverse RAHT on the GPU. In the forward pass, levels are processed bottomup; in the inverse pass, they are processed in reverse order. For each sibling pair, the transform uses the standard RAHT weights √︂ √︂ 𝑤0 𝑤1 𝑎= , 𝑏= , 𝑤0 + 𝑤1 𝑤0 + 𝑤1

E

215.8 127.2 128.5 214.0 129.3 133.3

10090.6 5866.7 6438.3 9236.8 4548.4 5391.3

23.9 20.1 19.6 23.4 20.3 20.5

R-D Curves

This section provides the per-sequence R-D curves for all evaluated methods. For completeness, we include one representative frame from each sequence and plot the corresponding bitrate–quality trade-off. Figures A.1 and A.2 report the results for the HiFi4G and N3DV datasets, respectively.

F

Generating R-D Curves

To generate the rate-distortion (R-D) curves, we perform an exhaustive parameter sweep for each baseline codec, per frame. For each parameter configuration, we compress and decompress the 3DGS representation of a single frame, render the decompressed Gaussians, and compute PSNR against the ground-truth renders (rendered from the uncompressed model). All renders use a resolution-downscale factor of 2. For V3 -2D, which operates on groups of frames, we compress a group of 20 consecutive frames starting from the target frame and report the per-frame average compressed size; PSNR and SSIM are measured only on the target frame. All other baselines compress and evaluate a single frame independently. The resulting (compressed size, quality) operating points are reduced to their upper convex hull to produce the final R-D curve. Table A.2 lists the swept parameters and their ranges for each baseline. Dataset-specific settings are noted where applicable.

to perform the corresponding orthonormal rotation independently for each attribute channel. Since pairs within a level are disjoint, the computation can be parallelized across active entries.

G

Compressing Static Scenes

Static 3DGS scene compression. We evaluate GS-NFS on two large static outdoor scenes from the Deep Blending dataset (drjohnson, 3M Gaussians, 748 MB) and Tanks & Temples (truck, 2M Gaussians, 485 MB). Table A.3 shows the results. GS-NFS achieves encode times of 91–165 ms, which 16

Algorithm A.2: GPU Octree Decoding Input : Compressed octree buffer 𝐵 on GPU; octree depth 𝐽 Output: Voxelized positions 𝑉ˆ on GPU; leaf Morton codes 𝐿 𝐽 on GPU 1

Algorithm A.3: expand_children_kernel: Expand occupied children and generate Morton codes Input : Parent Morton codes 𝐿𝑑 [1:𝑀𝑑 ]; occupancy bytes 𝑂𝑐𝑐𝑑 [1:𝑀𝑑 ]; write offsets 𝑜 𝑓 𝑓 [1:𝑀𝑑 ] Output: Child Morton codes 𝐿𝑑+1 [1:𝑇 ] 1 for 𝑝 ← 1 to 𝑀𝑑 do in parallel 2 𝑝𝑎𝑟𝑒𝑛𝑡 ← 𝐿𝑑 [𝑝] 3 𝑜𝑐𝑐 ← 𝑂𝑐𝑐𝑑 [𝑝] 4 𝑏𝑎𝑠𝑒 ← 𝑝𝑎𝑟𝑒𝑛𝑡 ≪ 3 // base child Morton code 5 𝑤 ← 𝑜 𝑓 𝑓 [𝑝] // exclusive-scan start offset for this parent 6 for 𝑖 ← 0 to 7 do 7 if 𝑜𝑐𝑐 ∧ (1 ≪ 𝑖) then 8 𝐿𝑑+1 [𝑤] ← 𝑏𝑎𝑠𝑒 + 𝑖 9 𝑤 ←𝑤 +1 10 end 11 end 12 end

// Step 1: Parse header. (𝑛𝑢𝑚_𝑙𝑒𝑣𝑒𝑙𝑠, 𝑙𝑒𝑣𝑒𝑙_𝑠𝑖𝑧𝑒𝑠, 𝑝𝑡𝑟 ) ← ReadHeader(𝐵)

// Step 2: Initialize root list (implicit root Morton code). 2 𝐿0 ← [ 0 ] // Step 3: Level-synchronous decoding. 3 for 𝑑 ← 0 to 𝐽 − 1 do // top-down levels 4 𝑀𝑑 ← |𝐿𝑑 | 5 𝑂𝑐𝑐𝑑 ← ReadOccBytes(𝑝𝑡𝑟, 𝑀𝑑 ) // read 𝑀𝑑 bytes from 𝐵 into a GPU array 6 𝑝𝑡𝑟 ← 𝑝𝑡𝑟 + 𝑀𝑑

7 8 9

10

11

// Count children per parent. for 𝑝 ← 1 to 𝑀𝑑 do in parallel 𝑐𝑛𝑡 [𝑝] ← Popcount(𝑂𝑐𝑐𝑑 [𝑝]) end

Algorithm A.4: RAHT prelude (non-parallel) Input : Morton codes 𝑀 [0:𝑁 𝑣 −1], Num voxels 𝑁 𝑣 , octree depth 𝐽 3𝐽 Output: [(𝐼 ℓ ,𝑊ℓ , 𝐹 ℓ )] ℓ=1 1 for ℓ ← 1 to 3𝐽 do 2 if ℓ = 1 then 3 𝐼 1 ← (0:𝑁 𝑣 −1)𝑇 // active indices at level 1 4 else
5 𝐼 ℓ ← 𝐼 ℓ −1 ¬[0; 𝐹 ℓ −1 ] // keep left siblings + singletons 6 end 7 𝑀ℓ ← 𝑀 [𝐼 ℓ ] // Morton codes at level ℓ 8 𝑊ℓ ← [𝐼 ℓ (2:end); 𝑁 𝑣 ] − 𝐼 ℓ // run-length weights (sentinel 𝑁 𝑣 ) 9 𝐷 ← 𝑀ℓ (1:end−1) ⊕ 𝑀ℓ (2:end) // path diffs
10 𝐹 ℓ ← 𝐷 ∧ (23𝐽 − 2ℓ ) = 0 // left-sibling flags 11 end 3𝐽 12 return [(𝐼 ℓ ,𝑊ℓ , 𝐹 ℓ )] ℓ=1

// Find total children at 𝑑 + 1. 𝑜 𝑓 𝑓 ← ExclusiveScan(𝑐𝑛𝑡) 𝑇 ← 𝑜 𝑓 𝑓 [𝑀𝑑 ] + 𝑐𝑛𝑡 [𝑀𝑑 ] Allocate 𝐿𝑑+1 of length 𝑇

// Expand children. ExpandChildrenKernel (𝐿𝑑 , 𝑂𝑐𝑐𝑑 , 𝑜 𝑓 𝑓 , 𝐿𝑑+1 ) with 𝑀𝑑 threads 13 end 12

// Step 6: Get voxel coordinates at leaf. ˆ 𝑣 ← |𝐿 𝐽 | 14 𝑁 15 𝑠ℎ𝑖 𝑓 𝑡 ← 𝐽𝑣 − 𝐽 ˆ 𝑣 ], 𝑦ˆ [1:𝑁ˆ 𝑣 ], 𝑧ˆ [1:𝑁ˆ 𝑣 ] 16 Allocate 𝑥ˆ [1:𝑁 17 Launch ReconstructPointsKernel ˆ 𝑦, ˆ 𝑧) ˆ with 𝑁ˆ 𝑣 threads (𝐿 𝐽 , 𝑠ℎ𝑖 𝑓 𝑡, 𝑥, ˆ 𝑦, ˆ 𝑧) ˆ 18 𝑉ˆ ← InterleaveXYZ(𝑥, // Reverse Morton Code. 19 return (𝑉ˆ , 𝐿 𝐽 ) is 31× faster than LTS-Draco and 1,200–3,400× faster than MesonGS. At quality comparable to LTS-Draco (<1 dB PSNR difference), GS-NFS produces compressed files that are 5–10× smaller.

H

Other Ablations

GPU vs. CPU octree encoding. We compare GS-NFS’s GPU octree encoder against Draco [1] and G-PCC [35] for position-only compression. Table A.6 shows that GS-NFS’s 17

36

Algorithm A.5: RAHT Prelude on GPU Input : Morton codes 𝑀 [0:𝑁 𝑣 −1], Num voxels 𝑁 𝑣 , octree depth 𝐽 3𝐽 Output: [(𝐼 ℓ ,𝑊ℓ , 𝐹 ℓ )] ℓ=1 𝑇 1 𝐼 1 ← (0:𝑁 𝑣 −1) 2 for ℓ ← 1 to 3𝐽 do 3 𝜇ℓ ← (23𝐽 − 2ℓ ) // mask for sibling test 4 for 𝑘 ← 1 to 𝑀ℓ do in parallel // 1 GPU thread per 𝑘 5 𝑐𝑢𝑟𝑟 ← 𝐼 ℓ (𝑘) ( 𝑒𝑛𝑑 if 𝑘 = 𝑀ℓ 6 𝑛𝑒𝑥𝑡 ← 𝐼 ℓ (𝑘+1) otherwise 7 𝑊ℓ (𝑘) ← 𝑛𝑒𝑥𝑡 − 𝑐𝑢𝑟𝑟 8 if 𝑘 = 𝑀ℓ then 9 𝐹 ℓ (𝑘) ← 0 10 else 11 𝐹 ℓ (𝑘) ← ((𝑀 (𝑐𝑢𝑟𝑟 ) ⊕ 𝑀 (𝑛𝑒𝑥𝑡)) ∧ 𝜇ℓ ) = 0 12 end 13 end 14 𝑃ℓ ← torch.shift(𝐹 ℓ ) // [0; 𝐹 ℓ (0:end−1)] marks right siblings 15 𝐼 ℓ+1 ← torch.masked_select(𝐼 ℓ , ¬𝑃ℓ ) 16 if |𝐼 ℓ+1 | = 1 then 17 break 18 end 19 end 3𝐽 20 return [(𝐼 ℓ ,𝑊ℓ , 𝐹 ℓ )] ℓ=1

34

34 33

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (36.29 dB) 10 12

32 31 0

2

4

6 8 Compressed Size (MB)

PSNR (dB)

PSNR (dB)

35 33 32 31 30

0

(a) Actor1_Greeting 32 31

30 29 28 27 0

2

4

6 8 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (32.07 dB) 10 12 14

PSNR (dB)

PSNR (dB)

31

30 29 28 27 26 0.0

(c) Actor3_Violin

2.5

5.0

7.5 10.0 12.5 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (32.51 dB) 15.0 17.5 20.0

(d) Actor4_Dancing

37

36

36 34 33 32 31 30 0

2

4

6 8 10 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (37.41 dB) 12 14

(e) Actor5_Oil-paper_Umbrella

PSNR (dB)

35 PSNR (dB)

4 6 Compressed Size (MB)

(b) Actor2_Dancing

32

26

2

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (34.56 dB) 8 10

34 32 30 28 0.0

2.5

5.0

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (37.32 dB) 7.5 10.0 12.5 15.0 17.5 20.0 Compressed Size (MB)

(f) Actor6_Changing_Clothes

35

PSNR (dB)

34 33 32 31 30

GPU octree encoding time is 16-34× faster (8–14× for decoding) than Draco and 70–100× faster than G-PCC for encoding (50–65× for decoding), while producing bitstreams of comparable size. ANS entropy coding of the octree occupancy bytes adds only ∼0.3 ms but roughly halves the compressed size. RLGR parallelization. GS-NFS parallelizes RLGR entropy coding by partitioning each attribute channel into fixed-size blocks and encoding them independently on GPU threads (§3.4). Table A.5 compares the CPU baseline (sequential perchannel RLGR) against GPU variants with different block sizes. Parallel RLGR a block size of 512 achieves a 58× encode and 109× decode speedup on a desktop GPU over CPU, with only ∼1.5% increase in compressed size. On Jetson Orin, a block size of 512 achieves ∼6 ms decode time per frame, compared to ∼180 ms for the CPU implementation–a 30× speedup. Smaller block sizes below 512 starts having diminishing returns. Block size 2048–8192 provides a balanced tradeoff: 18–51× speedup in encode/decode latency with negligible size overhead.

0

2

4

6 8 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (35.21 dB) 10 12 14

(g) Actor7_Nunchaku

Figure A.1: Rate-distortion curves for HiFi4G 4K sequences (frame 0).

18

Algorithm A.6: RAHT Transform (Forward / Inverse) on GPU

25.0 22.5

28 26 24 22 0

2

4

6 8 10 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (33.14 dB) 12 14 16

PSNR (dB)

PSNR (dB)

30

20.0 17.5 12.5 10.0

0

2

(a) cook_spinach

(b) coffee_martini 25.0

30

22.5

28 26 24 22 0

2

4

6 8 10 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (33.85 dB) 12 14 16

PSNR (dB)

PSNR (dB)

4

27.5

32

20

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (27.77 dB) 6 8 10 12 14 16 18 Compressed Size (MB)

15.0

34

20.0 17.5 15.0 12.5 10.0

0

2

(c) cut_roasted_beef 34

32

32

30

30

28 26 24 0

2

4

6 8 10 12 Compressed Size (MB)

4

6 8 10 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (28.27 dB) 12 14

(d) flame_salmon_1

34

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (33.82 dB) 14 16 18

PSNR (dB)

PSNR (dB)

Input : Attributes 𝐴 ∈ R𝑁 𝑣 ×𝐶 (GPU), prelude 3𝐽 schedule [(𝐼 ℓ ,𝑊ℓ , 𝐹 ℓ )] ℓ=1 , inverse flag 𝑁 ×𝐶 𝑣 Output: Coefficients 𝑌 ∈ R (GPU) 1 𝑌 ←𝐴 // clone for in-place updates 2 if inverse = 0 then 3 for ℓ ← 1 to 3𝐽 − 1 do // bottom-up 4 𝑀ℓ ← |𝐼 ℓ | 5 Launch raht_forward_level_kernel with 𝑀ℓ threads 6 for 𝑘 ← 0 to 𝑀ℓ − 2 do in parallel 7 if 𝐹 ℓ [𝑘] then 8 𝑖 0 ← 𝐼 ℓ [𝑘]; 9 𝑖 1 ← 𝐼 ℓ [𝑘 + 1]; 10 𝑤 0 ← 𝑊ℓ [𝑘]; 11 𝑤 1 ← 𝑊ℓ [𝑘 + 1]; √︁ 12 𝑎 ← 𝑤 0 /(𝑤 0 + 𝑤 1 ); √︁ 13 𝑏 ← 𝑤 1 /(𝑤 0 + 𝑤 1 ); 14 for 𝑐 ← 0 to 𝐶 − 1 do 15 𝑦0 ← 𝑌 [𝑖 0, 𝑐]; 16 𝑦1 ← 𝑌 [𝑖 1, 𝑐]; 17 𝑌 [𝑖 0, 𝑐] ← 𝑎 · 𝑦0 + 𝑏 · 𝑦1 18 𝑌 [𝑖 1, 𝑐] ← −𝑏 · 𝑦0 + 𝑎 · 𝑦1 19 end 20 end 21 end 22 end 23 end 24 for ℓ ← 3𝐽 − 1 to 1 do // top-down 25 𝑀ℓ ← |𝐼 ℓ | 26 Launch raht_inverse_level_kernel with 𝑀ℓ threads 27 for 𝑘 ← 0 to 𝑀ℓ − 2 do in parallel 28 if 𝐹 ℓ [𝑘] then 29 𝑖 0 ← 𝐼 ℓ [𝑘]; 30 𝑖 1 ← 𝐼 ℓ [𝑘 + 1]; 31 𝑤 0 ← 𝑊ℓ [𝑘]; 32 𝑤 1 ← 𝑊ℓ [𝑘 + 1]; √︁ 33 𝑎 ← 𝑤 0 /(𝑤 0 + 𝑤 1 ); √︁ 34 𝑏 ← 𝑤 1 /(𝑤 0 + 𝑤 1 ); 35 for 𝑐 ← 0 to 𝐶 − 1 do 36 𝑦0 ← 𝑌 [𝑖 0, 𝑐]; 37 𝑦1 ← 𝑌 [𝑖 1, 𝑐]; 38 𝑌 [𝑖 0, 𝑐] ← 𝑎 · 𝑦0 − 𝑏 · 𝑦1 39 𝑌 [𝑖 1, 𝑐] ← 𝑏 · 𝑦0 + 𝑎 · 𝑦1 40 end 41 end 42 end 43 end 44 return 𝑌

27.5

32

28 26 24 22

0

2

4

(e) flame_steak

6 8 10 Compressed Size (MB)

GS-NFS (Ours) V3-2D LTS-Draco MesonGS G-PCC GT (33.97 dB) 12 14 16

(f) sear_steak

Figure A.2: Rate-distortion curves for N3DV sequences (frame 1). Method

Parameter

Values

#

V3-2D

QP Group size

{0, 1, . . . , 40} 20

41

Octree depth {8, 10, 12}/{12, 14, 16}∗ Num. bits {8, 16} MesonGS Blocks {57, 66} Codebook {2048, 4096} {0, 8, 12, 16} {0, 8, 12, 16} {0, 8, 12, 16} {0, 8, 12, 16} 10

LTSDraco

eg (geom.) eo (opacity) et (SH) es (scale) Comp. level

G-PCC

Octree depth {8–12}/{12–17}∗ (𝑞𝑟 , 𝑞𝑑 , 𝑞𝑜 ) † 45 selected triples

24

256

225/ 270∗

∗ HiFi4G / N3DV. G-PCC total = octree depths × 45 QP triples. † 𝑞 : QP for remaining attributes, 𝑞 : QP for DC coefficients, 𝑞 : QP for opacity. 𝑟 𝑜 𝑑

Table A.2: Parameter sweep configurations for R-D curve generation.

19

Scene

Method

drjohnson

truck

LTS-Draco MesonGS GS-NFS LTS-Draco MesonGS GS-NFS

Enc. (ms)

Dec. (ms)

PSNR (dB)

Size (MB)

5,084 220,066 165 3,385 319,395 91

2,610 22,421 183 1,792 14,357 108

35.5 32.6 34.4 23.1 22.7 22.4

312.8 40.6 37.8 204.0 27.8 19.0

longdress

soldier

band2

pizza1

Method Draco (CPU) G-PCC (CPU) GS-NFS octree Draco (CPU) G-PCC (CPU) GS-NFS octree Draco (CPU) G-PCC (CPU) GS-NFS octree Draco (CPU) G-PCC (CPU) GS-NFS octree

Enc. (ms)

Dec. (ms)

Size (KB)

126 195 2.9 170 268 3.4 123 325 3.3 137 343 3.3

57 97 1.9 79 136 2.4 54 213 2.6 59 222 2.6

395 195 238 533 273 332 561 526 565 617 572 616

Block size

Enc. (ms)

Dec. (ms)

ΔSize

– – 8192 4096 2048 1024 512 256

143.8 494.2 15.7 8.0 4.1 2.9 2.5 2.5

207.1 447.4 15.0 7.6 4.0 2.4 1.9 2.1

0.0% 0.0% 0.1% 0.2% 0.4% 0.8% 1.5% 2.5%

CPU GPU GPU GPU GPU GPU GPU GPU

Table A.5: RLGR entropy coding latency: CPU vs. GPU with varying block sizes for flame_salmon. Sequence flame_salmon (400K Gauss)

sear_steak (250K Gauss)

Actor1 (130K Gauss)

Method Draco (CPU) G-PCC (CPU) Octree (w/o ANS) Octree (w/ ANS) Draco (CPU) G-PCC (CPU) Octree (w/o ANS) Octree (w/ ANS) Draco (CPU) G-PCC (CPU) Octree (w/o ANS) Octree (w/ ANS)

Enc. (ms)

Dec. (ms)

Comp Ratio

98.0 228.6 2.9 3.2 64.9 294.8 2.9 3.2 30.7 127.8 1.8 1.9

37.5 127.5 2.4 2.7 28.1 204.3 3.0 3.1 13.0 91.2 1.4 1.6

10.9× 11.3× 6.6× 11.2× 5.1× 5.2× 2.5× 4.8× 6.7× 6.8× 3.4× 6.1×

0 3 0 2 0 2

Tot. ch

PyTorch (ms)

CUDA (ms)

Speedup

11 56 11 35 11 35

77 100 101 125 79 96

20 28 31 57 25 47

3.9× 3.6× 3.3× 2.2× 3.2× 2.0×

Sequence

Compressed Size (MB) RGB YUV KLT

flame_salmon sear_steak Actor1

11.94 9.29 10.97

11.37 8.99 10.43

8.35 6.78 9.90

Relative Ratio RGB/KLT YUV/KLT 1.43 1.37 1.11

1.36 1.33 1.05

Table A.8: Impact of color decorrelation on compressed size (megabytes).

Table A.4: Position-only octree encoding on point-cloud sequences. Encode/decode in ms, size in KB, averaged per frame. Variant

SH degree

Actor1 Actor1 flame_salmon flame_salmon sear_steak sear_steak

Table A.7: RAHT decode latency on Jetson Orin (ms). CUDA vs. PyTorch implementation. Averaged across sampled frames.

Table A.3: Static 3DGS scene compression. PSNR, SSIM, and LPIPS computed on rendered test views. Sequence

Sequence

Table A.6: Octree compression: CPU-based methods vs GS-NFS’s octree codec.

20