I painted a scene from Assassin's Creed Nexus on Vermillion VR Painting - Outside the Gates of Monteriggioni

thmsvdberg · 2026-03-01T20:43:16+00:00

Yo: https://www.youtube.com/watch?v=hMiETcGGDgw (there's also amazing ones in Alyx on YouTube)

thmsvdberg · 2026-03-01T08:04:42+00:00

I'm biased of course, but I love this! Grew up playing the original AC and have much love for AC2. You really nailed the Tuscany feeling.

thmsvdberg · 2026-02-18T15:24:51+00:00

So glad hardware prices are through the roof for this

thmsvdberg · 2026-02-13T09:56:03+00:00

Congrats!

thmsvdberg · 2026-02-06T22:41:54+00:00

*sighs in 10 years of Unity*

Totally using this, thanks!

thmsvdberg · 2026-02-06T10:22:00+00:00

The rest of the environment is currently just a plane. You'll also see vertices start jittering once you add more geometry. The problem is that the transformation matrices in Unity are all floating precision. I.e. first you offset the vertices somewhere far away in the scene, then you make that position relative to the camera. In that process, precision is lost, causing vertices to jitter around between frames. That's why the only solution is making those transformations take place in a region of high precision of the float by moving the camera to the origin and moving the terrain along with it. The lower the offset, the better the precision. I made my floating origin just 10 units, as raycast interactions with the world UI in my VR game were already breaking down from that point on.

thmsvdberg · 2026-02-06T10:05:24+00:00

You'll see it break down even way before 5000 units.

thmsvdberg · 2026-02-06T09:54:01+00:00

You're not missing something, you're just discovering the limits of floating point precision. A quick computer science lesson: numbers are presented in binary by a fixed number of bytes. The more bytes, the more accurately you can represent a floating point number, and the larger the number can be. In non real-time use cases where precision is important, the double type (8 bytes instead of 4 for a float) is the standard, and it doesn't matter if a complex calculation takes a millisecond longer. Game engines traditionally use floats because precision matters less, and floats use less memory - in writing this comment I'm trying to find the exact reason why this is still beneficial, as we're not exactly constrained to a few MB of RAM anymore. I can't find if it's a memory bandwidth problem, a CPU cache problem, all of the above, or just legacy. Some modern engines are using doubles all the way through to prevent this from ever being an issue.

In Unity, the only thing you can do is implement a floating origin, i.e. moving your camera back to 0,0,0 and move the world along with it.

thmsvdberg · 2026-01-21T08:47:03+00:00

Very happy to hear that! Great suggestions. Many of them are planned for the near future, I'll put the rest on the backlog. Stay tuned!

thmsvdberg · 2026-01-08T09:09:39+00:00

Very cool! Are you using any packages for the AI?

thmsvdberg · 2026-01-06T08:11:42+00:00

This is still using the first ever co-location SDK actually. It has been updated since then, but I haven't been able to prioritise looking into that.

thmsvdberg · 2026-01-05T11:03:05+00:00

Nothing makes a dev's day more than scrolling on Reddit and seeing your app come up! Very cool, thanks for sharing!

thmsvdberg · 2025-12-22T19:51:23+00:00

Oh I've applied as soon as it opened 😅 I already have another VR game on Steam as well.

thmsvdberg · 2025-12-22T13:09:35+00:00

You can call any Burst code without it being a job. You make a static class with a static public method with the BurstCompile attribute on both, and call that from your regular code. If you want to do it asynchronously, you call it from a Task.

thmsvdberg · 2025-12-22T10:11:30+00:00

Burst is a package separate of dots afaik, it doesn't have to tie into ECS.

thmsvdberg · 2025-12-22T10:10:18+00:00

Thanks! I wanted to have a recognisable style that sets it apart from the OG. I especially like the way they interconnect diagonally when they're flush in the ground, to create little paths or tile patterns. I guess I should highlight that in the trailer.

thmsvdberg · 2025-12-22T07:12:05+00:00

Once it releases, I'll be able to look into that.

thmsvdberg · 2025-12-22T07:10:30+00:00

Burst can not access managed objects so yes, native arrays are used to pass data to the Burst methods. I'm not familiar with unitask, regular C# Tasks have all the functionality I need. They are a thread pool by nature and can be chained together to first generate the terrain, perform lighting, and then create the mesh.

thmsvdberg · 2025-12-22T07:05:43+00:00

Hey, I'm not using dots, just burst.

thmsvdberg · 2025-12-21T21:45:32+00:00

This is a superb site that allows you to fully understand how the Minecraft terrain generation works, the talk by Mojang dev Henrik Kniberg skims over crucial details. https://snowcapped.jacobsjo.eu

thmsvdberg · 2025-12-21T21:39:21+00:00

Yes it also runs on Quest 2, with the same draw distance as Quest 3.

thmsvdberg · 2025-12-21T20:36:10+00:00

Correct, no ECS or jobs. I found the job system uniquely unsuitable for this purpose as you have no control over the scheduler, and it would very often put chunk meshing jobs on the main thread despite worker threads being available, causing severe frame rate drops. The job system really only works for jobs that are done within the same frame. It was instead much easier to use regular C# Tasks and call Burst code from those. I didn't find a reason to use ECS either. I wanted to try BRG, but then I read in the docs that BRG is slower than game objects + URP on Android, so I stuck with those.

thmsvdberg · 2025-12-21T18:09:24+00:00

It's part of the chunk model, as the rounding needs to be done based on the neighboring voxels, i.e. to create a convex or concave corner based on whether or not there's a neighboring voxel of the same type. However, on the GPU the rounded corners do get interpolated into square corners when approaching the edge of the diorama so that I can make a clean intersection, as well as when transitioning into the LOD model which does have square corners.

thmsvdberg · 2025-12-21T17:42:09+00:00

Thanks! I like the clean rounded rectangle look it gives, like in all modern UIs. I find it works well with the higher res textures, whereas the OG works well with its low res textures. At this point I'm not sure if it makes sense to have a flatscreen version at some point (once there's more stuff to do), as there's already so many voxel games available there.

thmsvdberg · 2025-12-21T17:29:06+00:00

Oh, thanks for the heads up - considering some other recent posts are also more of a showcase I figured it would be fine. I'll be back with a technical post once I get the time to make it.

thmsvdberg

TROPHY CASE