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?

Amazing news. Looking forward to seeing this!

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!     

Awesome news, can you give details of your system (GPU / CPU) when it comes to load time?

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.