Visual Pinball Engine - 2025/2026 Updates

[freezy]

Hi folks!

 

It's finally time for an update. You may have noticed that my last significant update was over a year ago. There were a few reasons for the delay - my new job turned out to be a CTO gig, which meant a ton of responsibilities, and balancing both work and VPE was nearly impossible for most of 2024. However, things have calmed down since autumn, and I'm happy to say that it's more balanced again. As a result, I've been making good progress on VPE.

 

I initially planned to create a few demos for this post, but I realized that would take a lot of time I'd rather spend moving the project forward. So, without further ado, here's where we stand!

Physics

 

Finishing the physics improvements has been the most challenging part for me. Moving from a proof of concept a year ago to a solid implementation that covers all use cases, runs on all components, and doesn't break performance or backward compatibility was no small feat.

 

So, what has changed? Last time, we were discussing parenting and unconstrained transformations. Now, two key improvements are merged and functional:

1. Freely transformable objects: You can move, rotate, and scale any element with complete freedom. In VPX, only primitives have this flexibility.
2. Runtime transformations: You can mark an element as transformable at runtime, allowing movement, scaling, or rotation while the table is running. Note that velocity isn't yet calculated for these movements.

 

If you'd like more details, check out our documentation on transformations.

Sound

Before diving into the new sound features, let me introduce our new contributor, @arkehr (Arthur). He's part of a team working on a hybrid pinball machine that uses VPE. Over the last few months, he's been an invaluable resource providing bug fixes, new features, and, most notably, completing the sound system code that had previously stalled with multiple other contributors.

 

These new sound features cover mechanical sounds. They let you assign sounds to elements directly through the editor, so there's no coding required. For instance, consider the trough component:
 

The trough component exposes a switch and a coil. This allows us to add sounds components that trigger when either of those activates. The sound component links to a reusable sound asset, which contains one or even multiple sound clips that are then played. We can configure how different clips are selected, whether there should be volume or pitch changes applied, and whether the sound is looping.

 

What's cool about this approach is that sounds are closely coupled with the game item, meaning that per default, they will also be part of the items of our asset library. So, as a table author, you'll immediately get mechanical sound support with any item imported from the asset library.

 

But what about other sounds? Collision sounds, ball rolling, music, and callouts for original games? Arthur just submitted a PR for music and callouts - I still need to review and test it. Collision sounds will come later, once the necessary data is exposed. Ball rolling sounds are still up in the air - either we'll port how VPX tables handle them or explore procedural sound design. Some experimental work has been done, but nothing conclusive yet.

Packaging

 

Another major piece on the engine side is packaging: We need a file format to ship tables with the following requirements:

• It must be loadable during runtime (well, duh!)
• It must be importable into the editor, so others can modify and build on it.
• It must be loadable on any platform, so it can be shipped as a single file.
• It must not depend on Unity or any version of Unity, so old table files still work without having to be updated.
• It must be optimized for online transfer, i.e. as small as possible in size.
• It must be somewhat efficient to load, so tables load quickly.

 

I also feel it's important to use common, well-documented technologies. VPX uses a storage format that doesn't even have a proper name, sometimes it's called Compound Binary File, sometimes Structured Storage, but it's most famous for being the underlying container format for Word (.doc), Excel (.xls) and PowerPoint (.ppt) files.

 

Within this storage format, VPX uses what's called a BIFF structure, which is basically struct data serialized as binary. This makes it very hard to read for humans, and even if you want to read it in a program, you need a bunch of libraries that might not exist for your language or platform.

 

Long story short, our .vpe file format uses:

• The storage container is a ZIP file, making it easy for anyone to extract or even modify the data.
• The mesh and texture data are stored as a glTF binary. This is a standard by the Khronos Group, and as standard as it gets, for storing 3D data.
• Other binary data is just stored as files, within the ZIP container.
• Non-binary data is serialized as JSON.

 

If you're curious about the internal file structure, check out the documentation here.

 VPX Export

 

Speaking of the file format: We'll be fading out support for .vpx file export. You'll of course always be able to import .vpx files, but the more VPE improves, the less it makes sense to offer export for an engine that doesn't keep up with VPE's changes.

 

