But when everything else fails, bandwidth / memory optimization is the only thing that matters. I've managed to pack each voxel face into 6 bytes, while still having per-corner AO and supporting max 65K unique textures. Before this optimization every _vertex_ took 8 bytes.
I'm using the checkerboard pattern as a stress test, and it's quite good at that. It breaks most optimizations in my engine, namely empty / occluded chunk optimization and greedy meshing / face merging. Every chunk has the max amount of faces, giving the mesh generator a good workout.
One thing I've learned while writing a voxel engine is how huge the difference between "realistic" and "worst case" can be. With the same render distance, a typical hilly landscape uses about 2MB of VRAM, while a 3D checkerboard pattern uses over a gigabyte. Yup, that's three orders of magnitude!
And here's the current state, about 1 week after the initial commit. Ambient occlusion had a huge impact on the visuals.
Progress about 24 hours later
A screenshot of a window displaying a colorful voxel landscape with a black sky
There comes a time in every developer's life where they just have to write a voxel engine. This one is using #rust, wgpu and GPU driven rendering. #graphicsprogramming
Finally finished my latest article! It's about my experience of using a super ultrawide monitor for work and play for a bit under three years. It contains my thoughts about Samsung's (lack of) product design skills, and why Half-Life 2's FOV slider is a liar.
blog.paavo.me/1000-days-in...
But obviously there are many diversions into related and unrelated topics, like how FOV sliders are lying to you(!!!), or how DisplayPort MST could make the world a better place if manufacturers actually used it for once.
This is actually my third attempt at writing this article; in the first two iterations I had written several thousand words before even getting to the part where I buy this monitor. This time I handled that in a few paragraphs, and could mostly focus on the actual topic of the article.
I'm working on a new article, and it's once again grown to be an absolute monster in terms of length. I've had a 49 inch 32:9 monitor for about 3 years, and I want to tell the world how's it been. At the moment I've written almost 10 thousand words about hardware, productivity use and gaming.
But it's also ultimately much simpler than the traditional approach to rendering, at least so far: my entire scene is rendered by a single CPU-side draw call, bindless textures are so much nicer to use, LOD could be handled entirely by the compute shader etc.
The main benefit was performance. While release mode was fine, in debug mode (which I want to use to get wgpu validations) my little test scene was struggling to reach 60 FPS on my very powerful PC. Now it sits comfortably at locked 240 FPS, and release builds run at about 1000 FPS.
I've continued working on my little 3D engine based on wgpu and #rustlang. This week I managed to implement fully GPU driven rendering. The engine gives the GPU lists of drawables and meshes, and compute shaders perform AABB culling and generate indexed draw commands. 17K objects in about 0.03ms.
WESL advertises wgsl-analyzer as the official language server (or at least as a potential solution), but it doesn't actually support WESL from what I can tell? github.com/wgsl-analyze...
wgsl-analyzer provides autocompletion & syntax highlighting for VS Code, but doesn't support the same import syntax as naga_oil (even though it has some Bevy-specific features [which will be removed because of WESL migration?])
So I have to live with non-actionable errors in my IDE.
I integrated #bevy 's naga_oil to support shader imports. I had to use the version from git because the latest published release uses wgpu 24 (latest is 25). A new version will be released in sync with Bevy, but apparently naga_oil will also be deprecated and replaced with wesl-rs at some point?
I started this in December and resurrected it a few days ago by updating my dependencies, which took about an hour because of breaking changes in winit and wgpu. Good that these libraries are actively developed, but I imagine building anything bigger on top of these can be somewhat painful.
A colorful abstract tunnel rendered in a Windows 11 window
I'm working on a shader playground / 3D engine skeleton in #rustlang with winit, wgpu and naga_oil. About 1.5k LOC, has shader hot reload and very basic GLTF support. The DX is better than in my previous WebGL-based engine but the ecosystem is not yet very mature / stable.
Thanks for the share! YouTube decided to recommend your dithering video yesterday, and I watched it. Excellent work on that 👍
Ah yes, the joy of cover dates. Didn't realize they could be off by so much.
If I had more time, I would have written a shorter article 😄
I had assumed that triggering a script after an AI package finishes was only introduced in Fallout 3+, but apparently that's when they just added it to the editor UI. The scripting language already supported it in Oblivion.
Great catch! I had a look at this, and it is indeed powered by quest-specific scripting. When Glarthir's quest-related travel packages finish (= he reaches the victim), the script checks if the player can see Glarthir. If not, the victim NPCs are scripted to die.
New blog post: What was Radiant AI, anyway? blog.paavo.me/radiant-ai/ #TheElderScrolls #oblivion #gamedev
Working on a lengthy article about Oblivion's controversial AI system, Radiant AI. I've been writing this for about two weeks now, and the word count is not too far from a relatively short master's thesis. Hoping to finish it in the coming days.
New blog post! blog.paavo.me/demo-engine-... #graphicsprogramming #3d #wasm #rust #optimization
