Got a "particle system" working. This is a simple point grid being mapped to a sine wave.
The core of the work was figuring out dynamic WGPU vertex updates and reworking some of the overly simple parts of the Snowfall architecture to account for changing geometry.
What's exciting about the below image?
It is rendering lines.
Mostly internal work to refactor code and conceptual work to understand the various components of the WGPU architecture, but the engine code now supports rendering lines. This involved setting up a separate shader, render pass, line geometry buffer, and a few other things.
Not too exciting, but progress!
Also in the not-that-exciting category, I added a debug web view. The engine starts a small HTTP server that serves up basic data about the engine state. There's not much there yet!
Added shading based on world coordinate positions. This was mostly a test of adding new uniforms and vertex shader outputs to the shader program.
Added a voxel model. Very inefficient at this point, but "correct."
Tried increasing the resolution and found bugs :)
Guess: missing array data?
Manually counting the input data matches the generated positions array and checking against the runtime data...
4416 voxels * 6 faces/voxel * 8 positions/face => 105984 positiions4416 voxels * 6 faces/voxel * 6 indices/face => 158976 indices...seems correct.
Guess: too many draw calls?
Seems impossible as this is a single mesh.
Investigation: is it always the same voxels that are missing?
Flipping the order of the voxels during generation changes the missing voxels. Not sure what to conclude from this yet.
Drawing just the Z+ face on the voxels seems to work correctly. The same seems to be true when rendering any one of the six faces.
...but if as soon as 3 faces are rendered together, voxels seem to be lost.
Guess: too many indicies
Yup. The code is using u16 which has a max representable value of 256*256 = 65,536. There are 158,976 indices.
Changing to a u32 index buffer addresses the problem.
Resolution
Bumping the render code to always use u32 seems fine for this stage of development. Using the larger buffer size affords more flexibility, which is a higher priority right now than optimization for memory or performance.
Voxel chunking and optimizing away invisible faces need to be done regardless. After that is done, it should be easier to move back to a u16 index buffer.
With the bug fixed, here's a sine + cosine generated voxel heightmap of 128x128x32 resolution.
Progress update: have some vertices making it from disk to the screen. That's a cube sitting behind of a "2D" pentagon (not necessarily obvious without lights or shading yet).
The general task I've been working on is taking the "catch-all" State object from the Learn Wgpu tutorial and refactoring into a rendering architecture. This requires wrangling with lifetimes and data sharing, both in my learning how Rust works as well as how objects work in wgpu.
A bit more progress, getting basic semi-harcoded face shading working. Also changed the camera axes to a Z+ => UP system.
A bit more progress: depth buffering finally enabled and rendering multiple objects.
Ramping up on the custom rendering engine by going through the excellent Learn Wgpu tutorial. There's not much to say that's insightful here, but I find it's nice to create "early days" blog posts and images to highlight progress over time.
Though pedantic, I'd argue wgpu has a lot of configuration. I tend to consider boilerplate code common text that must be repeated to properly structure or specify another piece of non-common configuration or otherwise unique code. (Note: my personal definition is very different from AWS' definition which portrays "boilerplate" as a positive). By "must be repeated", I'm alluding to the kind of code that cannot be encapsulated easily into a reusable function, library, or other standard language primitive -- let's ignore macros certainly blur that line and just run with this hand-wavy definition!
In the context of creating many different wgpu programs, I can see how repeating the exact same configuration would constitue a good deal of "boilerplate code." However, that commonality could be easily wrapped into a reusable library, which -- if we're willing to run with my definition of boilerplate code! -- means it is not boilerplate code as the code does not have the quality that it "must be" repeated.
In the context of a single program, wgpu strikes me simply as a very low-level library with detailed, highly structured configuration.