For example, VPE now supports free transformations. The .vpx format doesn't, so we'd have to either extend the format (which VPX wouldn't understand anyway) or impose limits in VPE to keep everything "export-compatible". That would be a lot of work with no real benefit - nobody I know is using VPE to build VPX tables. So, expect VPX export functionality to disappear in the future.

Other Changes

 

We're back on Unity's latest version, Unity 6.0 at the time of writing. We've also made a few editor tweaks and removed a lot of code constraints related to VPX transformations, which simplified things significantly. Additionally, the project now compiles for production again, which wasn't the case for a while.

 

Arthur also rewrote our MPF integration. It's more stable, and it's more accessible thanks to shipping MPF with the Unity package itself.

 

What's Next

 

Hah, where to start. I think I'm mainly going to get all our table projects up to date, and T2 playable. I know, I said this years ago already, hehe. But now we have the physics to it properly.

 

After that, there are two big items on my radar:

1. Finish packaging so it works with our plugins, PinMAME, Visual Scripting, and MPF.
2. Build the player. Now that the file format is defined, we can finally start writing the player.

There are of course a zillion of other things to do. In the next few weeks, I'll go through our GitHub issues, confirm they're still valid, add any missing tasks, and tag them for community help where needed.

Retrospective

 

On a project of this size and duration, it's important to critically examine past decisions, and to see whether they still hold up, or whether they should be reversed or adapted. One recurring question is whether Unreal Engine 5 would have been a better choice, especially given Unity's recent struggles and Epic's success in securing AAA studios for UE5 titles.

 

For some context, UE5 didn't exist when I started VPE (we only had UE4, and there was no Nanite or Lumen). I still have limited experience with UE, so my viewpoint about UE is mainly based on what I've read. But what we can all agree on, I think, is that a game engine is just a tool. What matters is whether it's the right tool for your project. Here's why Unity works well for VPE:

• C# is awesome. I wouldn't want to use Blueprint or dive into C++ for porting a physics engine.  
• Unity's visual scripting is a great compromise for game logic (but I wouldn't want to do anything else with it).
• The editor is user-friendly and highly extensible, and compilation times are relatively quick.  
• Rendering is more than sufficient for a pinball table's typical polygon budget and mostly static camera. Nanite's advantages would be minimal here.  
• The Unity community is huge. Indie game devs still widely use Unity, and I've gotten many competent responses from its forums.

 

On the flip side, Unity has its downsides:

• Unity is still suffering from their previous incompetent leadership. If they had put their focus on game development instead of buying ad companies and VFX shops, then maybe Unity would have its own Lumen and Nanite by now.
• Dynamic global illumination remains a pain point. UE5 has a big advantage with systems like Lumen.
• Compared to Godot, Unity isn't open source (but neither is UE).

 

But all in all, I'm still happy with Unity. Even if I were to start over today, I'd pick it again.

 

And finally... Thanks!

 

Thanks for bearing with me. I know I said this last time, but expect more frequent updates going forward. They may not appear monthly (lesson learned!), but I'll try to post them in more regular bursts. Also, thanks to Arthur for his contributions and availability. It's much more fun to code in a group than all alone.

 

Cheers!

 

   -freezy.

 

[LynnInDenver]

Glad to hear things are moving forward. I get the whole "I stepped up into a whole new level in a portion of my life and that portion I had to let take everything for a while".

[TerryRed]

Always better to take your time and do it right within what makes sense to you with the time you have, and the resources available. Had you gone with your original plans, imagine all the limitations it would have meant down the line... and more work required to do things you wanted from the start. Now you will have a truly modern editor / player that won't be held back by catering to backwards compatibility for other apps.

 

I know it can be hard for some of us to understand why you went in the direction you did, but this is VPE. This is the year 2025. Your choices will mean MUCH less work for dev for VPE down the line, and MUCH less work for table authors who will no longer be constrained by older physics / tech / lighting / editors, etc.

 

Those of us who spend many months working on tables, really appreciate the extra effort to give us something much more modern than just VP with prettier graphics and a modern editor. Those who want perfect physics and extreme details of recreations or those who are creative loonies who want to go batshit crazy will understand just how important it was to take the time to add these features from the start, and not be held back.

 

Looking forward to the future!

Edited February 28, 2025 by TerryRed

[freezy]

8 hours ago, LynnInDenver said:

Glad to hear things are moving forward. I get the whole "I stepped up into a whole new level in a portion of my life and that portion I had to let take everything for a while".

 

Yeah, not sure though if it was a step up or some other direction

[Gravy]

Always exciting to hear any news on the project. Thanks for your continued efforts to bring this to fruition for the community.

[goodtwist]

Wow. Thanks freezy for the thoughtful write-up. We are so lucky people like you put effort into the various components that make open source virtual pinball possible!

Today I was looking at the specific code that makes anaglyphic glasses possible and I was blown away at the amount of thought that went into it. Thanks Devs!

[MauiPunter]

Congrats on your new CTO position.  Fun times.

[PastorLUL]

