Pith. sign in

REVIEW 5 major objections 7 minor 42 references

Virtual Memory for 3D Gaussian Splatting

T0 review · 5 major / 7 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper proposes rendering page IDs on a proxy mesh to a visibility buffer so that only visible Gaussian pages are streamed to the GPU, bounding memory use and accelerating rendering.

desk verdict Solid new application of virtual texturing to 3DGS, with an honest but incomplete evaluation that omits transparent scenes. read the letter →

arxiv 2506.19415 v1 pith:G4YTEFU5 submitted 2025-06-24 cs.GR cs.CVcs.HC

Jonathan Haberl , Philipp Fleck , Clemens Arth This is my paper
classification cs.GRcs.CVcs.HC
keywords 3DGaussianSplattingvirtualmemorytexturingvisibilitybufferlevelofdetailGPUstreamingocclusioncullingnovelviewsynthesis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that the memory bottleneck of large 3D Gaussian Splatting scenes can be broken by treating Gaussians as pages in a virtual-memory system. Borrowing the tile-streaming ideas of virtual texturing, offline preprocessing extracts a coarse proxy mesh, assigns every Gaussian to a page, marks mesh faces with page IDs, links overlapping pages, and builds coarser LOD levels per page. At render time, the proxy mesh is drawn to a small visibility buffer that records which page IDs are visible, and those pages, plus their linked neighbors, are the only Gaussians streamed into GPU memory. The paper claims this keeps GPU memory bounded and speeds up rendering, especially for large, heavily occluded scenes, and demonstrates the pipeline on desktop and mobile hardware.

What carries the argument

The central object is the page-ID visibility buffer: a low-resolution render of the proxy mesh in which each fragment outputs the ID of the Gaussian page covering that mesh face. This buffer converts occlusion into an explicit selection step, because the pixels it contains name exactly the pages that can contribute to the final image. Around it sits a page table that maps virtual pages to physical GPU pages, uses least-recently-used eviction, and stores per-page LOD information; page links, found by random sampling inside ellipsoids and checking the nearest proxy face, ensure that overlapping Gaussians on neighboring pages are requested together. The proxy mesh itself is built from plane-ellipsoid intersections cleaned with morphological operations and reconstructed with Marching Cubes, and the LOD levels are created by k-means clustering of Gaussian attributes followed by averaging.

What would settle it

Take a scene with a known Gaussian whose mean lies on an occluded page but whose visible tail extends into a neighboring page, render it with page links disabled and a deliberately small visibility buffer, and check whether the final image shows a hole; the paper's own ablation, in which disabling links drops PSNR from 42.89 dB to 35.02 dB, is already a strong version of this test.

Watch

Extended reading notes

Core claim

The central claim is that a 3D Gaussian Splatting scene can be rendered within a strict GPU memory budget by selecting Gaussians through a visibility-buffer page table instead of loading the whole scene. Preprocessing converts the scene into a simplified proxy mesh, groups Gaussians into pages by position, links pages whose ellipsoids overlap, and generates several LOD levels per page by clustering and averaging Gaussian attributes. Each frame, the proxy mesh is rendered with page IDs into a low-resolution visibility buffer; a compute shader reduces that buffer to the list of required pages, the page table uploads missing pages and evicts least-recently-used ones, and the LOD level for each page is chosen from its closest pixel depth. The paper reports that this selection reduces memory use and rendering time on the test scenes, with the largest gains when occlusion is abundant, and that page links are required to avoid visible artifacts.

Load-bearing premise

The method assumes that a coarse proxy mesh captures the scene's occlusion structure accurately enough, and that the random-sampling page-link test catches every overlap between Gaussian pages, so that every Gaussian that contributes to the image is on a page the visibility buffer requests.

Editorial extensions

