Simon

Devlog 11:

Fully working async chunk generation using taskflow is now working with versioned chunk-vertex-data. This allows for very fast remeshing.

For testing I currently spawn a block 5 blocks in the view direction from the player, but only in the same chunk so this is why the result may look a bit weird.

The biggest achievement at the moment is that it works to have two threads working independently from each other on the same elements without dead locking themselfes out or waiting forever for the other thread to finish working on some data.
One thread for rendering and only parsing the input and a second one to check if the player changed the chunk, update the chunks that need to be rendered and start the corresponding tasks in their own threads.
The next time after I finished calculating the vertices of a chunk when the renderer checked if the version changed it uploads the vertex data to the gpu and from there on it does not need to access the vertex data in the ram anymore as it has its own copy on the gpu where it needs it.

If you are interested in any other more specific features feel free to ask.

Devlog 10:

Went from Qt to GLFW for rendering and split the work into multiple classes in the process.
This gives me way more control and way better readability of the code.

By also going away from Qt Threads I now have to rework the multithreading, so only simple renderside generated chunk meshes consisting of only one cube for now.

The difference is not that notable in the recording but with qt i was hard stuck at 180 fps, with glfw the upper limit actually is my hardware.

Terrain generation also is implemented it just can not be used at the moment.

Devlog 09:

Added binary chunk mesh generation and paralized everything so chunks are properly loaded and unloaded by multiple threads.

Simple diffuse lighting also is implemented in the fragment shader

Devlog 08:

Added Meshes and logic to always load the chunks around the player and unload those that are further away. The meshes currently generate dummy data in their own thread, but are ready to be filled with the actual chunk mesh.

To reduce the data sent to the gpu, for every face there is one vertex that then by using instancing is used 4 times for a GL_TRIANGLE_STRIP.

Everything works async and should be thread safe, so one thread can write to it and another can read from it. Currently there is one thread for the inputs, one for the gameLoop that currently is not used yet and one for rendering.

Everything is coming together

Devlog 07:

We are back to a cube and a moving camera, so the foundation is laid.

The input is recorded through QML and passed on to the PlayerController. The renderer then updates the position according to the current inputs and the time since the last frame, so it feels as smooth as possible.

As the basic chunk data structure allready is there, it should not be too difficult to implement chunk rendering with a simple chunk meshing algorithm.

Devlog 06:

Added basic engine structure and player movement for a portable approach to allow for multiple rendering engines and easy switching in the future.

That is:

• World Data Structure in Chunks
• Block Data
• Engine to run in its own thread and call a tick function every 50ms
• PlayerController to live between the threads, input from qml, updates/ticks every frame and to be used in the engine

Devlog 05:

After trying to use vulkan with qt on macOS for a too long time, I now switched to OpenGL as it should me get quite a long way and allow for way faster prototyping and faster progress.

This also allows me to rewrite the chunk data backend and optimize and structure it better than it was before to make for a more stable gameplay and avoid stuff like chunks not unloading properly.

QRhi limited me as it seperated the chunk upload and configuring from the rendering. With OpenGL I now am able to change uniform buffers in between draw calls and also more complex features like indirect drawing are possible.

This means a fresh start so all I have to show for now after trying around to much is a black window, but more will follow soon.

What are your thoughts?
Is OpenGL a good starting point?

Devlog 04:

After some more optimizations I am now able to render quite a large region. The problem that now arrises is the amount of buffers used. Every chunk at the moment uses 6 buffers and QRhi just cant handle this. The next approach to fix this is to switch from QRhi to Vulkan to gain more control and implement a solution that can work for far larger render distances.

Optimizations:

• Greedy Meshing
• Frustum Culling
• Fully async chunk and mesh generation
• Removing faces that are facing away from the player

Devlog 03:

Voxel Worlds are hard :(

What I did:

• Moved chunk mesh generation in seperate worker threads and tried to make everything needed thread safe
• Implemented movement and game logic through its own classes running in its own thread
• Implemented instanced drawing for quads, drasticly reducing the amount of verticies and removing the need of indicies through TriangleStrip
• Added chunk generation using perlin noise

Devlog 02:

After too many hours, I now finally got a codebase, that can do efficient rendering of chunks using QRhi under Qml.

To achieve this the hardest parts were:

• Reducing the trafic between cpu and gpu. Only seending meshes if they changed
• Creating efficient meshes, using face culling for now (greedy meshing planned)
• Effiently storing the chunk data
• Getting the order of the triangles right to enable backface culling
• QRhi stuff:
  • Understanding the basics of the rendering pipeline and how QRhiCommandBuffers work

The picture currently shows one 32x16x32 stone chunk rendered with different colored faces.

If you have any questions feel free to comment <:

Devlog 01:

Tried a lot with QRhi and Qt Quick 3D but always had problems with optimization and different threads accessing different things and bing blocked by operations.

New try with QRhiWindow to stay in c++ for the whole 3D pipeline.

Allready learned a lot about 3D rendering and optimization.

Devlog 06:

New Features:

• changed from simple TabBar to ListView for workspace tab bar
• added drag and drop support for workspace tab bar, so you can reorder the files manually after opening

Fixes / Polishing:

• used enum for node type in cpp backend instead of string

Devlog 05:

Added web assembly demo hosted on github pages.
The project is not optimized for web assembly yet but it works.

Additionally some small features were added:

• closing files
• proper dimensions of the sidebar also on web assembly

Devlog 04:

Rewrote the way how the contents of the file are saved in the C++ backend by giving them their own classes and finally implemented a proper editor in which multiple files can be opened and switched easily.
Also created the editor for TODO lists.

Finally I looked into the ui and fixed some smaller details to just create a better ux.

Devlog 03:
Added basic editing structure for my file / folder structure to create / rename / delete files and folders.
Additionally fixing the ui to make it consistent and getting changes in the note editor to be registered and saved in the C++ backend

Devlog 02:
Added the basic project structure using Antigravity:
C++ backend subclassing QAbstractItemModel
QML Frontend with minimal functionallity

Getting this result needed a lot of knowledge around how qt handels models and what works and what does not, but after investing 30min into the implementation plan alone gemini did a great job on implementing all of the features.

For everyone who wants an idea how it works look at
https://github.com/simonpth/cirruspad/blob/main/CLASSES.md

The code is far from perfect and needs a bit of human polishing but it’s a good starting point.

Devlog 01:

I finished project, hackclub and github setup and now everything is ready to start. This devlog also is there to finish the task on the welcome page!