Sunday, 30 March 2025

Resonite Parser

So, a couple of days ago while talking to a friend and helping them. I thought of something that would help ProtoFlux parse JSON. For those of those not knowing what ProtoFlux is (or not wanting to go away from this page), ProtoFlux is a visual programming language for Resonite. Unlike in VRChat, a platform I hate for a good reason. ProtoFlux runs in realtime rather than needing to be compiled first, so you can view the output in real time.

What is Resonite

Resonite is a VR social sandbox platform, and is being built by Yellow Dog Man Studios. While they sadly dropped native Linux support, they did say that they are targeting Proton so people can still play Resonite on Linux. The platform at the moment, from what I can tell, is mostly dominated by people who are technically and/or creatively inclined in some way. There are a few issue with Resonite at the moment, but every platform does have its issues. A personal statement of mine is that Resonite is the future of VR platforms, as it is essentially the GMod of VR.

comparison to VRChat

VRChat is NOT a sandbox platform, or even near the level of creativity of Resonite. VRChat is built on top of Unity. And while I do like the Unity game engine, there are limitations to it. With the main thing about Unity being that it still uses Mono over the newer CoreCLR. With Unity maintaining their own fork of Mono, but in a blog post from Unity themselves, they will be switching over to CoreCLR. On top of that, when you use Unity, you pretty much have to compile the shaders at build time to use them in-engine. You cannot tell the engine to compile new shaders during runtime. On top of that, you cannot bundle scripts with Unity AssetBundles. This is why VRChat uses Udon, a once modification to the platform that is now officially part of the platform.

Udon

Udon compiles into a "totally not code" file, as Unity sees it. Which means it CAN be copied into the AssetBundle. There is, however, a limitation that VRChat has placed on Udon that I personally think is stupid. Udon CANNOT be attached to avatars that I know of. It could have changed since I last used that platform back in 2022. Udon can only be attached to worlds, and one might think that is totally fine. And 90% of the time it is, but an issue comes in the form of users who want to add interactive parts to their avatar. Case in point is this meme that was brought up in NeosVR.

There is a Unity Editor extension called Udon# (UdonSharp) that enables writing C# that will compile to Udon. The problem arises when you want to use some advance C#. Suddenly, the limits of Udon come back.

Why Resonite is better

Resonite is a more free platform to begin with. Firstly, you host your own sessions, on your own machine! This means that you have full control over your instance, the developers cannot easily get into your private session without having to essentially dig into it. On top of that, this also means that the headless can run on any VPS/physical server/container platform out there. For example, my headless is running in a docker container on my NAS at my house.

Secondly, you are allowed to put scripts on any object, and I do many any. Want to put a script on your avatar that makes it to where you enter a shadow dimension? You can do that! Want to make a hotel system that spawns a new instance for you to join, simply by waving a special card in front of a card reader? You can do that. Want to make an exit strategy that works in any world? Can do that too. Now, when I say scripts, I do mean ProtoFlux at this moment. But from what I have heard from the team and people who know more behind the scenes, they are working on getting WAsm working inside Resonite. This would essentially mean that any language that can compile to WAsm will work inside Resonite.

Thirdly, everything is done inside the platform. From making avatars, to props, to worlds are all built in Resonite for the most part. People still use Blender and Substance Painter to make the world look better, but people have built worlds inside Resonite using only tools found in Resonite. This also means you can see how things will act/look in real time than waiting for it to be packaged and uploaded to some server.

Shortfalls

There are a few short falls with how Resonite works at this moment, mostly stemming from the fact they still rely on Unity for rendering. But with the performance update that is around the corner, Unity is getting booted to just being a renderer instead of running the whole platform. This, in theory, means that quite a bit of short falls I can see and think of at this moment would go away.

The first short fall is that if Unity crashes, it takes the entire platform with it. Imagine just chilling and then Unity, out of nowhere panics and crashes. You can still hear people, and people can still hear you, but now your stuck seeing the last thing you were looking at. Waiting for the Unity Crash Handler to close the platform or force terminating it. It sucks terribly, but with the performance update kicking Unity to being its own process instead of relying on it to run the whole thing means better performance thanks to using CoreCLR, respawning Unity if it crashes instead of getting booted fully out, and easier to replace Unity with a different rendering engine.

The second issue with Resonite, no custom shaders. That's right, no custom shaders for you at this moment. It is planned to change, with talks of a custom rendering engine called Sauce being worked on. Sauce is supposedly going to be using Vulkan (hell yeah!) instead of DirectX or OpenGL. Vulkan means that there is fine-grain control over the GPU, which can translate to highly performant shaders being written. Supposedly, these shaders are going to be using the same structure as ProtoFlux. Which also means real-time feedback of how the shader will look and behave.

What is JSON -> Resonite parser then?

You might wonder why such a service would be needed if Resonite is powerful. ProtoFlux is still very much a simple way to do things in Resonite. Without advance features that pretty much all platforms have to parse structures like JSON, it means doing anything that returns a JSON is also much harder. Say you want to build a radio in Resonite, there are APIs that provide the information. But the side effect is that this information is in a JSON format. You could try to pick the data you want out, but if anything changes in that JSON, you have to then edit that script to re-fetch what you want. On top of that, building ProtoFlux that can do that easily is also a drag on resources, potentially causing a hick up when loading the object in. What would be easier is if there was some way to get that information without causing a hick up.

That is where this service came to my mind. Build ProtoFlux that uses this service, and you don't need to parse JSON at all. Since this service is written in C#, it will be a lot faster at parsing JSON. Supply the JSON and the paths to the values you want, and it returns those values. ProtoFlux just sends the data, then it just sleeps while it waits for the service to respond back. I would recommend looking at the doc page here. At the moment the only way to communicate with it is via the beta version of my site. It is how I test new ideas and check things out. The repository for it is the same as my blog site, since it is built into my blog site.

I built V1 of this service in 1 night, and then iterated on the next day. V1 did a simple find the first instance of the token. V1.2, however, is different in that it requires the path of the variable. This way is a lot better as it means that, instead of it assuming you want the first find, it picks exactly what you want out of there. Since it is in beta, things are likely to change. However, my plan is also simple in this regard. If I am planning something that breaks how it currently works, I will increment the version and leave the original as is. It does mean that some bloat will be present in the backend. The other option is that I put an end date into the code of v1, and this end date will cause the endpoint to respond with "Service hit EoL, please use the new version."

The thing I do hate about this project is, it is a band-aid solution. This isn't something that will continue to work in Resonite. At some point, my server will go down, and the same for my site. A better solution is something that is built into the platform. But this is the second-best option until that happens.