Visual Pinball Engine - 2025/2026 Updates

[gear323]

Hey Freezy,

It's really exciting to see this coming together with both the player app and the T2 table and all the thought you have put into the design.  Looking forward to the screenshots of the player app once you have it up and running. 

Thanks again for all the work you are doing on this, can't wait to try it whenever it is ready!   

 

[foofoorabbit]

On 6/12/2026 at 6:02 PM, freezy said:

Hi all!

 

Just a little update. I've started working on the player app, which is the actual "game" that players will use to load and play tables. The first challenge was to align the .vpe file format in a way that allows it to be imported at runtime. Then came the harder question: what if a user wants to load a .vpe file into the player 10 years from now that was created today? How can we make sure it still works? I came up with a few constraints that should make this possible:

• Assets packed into the file shouldn't use lossy compression, so re-importing them into the editor won't reduce quality.
• Nothing should be Unity-specific, so a .vpe file can be loaded by a player built with another engine in the future.
• Use common standards wherever possible.
• Version the file format explicitly, so older files can be migrated or interpreted correctly over time.

For materials and meshes, we're using the glTF format. However, glTF's material specs don't include all the features of HDRP, Unity's render pipeline. So I ended up extending the material specs with our own material definitions, which can be translated back to HDRP, or to another render pipeline, at runtime. This lets us keep the standard parts of glTF intact while extending it where needed.

 

Then there needed to be a good balance between file size and loading time. This is tricky because game engines usually pre-compress textures in a GPU-compatible format, allowing them to be streamed directly from storage into VRAM. But texture compression usually isn't lossless.

 

So what I ended up doing is adding a caching mechanism. The first time a table is loaded, its textures are converted into a GPU-compatible format and cached. After that, loading is faster by an order of magnitude. In my tests with T2, which is around 500 MB, the first load completes in just under 10 seconds, while subsequent loads take around one second.

 

Another advantage of this approach is that, for machines with less VRAM, we can downsize textures during that process. That should result in faster loading times and better runtime performance.

 

So I'm pretty happy with the progress. I think I have the foundations figured out. I'll be sharing screenshots of the player app soon. Maybe some designers among you would be interested in helping create a slick UI.

 

Cheers,

 

   -freezy.

 

Amazing news. Looking forward to seeing this!

[shiva]

Nice to see this back on the dock.

 

I finally just installed Unity after a absence of a few years when I noticed development was back, so really looking forward to this.

 

I saw you are using HDRP as Unity's render pipeline, but it was recently announced that it is being set to maintenance-only phase, and that Unity will be using and updating Universal Render Pipeline (URP) from now on. I know they have stated they will maintain it but no new updates are planned. Will you be updating to URP down the road when it becomes worth it to do so?

[freezy]

That's a very good question I wouldn’t have been able to answer a few weeks ago.

 

But it's much clearer now. Since the .vpe format is Unity-independent, we can use whatever RP we want for the player. We could even use another game engine. The physics would need to be ported too, of course, but you get the point.

 

Now, how will an insert authored in HDRP look in a URP player? If we naively convert the material properties from HDRP to URP, it probably won't look the same. That's why I'm about to define a set of semantic shaders, for example for plastics, inserts, and plastic ramps, so we retain that information in the material and can approximate it as closely as possible using the properties linked to that semantic.

 

To test this, we'll need a URP player, though, and that is indeed one of the next steps. Well, somewhat next step. I'll probably do a bunch of other stuff before that. 😅

 

The remaining question is what we do with the asset library authored in HDRP once HDRP is "deprecated". I don't know yet. Probably convert it to URP. But we still have a few years for that. Hell, maybe Godot might have caught up graphics wise by then and the project will go into a different direction completely, who knows

[freezy]

Been working on getting dmdext running in VPE. This will be fully featured, configurable through the player app, and cross platform. Here's a quick shot from my phone how it looks.

 

 

 

[gear323]

Wow. that looks great!  

[foofoorabbit]

If it wasn’t for the cursor doing the camera movement, you’d swear this was someone taking a video of a real T2 table.

[Dariusz75]

On 6/29/2026 at 12:59 AM, foofoorabbit said:

If it wasn’t for the cursor doing the camera movement, you’d swear this was someone taking a video of a real T2 table.

Not quite, T-800 skull is missing.

[foofoorabbit]

6 hours ago, Dariusz75 said:

Not quite, T-800 skull is missing.

True… probably the most important piece. 😅

[freezy]

It's WIP

 

[freezy]

A few more updates. First of all, I completed the work on dynamic colliders. Dynamic colliders now have a velocity and can now fully integrate with whatever weird mech needs to be implemented. Previously, dynamic colliders were "teleported" from frame to frame, which made them suitable for diverters, but not much more. Now it's a proper rigid body sim.

 

Then, I've ported over @vbousquet's new nudging system (doc here) from VPX. This includes a tilt bob simulation that authors can plug into their tables and that will trigger a tilt switch depending on how much the table was nudged. The tilt bob can be configured with sensitivity and how quickly it settles.

 

Here's a quick demo with the KL25Z: