Important update about future of FVNE

Hi all!

I'm writing this to share the latest plans we have going forward with the development of FVNE. There has been some changes with Unity (the game engine we're using), forcing us to re-evaluate our roadmap.

As many of you may know, we're in the process of migrating our project from the Built-in Render Pipeline (BiRP) to the High Definition Rendering Pipeline (HDRP). HDRP would allow us to do a lot of things that otherwise wouldn't be possible (more about that further down), in addition to simplifying our rendering implementation significantly. Since the BiRP has been abandoned many years ago (it hasn't received any new features for nearly a decade), this step is necessary for us bring the graphics up to par with modern standards. BiRP suffers from many limitations and drawbacks, and we were happy to finally leave it behind. BiRP will be fully deprecated in Unity 6.5. The transition to HDRP would also allow us to incorporate user designed environments* and VR* .

* (While it is possible to do in BiRP as well, it would make no sense to do so if we're migrating to HDRP anyway, since then we'd have to reimplement a lot of it and also all user environments would break in the process.)

New update from Unity

A few days ago, Unity shared their plans going forward with their different SRPs (Scriptable Rendering Pipelines, of which HDRP is a part of). In short, they're effectively abandoning HDRP. This came as somewhat of a surprise, as they've been pushing for people to transition away from BiRP to HDRP (and URP - Universal Rendering Pipeline - their other, simpler rendering pipeline meant for mobile phones, as opposed to HDRP which is made for PCs and consoles). There will be no new features implemented for HDRP - the system will only get maintenance updates going forward. Instead, URP will get all their attention, and they will attempt to bring missing features to URP (of which there are many compared to HDRP).

Needless to say, this is very bad news for us, having invested so much time into migrating to HDRP. Knowing that HDRP is a technological dead end, we feel reluctant investing into it. Even though it may suit us right now, this may not be the case years from now as it it falls further and further behind. We think investing into it risks us developing ourselves into a corner again, and we'd have to make yet another painful migration further down. This is undesirable, as it would force us to spend time re-implementing a lot of systems, as well as break all custom user environments.

Unity has been in hot water many times the past decade, becoming known for causing severe whiplash among developers using it with all these drastic turns. They make sudden, harsh changes, not only to the technology itself but also to their pricing and licensing, making it difficult for developers to anticipate the future and plan ahead. There have been many times where they develop or acquire technology, only to discontinue it some time later (despite making strong pushes for developers to adopt said technology). Some examples (in addition to BiRP and HDRP) include Artomatix (later rebranded Unity ArtEngine), Unity MARS, Unity Reflect, Ziva Technology, Wētā Digital technology and UnityScript. All of these were part of Unity at some point, only to be discontinued suddenly and unexpectedly, causing severe distress for any developer who happened to make use of those technologies.

The Problem

The transition to HDRP was meant to be a bit of a reset for us. Not only getting more modern graphics, but also getting rid of hacks we've been using for years to circumvent the many limitations that exist in BiRP (but in doing so we complicated the development and maintenance tremendously). A transition to HDRP would simplify the development and maintenance a lot, and also allow us to implement new features in regards to graphics.

Now, with the HDRP effectively abandoned, it means we only have one real choice going forward (when it comes to render pipeline migration) - move over to URP. However, the problem with URP is that it doesn't have the same features as HDRP. It is very lacking in many ways. Here's a table we compiled:

Here's the bug mentioned in the table. (Please vote on it if you're able to!)

Some definitions for the terms used:

Motion Vectors

Motion vectors are tiny pieces of data that tell the computer how each pixel on the screen moved from one frame to the next. They're essential for modern graphics techniques like TAA (Temporal Anti-Aliasing), DLSS by Nvidia, and FSR by AMD because those systems reuse information from previous frames to make the image look smoother and sharper. By knowing exactly how objects moved, the system can correctly line up past and current images, reducing flicker, jagged edges, and blur - without motion vectors, you'd see ghosting, smearing, or unstable visuals.

Tessellation

Tessellation is a graphics technique that automatically splits large, simple polygons into many smaller ones so objects can appear smoother and more detailed without artists having to model every tiny bump. The GPU dynamically adds this extra geometry where needed - often based on distance from the camera - making surfaces like characters look more rounded and realistic. It's especially useful with inflation.

