Recently, I’ve been working on some interactive sketches/games in Three.JS. For one of the levels I was building, I had the idea of importing something I built from one of my old MineCraft survival worlds in to use as part of it.

I figured that there was a pretty good chance of some software existing to export MineCraft levels to some 3D model format for 3D rendering or other purposes, and that indeed is the case. There are multiple options out there, but the one I chose to go with was jmc2obj.

I was reading a Hacker News thread for an article comparing GCP to some alternatives like AWS. I’ve been a GCP user for a good while now, and it’s definitely my go-to public cloud. We also use it at my dayjob at Osmos.

Reading the article and comments got me thinking about some of my favorite GCP features. GCP has a few excellent gems which are better than pretty much any competing cloud offering:

I’ve been building some interactive sketches/games in Three.JS, and I wanted to deploy it on my server. I export the models used by the level from Blender in glTF format, which is a modern, well-supported, and commonly used format for this. Specifically, I exported the models as a .glb file.

The Problem

When I loaded my levels in the browser, I noticed that the .glb file wasn’t getting compressed with gzip. This was a problem because the file is quite large - over 4MB - and glb is a format that should benefit greatly from compression.

As part of some recent work in procedural mesh generation, I’ve been working with a computational geometry library called geometry-central to trace geodesic paths on the surface of 3D meshes. geometry-central is written in C++, and I compiled the library to WebAssembly with Emscripten in order to use it in the browser.

As I recently learned, a geodesic path is the straightest path along a surface. It’s the path you would take if you were to walk in a straight line across the surface of some manifold for some distance in some direction.

Recently, one of my coworkers added code that uses v7 UUIDs. v7 UUIDs are a new type of UUID that contains a timestamp along with randomness, making them useful for DB primary keys and similar things.

However, that code broke my rust-analyzer install for local development. I already was running rust nightly locally, so there was some other issue. It said that Uuid::new_v7() wasn’t a function even though the v7 feature was enabled for the uuid crate and it was at the latest version.

I’ve been using Stable Diffusion XL via the Automatic1111 web UI to generate PBR textures for use in my Three.JS projects, as I’ve written about previously. Everything was going great until at random, the generation started crashing at 100% and I got this error in my console:

:0:rocdevice.cpp :2786: 58285575154 us: 154003: [tid:0x7f59ee1216c0] Callback: Queue 0x7f583ec00000 Aborting with error : HSA_STATUS_ERROR_OUT_OF_RESOURCES: The runtime failed to allocate the necessary resources. This error may also occur when the core runtime library needs to spawn threads or create internal OS-specific events. Code: 0x1008 Available Free mem : 13386 MB ./webui.sh: line 254: 154003 Aborted (core dumped) "${python_cmd}" "${LAUNCH_SCRIPT}" "$@"

I’ve been working on some procedural terrain generation for my 3D work in Three.JS lately. I wanted to try out a fresh noise function for generating terrain; everyone has used Perlin noise or some variant of it for decades.

I came across a blog post by Bruce Hill describing a noise function he designed himself - called Hill Noise. It works by combining a bunch of sine waves together with different offsets and rotations. If you add enough of them together, the results can look pretty organic and random.

I’ve been trying out a tool written in Rust called Blackjack for procedural, node-based 3D modelling. It’s a lot like Blender’s geometry nodes.

There aren’t a lot in terms of docs, and it looks like the project isn’t being actively developed right now. Nonetheless, I think it’s an extremely cool project, and the code is very high quality. So, I’ve been spending a bit of time getting familiar with it and trying it out.

The Problem

I was working on some procedural dynamic LOD terrain in Three.JS. As part of this, I was manually constructing indexed BufferGeometry instances. Things were working alright, but when I added in a depth pre-pass I started getting errors like this in the console and the terrain failed to render:

GL ERROR :GL_INVALID_ENUM : glDrawElements: type was GL_FLOAT

The code I had looked something like this:

const vertices = new Float32Array((segments + 1) * (segments + 1) * 3);
const indices = new Float32Array(segments * segments * 6);

// ... compute terrain and populate vertices and indices ...

const geometry = new THREE.BufferGeometry();
geometry.setAttribute('position', new THREE.Float32BufferAttribute(vertices, 3));
geometry.setIndex(new THREE.BufferAttribute(indices, 1));

const mesh = new THREE.Mesh(geometry, material);

The Cause

This error is caused because I accidentally used a Float32Array to store the indices, but I should have used an integer array type. I’m not sure why it originally worked and then stopped working when I added the depth pre-pass though.

The Problem

I’ve been working on a shader in GLSL for implementing volumetric fog via raytracing. I did the majority of the work for it it on my M1 Macbook laptop while traveling, but I was eager to try it out on my powerful 7900 XTX when I got home to see how it performed.

To my surprise, the results looked extremely different! The lighting was very low-detail on my desktop with the AMD GPU compared to how it looked on my Macbook.