TLDR: Written version of the talk I gave at Develop Brighton 2026. Yes Godot can ship commercial VR, we paid roughly £80k in early adopter tax to do it. War stories from rebuilding Godot's core, the community PS5/PSVR2 port with George Marques and André Ewald, why I ended up writing a whole new render server for 4.7, and a call to arms for platform holders and render programmers. Nothing in here is PlayStation NDA material, sorry.

Extended talk recording this article is based on.

---

I gave this talk at Develop Brighton this week and wanted to share a more public version. A bit slower, no conference clock, and this written companion for the folks who prefer reading to watching. Nothing in this talk is NDA'd about PlayStation, sorry about that. There are juicier behind the scenes details but those live in partner spaces where I'm allowed to share them.

This was originally meant to be a post mortem. Then a bunch of stuff happened, which means it is now a partial post mortem. You'll see why.

Who Am I

I'm Claire and I've been doing this since the PS2 days. I contribute to Godot, mostly on the OpenXR side and increasingly some render stuff here and there. I've shipped a wide range of games and I've been doing VR since 2013. I joined Sony to work on PSVR networking and my team there did significant metaverse work: social VR chat, hand gestures, all that stuff came out of us. Most recently I shipped Dreams and Substance 3D Modeler, and now I'm working on Augmental Puzzles.

Up Front: Godot Works

Some of this talk is going to come across a bit negative and I want to say up front that it is not meant to be. Godot works for many many teams. If you're making a 2D game it's kind of a no-brainer, and for most simpler 3D games it's very reliable.

Some honest caveats though. If you're doing an open world or streaming heavy game, leaning on lots of character animation, or going for a very realistic art style, Unreal is probably a better fit. If you're an out-the-gate VR dev, especially standalone, you might prefer Unity because the renderer is a bit more capable. Godot has an asset library but at the moment it's free only, which will change in future, but it means the ecosystem isn't as well serviced as the others. And on console porting there are plenty of studios providing the service, but the community port side is less mature.

Can Godot Ship Commercial VR?

Yes. We did however pay about £80k in early adopter tax. That is pure engine work we had to do that we would not have had to do shipping on Unity. It does not mean every studio starting a VR game in Godot needs to pay that much. If you started now I don't think it would be that high, but I do think there would still be a tax. And that number does not include the PlayStation and PSVR2 work. That's a whole other set of numbers.

We're in early access, so yay, it works. I broke the whole £80k down in my GodotCon writeup if you want the itemised version.

The Games That Got Us Here

Augmental wasn't our first Godot VR game. It's the game we ended up at.

Digging VR. An archaeological modeller-style digging game. Blocked by missing render features, which I've written about before. I didn't want to write an engine, I wanted to make a game, so we shelved it. Funny thing: the features exist now. We just couldn't wait.

Rune Magic. Stopped for gameplay reasons. Clean cancel before the sunk-cost trap closed. Not Godot's fault, that's just gamedev.

Magic Shop. A physics title based on my wife's first trilogy of books. We ran into physics trouble on early Jolt and solved it with custom physics responses, then cancelled it when our funding was cut. This was why I left Adobe to get back into games, and then, well, anyone in the VR industry can tell you what September 2024 looked like. I covered the business side in VR Biz: The Funding Cliff.

The Pivot: Augmental Puzzles

While I was at Adobe I worked with Logitech, Apple and many others. With Logitech it was the MX Ink pen. I got support for it into Godot, which was relatively painless, and made a little drawing demo. When it was done I sat there thinking about what to do next and went: well, I really want a place to do sudoku in VR. It doesn't exist. Holy shit, we can make that pretty quickly. Let's get it out the door.

Speed of Godot

This is what I always say to people when they ask me about Godot: the speed of getting things up and running really is a strength. It's a joy to work with. We had the core game of sudoku up and playable in about two days, and the full menu flow with basically all the components of the game out in a week. Everything was still scratch graphics, but it was there.

One of the nice things early on was composition layers, which get you really high quality 2D layers quite cheaply. They worked really well for us initially and we honestly could probably have shipped with them. We no longer use them because we moved to a different art style, but they were great scaffolding.

However the game grew in scope, for reasons I'll get to. Recently we were finally able to show some of that ambition.

Nonograms are out now, and we announced Augmental Puzzles is coming to PSVR2.

Where I've Covered This Before

