Well, I finally did it! Cyberfire 3D works up to my standards. It's not as interactive as 2D, but both were originally intended as strictly visual demos, so I'm at least glad one of them has interactivity. While there are still a few rough spots, especially around the bottom of the flame, they are not all that noticeable. The camera can be controlled like most other 3D software. Left click and drag to rotate, right click and drag to pan, and mouse wheel to scroll.

Another thing that I've added is the ability to change the number of passes the renderer does per frame. This increases the visual quality, at the cost of decreased performance. I find the sweet spot (for my setup, at least) is around 2-4 passes, YMMV.

Something that I haven't talked about before is the launcher. With the addition of 3D, I knew I wanted to have some way for the end user to toggle between the 2D and 3D versions. I added it earlier, but did not think it was noteworthy to include. Now, it also handles setting the height, width, and, for the 3d version, depth of the fire matrix. It's just a simple PySide6 application that modifies env variables to be able to correctly launch the other applications from there.

That's about it. While I might keep updating it if I get new ideas, this project is in a state where I'm happy enough with it.

I was able to squash quite a few bugs in the renderer. Flipping the image so that the fire rendered the right way was easy enough. Figuring out what magic numbers to flip in order to get the camera controls was not, however. I still haven't fully gotten color to work yet, but it's... going. The empty voxels are now transparent, as are the low-intensity fire voxels to some degree. The cube is now also rendering on two sides instead of only one, though some other issues have cropped up.

Namely, those issues are that the sides of the cubes that don't render correctly have an oddly patterned pattern of mostly red pixels throughout. In addition, the fire has decided to split into red, green, and blue sections in a remarkably distinct pattern. There is also an odd hotspot on one of the top edges of the cube. The bottom is a completely noisy mess, as well. So, overall, progress, but not completion.

3D progress

Once I'd mostly completed the 2D version of Cyberfire, the natural question for me was: what about 3D?

The code wasn't particularly specific to 2D implementations, and I could easily adjust the logic. The hard part was going to be the rendering, though, especially keeping it performant.

My initial approach was to treat the heat as a sort of density and use the Marching Cubes (https://en.wikipedia.org/wiki/Marching_cubes) algorithm, an algorithm that is able to turn a 3d grid of scalar density values into a triangle mesh. In this case, I was going to use it to turn heat into a triangle mesh, but the idea remains the same. However, while implementing Marching Cubes, I kept running into issues related to the generation and projection of triangles. Once I'd spent enough time staring at the code, I realized that trying to fix the code would be more trouble than it was worth. Then, while browsing through the Taichi documentation, I realized that Taichi provides its own voxel renderer, for use in a 100 line challenge. While I certainly wasn't going to be fitting any of my code in 100 lines, the renderer itself was still useful. After a lot of issues, I was finally able to get the fire rendering in 3d. However, there are still a lot more issues to tackle before the code is done. Firstly, that the fire is rendering upside-down. Next, it's not using the correct color. The empty pixels are still being rendered, instead of being discarded and transparent. The cube of fire is only being rendered on one side.

All of these issues mean that the 3d renderer is still not complete, though it is getting closer to it.

Well, this is the first devlog (8 hours in), and it very well may be the only devlog I post, but I'd still like to talk a bit about the process and the decisions that I made along the way.

Why this project? Well, I was looking around my unfinished projects directory when I came across this project from a couple years ago. I wanted to give it a shot at finishing it, or at least polishing it up a bit.

The general idea of how this program works is a bit counterintuitive. While most fire simulations represent heat as things that rise, and so pixels tend to set pixels higher than them. This simulation does the reverse. Each pixel looks at pixels below it in order to determine its heat value. This also has the unintended (but not unwelcome) side effect of making the bottom row of pixels always keep its heat value, as they do not have pixels below them to look up their new heat values, so the ground is flammable. The X coordinate is also warped by a random amount, plus some scrolling perlin noise for added variety with coherence. The sparks at the tops of the flames are emergent behavior, there is no part of the code that intentionally creates those.

Why Python? Well, it's what I know best. Additionally, I'd recently discovered Taichi, a domain specific, high performance, parallel language that is embedded within, and uses the semantics of, Python. Taichi allows me to run the fire simulation at a solid 60fps, and I've gotten it to run at 120 FPS at 1440x960 before being bottlenecked. At 640x480, it runs at a blazing (ha) fast 500 fps. None of these are precise benchmarks, and YMMV.

I use PySide6 for the GUI, as my machine uses Plasma for the Desktop Environment, so it just made sense to write something for QT. Also, I know the library reasonably well.
While this project is not intended to be a realistic fire simulation, it does have an excellent stylized fire look to it.