The source release for EVER caught my attention because it looks familiar at first glance: a scene represented by many ellipsoid-like elements. The important difference is in how those elements contribute to the image.
Standard 3D Gaussian splatting projects Gaussian primitives into the image and composites their contributions. That makes a fast renderer possible, but it is an approximation to the way density along a ray would accumulate. EVER, short for Exact Volumetric Ellipsoid Rendering, takes the volumetric interpretation more literally.
The reference implementation describes an exact volume-rendering approach for its ellipsoid representation. "Exact" has a specific scope here. It concerns the rendering calculation for the chosen scene model. It does not mean the reconstructed scene is an exact copy of the physical world or that every camera view will match a photograph perfectly.
That is a distinction I want to keep visible, because representation and evaluation are easy to mix together. A mathematically faithful renderer can still operate on imperfect geometry, incomplete observations or parameters learned from a limited set of images.
What a ray encounters
Imagine looking through two partly transparent volumes. The amount of material encountered depends on the path through each volume, and the nearer material affects how much of the farther material remains visible. If the volumes overlap, the relationship becomes more complicated than placing two flat translucent cards in front of the camera.
A projected splat is useful because it replaces much of that work with a compact image-space operation. An exact volumetric method spends more effort accounting for the represented volume along the ray. The interesting question is what that changes in visible quality, consistency and cost.
Thin structures, overlapping elements and changes in viewpoint are useful places to look. A representation may behave well near the training cameras and reveal approximation errors when the camera moves. I would inspect those cases before judging the result from a single attractive frame.
There is also a training implication. The renderer defines the image that optimization is trying to match. If its approximation changes, the learned parameters may change with it. It is not always meaningful to take a scene optimized for one renderer, switch the rendering formula and assume every difference is an improvement.
That suggests a careful comparison: keep the input images and camera setup consistent, train each method as intended, and report rendering cost separately from training cost. Memory usage and the size of the stored representation matter too. A method can offer a useful quality trade without winning every metric.
For my purposes, the code release makes the work easier to understand as an engineering proposal. I can inspect which assumptions live in the representation and which live in the renderer. That is more informative than calling it another Gaussian-splatting variant and stopping there.
The broader lesson is that a familiar-looking primitive can conceal a different model of image formation. Small ellipsoids on a diagram do not tell us how opacity, overlap or view changes are handled. Following one ray through the representation is often the best way to see what has actually changed.