I've given other talks on all this. At Develop North I talked about Godot from a professional perspective. At GodotCon recently I gave a longer talk on most of this material, which is on YouTube and written up on this blog. And if you're a PlayStation partner I'm sharing more detail in the spaces where I'm allowed to.

One thing I won't dwell on because I've covered it before is the monkey paw effect. A lot of personal issues delayed the game. Short version: a lot of people in my life got sick, some got cancer, and recently my cat passed. We joke about it now because when my friend joined the company his wife was in hospital within a month. Bad luck ran deep. The longer version is in A Personal Journey.

Why This Talk Exists

This bit is really important to me. When I came into the industry it was normal for programmers to skill up by fixing the in-house engine, or adapting a licensed engine to your game. When new console cycles happened you'd inevitably be asked to port the engine to new hardware or support some bespoke vendor thing. Developers learned by doing it. Consoles would try new things, new things usually appear on consoles first, and doing new things requires people to support and work with them.

What really sucked this last decade is that as we developed the standards and software around VR we were at the peak of the engine duopoly. Almost everyone was on Unity or Unreal, so very few people engaged directly with the VR standards, and the standards didn't get good. I always say the way to know if someone is actually using a thing is that they're complaining about it. If a programmer uses a language, an engine or a console, they bitch about it, and that informed complaining is how things improve. VR's growth got heavily stunted by the lack of it.

I'd also argue there was a lot of innovation in the last console cycle that people don't realise, because Unity and Unreal didn't really engage with the consoles' advantages beyond some shiny graphics. There's so much VR headsets can do that you never see games do, because the Unity or Unreal plugin doesn't support it. Innovation requires that we play with things. That's one of the main reasons I advocate for Godot, and why this talk exists.

Act II: Rebuilding Godot's Core for Commercial VR

Godot in One Slide

This is probably the slide that will get the most critique. It's not meant to be conclusive, and I'm speaking from the perspective of a game dev who has shipped on console and maybe isn't that familiar with Godot.

Godot at its heart is a 90s style object-oriented engine. Updated in places, but that's the skeleton. It achieves its scripting layer and extensions largely through a Variant union type wrapping common data structures. There's an object ID database at the core of managing all this that is very mutex heavy, with instance locking that makes threading awkward. There's an authoritative scene graph with parent-relative transforms, and those transforms are fat because they support non-uniform scale, which causes a whole bunch of problems for physics and graphics optimisations. The renderer is not bindless and not threaded. There is a threaded mode but it's still marked experimental, we tried it, we hit a lot of problems, it's still not recommended.

The memory model is probably one of the biggest issues. It's very POSIX heavy, doesn't make good use of memory mapping, and while there's a virtual file system in the pck package format it isn't uniformly implemented. In Android land it's still sparse files in the APK. There's a lot of internal caching, buffering and memcpy throughout the engine. A lot of IO and data inefficiency, largely because it was mostly built by devs who weren't shipping on console.

And that's the honest history. Godot started as a commercial in-house engine that didn't make it commercially. It got good because a grant landed, open source devs poured in, and Godot 2, 3 and 4 happened. In the 4.x cycle we've seen much more high level engagement and the engine has improved massively across the board. But some of that core data structure stuff is very hard to update mid-cycle without breaking a lot of things.

The good news: it's very modular. I always say a game engine is 100 to 120 things, and the parts that annoy me are probably different from the parts that annoy you. You fix up the parts you need to fix up. You don't have to build a whole engine. At a baseline it's good enough in most places and you improve where your game demands it. It's designed like a stock car, it's not meant to be perfect. Meanwhile it's very hard to pop the hood on Unity, even with a source licence it's not designed for it, and if you're a serious AAA title on Unreal you're almost certainly shipping a custom engine build anyway, it's just harder to work with.

War Story 1: Label3D Ate My Framerate

We were on target for a friends and family build in about three months, even with the personal life stuff happening, and then I hit horrible frame rate spikes. I went down the rabbit hole. RenderDoc eventually told me why: my average frame rate was fine and my menus were simplistic, there was no reason to have render performance problems, but I was getting material creation storms causing spikes.

Tracked it down to Label3D. It creates a unique material per glyph. Every. Single. Character. It relies on layers of caching to basically solve the problem away, but as we know, high level bad algorithmic decisions always come back to bite you. The MSDF texture would grow mid-frame and there'd be a pile of material thrashing on top. Because the renderer isn't bindless this all lands as a horrible VR spike. In VR a spike is a failed frame submission, there's no hiding it. We'd have failed store submission, and the game just felt shitty. So instead of shipping the friends and family build, we fixed it.