Super Resolution

Super Resolution is a graphics technique that takes an image - often rendered at a lower resolution - and reconstructs it into a sharper, higher-resolution version using advanced algorithms or AI. This allows games to run faster while still looking crisp, as seen in technologies like DLSS from Nvidia and FSR from AMD. Importantly, it can also be applied to an image that's already at full resolution to enhance clarity even further - boosting fine details, improving edge sharpness, and making the overall picture appear cleaner and more defined than standard rendering alone.

Sub-Surface Scattering

Sub-Surface Scattering (SSS) is a graphics technique that simulates how light enters a material, scatters beneath its surface, and then exits at a different point. This is what makes materials like skin, wax, marble, or milk look soft and slightly translucent instead of hard and plastic-like. Without it, skin in particular can look flat and unrealistic; with it, light gently glows through thinner areas - like ears or fingers - making characters appear much more lifelike and natural.

Volumetric Lighting

Volumetric Lighting is a graphics technique that simulates how light travels through the air and interacts with particles like dust, fog, or smoke. Instead of lighting only surfaces, it makes light itself visible as it scatters through space - creating effects like sun rays through trees, glowing headlights in mist, or shafts of light in a smoky room. This adds depth, atmosphere, and realism by making light feel like it exists in a physical environment rather than just illuminating objects.

Custom Depth Writing

Custom Depth Writing is a technique where an object deliberately writes its depth (distance from the camera) into the depth buffer in a controlled way. This makes it possible to create advanced blending effects such as dithering-based fades (where objects smoothly dissolve in and out without hard popping), and soft intersections where meshes blend naturally into each other instead of visibly clipping. It's often used to smoothly merge terrain with roads or rocks, or create seamless transitions between overlapping objects - helping scenes feel less rigid and more visually polished.

Probe Volumes

Unity's Probe Volumes are an advanced lighting system that stores baked light information in a 3D grid of small lighting samples throughout a scene. Unlike traditional Light Probes - which rely on scattered probe points that are blended together - Probe Volumes fill space more evenly and capture lighting direction and intensity more accurately. This results in smoother, more consistent lighting on moving objects, fewer lighting pops when crossing probe boundaries, and better handling of complex indoor spaces. In short, Probe Volumes provide more stable, higher-quality indirect lighting compared to classic blended Light Probes.

Raytracing

Raytracing is a rendering technique that simulates how light physically travels and bounces in the real world. Instead of faking lighting with approximations, it traces rays from the camera into the scene, calculating reflections, shadows, and global illumination based on how light would actually interact with surfaces. This produces highly realistic results - accurate reflections in mirrors, soft natural shadows, and believable lighting bounce - but requires much more computing power than traditional methods.

Screen Space Reflections

Screen Space Reflections (SSR) is a rendering technique that creates reflections using only the information already visible on the screen. Instead of calculating reflections from the entire 3D world, it traces reflection rays through the rendered image to approximate what a surface (like water, glass, or a shiny car hood) should reflect. This makes it much faster than full raytracing, but it has limitations - objects that are off-screen or hidden can't appear in the reflection, which can sometimes cause missing or fading reflections at the edges of the screen.

What's the plan?

Here's the situation we're finding ourselves in - HDRP has the features we want, but that rendering pipeline will be abandoned. BiRP is already abandoned, and will be deprecated in Unity 6.5. URP is the only pipeline going forward, but it's missing features that we need (specifically it's support for tessellation and motion vectors that is most pressing).

Given this, we have come to the conclusion to delay the render pipeline migration until we know more and see how things develop. Unity are notorious for making big changes, only to backpedal later. We currently can't make any plans in regards to a render pipeline migration before we know with confidence what Unity will actually do and stick to.

This means the HDRP migration is halted, potential URP migration is in review and custom user environments and VR are postponed until further notice.

In the meantime, we will resume ordinary development of the app. This means implementing new features related to FVNE itself, polishing existing ones, and potentially also giving the cloud some much needed TLC.

All the best.

- odes