If this is right

  • A scene larger than GPU memory can be rendered with a fixed-size GPU buffer, because only pages visible from the current camera position are resident at any time.
  • Occluded environments benefit most: the visibility buffer removes Gaussians hidden behind other structure, which frustum culling alone cannot do.
  • When the GPU buffer is under pressure, the adaptive LOD mechanism pushes level transitions closer to the camera, trading distant detail for a hole-free frame.
  • The method accepts standard 3D Gaussian Splatting scenes without retraining, so existing reconstructions can be preprocessed and rendered at larger scale.
  • The page table and visibility buffer add only a small fraction of frame time compared with the depth sorting and splatting they save.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the visibility buffer sees only what the proxy mesh exposes, scenes with heavy transparency would need pinned pages on transparent surfaces; the paper lists this as future work, and a coarse depth channel in the buffer would make the fix straightforward.
  • Replacing the random-sampling page-link heuristic with a bounding-volume hierarchy over Gaussian extents would likely make links both cheaper and more complete, directly attacking the main source of missing pages.
  • The same page-table structure could serve any scene representation that can provide an occlusion proxy, so the idea extends beyond Gaussian splats to hybrid mesh-radiance-field renderers.
  • Pushing page assignment and proxy-mesh construction into the training stage, instead of running them as an offline post-process, would remove the hour-scale preprocessing the largest test scene requires and could optimize pages for few links from the start.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 7 minor

Summary. The paper presents a virtual-memory system for rendering 3D Gaussian Splatting scenes that exceed GPU memory. An offline stage extracts a proxy mesh from the Gaussian ellipsoids, assigns Gaussians to pages, links overlapping pages, and builds LOD levels by k-means merging. At runtime, the proxy mesh is rendered to a low-resolution visibility buffer of page IDs; the resulting page list, augmented by links, drives a page table that streams required pages into a bounded GPU buffer, with LRU eviction and distance-based LOD selection. The system is implemented in Vulkan and ported to iOS via MoltenVK, and evaluated on four scenes (SciArt, Residence, Alameda, Berlin) on a GTX 1070 desktop and an iPad Pro M1. The paper reports that the method reduces GPU memory and frame times relative to rendering the full scene without virtual memory.

Significance. If the claims hold, the paper offers a practical mechanism for rendering 3DGS scenes larger than GPU memory, borrowing mature virtual-texturing technology. The authors provide a full implementation, a mobile port, and ablation studies that isolate page linking, LOD, buffer size, and page size; they also clearly identify several limitations (low-resolution visibility buffer, lack of LOD blending, transparency). The contribution is incremental but useful: it is one of the first to apply occlusion-based page streaming rather than frustum-only streaming to 3DGS. However, the central assertion that the method 'efficiently identifies visible Gaussians' is only demonstrated for the tested opaque scenes; the transparency limitation and the approximate page-linking heuristic are load-bearing and need stronger validation before the contribution can be fully accepted.

major comments (5)
  1. [Sec. 4.1, Sec. 4.3] The page-determination stage is an opaque-surface test: page IDs are rendered on the proxy mesh with ordinary depth testing, so any face behind another face is treated as occluded. 3DGS, however, composites Gaussians with alpha blending, so semi-transparent structures do not fully hide the Gaussians behind them; those background pages will be marked invisible and never streamed, creating holes. The manuscript acknowledges this in Sec. 4.3 ('Transparency challenges in page determination echo traditional virtual texturing issues'), but the abstract and Sec. 4.1 still claim the method 'efficiently identifies visible Gaussians.' This is a load-bearing gap: either restrict the claim to opaque scenes, evaluate a scene with significant transparency, or implement the suggested pinning of transparent pages.
  2. [Sec. 3.3, Table 2] Page linking is the mechanism that repairs missed visibility, but its correctness is not established. Links are found by generating random points inside each ellipsoid and checking only the nearest proxy-mesh face; the paper gives no sampling density, no convergence criterion, and no analysis of failure modes. Table 2 shows how much depends on this heuristic: disabling page links drops PSNR from 42.89/47.19 to 35.02, and Figure 16 shows visible artifacts. Because the central claim is that the visibility buffer plus links returns the exact set of pages needed for artifact-free rendering, please provide an empirical sensitivity analysis (number of samples per ellipsoid, number of nearest faces) and, on a small scene, compare against exhaustive ellipsoid-intersection testing.
  3. [Table 2] The rows 'Without page links, with LOD' and 'Without page links, without LOD' report identical PSNR (35.02) and SSIM (0.97) values. Either this is a copy-paste error or LOD has no effect when page links are disabled; in either case the table must be corrected and the result explained, since Table 2 is the main evidence for the contribution of page linking.
  4. [Sec. 5] The quantitative evaluation compares only ablations of the proposed method and does not include any existing large-scene 3DGS system as a baseline (e.g., CityGaussian [20], Hierarchical 3DGS [15], or a full-scene non-streaming renderer on the same hardware). All timings are medians with no error bars or repeated-run variance, despite the acknowledged nondeterminism of the adaptive LOD thresholds (Sec. 5.2). To support the claims of reduced memory and accelerated rendering, please report mean/median with variance over multiple runs and, where feasible, compare against a published system or a clear non-streaming baseline.
  5. [Sec. 4.3, Table 4] The paper acknowledges that rendering the visibility buffer at low resolution 'can cause distant pages to be missed' (Sec. 4.3). This is not peripheral: the streaming decision is based entirely on that buffer, so a missed distant page translates directly into holes in the final image. Page links only cover geometric overlap, not visibility through distant gaps. Please add a quantitative study of visibility-buffer resolution versus the 'Missing Pages' metric introduced in Table 4, and either bound the resolution error or relax the claim of exact visibility identification.
minor comments (7)
  1. [Sec. 5.1.3] The heading 'Synchronsitaion' is a typo for 'Synchronization'.
  2. [Table 2] The table caption uses 'ArtSci' while Figure 13 and the text call the scene 'SciArt'; please unify the naming.
  3. [Table 4] The 'Missing Pages' metric is not defined; with a 250-page buffer, a value of 549 suggests it counts repeated requests or page faults rather than unique missing pages, so please define it in the text.
  4. [Table 1] The text around Table 1 is inconsistent about storage overhead: it says the overhead is negligible, but the final file size for SciArt (1505.5 MiB) is nearly double its initial size (804.9 MiB) due to padding and LOD levels; please clarify that 'overhead' refers only to the mesh/links file and state the LOD storage cost explicitly.
  5. [Sec. 3.1] In Equation (1), the symbols v_z, s, and n are not defined at first use; please define them in the text before or immediately after the equation.
  6. [Figures 20 and 21] The stacked time-segment bars are not accompanied by an explicit legend or color key; please add a legend so the reader can map each segment to the stages described in the text.
  7. [Sec. 5.3.2] The claim that frame times decrease as the number of pages decreases is based on unsmoothed FPS; please report a correlation coefficient or a smoothed plot to support the relationship.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: visible-page determination is an implemented heuristic validated by image-quality ablations, not a claim true by construction.

full rationale

The paper's central claim is that rendering page IDs of a proxy mesh into a visibility buffer, together with page links, identifies the Gaussian pages required for the final image. This is not circular, because the claim is not true by definition: the correctness of the identified page set is checked empirically against full-scene renders using PSNR/SSIM, and the paper's own ablation (Table 2) shows that disabling page links degrades PSNR from 42.89/47.19 to 35.02. Thus the page-selection mechanism is validated by its downstream image quality rather than being defined to match the output. The 50-80% memory-usage target in Section 5.1.1 is an explicit adaptive control goal, not a fitted parameter later repackaged as a prediction; memory and frame-time results are direct measurements. The page-linking heuristic using random points inside ellipsoids and nearest proxy-mesh faces is approximate, and the paper explicitly acknowledges its failure modes in Section 4.3 (low-resolution visibility buffer can miss distant pages) and in the Conclusion (transparency challenges in page determination). These are legitimate correctness risks, not hidden circularity. The only self-citation, Haberl [10], is referenced in Section 5.1 as a source of more in-depth implementation description and is not load-bearing for the method's correctness or for any derived result. The paper does not claim a first-principles derivation; it is an empirical systems contribution, and no step in its derivation chain reduces by construction to its own inputs.