FastText, and the Slug Patent Going Public Domain

The fix was FastText, our replacement for Label3D: a shared resource across all text nodes to kill the material creation problem, pre-cooked glyphs so nothing grows mid-frame, one draw call per node rather than a mesh surface per letter, and instance parameters driving per-glyph colour and theming through a custom shader. The full saga is in VR Text Was Killing Performance, So I Took a Hatchet to Godot's Label3D.

Now for the really cool bit, because it just happened this week. I've always said I wanted to move to Slug style dynamic GPU fonts, where you encode the actual curves and get infinite resolution. Most GPU font rendering was already perfectly fine to use, but Slug held a software patent on a banding compression trick that is critical for making it fast enough for VR. This year Eric Lengyel put the Slug patent into the public domain. So at Develop, in between prepping this talk and seeing friends, I finished the work. FastText now has proper GPU curve based fonts instead of MSDF. Infinite resolution fonts and SVGs, monochrome for now since I don't need multi-colour and I want to stay performant, but full colour emoji would be fairly trivial to add. Complex SVG rendering too.

Side note: there's another great VR game in development in Godot, Penguin Festival. When I spoke to Zi about this problem his solution was "I just used TextMesh". That would have worked out of the gate, and I tell people now: yeah, do that. It's not efficient, it's not as good, but it works. This is exactly the "what bugs you won't bug me" thing. It bugged me, and either way we'd have needed a solution eventually.

War Story 2: Compliance and Storefronts

Godot has a real problem here. If you want to ship on Steam, Godot seems great, and there are plugins for Meta, Epic, Pico and everything else. But because Godot's core is MIT licensed and the Foundation rightly avoids anything with licensing entanglements, none of that goes into the core engine. Same for anything with many valid solutions, like terrain: it stays out as modules and extensions.

The consequence is Godot at its core has no basic API structure for users, entitlements, leaderboards, transactional save data, session management or matchmaking. Save management is still POSIX file based, which we all know we should never do. So every plugin that fills the gap is built for one platform with its own API and its own interface. As someone who's been through console submission a bunch of times: TRCs and compliance around user management, states and session handling get complicated. Having a per-platform implementation of that, with per-platform bugs in your game logic, is a mess. I'd love to see a generic MIT-safe API that these platform plugins could hook into so game devs don't redo it every time.

The other problem is many of these plugins are community maintained and not necessarily GDPR compliant. As a studio we have to sign data controller agreements and be able to verify what happens to user data, which means validating all the code we pull in. The legal fines here aren't always revenue based, they can go extremely high, and in some cases, especially around child safety law, you can be personally liable, not just the company. Dot your i's and cross your t's.

Backend Unified Middleware

So we built one layer. Originally it was Butler, for user management, then Backend Unified Middleware. We called it a bunch of things but really it's a pun on BUM, because it deals with the platform shit.

One common interface for all our platforms, with per-platform implementations inside the module that we can verify and run through unit testing. The game only has one surface to implement against. It does offline mode for tradeshows with increased analytics, multi-slot saves with cloud merge on top of transactional saves, and an auth state machine I know is compliant. That was a big chunk of the effort, and there were plenty of other small things across the engine, some not so small.

Extensions vs Modules vs Addons (and FUCK SCONS)

You might have heard me mention extensions, modules and addons. They're not 100% the same. The project tries to keep extensions and modules similar enough that you could in theory move code between them. It's not really there.

Android extensions were a real pain for us for weeks. We had issues with the JNI bridge, especially with Epic Online Services which has injection requirements, issues with external libraries, linking and build chains. It cost us a lot of time, effort and money, and in cases delayed months of work. Recently, as we port to more headsets, we've had to move the extension back into a module because not everything was playing nicely with our JNI setup, and we're still tracking down issues from that. This is an ongoing point of pain. Daily.

And then the slide says it: FUCK SCONS. To be clear, this is not a complaint about SCons as a software stack. It's that SCons isn't standard. Basically everything in the games industry is CMake or Visual Studio, or something built on top of those two. People use Ninja and other systems, but it's one of those two underneath. Because SCons is nonstandard, none of the tooling and solutions we as an industry have built really work with it. Incredibuild, and some other systems I can't talk about, intercept compiler commands and do work natively with SCons, but even then it's slow as hell because of how SCons constructs things, and it's single threaded.