The professional life ain't no joke. Good looks freezy 🤗

[PLCJim]

Freezy,  will Nvidia's discontinuing PhysX on the latest gen of RTX cards impact VPX?  In other words, does VPX utilize any of NVidia's PhysX SDK?

[freezy]

No, we don't use PhysX.

[freezy]

I've taken some time to write a style guide for 3D assets. If there are any game developers or technical artists among us (@Pandeli 👀😄), feedback would be very welcome!

 

https://docs.visualpinball.org/creators-guide/editor/asset-library-styleguide.html

[foofoorabbit]

Super commendable to see so much documentation. Amazing work @freezy!

[freezy]

Thanks!

 

Those who want to follow T2 progress, head over here:

 

 

[TreZ]

THIS IS WONDERFUL!!!

I have long fantasized about a Unity-based VP system, and today I learned that this exists!

@freezy If you are looking for more contributors, I would LOVE to be involved.
I've been a professional game dev for 30 years, and am a Unity Ninja!

I love that you chose Unity over Unreal. Someone on one of my forums once said (paraphrased):
 

Quote

If you want to create a game with luscious, vibrant worlds, magical art, and spectacular visuals, go with Unreal.

If you want to actually ship a game, go with Unity

Sending you a PM!
 

[marco37]

Hi @freezy
 

Thanks again for all the work you’re putting into VPE!
 

I haven’t been able to find any post or issue that mentions this, so I wanted to ask directly:
Do you plan to add FPS‑boosting rendering tech to the engine? I’m thinking of temporal upscalers / frame‑generation such as NVIDIA DLSS, AMD FSR 2 / 3, Intel XeSS, or at least Unity 6’s built‑in Dynamic Resolution Scaling and Variable Rate Shading.

Is this already on your roadmap? If so, what are the main considerations (licensing, cross‑platform support, etc.)?

Thanks in advance for any insight!

Edited May 5, 2025 by marco37

[freezy]

Yes, all of that should be supported, but I’m not yet sure how or on which platforms, since my only experience so far is a quick test in the editor. I’ll know more once I start working on the player app.

[marco37]

1 hour ago, freezy said:

Yes, all of that should be supported, but I’m not yet sure how or on which platforms, since my only experience so far is a quick test in the editor. I’ll know more once I start working on the player app.

Thx, adding new tech to improve 4K pincabs on Windows would be a big leap.
Good luck with the rest of the work, and thanks again!

[mandermannen]

This looks insanely good! Sorry for my questions, will this be available for 'players' within months/ years (in normal situations)? Again sorry, but seeing the video's of t2... im really exciting about this. Will this be the standard of the vpw team?

[freezy]

You know, everyone tries and usually fails to predict when projects like these will be available. Although I have a rough idea, I won’t share it. Doing so only creates unnecessary stress and disappointment. I hope you can understand that.

 

Regarding VPW, we don’t announce projects in advance, so I guess you'll have to find out by yourself.

[foofoorabbit]

I like stress and disappointment.

 

Ok, I don’t… it’s probably for the best that there isn’t a release date. As long as freezy (and hopefully others) show off the table they are building, I’m ok with waiting. 

[mandermannen]

I totally undertand it. Im just really excited about this from what i see on the video's of t2. As a cabinet user will this need changes to dof, dmdext, b2s and pinuppopper?

[robertms]

8 hours ago, mandermannen said:

As a cabinet user will this need changes to dof, dmdext, b2s and pinuppopper?

 

Yes.

[BostonBuckeye]

Hi Freezy,

 

I heard you may be planning on adding a P-ROC/MPF plug-in to add native support for P-ROC tables. Specifically CCC is what I am interested in. Is this true?

 

Also, will the anaglyph 3-D be superior to what is in VPX which has amazing depth but a fair amount of ghosting and not the best colors? Will you offer settings for specific glasses like Trioviz?

 

BostonBuckeye

[freezy]

Just a quick update. Took as break from T2 as you might have noticed and worked on the asset lib. Just finished the decal feature in the asset browser, where you can assign multiple decals to an object and it will render out thumbs for all the combinations for quick access.

 

 

So, I'm pretty happy with that now. Next I'll finish moving the remaining assets to the new repo, publish it, and then VPE should be in a state where new devs aren't greeted by error messages...

 

@BostonBuckeye MPF support exists already. P-ROC will probably follow at some point, but no timeline. Anaglyph I have no experience yet. Will probably not come from me.

[BostonBuckeye]

Thank you for responding Freezy and thank you for all that you do for this hobby. I enjoy the videos and updates even though I don’t understand much of the technical details.