Assumptions & free parameters 6 free parameters · 5 assumptions · 0 invented entities

The central claim rests on several hand-chosen system parameters (page size, staging buffer, LOD merge factor, visibility buffer resolution) and on two heuristics: proxy-mesh visibility and random-sampling page linking. No fatal circularity is present; these are engineering choices, not fitted predictions. No new physical entities are postulated.

free parameters (6)
  • Page size = 2048 Gaussians
    Chosen based on Table 3 tradeoff between page table update cost and cache locality/render time. Affects performance and memory tradeoffs.
  • Staging buffer size = ~18.4 MiB (40 pages)
    Chosen to balance copy delays; affects streaming stalls and artifact frequency.
  • LOD fixed scale-up factor
    Applied to merged Gaussians to fill gaps after averaging; no value given. Directly affects LOD visual quality.
  • k-means attribute weights
    Position attributes are prioritized, but exact scaling weights are not specified; affects LOD clustering quality.
  • Adaptive LOD threshold step size = 1% adjustment
    Step size increases by 1% after successive similar adjustments and decreases by 1% on direction changes; affects LOD stability.
  • Visibility buffer resolution
    Described as 'much smaller than the final rendering' but no concrete resolution is given; low resolution can cause distant pages to be missed.
assumptions (5)
  • standard math Hartmann's ellipsoid-plane intersection method and Marching Cubes produce a valid proxy mesh.
    Invoked in Sections 3.1 and used throughout preprocessing. Standard computational geometry, accepted background.
  • domain assumption The proxy mesh generated from axis-aligned slice intersections is a faithful visibility proxy for occluded Gaussians.
    The entire visibility buffer idea relies on this. Section 3.1 builds the mesh, Section 4.1 uses it per frame. Not proven; the paper acknowledges low-resolution misses.
  • ad hoc to paper Random point sampling within each ellipsoid followed by nearest-face lookup discovers all page overlaps that matter for visual quality.
    Section 3.3 explicitly calls this 'approximate' and uses it to avoid O(n^2) linking. Missed overlaps cause artifacts, as shown in Table 2 and Figure 16.
  • ad hoc to paper Merging Gaussians by averaging attributes and scaling up by a fixed factor produces acceptable LOD levels.
    Section 3.4 describes the LOD merge. Section 5.2 admits LOD can lower quality and create artifacts near the camera.
  • domain assumption The global sort plus hardware rasterizer pipeline is a fair baseline for comparing virtual memory on and off.
    Section 5.3 compares only against the authors' own renderer without virtual memory, not against external systems, so the measured speedups are not benchmarked against prior art.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Virtual Memory for 3D Gaussian Splatting." pith.science (2026). https://pith.science/paper/G4YTEFU5

@misc{pith2026250619415,
  author       = {Pith},
  title        = {Pith review of: Virtual Memory for 3D Gaussian Splatting},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/G4YTEFU5}},
  note         = {Machine review of arXiv:2506.19415}
}
read the original abstract

3D Gaussian Splatting represents a breakthrough in the field of novel view synthesis. It establishes Gaussians as core rendering primitives for highly accurate real-world environment reconstruction. Recent advances have drastically increased the size of scenes that can be created. In this work, we present a method for rendering large and complex 3D Gaussian Splatting scenes using virtual memory. By leveraging well-established virtual memory and virtual texturing techniques, our approach efficiently identifies visible Gaussians and dynamically streams them to the GPU just in time for real-time rendering. Selecting only the necessary Gaussians for both storage and rendering results in reduced memory usage and effectively accelerates rendering, especially for highly complex scenes. Furthermore, we demonstrate how level of detail can be integrated into our proposed method to further enhance rendering speed for large-scale scenes. With an optimized implementation, we highlight key practical considerations and thoroughly evaluate the proposed technique and its impact on desktop and mobile devices.