I think this is where the disconnect comes from. On a normal non-gamedev open source project you put all your weight on CI, GitHub or GitLab runs your builds in the background and you don't much care. In a game studio, even a relatively small one, everyone has a beefy PC, because games need more processing power at development time than at runtime. Your dev PC is recommended spec or higher. If you're paying someone 50k, 80k, six figures, then a £10k Threadripper box is entirely reasonable, and all those CPUs sit mostly idle. So it's standard even in small studios to run a LAN build distribution system, these days with Tailscale in the mix for remote folk, tuned to be respectful so it never slows down the person using the machine. If you want an open source one I recommend FastBuild. None of this plays nicely with SCons. And no, I'm not saying I like CMake.

Act III: The PS5 / PSVR2 Gauntlet

Why a Community Port

Lots of porting companies were doing Godot console ports before W4 did theirs, and there are still many choices. But when W4's console port was announced on the official Godot blog, and this is all happening in September 2024 when we were in the middle of a lot of stuff so I was maybe a little angry, certain egos and bad comms meant that for a very long time the average Godot user, even people reading the actual blog post, got the impression the W4 port was the official port.

Godot, since the 4.0 cycle, is run by a foundation with a structure inspired by Blender's, and I think the Foundation does wonderful work. W4 is a private company that has name recognition because of certain people in it. There's an over-ascription to personality that happens all the time: "but so-and-so is so important". Have you seen all the programmers cleaning up the mess behind them? Have you seen all the other people working? It felt very much not in the spirit of Godot to me, and it didn't solve the problems I was facing or the reasons I was investing all this money in Godot in the first place rather than just using Unity or Unreal, which from a pure technical standpoint are better engines. I wrote the polite version of all this at the time in Godot on Console.

So I threw down the gauntlet a bit. There's a community Switch port. Why isn't there a community PlayStation port? This also comes from having worked at PlayStation, on the PS5 itself, and being quite frustrated with the poor support I saw for platform features. Let's do it. Let's make a community based thing.

Where the Port Is Now

The 4.5 community port: 2D games could start porting today, the 2D samples largely run, 3D lighting work is in progress, platform work remains, and nothing has been through submission yet. If you're a PlayStation developer, go on the DevNet forums, ask in the thread for access to the Discord, and from there you get access to the repo. All MIT licensed, you just need to be a registered PlayStation developer.

Then there's the 4.7 port, which exists as of a few months after my GodotCon talk. It's 100% focused on VR and our needs, and it's a complete rewrite of the render server. That one is private for now and will release at a later date. I'm still actively contributing to the 4.5 port, it's just the render side where the two differ.

The Team

I was very focused on the studio when George Marques reached out. George is the GDScript lead maintainer, he has a porting company, and he said: I want to do this, let's collaborate. At the same time André Ewald, who also runs a porting company, reached out with the same energy. So we organised and did it together.

This was great because I hate build systems, and George has a very deep knowledge of Godot that I don't have, especially around SCons. He built the base of the 4.5 plumbing: the build system, the SCons-to-target deploy, the Godot hookup logic, all the basic plumbing so we could export to console. I cannot give him enough credit. It sped us up immensely because I'm terrible at that stuff and he did a very good job. Then the monkey paw came for him too: personal life issues mean he's had to largely step away from the port work. His contribution was massive and I want it acknowledged.

The 4.5 port is now led by André. He's a render programmer, ex-Ubisoft, and he got us the first hard-coded triangle on PS5 hardware. He runs the port and its Discord and is actively porting games using the 4.5 work, so it's moving forward nicely.

Me, I did the memory model work, the POSIX file system fight, save data, and then, because memory allocation and GPU work sit really close to what André was doing, "let me just show you what I mean" turned into a large chunk of render work. The biggest piece was the shader pipeline, which was the largest pain point of the whole port and I'm still not happy with the solution. Hence what follows.

Fight 1: POSIX IO vs Unified Memory

Yes, the chip picture on the slide is from a Mac. The point stands: anything that isn't a desktop PC looks like that now.

Godot's file model is rooted in POSIX, and POSIX was old at the turn of the millennium. We have much better low level file management now, native mapping and the like. Everything funnels through the user:// mount via a file-access shaped layer. It's not transactional save data, so it wouldn't pass TRC.

Look at any modern device. Your phone, your VR headset, your games console, your Mac, hell even a lot of Windows laptops, the Steam Deck, the Steam Machine: SoC unified memory architectures are the norm. And even ignoring that, if you're still coding with 90s brain, or even ten-plus-year-old Xbox 360 brain, the sequential read times of modern storage are incomparable. If your core data structures are built around heavy caching you're not making good use of the hardware at all. POSIX-style file thinking was a bad idea even in the 360 and PS3 era.

