Source-linked AI summary
MeshSplatBench: A Unified Benchmark for Triangle-Based Neural Rendering
Kaixuan Zhang, Minxian Li, Mingwu Ren, Xiatian Zhu
TL;DR
Triangle-based neural rendering is difficult to assess for production because existing evaluations largely remain inside specialized research renderers. MeshSplatBench standardizes the full path from native optimization to Unity deployment while preserving native semantics, revealing deployment-dependent quality and topology problems. Its results show that rasterizability alone does not ensure graphics readiness.
Problem
Existing triangle-based methods are evaluated mainly in custom CUDA renderers, leaving practical engine deployability and fair cross-method comparison insufficiently characterized.
Method
MeshSplatBench standardizes native evaluation and uses a three-tier Unity protocol plus an auditable .triasset interface to compare native, dedicated, and default rendering conditions.
Results
The benchmark reproduces published native PSNR values within 0.8% maximum relative deviation, while deployment causes quality gaps, ranking inversions, and topology defects.
Takeaways & Limitations
Graphics readiness requires joint alignment of representation, topology, appearance, boundary behavior, compositing, and engine compatibility rather than rasterizable primitives alone.
Takeaways & Limitations
Dedicated Unity support does not exactly reproduce native per-camera sorting, and DiffSoup’s ColorMLP is not implemented; default rendering discards higher-order appearance, learned opacity, and soft coverage.
Abstract
from arXiv · showhide
Triangle-based neural rendering bridges neural scene representations and conventional graphics pipelines by optimizing explicit geometric primitives compatible with standard rasterization hardware. However, existing approaches are evaluated almost exclusively within custom research renderers, obscuring their practical deployability in production engines. To bridge this gap, we introduce \textbf{MeshSplatBench}, a unified benchmark that systematically investigates triangle-based neural rendering across the complete pipeline from native optimization to game-engine deployment. MeshSplatBench establishes a standardized evaluation protocol while preserving each method's native optimization semantics, reproducing published results within $0.8\%$ PSNR deviation. Furthermore, we introduce a hierarchical Unity deployment protocol spanning three rendering tiers: native CUDA renderers, method-specific dedicated engine shaders, and standard opaque mesh pipelines, isolating the exact fidelity losses caused by engine adaptation \textit{vs.} representation reduction. Finally, we conduct a topological audit of reconstructed surfaces, demonstrating that explicit connectivity and shared indexing alone are insufficient to guarantee production-ready assets due to prevalent non-manifold structures, fragmented components, and boundary artifacts. Overall, MeshSplatBench demonstrates that rasterizability is merely a primitive-level attribute, whereas graphics readiness requires jthe holistic alignment of representation, topology, and engine compatibility. Source code will be released.
1 INTRODUCTION
Triangle-based rendering offers hardware-compatible geometry, but practical deployment depends on specialized appearance and compositing behavior, standardized evaluation, and mesh topology. MeshSplatBench evaluates these factors across native and Unity conditions, finding substantial deployment gaps and renderer-dependent rankings.
- Motivation: Triangle primitives are directly expressible by modern rasterizers, yet production appearance may depend on soft coverage, learned opacity, view-dependent SHs, neural decoders, and custom ordering.These mechanisms make rasterizable geometry insufficient as a graphics-ready asset.
- Motivation: Existing evaluations largely use custom CUDA renderers, while inconsistent compositing policies and metric implementations hinder fair comparisons and obscure engine deployability.Native NVS metrics therefore characterize both representations and specialized rendering kernels.
- Topological audit: Indexed connectivity does not ensure production-ready geometry: MeshSplatting assets retain open boundaries, non-manifold structures, and fragmentation.The audit targets whether shared vertices yield well-formed meshes, while the benchmark also finds no method dominates all evaluated metrics.
- Benchmark contribution: MeshSplatBench standardizes evaluation while preserving native optimization loops and reproduces published native PSNR values with maximum relative deviation below 0.8%.Dataset splits, camera calibration, background policies, resolutions, and metric implementations are standardized.
- Deployment protocol: The Unity protocol compares Native, Dedicated, and Default conditions to separate engine adaptation from representation reduction using matched viewpoints.Dedicated Unity supports method-specific shaders, while Default Unity reduces assets to opaque meshes with hardware Z-buffering.
- Findings: Up to 4.88 dB of PSNR adaptation loss occurs, and native method rankings can invert under standard mesh constraints.2DTS leads MeshSplatting natively by 3.44 dB but falls below it on default mesh paths.
2 RELATED WORK
Related work spans neural representations, triangle-based primitives, mesh conversion, and native benchmarking. MeshSplatBench extends these directions by evaluating post-deployment behavior and graphics readiness beyond image-space metrics.
- Neural scene representations: NeRFs use continuous volumetric integration, while 3DGS enables real-time rasterization with explicit anisotropic Gaussian primitives.Both remain tied to specialized rendering pipelines despite strong visual fidelity.
- Triangle-based representations: Triangle-based methods optimize geometry expressible by hardware rasterizers and include both disconnected triangle soups and connected indexed-surface paradigms.The cited paradigms include 2DTS, Triangle-Splatting, and MeshSplatting.
- Cross-cutting issue: Learned opacity, SHs, boundary anti-aliasing, and depth compositing determine how much specialized engine support is required after export.These attributes distinguish geometric representation from rendering behavior.
- Neural asset deployment: Mesh conversion methods bake or extract deployable polygon meshes from implicit fields, Gaussian splats, or other neural representations for lightweight shader execution.Examples include MobileNeRF, BakedSDF, SuGaR, and GaMeS.
- Benchmarks: Existing benchmarks establish rigorous native evaluation but leave post-deployment behavior unexamined because they operate within research environments and focus on image-space metrics.MeshSplatBench addresses this omitted deployment dimension.
3 MESHSPLATBENCH: BENCHMARK DESIGN
MeshSplatBench combines standardized measurement with native-semantic preservation and an auditable asset interface. Its design evaluates reproduction, native performance, engine deployment, and graphics readiness across the pipeline.
- Standardization: The benchmark standardizes preprocessing, calibrated and evaluation cameras, image resolution, background policy, color handling, and NVS metrics while preserving each method’s official optimization logic.Preserved method-specific elements include training logic, hyperparameters, primitive updates, and topology updates.
- Evaluation dimensions: Four dimensions measure reproduction fidelity, standardized native performance, engine deployment, and graphics readiness.The dimensions cover image quality, efficiency, optimization cost, memory, geometry, renderer-constrained fidelity, runtime, and exported representation properties.
- Asset abstraction: A method adapter maps trained native representations to versioned engine assets through the unified .triasset contract.The adapter produces an asset consumed by the unified execution engine.
- Asset abstraction: The .triasset contract stores geometry, topology, appearance attributes, opacity, coverage parameters, provenance metadata, and explicit markers for unsupported fields.The native checkpoint remains the source of truth, while renderers declare which fields they consume.
4 RENDERER-CONDITIONED ENGINE DEPLOYMENT
The deployment protocol evaluates the same assets and matched cameras under native, dedicated Unity, and default Unity conditions. This hierarchy separates engine adaptation from degradation caused by replacing specialized rendering with generic mesh primitives.
- Matched-view evaluation: Matched camera sets and fixed capture settings enable direct comparison against the same ground-truth images across all three rendering conditions.The protocol records camera transforms, intrinsics, image dimensions, and clipping planes before backend conversion.
- Hierarchical rendering conditions: The native condition measures performance in each method’s official research renderer, while dedicated and default Unity progressively impose practical engine constraints.The default condition uses a standard opaque mesh with vertex color and Z-buffer visibility.
- Deployment gaps: The adaptation gap measures loss from native to dedicated rendering, while the portability gap measures additional degradation from dedicated to default rendering.For lower-is-better metrics such as LPIPS, the sign convention is reversed so positive gaps consistently indicate degradation.
- Feature preservation: Dedicated Unity support does not exactly reproduce native rendering because per-camera primitive sorting and DiffSoup’s ColorMLP are not implemented.Default rendering additionally discards higher-order view dependence, learned opacity, soft coverage, and method-specific compositing.
- Feature preservation: The default condition preserves geometry and, when available, a baked SH-DC color term as a static appearance fallback.Table 2 marks native properties as retained, partially retained, discarded, or inapplicable under dedicated and default Unity conditions.
5 BENCHMARK EVALUATION
MeshSplatBench evaluates triangle-based neural rendering across standardized native benchmarks, renderer-conditioned Unity deployment, and a structural audit of reconstructed meshes. Results show that native fidelity, portability, efficiency, and topology are distinct dimensions, with engine adaptation and representation reduction causing substantial quality changes.
- 5.1 EXPERIMENTAL SETUP AND REPRODUCTION CHECK: Across 27 Mip-NeRF 360 method–scene pairs, reproduced native PSNR values differed from reported results by less than 0.8% relative deviation.The mean absolute difference was 0.075 dB, with a maximum of 0.230 dB.
- 5.2 STANDARDIZED NATIVE BENCHMARK: Native results show no single representation simultaneously dominates image fidelity, throughput, memory, and training time across the evaluated datasets.2DTS leads image fidelity on Mip-NeRF 360 and NeRF-Synthetic, Triangle-Splatting leads two Tanks and Temples image metrics, and DiffSoup leads native FPS and optimization time.
- 5.2 STANDARDIZED NATIVE BENCHMARK: Background policy changes DTU rankings, with different methods leading NVS and geometry metrics under full-image versus foreground evaluation.This separates novel-view fidelity from geometry accuracy as evaluation objectives.
- 5.3 RENDERER-CONDITIONED DEPLOYMENT: Removing method-specific support creates Mip-NeRF 360 portability gaps of 10.76 dB for 2DTS, 8.19 dB for Triangle-Splatting, and 2.69 dB for MeshSplatting.Native ranking reverses under Default Unity: 2DTS leads Native and Dedicated PSNR, while MeshSplatting leads Default Unity.
- 5.3 RENDERER-CONDITIONED DEPLOYMENT: Default Unity reduces rendering to a standard opaque mesh path, producing sub-millisecond GPU times and up to 3754 FPS while dropping non-standard shading and sorting passes.The throughput increase can coincide with severe fidelity loss, including a 15.64 dB drop for 2DTS.
- 5.4 STRUCTURAL ANALYSIS OF MESHSPLATTING: MeshSplatting’s indexed connectivity still exhibits boundaries, non-manifold structures, and fragmentation, with its largest component containing only about 70% of faces and 69% of area.These diagnostics indicate structural irregularities but do not by themselves prove geometric incorrectness.
- 5.4 STRUCTURAL ANALYSIS OF MESHSPLATTING: Graphics readiness requires joint alignment of geometry, topology, appearance, boundary behavior, compositing, and engine compatibility rather than rasterizable primitives alone.The benchmark recommends compact appearance representations, robust boundary modeling, topology optimization, and explicit declaration of unsupported learned fields.
6 CONCLUSION
MeshSplatBench separates native rendering quality from engine portability and evaluates whether connected triangle representations form practical graphics assets. Its results show that rasterizability alone is insufficient for graphics readiness.
- Matched native–dedicated–default evaluation reveals substantial quality gaps and renderer-dependent ranking changes.The protocol separates engine integration from portability to a conventional mesh path.
ETHICS STATEMENT
MeshSplatBench emphasizes responsible use and disclosure for reconstructed or synthetic content.
- Deployed systems should use authorized data, disclose synthetic or reconstructed content, and preserve attribution.
REPRODUCIBILITY STATEMENT
The project plans to release the benchmark implementation and documentation needed to reproduce its evaluation pipeline.
- MeshSplatBench will publicly release code and evaluation configurations covering protocols, assets, rendering conditions, metrics, datasets, and reproduction materials.
A.1 UNITY RENDERER IMPLEMENTATION DETAILS AND KNOWN MISMATCHES
The Unity implementation adapts method-specific features and compositing into dedicated or default rendering paths, but several mismatches remain relative to native CUDA rendering. These include ordering, coverage, view-dependent appearance, and excluded representation fields.
- Dedicated renderer: Dedicated Unity rendering uses method-specific shader branches for blending, spherical harmonics, opacity, and coverage, but does not numerically match native CUDA rendering.
- Primitive order and coverage: Native front-to-back sorting is not reproduced, so overlapping transparent primitives may composite in a different order.Unity preserves primitive index order rather than sorting per camera, and its coverage evaluation also differs from native tile-level processing.
- View-dependent appearance: Unity evaluates view direction at centroids or corners rather than reproducing native per-pixel ray evaluation exactly.DiffSoup’s Unity path remains partial because its feature interpolation and view-conditioned ColorMLP are not validated.
- Default renderer: Default Unity rendering excludes higher-order spherical harmonics, opacity, coverage parameters, neural features, and method-specific compositing.The default path uses an unlit opaque vertex-color shader and may bake only the zeroth-order spherical-harmonic coefficient.
A.2 MIP-NERF 360 UNITY TIMING AND RESOURCE RESULTS
The evaluation separates native rendering behavior from Unity deployment, measuring image quality, throughput, timing, memory, asset size, reproducibility, and topology under explicit protocols. Results show that engine conditions and evaluation protocols materially affect both measured quality and practical readiness.
- Timing and resource measurements: Unity timing and resource tables report GPU frame-time percentiles, renderer graphics allocation, and serialized asset size using scene-level means rather than pooled measurements.Lower frame time is better, and incompatibility is reported as N/A.
- Native-renderer scope: Native measurements characterize fidelity and computational cost but do not establish engine-side retention, Unity deployment costs, or resource use.Native-renderer averages include image metrics, FPS, memory, and optimization time, while deployment conclusions require renderer-conditioned results.
- Topology audit: Topology analysis distinguishes local vertex reuse, boundary and manifoldness, and global connectivity because shared indexing does not by itself establish a well-behaved surface.LCC fractions and component counts describe connectivity, while non-manifold measures identify invalid fan structures; legitimate partial-scene boundaries remain possible.
- Reproduction and protocol sensitivity: Reproduction checks find a largest per-scene PSNR deviation of 0.775% across reported method–scene pairs, with protocol-specific implementation differences documented for LPIPS and dataset coverage.DiffSoup is omitted from the per-scene reproduction figure because corresponding values are unavailable, and its LPIPS backbone differs from the benchmark’s uniform VGG setup.