Figures

Figures reproduced from arXiv: 2506.19415 by the authors.

Figure 1
Figure 1. 3D Gaussian Splatting scene of a truck. The scene is provided by [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 3
Figure 3. The image depicts a red ellipsoid with its blue intersection plane, [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. 2D demonstration of a Gaussian, which has been assigned to [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figures from the paper (15 more)
Figure 6
Figure 6. Figure 6: Gaussians are clustered based on their properties, then averaged. [PITH_FULL_IMAGE:figures/full_fig_p004_6.png]
Figure 7
Figure 7. Figure 7: Visualization of the page table entry for a single physical page. [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]
Figure 9
Figure 9. Figure 9: The area resulting in discarded pixels when drawing a long, thin [PITH_FULL_IMAGE:figures/full_fig_p006_9.png]
Figure 10
Figure 10. Figure 10: Rendered primitives are shaded based on the ID of their page. [PITH_FULL_IMAGE:figures/full_fig_p006_10.png]
Figure 11
Figure 11. Figure 11: High-level overview of the stages of rendering with virtual memory. Orange bars indicate synchronization between CPU and GPU. Each step [PITH_FULL_IMAGE:figures/full_fig_p007_11.png]
Figure 12
Figure 12. Figure 12: Our implementation running on an iPad Pro. The application [PITH_FULL_IMAGE:figures/full_fig_p007_12.png]
Figure 13
Figure 13. Figure 13: Example images of the evaluated scenes: SciArt and Residence are taken from the UrbanScene3D [19] dataset and trained with VastGaussian [18]. And Alameda and Berlin are from Zip-NeRF [2] and trained with Nerfstudio [33]. Scene Initial Size [MiB] Pages Links File Size …
Figure 14
Figure 14. Figure 14: Similar quality, smaller memory footprint: To avoid creating holes [PITH_FULL_IMAGE:figures/full_fig_p008_14.png]
Figure 15
Figure 15. Figure 15: Images with the same camera position and settings, rendered with ablations of our method (left). Images on the right compare these to the [PITH_FULL_IMAGE:figures/full_fig_p009_15.png]
Figure 16
Figure 16. Figure 16: No Page Links leading only the pages of Gaussians determined [PITH_FULL_IMAGE:figures/full_fig_p009_16.png]
Figure 17
Figure 17. Figure 17: Memory usage during a fly-through in the scene "Residence" [PITH_FULL_IMAGE:figures/full_fig_p009_17.png]
Figure 18
Figure 18. Figure 18: Memory usage during a fly-through in the scene "Alameda" with [PITH_FULL_IMAGE:figures/full_fig_p010_18.png]
Figure 20
Figure 20. Figure 20: The time taken for various steps with virtual memory as well as [PITH_FULL_IMAGE:figures/full_fig_p010_20.png]
Figure 23
Figure 23. Figure 23: Time taken to render a frame with the median of each stage on [PITH_FULL_IMAGE:figures/full_fig_p011_23.png]
Figure 22
Figure 22. Figure 22: Comparison of the time taken to render frames on desktop and [PITH_FULL_IMAGE:figures/full_fig_p011_22.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

42 extracted references · 22 canonical work pages

  1. [20]

    Y . Liu, H. Guan, C. Luo, L. Fan, N. Wang, J. Peng, and Z. Zhang. Citygaus- sian: Real-time high-quality large-scale scene rendering with gaussians. (arXiv:2404.01133), July 2024. arXiv:2404.01133 [cs]. doi: 10.48550/ arXiv.2404.01133 2

    arXiv doi:10.48550/arxiv.2404.01133 2024

  2. [15]

    Kerbl, A

    B. Kerbl, A. Meuleman, G. Kopanas, M. Wimmer, A. Lanvin, and G. Dret- takis. A hierarchical 3d gaussian representation for real-time rendering of very large datasets.ACM Transactions on Graphics, 43(4):1–15, July

    work page

  3. [1]

    S. Barrett. Sparse virtual textures. https://silverspaceship.com/ src/svt/, 2008. Accessed: 2024-06-04. 3, 5

    work page 2008

  4. [2]

    J. T. Barron, B. Mildenhall, D. Verbin, P. P. Srinivasan, and P. Hedman. Zip-nerf: Anti-aliased grid-based neural radiance fields.ICCV, 2023. 8

    work page 2023

  5. [3]

    H. Chen, C. Li, and G. H. Lee. Neusg: Neural implicit surface reconstruc- tion with 3d gaussian splatting guidance. (arXiv:2312.00846), Dec. 2023. arXiv:2312.00846 [cs]. 2

    arXiv 2023

  6. [4]

    Z. Fan, K. Wang, K. Wen, Z. Zhu, D. Xu, and Z. Wang. Lightgaussian: Unbounded 3d gaussian compression with 15x reduction and 200+ fps. (arXiv:2311.17245), Feb. 2024. arXiv:2311.17245 [cs]. 2

    arXiv 2024

  7. [5]

    Frumusanu

    A. Frumusanu. The 2020 mac mini unleashed: Putting apple sil- icon m1 to the test. https://www.anandtech.com/show/16252/ mac-mini-apple-m1-tested, 2020. Accessed: 2024-10-18. 10

    work page 2020

  8. [6]

    L. Gao, J. Yang, B.-T. Zhang, J.-M. Sun, Y .-J. Yuan, H. Fu, and Y .-K. Lai. Mesh-based gaussian splatting for real-time large-scale deformation. (arXiv:2402.04796), Feb. 2024. arXiv:2402.04796 [cs]. 2

    arXiv 2024

Show all 42 references
  1. [7]

    Girish, K

    S. Girish, K. Gupta, and A. Shrivastava. Eagles: Efficient accelerated 3d gaussians with lightweight encodings. (arXiv:2312.04564), Dec. 2023. arXiv:2312.04564 [cs]. 2

    2023 arXiv

  2. [8]

    T. K. Group. Khronos vulkan portability initiative. https://www. khronos.org/vulkan/portability-initiative, 2024. Accessed: 2024-10-15. 7

    2024

  3. [9]

    Guédon and V

    A. Guédon and V . Lepetit. Sugar: Surface-aligned gaussian splatting for efficient 3d mesh reconstruction and high-quality mesh rendering. (arXiv:2311.12775), Dec. 2023. arXiv:2311.12775 [cs]. 2

    2023 arXiv

  4. [10]

    Haberl.Virtual memory for 3D Gaussian Splatting

    J. Haberl.Virtual memory for 3D Gaussian Splatting. Master’s Thesis, Institute of Visual Computing, Graz University of Technology, Inffeldgasse 16/2, A-8010 Graz, Austria, Dec. 2024. doi: 10.3217/xstz7-q3q02 6

    2024 doi

  5. [11]

    J. Hable. Variable rate shading with visibility buffer render- ing. https://advances.realtimerendering.com/s2024/index. html#hable, 2024. Accessed: 2024-08-07. 6

    2024

  6. [12]

    Hartmann

    E. Hartmann. Computerunterstützte darstellende und konstruktive geome- trie. https://www2.mathematik.tu-darmstadt.de/~ehartmann/ cdg-skript-1998.pdf, 1997. Accessed: 2024-09-09. 3

    1998

  7. [14]

    Kerbl, G

    B. Kerbl, G. Kopanas, T. Leimkuehler, and G. Drettakis. 3D Gaussian Splatting for Real-Time Radiance Field Rendering.ACM Transactions on Graphics, 42(4):1–14, Aug. 2023. doi: 10.1145/3592433 1, 2, 5, 6, 11

    2023 doi

  8. [16]

    J. C. Lee, D. Rho, X. Sun, J. H. Ko, and E. Park. Compact 3d gaus- sian representation for radiance field. (arXiv:2311.13681), Nov. 2023. arXiv:2311.13681 [cs]. 2

    2023 arXiv

  9. [17]

    doi: 10.1145/3658160 2, 8, 11

    doi

  10. [18]

    J. Lin, Z. Li, X. Tang, J. Liu, S. Liu, J. Liu, Y . Lu, X. Wu, S. Xu, Y . Yan, and W. Yang. Vastgaussian: Vast 3d gaussians for large scene reconstruction. (arXiv:2402.17427), Feb. 2024. arXiv:2402.17427 [cs]. doi: 10.48550/ arXiv.2402.17427 2, 8

    2024 doi arXiv

  11. [19]

    Z. Li, Z. Chen, Z. Li, and Y . Xu. Spacetime gaussian feature splatting for real-time dynamic view synthesis. (arXiv:2312.16812), Dec. 2023. arXiv:2312.16812 [cs]. 2

    2023 arXiv

  12. [21]

    L. Lin, Y . Liu, Y . Hu, X. Yan, K. Xie, and H. Huang. Capturing, recon- structing, and simulating: the urbanscene3d dataset. (arXiv:2107.04286), July 2022. arXiv:2107.04286 [cs]. 8

    2022 arXiv

  13. [22]

    T. Lu, M. Yu, L. Xu, Y . Xiangli, L. Wang, D. Lin, and B. Dai. Scaffold-gs: Structured 3d gaussians for view-adaptive rendering. (arXiv:2312.00109), Nov. 2023. arXiv:2312.00109 [cs]. 2

    2023 arXiv

  14. [23]

    W. E. Lorensen and H. E. Cline. Marching cubes: A high resolution 3d surface construction algorithm. InProceedings of the 14th Annual Confer- ence on Computer Graphics and Interactive Techniques, SIGGRAPH ’87, 7 pages, p. 163–169. Association for Computing Machinery, New York,...

    1987

  15. [24]

    Mittring and C

    M. Mittring and C. GmbH. Advanced virtual texture topics. InACM SIGGRAPH 2008 Games, SIGGRAPH ’08, 29 pages, p. 23–51. Asso- ciation for Computing Machinery, New York, NY , USA, 2008. doi: 10. 1145/1404435.1404438 4

    2008

  16. [25]

    A. J. Mayer.Virtual Texturing. Master’s Thesis, Institute of Computer Graphics and Algorithms, Vienna University of Technology, Favoriten- strasse 9-11/E193-02, A-1040 Vienna, Austria, Oct. 2010. 3, 6, 11

    2010

  17. [26]

    Apple ipad pro 11" (3rd gen, 2021)

    NanoReview.net. Apple ipad pro 11" (3rd gen, 2021). https://nanoreview.net/en/tablet/ apple-ipad-pro-11-3rd-gen-2021?m=r.1 , 2021. Accessed: 2024-10-18. 10

    2021

  18. [27]

    Morgenstern, F

    W. Morgenstern, F. Barthel, A. Hilsmann, and P. Eisert. Compact 3d scene representation via self-organizing gaussian grids. (arXiv:2312.13299), Dec. 2023. arXiv:2312.13299 [cs]. 2

    2023 arXiv

  19. [28]

    Niedermayr, J

    S. Niedermayr, J. Stumpfegger, and R. Westermann. Compressed 3d gaus- sian splatting for accelerated novel view synthesis. (arXiv:2401.02436), Jan. 2024. arXiv:2401.02436 [cs]. 2

    2024 arXiv

  20. [29]

    Navaneet, K

    K. Navaneet, K. Pourahmadi Meibodi, S. Koohpayegani, and H. Pirsiavash. Compact3D: Compressing Gaussian Splat Radiance Field Models with Vector Quantization. Jan. 2024. 2

    2024

  21. [30]

    Pranckeviˇcius

    A. Pranckeviˇcius. Making gaussian splats smaller. https://aras-p. info/blog/2023/09/13/Making-Gaussian-Splats-smaller/ , Sep 2023. Accessed: 2024-06-04. 2

    2023

  22. [31]

    Pranckevi ˇcius

    A. Pranckevi ˇcius. Making gaussian splats more smaller. https://aras-p.info/blog/2023/09/27/ Making-Gaussian-Splats-more-smaller/ , Sep 2023. Accessed: 2024-04-06. 2

    2023

  23. [32]

    Richermoz

    A. Richermoz. Sparse texture binding is painfully slow. https://forums.developer.nvidia.com/t/ sparse-texture-binding-is-painfully-slow , 2023. Accessed: 2024-09-01. 5

    2023

  24. [33]

    K. Ren, L. Jiang, T. Lu, M. Yu, L. Xu, Z. Ni, and B. Dai. Octree-gs: Towards consistent real-time rendering with lod-structured 3d gaussians. (arXiv:2403.17898), Mar. 2024. arXiv:2403.17898 [cs]. 2

    2024 arXiv

  25. [34]

    Tatarchuk

    N. Tatarchuk. Welcome and introduction – trends in games and render- ing. https://advances.realtimerendering.com/s2024/index. html#intro, 2024. Accessed: 2024-08-20. 7

    2024

  26. [35]

    Tancik, E

    M. Tancik, E. Weber, E. Ng, R. Li, B. Yi, J. Kerr, T. Wang, A. Kristof- fersen, J. Austin, K. Salahi, A. Ahuja, D. McAllister, and A. Kanazawa. Nerfstudio: A modular framework for neural radiance field development. InACM SIGGRAPH 2023 Conference Proceedings, SIGGRAPH ’23,

    2023

  27. [36]

    Moltenvk

    The Brenwill Workshop Ltd. Moltenvk. https://github.com/ KhronosGroup/MoltenVK, 2015. Accessed: 2024-09-24. 5

    2015

  28. [37]

    Nvidia geforce gtx 1070

    techpowerup.com. Nvidia geforce gtx 1070. https://www. techpowerup.com/gpu-specs/geforce-gtx-1070.c2840 , 2024. Accessed: 2024-10-18. 10

    2024

  29. [38]

    S. Willems. Hardware capability database for vulkan. http://vulkan. gpuinfo.org, 2016. Accessed: 2024-09-24. 5

    2016

  30. [39]

    Waczy´nska, P

    J. Waczy´nska, P. Borycki, S. Tadeja, J. Tabor, and P. Spurek. Games: Mesh- based adapting and modification of gaussian splatting. (arXiv:2402.01459), Feb. 2024. arXiv:2402.01459 [cs]. 2

    2024 arXiv

  31. [40]

    Y . Yuan, X. Li, Y . Huang, S. De Mello, K. Nagano, J. Kautz, and U. Iqbal. Gavatar: Animatable 3d gaussian avatars with implicit mesh learning. (arXiv:2312.11461), Dec. 2023. arXiv:2312.11461 [cs]. 2

    2023 arXiv

  32. [41]

    Z. Yan, W. F. Low, Y . Chen, and G. H. Lee. Multi-scale 3d gaussian splatting for anti-aliased rendering. (arXiv:2311.17089), Nov. 2023. arXiv:2311.17089 [cs]. 2, 4, 11

    2023 arXiv

  33. [43]

    H. Zhao, H. Weng, D. Lu, A. Li, J. Li, A. Panda, and S. Xie. On scal- ing up 3d gaussian splatting training. (arXiv:2406.18533), June 2024. arXiv:2406.18533 [cs]. 2

    2024

  34. [2024]

    arXiv:2403.11367 [cs]. 2

    arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.