The pck virtual file system is not optimal, it's not consistently implemented across platforms so performance varies a lot, and it's riddled with local cache problems. The number of reads and copies a texture goes through getting from cold storage into the GPU is a lot, and it's like that across resource loading generally. The biggest problem is that Godot exposes FileAccess as a primary user API, so game devs use it heavily in their actual game logic. Mapping that onto anything that isn't a PC is not great, and it encourages bad loading systems that slow everything down.

We did our best job here leaning heavily on the resource system. There's stuff I want to say about the result that's platform specific so I can't. We have a thing, it works, and it could be a lot better.

Fight 2: The Shader Pipeline Wall

GDShaders largely just run, and that's the magic being sold. How it works: your little snippets, vertex, fragment, light, get copied and pasted into very large template files. Macros turn features on and off to generate all the variants. Those enormous GLSL files get passed to the SPIR-V compiler with barely any trimming, and then SPIRV-Cross fans it out. For most platforms SPIRV-Cross can emit something native, on Metal it goes through another translation layer. Between 4.5 and 4.7 there has been some work to trim what gets sent to SPIR-V, still pretty terrible, but improving.

The issue is the whole "the compiler will optimise it away" mindset. Compilers can't infer intent through layers of macro guff, and undefined behaviour is a thing. I've got a friend who works on the PlayStation shader compiler and I've had this conversation with several graphics programmers, because I'm not the best graphics programmer. On AMD console hardware, and you know this from PCs and Macs too, the shader resource tables and registers are much smaller than on say an NVIDIA GPU, because it's more optimal to do it that way. Push Godot's giant macro-soup variants through SPIRV-Cross at that and you start hitting hard limits. Not performance problems. Will-not-compile problems. And because those bind layout set structures have to be maintained all the way through the pipe it gets really messy.

The worst part: once you've done all this, the GDShader file you wrote and the file you're debugging on console have gone through so many transformations that the iteration loop is really shitty. The pipe is very long.

What we built for 4.5: a custom SPIRV-Cross backend emitting native PSSL, with massive reflection tables and huge scripts churning through the 200 to 300 shader variants. My loop was literally "these shaders aren't compiling, why, can I put a special exception in for that, boom, next". The goal was that if you use the 4.5 community port you don't redo your shaders. Turnkey as possible. We got there: the 2D samples are playable. There's still a lot of work to be done, and programmers are welcome to join.

Sidebar: Shader Templates

This wall is being attacked upstream too. Clay's original shader templates proposal is what led to compositor effects. Compositor effects are not very optimal in how they're done, but they're a way to inject custom render work and they took some pressure off in the mid 4.x cycle. Now there's a more modern shader templates proposal from Bastiaan Olij, head of the XR team: PR #111939, template support in the rendering server core with .gdtemplate files for Forward+ and Mobile, in review now.

I really like this idea. It means per-platform optimisation, stripped down shaders specific to your needs. What we probably would have done with it, and we talked about this, is build GD shader templates that ingested our 200 to 300 files and effectively replaced the GDShader pipeline with our own. Not the best solution but a good one. Regardless of PlayStation I think the template system is good.

Also worth noting: the big RenderingServer decouple PR #116454 landed mid-flight and broke half my PRs. Which tells you how alive this area is. There's a lot of movement here and I'm hopeful it gets fixed properly.

The Breaking Point

So I'm porting all this down to 4.5. I'm hitting the mutexes. I'm hitting the non-bindless renderer, which is just not the norm any more, almost every serious renderer out there is bindless now. Mem-copies everywhere. And then I went to GodotCon, gave my talk, watched a great NVIDIA talk, had a bunch of conversations, and came to a conclusion:

I wasn't building a good PS5 engine. I was porting 1990s decisions to 2020s silicon. It didn't feel good. At the same time some business conversations happened that I didn't like. So I came back and said: why not both?

Why Not Both

The red pen is the plan: a third option that bypasses both existing compositors.

For those who know the architecture: Godot has Forward Clustered, Forward Mobile (the one recommended for VR) and Compatibility. These are backed by two compositors. RasterizerGLES3 plugs into OpenGL, GLES and ANGLE, it's what web uses, and it's a very old fashioned pipe, but it's there, it works, it's a good baseline. CompositorRD sits on the RenderingDevice layer, which is how Vulkan, D3D12 and Metal are supported. The 4.5 plan was a PlayStation device based largely on the D3D12 device, since that's a better base than Vulkan for it.

The problem: anyone who knows graphics programming knows that if you're supporting all of those backends through one abstraction, you're basically making the worst version of each of them, because you have to compromise everywhere. And because Forward Clustered and Forward Mobile share so much, there are decisions in there that could be split out cleanly but aren't, because it's easier to modify things in place, easier to push the PRs through. Code maintenance and community pressure shape architecture. Both compositors also drag along a whole family of subsystems for material storage, light storage and the rest.

So: fuck it, let's write an entirely new render server, a third option alongside CompositorRD and RasterizerGLES3, and skip that whole pile of inherited decisions. The plan in the future is to make a version backed by Vulkan or D3D or Metal, maybe WebGPU, to open it up beyond PlayStation. But it's a pure new render server. That was the 4.7 decision.

Architecture of the New Renderer

The new renderer is pure bindless and attempts to be as lock free as possible. Producer-consumer ring buffers carry tight command streams, with no object DB mutex tax, because I've done a lot of mutex elimination work. It has explicit core affinities, which is critical for cache behaviour: on a lot of this hardware CPU cores are paired up sharing cache, so we explicitly map physics here, game loop here, renderer here, these sub-jobs there. You lay it out to the hardware, and console CPUs reward you for caring.

Rather than the pipeline being determined through shaders and render state, we've taken the shader template concept and gone harder: every material drives its own execution. We can still cluster by material because materials with similar needs batch naturally, but a material could be a volumetric shader, or an intersection shader for ray tracing. For canvas rendering it lets us do this really optimised thing where we squirt tiny amounts of data through a path that caters for the vast majority of canvas cases rather than all of them. We also just don't support non-uniform scale by default. Everything is uniform scale, and if you need non-uniform we interject a deformation step, because it's the special case not the common case. That opens up a whole bunch of GPU pipe speedups.

The other decision that follows from material-driven pipelines: platform native shaders. On PlayStation you write PSSL. On Apple you'd write Metal. On Vulkan, GLSL. This sounds like a lot of work but the reality is copying a folder of shaders and making a few minor changes per platform is quick and easy, and you probably want platform specific shaders anyway, because platform hardware is different and the compromises you want differ with it. A unified shading language is lovely and not super practical in performance terms.

This was heavily inspired by Sebastian Aaltonen's No Graphics API post about moving past the Vulkan-bloat world, very good post, highly recommend it, and he's giving a SIGGRAPH talk this week. Thankfully some people have built real implementations playing with these ideas, like Daxa in Vulkan, so I had code references to check interpretations against. Then I could look at PlayStation hardware and just ask: what's best for PlayStation? And not worry about any other platform until later.

Progress Pics From the Port

Little test scenes from the 4.7 renderer coming up: canvas, texturing, the first triangle through the shader pipeline, compute writes, instancing, then stereo VR pairs and finally lighting.

These are progress images from the PlayStation port and it's been really fun having them to share. What you're seeing across them: the canvas renderer coming up, texturing tests, the first triangle that goes through actual shaders, writing with compute shaders, supporting all the different pipeline kinds including mesh shaders, importing and baking shaders through the editor, per-object instancing, and the shader reflection work. We annotate platform native shaders in some cases, because the reflection is very good and works most of the time, but occasionally you want to expose something explicitly. Then VR running in stereo, which was a great day. Lighting went in over the last week.

Shadowing is not in yet, and I don't know exactly how we'll do it, because we're VR focused and dynamic shadows aren't as central there. One of the nice things about building a VR-first renderer targeting 90 and 120 fps is that we can decouple real-time shadowing from the frame rate. There are some interesting SIGGRAPH papers here: what if the shadow technique smears over a couple of frames? We can do some very cool tricks with that. That's the active work right now.

Act IV: The Call to Arms

Remember the PhyreEngine?

If you're a game dev of a certain age you might remember the PhyreEngine. When we moved from the PS2 era to PS3 and 360 we were moving from fixed function to shader pipelines, and it was new and different. I maintain the PS3 architecture was pointed in the right direction, maybe a bit too early, because it's where we're heading now: general purpose compute units with specialised sidecar hardware, DSPs, neural blocks. So Sony said: let's make an engine, MIT licence it, any dev can use it, and here's how we think you build a game engine for PS3. The sad part is it wasn't built for a specific game. Lots of devs looked at it and took code from it, plenty of MIT code ships on these platforms, but nobody was using the engine, so the team never got enough love.

Platform holders constantly lend engineering time to proprietary engines. Unreal, Unity, the Call of Dutys and GTAs, and in my case at PlayStation, often helping indies with smaller stuff. Godot has already had engagement from Apple, Microsoft and Khronos. Godot's OpenXR implementation is the reference implementation for OpenXR, and that's how I got involved in Godot in the first place. I totally forgot to tell that story in the talk, but whatever.

Here's the pitch. If you work at a platform holder, you could write a simple C sample program to show off your rendering technique or your new platform library. Or you could implement it in Godot and show it in an actual engine. It's more realistic, it's something people actually use and want, and it's MIT licensed so it's immediately engageable. People building custom engines can pull from Godot far more easily than from a vendor sample or from Unreal. "Here's our new console, running Godot sweetly, because we helped" is a launch story that breaks the duopoly.

It's Already Happening

NVIDIA. Leroy Sikkes gave a great talk at GodotCon on NVIDIA's path tracing fork of Godot. The traditional way to do what he did would have been a standalone C sample showing off the new NVIDIA render stuff. Instead he built it in Godot. Godot people have been helping him, he's been getting good feedback, and it's far more valuable to NVIDIA than a standalone project would have been. It also started a lot of good conversations about what ray tracing looks like in Godot, and moved the whole bindless conversation along. Huge value for both sides.

Apple. Anyone who thinks Apple isn't still very much in the VR game wasn't watching WWDC, which was filled with VR enhancements. They've contributed engineering time to Godot's Metal renderer, so Godot runs better on iPhones and better on headsets. Some of that engagement is private, some isn't. And then the really cool part: Apple's visionOS support for Godot. Take a 2D Godot game and it just works on Vision Pro, rendered onto a quad. Take a 3D game, not even a VR game, and it just works rendered into a volume. Take your Godot VR game into their immersive space still using Godot's Metal renderer. And if you want to go the whole way, there's the RealityKit path where they fully replace Godot's renderer, very similar to what I'm doing for PlayStation, and you get the best possible renderer on that hardware out of the box.

That's fantastic. The Godot team doesn't have to maintain that renderer, Apple gets to make some platform specific calls, and everyone wins. This is exactly the kind of engagement community ports and open engines make possible. I wrote about Apple's scene graph thinking a while back in Split Rendering for VR if you want more on why their approach makes sense.

The Takeaway for Studios

You don't adopt Godot because it's a turnkey solution. You adopt it as a seed for your technology stack. I've been saying this since 2024: it gets you going fast, and the parts you need to change will be different from the parts everyone else needs to change. Maybe you're making a Lemmings-like, or a tactics game, or something with a lot of digging and Minecraft-ish tech. The bits you optimise are also where you build your studio's technical value. In our case we've got a full puzzle solving AI framework that's a core part of our studio's value. You own it, free and clear. You were always going to spend that £80k bending Unity or Unreal to your game anyway. In Godot you spend it on code you own.

You don't have to agree with everything happening in Godot main. Fork hard, make your own calls, and still pull from main and push to main with shared history. And the best part: even if you end up replacing a large amount of Godot behind the scenes, the Godot interface and metaphors stay the same. One of the hardest problems with custom engines has always been spin-up time for new hires, freelancers and codev studios. It's why so many studios were forced off their custom engines: hiring costs, outsourcing friction, technical risk. Godot gives you a common language to bring people in with. It doesn't remove those costs but it minimises them. And once a piece of tech is ten plus years old, open source almost inevitably wins. See Blender.

Vision for the Godot Engine

The Foundation recently posted a vision statement for the engine. This is really important because the conversations around Godot 5.0 have begun. Godot is a very big community, the Foundation is doing a great job of shepherding it, and a vision statement probably should have happened sooner, but I'm so glad it's there.

These core goals tell you whether Godot is ready for you and whether Godot's future aligns with yours. Take "runs on hardware people own", which is about Godot working on low end phones as much as anything. That sounds like it clashes with my high performance VR goals, but it doesn't. It means any high performance work we want adopted upstream has to be built so it can be turned off or live nicely alongside solutions for low end hardware, and that it's secondary to accessibility. That's an alignment of values, and it tells us how to shape our strategy and our engagement. Read these in letter and in spirit, and think about how to engage with them positively, not as gauntlets thrown or lines in the sand. Most of the work of Godot is communication and community management. Getting all these people aligned. The actual code is one of the smaller parts, even though the ostensible product is a thing you compile.

Get Involved

A few calls to action to close on.

If you're Godot-curious about VR: the Godot XR Game Jam runs for a week in September. Great way to dip your toes in.

If you're a PlayStation developer: go on DevNet, find the thread, request access to the Discord, and from there the repo. The 4.5 work is all available and we encourage you to contribute, there is still a lot to do and active ports are underway. The 4.7 render work isn't being shared yet, but anything I do that isn't the renderer lands in the 4.5 port.

If you're a render person: please engage with the shader template work, the material and bindless conversations, and the future-of-Godot discussions. We need more experienced industry people with time to engage. And based on recent conversations around Godot: review is almost more valuable than writing code, especially review from an informed position. There are a lot of hard rendering discussions ahead. I wrote about making PRs and review sustainable in Better PRs.

I didn't get to the OpenXR extension matrix stuff in this talk, that's covered in OpenXR's New Controller and Why the People in the Room Matter, and the Khronos matrix stays permanently bookmarked.

And our game: Augmental Puzzles. I'm terrible at promoting it. It's in early access on Meta Quest and Steam, we're making it better every day, we're mid-port to about five different platforms, and we're solving performance problems daily. Any support there directly helps fund the PlayStation work. We don't have a mechanism to support the port itself, that's complicated, but a few studios are digging in now and we can always use more, especially folks with experience in the space. Informed voices are very much needed.

Conclusion

The partial post mortem, in one breath: Godot got us playable in days, the early adopter tax was real, the community port got 2D samples running on PlayStation hardware, and somewhere along the way I stopped porting old decisions to new silicon and started building the VR-first renderer I actually wanted. The 4.5 port keeps moving under André, the 4.7 renderer is lighting scenes in stereo, and Augmental Puzzles is coming to PSVR2.

I hope this encourages you to check out Godot a bit more, and if you take one thing back to your studio, make it the seed mindset. Feel free to contact me online and ask questions. I'm reachable on Bluesky, LinkedIn, occasionally X, and the Godot Contributors Chat. Ciao.

---

Links

The port

• PlayStation developers: request Discord access via the DevNet forums thread, repo access follows
  
• Rhine Games (André Ewald) leads the 4.5 community port
  
• George Marques built the 4.5 build system foundations
  
  

Related posts

• Shipping VR in Godot: Troubles, Victories and Reality the GodotCon talk writeup with the full £80k breakdown
  
• Better PRs: Voting Panels, AI Review, and Stack Your Damn Commits making review sustainable
  
• VR Text Was Killing Performance, So I Took a Hatchet to Godot's Label3D the FastText saga
  
• OpenXR's New Controller and Why the People in the Room Matter why standards need us complaining
  
• A Personal Journey: Year One of Flammable Penguin Games the monkey paw, longer version
  
• Split Rendering for VR Apple's scene graph approach and friends
  
• Godot's Rough Patch API churn and forked-engine pain
  
• Godot on Console the 2024 gauntlet post
  
• Godot: The Secret XR Tech Move the seed mindset
  
• Volume vs Surface the digging game tech
  
• VR Biz: The Funding Cliff September 2024 in VR
  
  

Proposals and PRs

• Shader templates proposal #8366 by Clay, led to compositor effects
  
• Shader template core support PR #111939 by Bastiaan Olij, in review
  
• RenderingServer decouple PR #116454 the one that broke half my PRs
  
• Godot Engine vision statement
  
  

Tech mentioned

• No Graphics API by Sebastian Aaltonen the post that shaped the 4.7 renderer
  
• Daxa bindless Vulkan implementation worth studying
  
• A Decade of Slug by Eric Lengyel the patent going public domain
  
• Slug Font Library
  
• Compositor effects docs
  
• Khronos OpenXR extension support matrix
  
• FastBuild open source distributed builds
  
• Tailscale for the remote-studio LAN
  
• PhyreEngine
  
• NVIDIA path tracing fork of Godot and Leroy Sikkes at GodotCon
  
• Apple visionOS support for Godot and the visionOS 27 engine plugins
  
• Penguin Festival by Zi Ye the TextMesh pragmatist
  
• Logitech MX Ink
  
• Godot XR Game Jam, September 2026
  
  

Augmental Puzzles

• Augmental Puzzles on Steam
  
• Augmental Puzzles on Meta Quest
  
  

Find me

• Bluesky
  
• Mastodon
  
• Twitter