|
1983
|
rasterminal by @PavolUlicny | Stardance
|
PavolUlicny
|
1
|
470.39
|
8580
|
[{"ship_num": 1, "ts": "2026-0 [{"ship_num": 1, "ts": "2026-09-08T16:24:17Z", "hours": 449.0, "multiplier": 19.99, "payout": 8580, "blessing": "neutral", "text": "rasterminal rasterminal is a 3D model viewer in the terminal Why i decided to build it The original idea didn’t really have any big inspiration, I’ve just always been fascinated by the inner workings of 3D and how that all works. I’ve been wanting to build a project involving 3D for a while and I didn’t want to make just another program that uses libraries and GPU drivers to do all the work. So I came up with the idea: a software rasterizer that renders in the terminal! There are lots of TUIs and lots of boring old software rasterizer projects, so I just combined the two into something unique. And over time, I realized I could make it an actually useful tool, with no real competition: a 3D model viewer in the terminal. Sure, there are some similar projects on GitHub (like taigrr’s trophy), but none are actually usable with heavier models or support pixel graphics. What I learned I learned a lot. I really mean a lot. Anything from math and rendering to how terminals work and how to control them using escape sequences. I don’t want to sit here and name everything I learned over the period of the last 5 months, but I can confidently say that this project really taught me how much work goes into everyday software and how to actually develop and maintain a project professionally. The future of rasterminal The whole project is very far from done. You can see that from the latest release version: v0.1.0-alpha.2. I’ve got a lot of work to do and I’ve roughly got the major landmarks mapped out. Main things I definitely want to change/add at some point before v1 are: Add animation support (currently can only render still meshes) Complete the renderer (complete support for basically every feature of every format that makes sense to support) Add optional GPU acceleration (after I’m satisfied with everything else) Hardware / OS support Supports every major OS (Windows, Linux, MacOS, and any other POSIX-based OS, so practically everything), and every CPU that I could think of (any architecture, 32 or 64bit). You would have to actually try a to find a platform that it doesn’t support (most of the unsupported hardware are big-endian systems, which are basically phased out completely). This is one of the main goals of the project, so (almost) any modern machine with a terminal can run it. Special thanks Special thanks to anyone who followed, liked, helped, or otherwise supported the project in any way. I wouldn’t have had the motivation to push it this far if it wasn’t for you guys.", "repo": "https://github.com/PavolUlicny/rasterminal", "demo": "https://github.com/PavolUlicny/rasterminal/releases/tag/v0.1.0-alpha.2"}]...
|
[{"post_id": 70278, "ts": "202 [{"post_id": 70278, "ts": "2026-09-18T21:10:51Z", "hours": 6.11, "text": "Code quality and CI improvements Finally did the long overdue main loop refactor. The main loop is now way shorter, more readable and more testable. I just split off some of the main loop’s work into it’s own modules, which made them way better looking and also, since they are now standalone modules, actually testable. A big win for repo structure. In the process, I also replaced the input handling’s long if chain that made each character do it’s job with a switch statement. It’s more readable and theoretically faster, although since I compile it with -O3, it probably made no difference or an unnoticeable one at best. I also finally fixed the super long CI times. Until now, CI used to take ~50 minutes (depending on how fast the GitHub runner was) because of cppcheck. Everything else finished in under 10 minutes, but cppcheck stalled it for an hour. It was stalling in mesh_assimp.cpp (the assimp wrapper) for most of it’s runtime. I always thought it was because assimp is a very large library. So I experimented with it a little. I included everything I include in the wrapper into a test file with a little code and ran cppcheck on that. It finished in less than 10 seconds. Eventually, I found out it was somehow taking that long because the main loader function was too long and handled too much by itself. So i just refactored it into 3 separate functions, without changing the behavior at all. Somehow, I still don’t get why, it reduced the whole cppcheck run to 9 minutes. a more than 5x improvement, just because I split a function into more functions. I’m not complaining, but it’s definitely weird. CI is now way faster and adding new things is gonna be way smoother now."}, {"post_id": 68728, "ts": "2026-09-15T17:06:41Z", "hours": 6.6975, "text": "Miscellaneous fixes and improvements Fixed two races in platform code (one MacOS, one Windows) Removed build flags that disabled some compiler security hardening at the cost of a little performance Fixed the test framework to not freak out on NaN in near assertions Improved thread launching and handling in loaders and renderer So overall just boring fixes and improvements, nothing special."}, {"post_id": 66825, "ts": "2026-09-12T18:42:57Z", "hours": 8.5847, "text": "Refactored the platform layer The whole platform layer was just one file until now. Since I did a lot of work on it recently, it grew to over 2400 lines of code. It was super confusing and disorienting. So I decided to refactor it (split it) into 8 files, based on what they handle: console.h - saving/restoring terminal state control.h - termination signal handling file.h - file operations (64bit) input_reader.h - handling input (not parsing, that is it’s own file) shared_memory.h - shared memory handling for the kitty protocol terminal_io.h - writes output to the terminal terminal_query.h - querying the terminal for things like graphics capability, etc. timing.h - frame timing and sleeps"}, {"post_id": 64252, "ts": "2026-09-08T14:55:07Z", "hours": 2.3467, "text": "Last pre-release checks and cleanup I’m finally ready to release v0.1.0-alpha.2. Only notable thing I changed here is that I changed the default thread count: It now defaults to hardware concurrency everywhere. Other than that, I of course did final documentation checks and fixes and now I’m just waiting for CI to pass so I can tag it and let the release workflow do the last step. So this is hopefully the last devlog before my ship!"}, {"post_id": 63837, "ts": "2026-09-07T20:19:19Z", "hours": 10.4164, "text": "Did some polish and cleanup of the platform layer Did final polish and cleanup of the platform layer since I want to actually finally cut a release relatively soon and I just did a lot of work there. Fixed things like useless tests, outdated or wrong comments and some platform specific quirks. Probably actually gonna cut a release soon (this time for real). Also added early rejections for BVH and CSM files, since they contain no model geometry (they can’t currently be displayed at all) and documented the change. The code is basically done (hopefully, I really don’t want to find another big gap that’s gonna take a week to close), I just want to correct anything wrong in the README, changelog, manpage or help menu and maybe make them look a little better before cutting a release and shipping."}, {"post_id": 62122, "ts": "2026-09-05T11:43:50Z", "hours": 9.5678, "text": "Working on SIGSTOP and SIGCONT handling SIGSTOP and SIGCONT are POSIX signals for stopping and resuming a running process. I’m working on adding handling for these, so you can safely pause and unpause rasterminal at any time. This is a lot of work, since until now, we just set up the terminal on program start and cleaned up when the program exited. There’s a lot of quirks and weird scenarios that I have to handle, for example if another signal gets sent while cleaning up the terminal for SIGSTOP. I’m trying to catch as many edge cases by just doing random things while using the program and also with the help of AI to come up with potentially uncaught scenarios."}, {"post_id": 59763, "ts": "2026-09-01T18:10:34Z", "hours": 4.3639, "text": "Added handling for SIGINT, SIGTERM, SIGQUIT and SIGHUP I don’t really have much to say here, I just added the full per-spec handling for all these. Only remaining POSIX-only gap is now SIGSTOP/SIGCONT (stop/resume process). I’m also starting school now, so I’ll be working on this less."}, {"post_id": 58964, "ts": "2026-08-31T15:12:04Z", "hours": 3.8394, "text": "Fully fixed and merged the first POSIX cleanup item Well, would you look at that! That took significantly less time than the Windows fix. It is partly because it was a smaller fix and only part whole POSIX fix, while the Windows one was the whole thing and also the foundation had already been laid out from the Windows work and I just integrated the POSIX path into that, but it is also very much because Microsoft is a horrible, terrible company that can’t make good software. I mean, look at GitHub, they have been going downhill ever since they got acquired by Microsoft. Now that I got that out of my system, here’s what was fixed: If the program cannot enable raw mode at startup, it safely fails instead of continuing and corrupting the terminal state If the cleanup gets interrupted, it retries cleanup so it doesn’t leave the terminal state corrupted after one failed attempt Onto the next POSIX fix: handling SIGQUIT and SIGHUP."}, {"post_id": 58269, "ts": "2026-08-30T17:14:59Z", "hours": 8.6936, "text": "Merged the full Windows console restoration branch My nightmare is over. I hopefully won’t have to deal with Windows for a while now. Summary of what is now fixed/handled on Windows: Ctrl+C, Ctrl+Break and Q exits fully recover the terminal’s state Ctrl+C and Ctrl+Break don’t leak mouse escape sequences into the next prompt if you terminate while actively dragging a model A bunch of other minor Windows or cmd.exe specific quirks Only thing that isn’t handled (didn’t find a good way to handle it) is task manager “end process”. It kills the program without cleaning up and sometimes freezes the shell."}, {"post_id": 56881, "ts": "2026-08-28T21:26:16Z", "hours": 9.6883, "text": "I HATE WINDOWS Windows just doesn’t work. It doesn’t work. Nothing works on Windows. Everything breaks. I don’t get it. THE UNIT TESTS PASS ON WINDOWS CI BUT WHEN I ACTUALLY RUN THE TESTS ON WINDOWS IT FAILS????? HOW IS THAT EVEN POSSIBLE. The release is now definitely getting delayed by at least a week because I keep running into more and more and more and more and more and more and more and more and more issues. I hate Windows. Microslop is the only company that could mess up a basic terminal emulator. And I also have to reboot my PC every time I fix something and push it and then reboot to get back to linux. this is torture. At one point I tried to do it on a Windows VM on linux but that was too slow so I just gave up."}, {"post_id": 55585, "ts": "2026-08-27T15:06:53Z", "hours": 8.8714, "text": "Found a bunch of terminal cleanup gaps Most of them are Windows or cmd.exe specific (nothing ever works on Windows), but some are present on POSIX too. The Windows specific ones are: cmd.exe for some unknown reason doesn’t turn off the raw input sequences, so arrow keys don’t work like they should, even though I explicitly turn it off (????????) (I hate Windows, they always have to do something unexplainable for no reason just so your code doesn’t work as it should) when you terminate the program with ctrl+c or ctrl+break while actively dragging the model around, it sometimes leaks mouse escape sequences into the next prompt bunch of other weird small stuff that nobody cares about And the few on POSIX are mostly ctrl+z suspend/resume behaviour not recovering the terminal and the same thing with ctrl+\\ (SIGQUIT). I’m still working on fixing these. Most of the windows ones are already fixed, but I haven’t even started with the linux/POSIX ones. I have postponed the planned release to when I fix these + any other issues I find."}, {"post_id": 54695, "ts": "2026-08-25T19:14:01Z", "hours": 10.7308, "text": "Cutting a release The repo is in a pretty complete and polished state, so I’ll cut a release here. This will also probably be the last release before I ship, so I’m making sure that nothing is broken and everything works on every platform. I’ve still got a lot of work to do though, even after the end of stardance, like animations, glTF PBR, format completeness for every format, GPU acceleration, etc."}, {"post_id": 53861, "ts": "2026-08-24T15:48:08Z", "hours": 10.9639, "text": "Merged the full assimp integration into main I really don’t have much to say here, I’ve already put all the info about the branch into the past devlogs. All the formats work and the wrapper is very sturdy. I’ve found more bugs in assimp itself than my code (devlog on that soon). So, rasterminal can now load basically any 3D model you throw at it. Some of the formats assimp supports are so niche, I’ve never even heard of them."}, {"post_id": 53278, "ts": "2026-08-23T18:46:58Z", "hours": 13.1411, "text": "Fuzzing my assimp wrapper I’m trying a bunch of hand-crafted models from all the formats that I can load and trying to find things that dont load or render properly. Also had AI write me a simple fuzzer in python and I’m just letting it run for a few hours. Also auditing the assimp loader paths against my wrapper to find any format specific behaviour that should be handled. I’ve already found a bunch of things and I’m still finding more. Assimp has a lot of weird quirks and issues that I keep running into. Honestly kinda regretting the decision to integrate it, but since I’m already so deep in, I’ll just keep going."}, {"post_id": 52574, "ts": "2026-08-22T19:13:37Z", "hours": 11.0969, "text": "Still working on the assimp intgration Currently trying various models from all the different model formats that assimp loads. So far found a segfault, some weird behavior and integration mistakes that I made. Also found a small bug in assimp itself, for which I’ve submitted the PR with the fix to their GitHub repo. For anyone interested, here’s the PR: https://github.com/assimp/assimp/pull/6799"}, {"post_id": 51884, "ts": "2026-08-21T19:41:32Z", "hours": 6.9825, "text": "Working on assimp integration Yop, I’m adding the Open Asset Import Library as a fallback for any model formats that aren’t natively supported with their own dedicated loader (only ones with dedicated loaders are glTF2, PLY, STL and OBJ). I’m still keeping the dedicated loaders, because they are more feature-complete, to-spec and wayyy faster (especially the glTF one). I added it because I feel like for a 3D model viewer, support for many formats, even niche and obscure ones, is pretty important, even though nobody might use them. This roughly doubled compile time and almost quadrupled binary size, which also made CI take way longer (of course). It somehow made the MacOS runners take 50 minutes to compile (from the previous 3 minutes), but I fixed that by bounding the number of processes CMake can spawn to the number of threads on the runner (previously was using -j which spawns as many as it wants and it was spawning about 230 of them). I’m still testing how it handles various model formats and trying to find any reachable segfaults."}, {"post_id": 51275, "ts": "2026-08-20T20:14:42Z", "hours": 6.7119, "text": "Cleanup and restructuring changes After I just merged three big feature branches (kitty and sixel graphics protocols and the high-res performance branch), I needed to do some overdue cleanup and refactoring. And so I did: Collapsed the super long changelog entries into way more readable and legible points Restructured the src directory into multiple subdirectories because it had like 50 files already Sadly completely removed the Make build system, so now you can only build with CMake (CMake is very much evil and even more evil but it’s the only one of the two that supports windows and I was tired of managing two build systems) Removed the –graphics-scale flag, so now everything renders at native resolution And some small docs and comment cleanup"}, {"post_id": 50683, "ts": "2026-08-20T00:07:13Z", "hours": 12.3297, "text": "Finally merging the performance branch It’s finally time to merge the performance branch. I basically redesigned the whole renderer and rasterizer around high resolution workloads, where it would still choose the old high-poly paths where they were faster. Even snuck in some SSE2 SIMD code (picture), although I will probably be switching to a dispatch SIMD library like Google’s Highway. Not entirely sure it will be Highway or even if I will do that yet, that depends on the code complexity and before/after benchmarks."}, {"post_id": 49184, "ts": "2026-08-17T20:28:00Z", "hours": 14.5689, "text": "Still optimizing… Spent the first ~7 hours trying to find microoptimizations and each one was either a wash or worse somehow. The compiler works in mysterious ways. At some point, I just gave up and let Claude have a go at the optimizing. Surprisingly it actually came up with a lot of interesting optimization techniques and solutions that I definitely couldn’t have come up with on my own. But it found so much, that the whole diff adds 5k lines of code. So now I’ll be cleaning up, testing, and maybe further optimizing that diff…"}, {"post_id": 48227, "ts": "2026-08-16T15:09:59Z", "hours": 3.5944, "text": "My reported bug in libtermkey has been fixed in the newest version Just got an email from one of the maintainers that the crash bug i reported a month ago was fixed in the new release. libtermkey is a terminal input parsing library that I considered using and found a crash bug in. The bug was already fixed in neovim’s fork of the library, so i just pointed the maintainers at that fix. For anybody interested, here’s the issue link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142891"}, {"post_id": 48078, "ts": "2026-08-16T11:20:07Z", "hours": 11.47, "text": "Working on improving performance With the addition of the high-res protocols, the target resolutions quickly went from hundreds or thousands of pixels to millions. So I now desperately need to improve performance. So far it’s looking promising: A whole model covering the camera 6 moving at 4k went from about 8 fps to 20-30 fps. Not ideal yet, but I think we’re on the right track. Super dense meshes (more than 2 million polygons) improved 2-3x Meshes with transparent parts improved about 2x While these wins may seem really big (they kinda are), the jump in resolutions still means they are barely usable interactively. I do want to add gpu acceleration later (with the cpu path as a fallback), but until then I want to make it as fast as I possibly can."}, {"post_id": 47112, "ts": "2026-08-14T19:18:15Z", "hours": 9.0333, "text": "Fully merged sixel Fully merged the sixel protocol implementation. Works on all platforms everywhere that supports it. So now both high-res terminal protocols done. Moving onto other minor things and especially performance."}, {"post_id": 46486, "ts": "2026-08-13T18:38:49Z", "hours": 10.6753, "text": "Working on adding full Sixel support Working on adding support for the other mainstream terminal pixel protocol of the main two - Sixel. Already did fully implemented the kitty protocol last time, so once I’m done with this one, I’ll be done with terminal protocols (at least for the near future, hopefully). There are some other ones like the iterm2 protocol, but that one’s pretty rare and I won’t add it unless I really don’t have anything better to do. It’s basically done, just need to polish it and test it on a bunch of terminals and operating systems to make sure everything works before merging."}, {"post_id": 44676, "ts": "2026-08-10T16:23:20Z", "hours": 4.0767, "text": "Fully merged and done with Kitty Finally completed the kitty protocol implementation. It is kinda slow, since the resolution is so much bigger, so I will try to optimize the high-res performance even more. So now the next two big milestones are: Add Sixel on top of kitty, that’ll be a lot of work Optimize the rasterizer even more I was thinking of maybe adding gpu rendering as an option for super large meshes or high-res scenarios, but idk. I’ll definetly keep the pure cpu renderer for computers without gpus, but I’m not sure about a gpu implementation. It would be hard to do, less portable and it might not even work that well."}, {"post_id": 44513, "ts": "2026-08-10T09:59:08Z", "hours": 6.8483, "text": "Found a bug in Ghostty’s kitty protocol handling Ghostty is a modern and fast terminal emulator that i personally use. While testing the kitty protocol feature in rasterminal, I found a Ghostty bug that lagged my whole computer after a few minutes. I tested it in Kitty (terminal emulator) and there it worked fine. I looked at Ghostty’s code vs Kitty’s, found the bug and reported it to the Ghostty maintainers. Mitchell himself (the creator) fixed it in like 2 hours. Honestly I’m kinda sad I didn’t get to become a contributor and fix the bug, but since it was a small fix and I already described it in the issue, I get why Mitchell just fixed it in main. Here’s the full issue: https://github.com/ghostty-org/ghostty/discussions/13719"}, {"post_id": 43513, "ts": "2026-08-08T20:35:37Z", "hours": 7.6361, "text": "Working on adding support for the Kitty protocol Some modern terminals like Kitty and Ghostty have support for the Kitty protocol. It’s a feature that allows you to display high resolution content like images and videos in the terminal without it looking super pixelated. There’s also the Sixel protocol, which is basically the same thing but a little worse and more widely supported (even Windows terminal has it). I’ll add Sixel after i merge Kitty to main. It is very clearly a worthwhile feature and I have been planning to add it from the start of the project. Today I finally decided that it’s time. Most of the work is already done on the branch and i’m just polishing out the bugs and issues before I merge. In the photos, you can see the comparison between using just the block characters and using Kitty. It is a night and day difference. Although the performance isn’t great at that high of a resolution, but I’m still working on optimizing that."}, {"post_id": 42752, "ts": "2026-08-07T17:00:51Z", "hours": 3.5125, "text": "Minor comment cleanup Just did some comment cleanup: Deleted redundant comments and why comments Removed separator comments Compressed or rewrote some really long comments (without removing the info they give)"}, {"post_id": 42161, "ts": "2026-08-06T19:24:06Z", "hours": 8.2153, "text": "Added issue templates + contributing documentation Added templates and a config for submitting GitHub issues, for both bug reports and feature requests. Also added a CONTRIBUTING.md for clear instructions on how to make, structure and audit code contributions. (tests, linters, formatting, etc.) I tried to make some optimizations to the renderer by auditing the compiler generated assembly and looking for inefficiencies, but everything i tried turned out to actually hurt performance. And GitHub actions decided to have a major outage right when i pushed the commits, so that’s awesome"}, {"post_id": 39599, "ts": "2026-08-02T18:05:04Z", "hours": 7.4436, "text": "Completely redesigned and rewrote the HUD The HUD used to be just a single line at the bottom of the screen aligned to the left. It looked pretty bad, but it did tell the user everything they needed to know. [picture 1] First, I added model name sanitization, so models with control bytes like newline ( \\n ), line feed or other symbols like emojis can’t break the whole program when trying to display them in the HUD. Then, I completely redesigned the whole HUD to look better and be more robust, while still telling the user everything they need to know. I went with this design [picture 2]: On the left, you only have the model name. In the middle, first you have the current shading mode (highlighted in cyan), then the lighting mode in plain white and then the background color in gray. All three middle indicators are separated with a dot and are different colors, so nobody can confuse them. On the right, there’s 3 boolean indicators: spin (if the model spin is on), backface cull (if it’s currently culling backfaces) and texture (if it’s showing the texture, isn’t there at all on models without a texture). They are gray if inactive and cyan if active. The last thing on the right is just the fps number. There can also be optional indicators: Wireframe color (in the middle, after the shading mode) which only shows up in wireframe mode. [picture 3] First person speed multiplier (on the right, between the bools and the fps number) which shows up only in first person mode. [picture 4] I also made each “island” cleanly disappear when the terminal’s width is too low instead of just slowly getting cut off letter by letter. I think this design looks better, less cluttered and is pretty easy to understand at a glance. I would very much appreciate a star on GitHub!"}, {"post_id": 38478, "ts": "2026-07-31T21:36:35Z", "hours": 7.7572, "text": "Did a smaller fix and added a pretty big feature First, let’s talk about the small fix: I Fixed a super long model name showing up in the HUD in it’s full length, often blocking out other HUD elements. Previously, the HUD would display a model name of any length. Now there’s a hard cap of 24 chars, with any name longer than that truncated (middle style truncation) to fit into that limit. And now the big feature: Added a first person noclip-style camera mode. It’s accessed with the –first-person flag and let’s you explore the model as a floating camera (not bound like the default orbit camera). It was honestly easier to implement than I thought it would be. With it, I added two new keybinds special to the first person mode - E and V for going up and down. They don’t do nothing in orbit mode. Also added a second –first-person-speed flag for controlling the initial movement speed. It is also controllable during runtime with scrolling or +/- (I didn’t know what to bind these to in this mode since you can’t zoom like in orbit mode and this was the only place where they fit). In the photos, you can see some angles taken in the first person mode that weren’t possible in the default orbit mode."}, {"post_id": 37806, "ts": "2026-07-30T19:08:29Z", "hours": 2.7436, "text": "Finally committed and pushed the input rework Tested it on both linux and windows and everything seems to work. No inputs interpreted as other inputs, all edge cases handled, just works. Finally can move onto other things."}, {"post_id": 37656, "ts": "2026-07-30T15:25:21Z", "hours": 9.285, "text": "Still working on the input parsing system It is very hard and I keep finding bugs and reasons to redesign it. I’m in pain. I do think I’m getting closer to the final robust design."}, {"post_id": 36697, "ts": "2026-07-28T22:28:53Z", "hours": 9.9361, "text": "Working on completely rewriting the current input parsing handling The current input handling is subpar at best; it interprets a lot of random keys as escape, which currently quits the program (This will also be changed to Q and Ctrl+C only. Kind of a no-brainer since this is the more standard choice for TUIs - for example btop - and it also means I don’t have to deal with the headache of distinguishing function keys and others from escape) and has a lot of other quirky behavior that needs fixing. I’ll also try to improve robustness against malformed input like a leaky SSH session. There are a lot of various edge cases and situations where you have no way to distinguish real input from malformed input. This is all a very major pain in the ass. And I thought figuring out the raw mode output would be the hard part. And after all this, I’ll end up with way less attention than strictly slower, less robust competitors, just because they already have an audience from other projects. I bet nobody will even read this. I’m basically talking to myself right now. Or maybe, just to spite me, the algorithm will push this more than my other devlogs."}, {"post_id": 35924, "ts": "2026-07-27T17:55:43Z", "hours": 8.7953, "text": "So, i found two memory bugs in a widely used terminal input library I was researching terminal input libraries to use for this project because my current approach was so buggy that it wasn’t worth fixing. Both of them are memory bugs in the libtermkey library. There are forks of the lib with this fixed, but since many projects still rely on this lib, i submitted them anyways. I’ve also confirmed that the bug is present on my machine on Ubuntu 24.04 LTS on Neovim, because it links the vulnerable shared library. I didn’t mark them as CVEs (hopefully that isn’t a problem). If anyone want’s to look at the bug reports, they are at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142891 and https://bugs.launchpad.net/ubuntu/+source/libtermkey/+bug/2161916"}, {"post_id": 33607, "ts": "2026-07-23T17:38:48Z", "hours": 4.5575, "text": "Added more CLI flags for startup customizability Added flags to set the camera pitch, yaw and zoom on startup. Now every runtime-settable variable can be set during startup through the CLI. The R button now resets the state to the CLI set state, not to factory defaults."}, {"post_id": 32607, "ts": "2026-07-21T21:48:11Z", "hours": 4.4442, "text": "Added –spin-speed and –spin-direction flags Added CLI flags for the spin speed and direction. The speed is in deg/s and the directions is simply left or right. Here’s what 1000 deg/s looks like spinning to the right:"}, {"post_id": 30923, "ts": "2026-07-18T22:17:24Z", "hours": 8.6892, "text": "Did a bunch of small code quality and usability improvements Fixed a Windows bug that crashed the program on model sizes bigger than 2GB, improved the orbit usability (fixed mouse drag behavior when models are turned upside down), and did a few cleanups and fixes in the CLI parsing. I’m planning on adding a few CLI flags that I think can be very useful for some people, specifically better spin settings, starting camera angle/zoom control and a few more."}, {"post_id": 29772, "ts": "2026-07-16T21:27:23Z", "hours": 0.7175, "text": "Finally merged color-fallback, I can move onto other things The branch is finally merged. I’ve accumulated a bunch of usability and code quirks and issues that i can finally get to now that the branch is merged. So now I’ll be reworking all the CLI flags, camera and other components. And we also passed the 700 commit mark with this merge!"}, {"post_id": 29484, "ts": "2026-07-16T13:40:29Z", "hours": 4.9444, "text": "Changed the 24bit to 256 color palette conversion logic Until now, the conversion picked the closest color possible mathematically. But from testing on a bunch of different models, I’ve realized that it doesn’t actually look very close to the human eye. So I swapped it out for a different method, called CIELAB distance. Now it still doesn’t look perfect, but as a fallback for older terminals it’s close enough."}, {"post_id": 28408, "ts": "2026-07-14T17:26:16Z", "hours": 9.2258, "text": "Working on a –color compatibility flag The color terminal compatibility thing I was working on has landed in the branch, now I’m adding a –color flag to override the automatic capability detection for situations like ssh, where we almost always degrade to the 256 color pallete for maximum compatibility. So now you’re gonna be able to use the right color mode even if the automatic detection is wrong for your situation."}, {"post_id": 27302, "ts": "2026-07-12T19:23:17Z", "hours": 10.3522, "text": "Working on terminal color capability detection I am adding automatic terminal capability detection, meaning that rasterminal will get the terminal type and either refuse to render on super old or “dumb” terminals, degrade on some terminals and render normally on modern ones."}, {"post_id": 24314, "ts": "2026-07-07T20:18:01Z", "hours": 5.1908, "text": "Working on adding 256 color support Some older terminals can’t display full 24bit RGB colors and use a 256 color palette instead. I’m adding a fallback so the older terminals can still use rasterminal. It still calculates the full old RGB colors, but then just maps them to the nearest 256 color with LUTs. On a side note, I switched my terminal emulator from Kitty to Ghostty."}, {"post_id": 23070, "ts": "2026-07-05T20:10:12Z", "hours": 10.4403, "text": "Working on portability Did a bunch of small fixes and improvements in the last ~week. Right now I’m on vacation for the next couple of days, so I won’t be active. I am currently working on broader terminal and platform support, so older systems and terminals will be able to run cleanly with some fallbacks or will fail loud with a clear message about what isn’t supported."}, {"post_id": 19371, "ts": "2026-06-30T17:34:50Z", "hours": 5.1925, "text": "Completely removed the shadow map Before, rasterminal built a shadow map on model load and displayed it during runtime. I now completely removed it, because it was slower during load, slower during runtime, sometimes looked broken on curved surfaces and added essentially no value. Here, the first picture is with the shadow map and the second is without."}, {"post_id": 18685, "ts": "2026-06-29T21:27:29Z", "hours": 13.4722, "text": "Wasted 7 hours of my life Did a bunch of smaller cleanups and fixes, and then I tried to template the unlit and lit paths in the rasterize_flat function, which turned out to be a performance regression. Awesome."}, {"post_id": 17021, "ts": "2026-06-27T17:00:39Z", "hours": 5.7733, "text": "Added a release workflow, manpage and changelog I added a github release workflow that works alongside the changelog and released the first pre-release version: v0.1.0-alpha.1 Also added a manpage and an install target to make and cmake that installs the binary, docs and manpage into the path."}, {"post_id": 16313, "ts": "2026-06-26T15:28:43Z", "hours": 5.1883, "text": "Pararelized the wireframe shading mode I did a bunch of small things alongside it, but the main feature for this devlog is the pararelization of the wireframe shading mode. It was previously fully single threaded, but it wasn’t that hard to pararelize, i just had to make the function it used to write into the framebuffer (draw_line) CAS atomic, to avoid race conditions. Now wireframe is the fastest shading mode in basically all scenarios. Below, you can see a performance benchmark (built into rasterminal using a flag) with wireframe mode on a super dense mesh and how the wireframe mode looks like (you can also cycle the colors)."}, {"post_id": 15932, "ts": "2026-06-25T21:35:36Z", "hours": 1.9053, "text": "Split the tests into sub-directories The test suite is now very long (20k LOC across 47 files), so i decided to split it into sub-directories instead of just having 47 files in one flat dir. It’s cleaner, more maintainable and looks better."}, {"post_id": 15741, "ts": "2026-06-25T16:48:43Z", "hours": 4.9903, "text": "Completely removed gouraud shading mode Gouraud was previously the main shading mode, but now I’ve just completely removed it. It was by far the slowest, while not adding any actual value to the project. Blinn-phong lighting is faster AND it supports more features (normal maps, etc.), so there was just no point in keeping gouraud. Now that I’ve removed it, the project has less code to maintain and a faster default shading mode with more features."}, {"post_id": 15551, "ts": "2026-06-25T08:50:38Z", "hours": 3.7597, "text": "Added proper OBJ bump map support OBJ bump maps are textures for simulating bumps and wrinkles on models. Blender used to author bump maps as normal maps for some reason, so I made it automatically detect if it’s a normal map disguised as a bump map and handle it well, since there are a lot of old Blender OBJ models in the wild. But it also handles bump maps as bump maps normally, so it’s basically the best of both worlds."}, {"post_id": 15117, "ts": "2026-06-24T15:43:58Z", "hours": 6.87, "text": "Added texture transform into the TEXCOORD branch and merged it into main Not that hard, just read it, pass it to the rasterizer and then display it. I did have a very sneaky bug in the loader that made the whole feature render wrong, where I just had to negate one value to fully fix it, but now everything fully works. Below you can see the Khronos test asset for texture transforms. (tick means fully working, clearcoat is not yet implemented so it doesn’t show as working)"}, {"post_id": 13839, "ts": "2026-06-22T17:59:12Z", "hours": 5.2097, "text": "Added TEXCOORD_1 support glTF sometimes authors a second TEXCOORD set (first one is TEXCOORD_0, 0 indexed numbering). The official spec only requires support for the first two TEXCOORD sets, even though there can theoretically be any number of them in a model. That said, major model exporters don’t author any more than the two sets, so to avoid extra work, I only added support for 0 and 1. (not merged into main yet, I want to polish it a little and maybe add KHR_texture_transform support on top of it first)"}, {"post_id": 12798, "ts": "2026-06-20T22:37:18Z", "hours": 7.6314, "text": "Optimized the transparent cleanup path in the renderer After rendering the model in the transparent path, we have to resolve the transparent pixels, which basically just pastes in the pixels behind it and sometimes tints it based on how dark and what color the transparent material is (tinted glass will make the things behind it darker, normal glass will be mostly completely untinted). Before, the resolve function looped over every single pixel in the frame, even non-transparent and background ones. This is obviously wasteful. So I made it find the smallest box, in which all the transparent pixels of the whole frame fit and just looped over that. It recovered the overhead of the transparent resolve on models with smaller transparent parts, but it also made fully transparent or mostly transparent models slightly slower (it still basically loops over almost the whole screen on these types of models, so keeping track of the smallest bounding box while also still doing the same work as before made it a little slower). But the performance benefits for the average model outweighed the losses on rare fully transparent models. In the image, you can see the benchmark results versus the baseline."}, {"post_id": 12171, "ts": "2026-06-19T21:42:34Z", "hours": 6.6653, "text": "Made the shading mode branches compile time instead of runtime in the renderer with templates Did the same template if constexpr (compile time if branches) thing that we already do for opaque/transparent models with the shading mode (was a runtime per triangle if branch before), which improved performance. It basically just makes a new copy of the function for each shading mode x each transparency mode, so 4x2 which is 8 slightly different functions and uses the correct one on each call. That increases binary size and icache pressure, but drops per triangle or per pixel if branches that hurt performance, so it’s an overall performance win. Benchmarked across a ton of different resolutions, models, shading modes, etc. (the benchmark by itself took like 2 hours to run)"}, {"post_id": 10115, "ts": "2026-06-16T18:24:38Z", "hours": 4.0297, "text": "Added support for wrap modes for textures Only in glTF and OBJ models (the only ones that support it) and verified with the Khronos group sample assets model. Also added PLY texture support."}, {"post_id": 9453, "ts": "2026-06-15T20:20:25Z", "hours": 4.6839, "text": "Working on adding supersampling anti-aliasing Still a work in progress and I might not merge it into main, because it’s a lot of work for not that much benefit. I have to catch a lot of bad_allocs and things like that for super large SSAA sizes, which is really annoying and can affect performance. SSAA works by rendering at a higher resolution and then downscaling for better edges (makes edges smooth and fade-in instead of jagged) Picture with 2x SSAA and without SSAA:"}, {"post_id": 8652, "ts": "2026-06-14T11:36:32Z", "hours": 5.2058, "text": "Adapted the arg parsing and CLI behaviour to the GNU standard Now, rasterminal’s CLI behaves under the GNU CLI standards, so on par with most linux tools."}, {"post_id": 8162, "ts": "2026-06-13T16:37:29Z", "hours": 2.8394, "text": "Added deduplicating vertices to the stl loader. After two unsuccessful and unmerged branches, I finally did something useful on main. I used to deduplicate the vertices in stl_reader and then reduplicate them in the loader. But now, we just dedup in stl_reader and use those. That also allowed me to enable ambient occlusion, which was disabled for stl before. And now crease smoothing fully works too. And it’s faster (runtime wise, load time is slower because of ambient occlusion and crease smoothing that weren’t there before). So an all-round very positive change, and also an end to my non-merging dry spell."}, {"post_id": 7990, "ts": "2026-06-13T10:20:35Z", "hours": 2.4908, "text": "Replaced tinyobjloader with rapidobj for way faster obj parsing But after actually replacing it and integrating it into the source code, i realized it’s not worth it, because rapidobj just has too many downsides and isn’t very actively supported anymore. For example, it doesn’t support multiple mtl files, which is against the spec. So if i want to keep it spec compliant, I need to find a workaround for it, which just isn’t worth the speed increase of rapidobj, even if it’s like 4x faster (from my testing on a large obj) The graph is from this article: https://aras-p.info/blog/2022/05/14/comparing-obj-parse-libraries/"}, {"post_id": 7643, "ts": "2026-06-12T19:26:54Z", "hours": 8.7975, "text": "I tried to rewrite the STL loader from scratch for more performance But it’s taking super long and I’m way too bored with it, so I think I’ll just abandon the branch and work on something else."}, {"post_id": 6791, "ts": "2026-06-11T11:35:25Z", "hours": 3.6575, "text": "Added full native 32 bit support for all platforms Didn’t have to redesign any of the source code (thankfully), just some warning suppressing and fixing some static casts. Also added a CI job that’ll flag future 32 bit compatibility regressions."}, {"post_id": 5755, "ts": "2026-06-09T17:34:17Z", "hours": 4.1133, "text": "Transparency is fully done and merged. Did some polish, cleanup and optimization on the transparency branch and successfully merged into main."}, {"post_id": 4897, "ts": "2026-06-08T13:53:56Z", "hours": 3.2906, "text": "Transparency is basically done, with caveats. Transparency works correctly, but transmission , which is completely different, is simplified to transparency. So for spec-complete gltf, I would need to implement the whole transmission pipeline, which I’m way too lazy to do right now. So for now, we just simplify it to transparency and call it a day."}, {"post_id": 4320, "ts": "2026-06-07T16:09:10Z", "hours": 6.2586, "text": "Working on adding transparency support. For that, I have to completely rework the rendering loop and the rasterizers, so basically the whole core of the project. It’s going very badly. And since performance is a big factor here, I’m going for a template approach so the transparency overhead doesn’t affect non-transparent meshes."}, {"post_id": 3846, "ts": "2026-06-06T22:11:48Z", "hours": 3.5269, "text": "I did a hot-loop performance cleanup run, because the hot loops were getting slower with new features, and I found a big optimization opportunity in clip-near call sites: clip_near slices off the part of a triangle that pokes behind the camera’s near plane, but almost every triangle is fully in front of it with nothing to clip. The pipeline still called it for all of them, and in the compiled binary that common case just copied all three vertices to memory and back, millions of times a frame. The fix was to check inline whether the triangle is fully in front and skip the call entirely if so. Result on a 2.77M-triangle model: median frame time dropped from 21.1 ms to 19.2 ms, about 8.7% faster."}, {"post_id": 3572, "ts": "2026-06-06T15:51:49Z", "hours": 2.4386, "text": "Because of all the libraries I added, the binary size increased significantly. I don’t use most of the vendored code, so I added build flags to ignore unused code in the final binary. Other than that, I added some other performance flags and also a CMakePresets.txt. It took longer than it should’ve, because I tested and benchmarked a bunch of other configs and flags. I put off PGO for now."}, {"post_id": 2939, "ts": "2026-06-05T20:55:20Z", "hours": 3.9267, "text": "I wired in Webp image format support by vendoring in google’s libwebp decoding library. It wasn’t that hard to wire into the source code, the hard part was the vendoring, dealing with licenses and professional vendoring practices. Only thing that remains to add for full gltf extension support is avif image support, but I’ll do that later."}, {"post_id": 2739, "ts": "2026-06-05T14:38:57Z", "hours": 1.3417, "text": "I just added unlit material support, which means materials that are supposed to stay intentionally unaffected by lighting render correctly. Pretty straightforward change, just read it at load time and then check if that material is unlit during the lighting pass and skip it."}, {"post_id": 2631, "ts": "2026-06-05T08:21:00Z", "hours": 3.3225, "text": "Reworked the whole readme with better instructions, screenshots and a gif. The gif was super annoying to polish, because i used asciinema which records all the setup escape sequences so there were gaps at the start and end that i had to manually read and remove. And I also had to perfectly close it exactly when it did one full rotation and that took like an hour to perfect. At least now I don’t have to touch the readme for a while."}, {"post_id": 2311, "ts": "2026-06-04T18:46:14Z", "hours": 3.1892, "text": "Well, I tried to refactor the main rendering loop for like the third time, because it’s horrifyingly indented, but it has defeated me once again. At this point, I’m confident that it’s impossible to do without a noticeable drop in performance, or g++ is just ragebaiting me. I installed a rainbow indentation neovim plugin just to show the absurdity of this."}, {"post_id": 386, "ts": "2026-06-01T18:58:14Z", "hours": 0.6783, "text": "I just implemented KTX2 and Basis texture support, which are special compressed texture formats. So now any models with these textures are viewable in rasterminal."}, {"post_id": 359, "ts": "2026-06-01T17:59:06Z", "hours": 4.5428, "text": "Hey everyone, I want to introduce my project! rasterminal is a full software 3D rasterizer and model viewer that runs entirely in your terminal. The whole rendering pipeline is implemented from scratch. I only rely on third-party libraries for load-time things like 3D model parsing, image parsing, and decompression. It doesn’t touch the GPU at all, running purely on the CPU. That makes it completely safe for SSH usage, though it does come with a performance cost. I use multithreading to recover some of what’s lost, and the result is still significantly faster than any other terminal 3D viewer I’ve come across. Right now I’m focused on broader 3D format feature support and transparent material rendering. If you want to try it out, I’d love to hear what you think, feedback and issues are very welcome over on GitHub. https://github.com/PavolUlicny/rasterminal Thanks for any support! 🙏"}]...
|
Title: rasterminal by @PavolUlicny | Stardance
De Title: rasterminal by @PavolUlicny | Stardance
Devlogs:
Hey everyone, I want to introduce my project! rasterminal is a full software 3D rasterizer and model viewer that runs entirely in your terminal. The whole rendering pipeline is implemented from scratch. I only rely on third-party libraries for load-time things like 3D model parsing, image parsing, and decompression. It doesn’t touch the GPU at all, running purely on the CPU. That makes it completely safe for SSH usage, though it does come with a performance cost. I use multithreading to recover some of what’s lost, and the result is still significantly faster than any other terminal 3D viewer I’ve come across. Right now I’m focused on broader 3D format feature support and transparent material rendering. If you want to try it out, I’d love to hear what you think, feedback and issues are very welcome over on GitHub. https://github.com/PavolUlicny/rasterminal Thanks for any support! 🙏
I just implemented KTX2 and Basis texture support, which are special compressed texture formats. So now any models with these textures are viewable in rasterminal.
Well, I tried to refactor the main rendering loop for like the third time, because it’s horrifyingly indented, but it has defeated me once again. At this point, I’m confident that it’s impossible to do without a noticeable drop in performance, or g++ is just ragebaiting me. I installed a rainbow indentation neovim plugin just to show the absurdity of this.
Reworked the whole readme with better instructions, screenshots and a gif. The gif was super annoying to polish, because i used asciinema which records all the setup escape sequences so there were gaps at the start and end that i had to manually read and remove. And I also had to perfectly close it exactly when it did one full rotation and that took like an hour to perfect. At least now I don’t have to touch the readme for a while.
I just added unlit material support, which means materials that are supposed to stay intentionally unaffected by lighting render correctly. Pretty straightforward change, just read it at load time and then check if that material is unlit during the lighting pass and skip it.
I wired in Webp image format support by vendoring in google’s libwebp decoding library. It wasn’t that hard to wire into the source code, the hard part was the vendoring, dealing with licenses and professional vendoring practices. Only thing that remains to add for full gltf extension support is avif image support, but I’ll do that later.
Because of all the libraries I added, the binary size increased significantly. I don’t use most of the vendored code, so I added build flags to ignore unused code in the final binary. Other than that, I added some other performance flags and also a CMakePresets.txt. It took longer than it should’ve, because I tested and benchmarked a bunch of other configs and flags. I put off PGO for now.
I did a hot-loop performance cleanup run, because the hot loops were getting slower with new features, and I found a big optimization opportunity in clip-near call sites: clip_near slices off the part of a triangle that pokes behind the camera’s near plane, but almost every triangle is fully in front of it with nothing to clip. The pipeline still called it for all of them, and in the compiled binary that common case just copied all three vertices to memory and back, millions of times a frame. The fix was to check inline whether the triangle is fully in front and skip the call entirely if so. Result on a 2.77M-triangle model: median frame time dropped from 21.1 ms to 19.2 ms, about 8.7% faster.
Working on adding transparency support. For that, I have to completely rework the rendering loop and the rasterizers, so basically the whole core of the project. It’s going very badly. And since performance is a big factor here, I’m going for a template approach so the transparency overhead doesn’t affect non-transparent meshes.
Transparency is basically done, with caveats. Transparency works correctly, but transmission , which is completely different, is simplified to transparency. So for spec-complete gltf, I would need to implement the whole transmission pipeline, which I’m way too lazy to do right now. So for now, we just simplify it to transparency and call it a day.
Transparency is fully done and merged. Did some polish, cleanup and optimization on the transparency branch and successfully merged into main.
Added full native 32 bit support for all platforms Didn’t have to redesign any of the source code (thankfully), just some warning suppressing and fixing some static casts. Also added a CI job that’ll flag future 32 bit compatibility regressions.
I tried to rewrite the STL loader from scratch for more performance But it’s taking super long and I’m way too bored with it, so I think I’ll just abandon the branch and work on something else.
Replaced tinyobjloader with rapidobj for way faster obj parsing But after actually replacing it and integrating it into the source code, i realized it’s not worth it, because rapidobj just has too many downsides and isn’t very actively supported anymore. For example, it doesn’t support multiple mtl files, which is against the spec. So if i want to keep it spec compliant, I need to find a workaround for it, which just isn’t worth the speed increase of rapidobj, even if it’s like 4x faster (from my testing on a large obj) The graph is from this article: https://aras-p.info/blog/2022/05/14/comparing-obj-parse-libraries/
Added deduplicating vertices to the stl loader. After two unsuccessful and unmerged branches, I finally did something useful on main. I used to deduplicate the vertices in stl_reader and then reduplicate them in the loader. But now, we just dedup in stl_reader and use those. That also allowed me to enable ambient occlusion, which was disabled for stl before. And now crease smoothing fully works too. And it’s faster (runtime wise, load time is slower because of ambient occlusion and crease smoothing that weren’t there before). So an all-round very positive change, and also an end to my non-merging dry spell.
Adapted the arg parsing and CLI behaviour to the GNU standard Now, rasterminal’s CLI behaves under the GNU CLI standards, so on par with most linux tools.
Working on adding supersampling anti-aliasing Still a work in progress and I might not merge it into main, because it’s a lot of work for not that much benefit. I have to catch a lot of bad_allocs and things like that for super large SSAA sizes, which is really annoying and can affect performance. SSAA works by rendering at a higher resolution and then downscaling for better edges (makes edges smooth and fade-in instead of jagged) Picture with 2x SSAA and without SSAA:
Added support for wrap modes for textures Only in glTF and OBJ models (the only ones that support it) and verified with the Khronos group sample assets model. Also added PLY texture support.
Made the shading mode branches compile time instead of runtime in the renderer with templates Did the same template if constexpr (compile time if branches) thing that we already do for opaque/transparent models with the shading mode (was a runtime per triangle if branch before), which improved performance. It basically just makes a new copy of the function for each shading mode x each transparency mode, so 4x2 which is 8 slightly different functions and uses the correct one on each call. That increases binary size and icache pressure, but drops per triangle or per pixel if branches that hurt performance, so it’s an overall performance win. Benchmarked across a ton of different resolutions, models, shading modes, etc. (the benchmark by itself took like 2 hours to run)
Optimized the transparent cleanup path in the renderer After rendering the model in the transparent path, we have to resolve the transparent pixels, which basically just pastes in the pixels behind it and sometimes tints it based on how dark and what color the transparent material is (tinted glass will make the things behind it darker, normal glass will be mostly completely untinted). Before, the resolve function looped over every single pixel in the frame, even non-transparent and background ones. This is obviously wasteful. So I made it find the smallest box, in which all the transparent pixels of the whole frame fit and just looped over that. It recovered the overhead of the transparent resolve on models with smaller transparent parts, but it also made fully transparent or mostly transparent models slightly slower (it still basically loops over almost the whole screen on these types of models, so keeping track of the smallest bounding box while also still doing the same work as before made it a little slower). But the performance benefits for the average model outweighed the losses on rare fully transparent models. In the image, you can see the benchmark results versus the baseline.
Added TEXCOORD_1 support glTF sometimes authors a second TEXCOORD set (first one is TEXCOORD_0, 0 indexed numbering). The official spec only requires support for the first two TEXCOORD sets, even though there can theoretically be any number of them in a model. That said, major model exporters don’t author any more than the two sets, so to avoid extra work, I only added support for 0 and 1. (not merged into main yet, I want to polish it a little and maybe add KHR_texture_transform support on top of it first)
Added texture transform into the TEXCOORD branch and merged it into main Not that hard, just read it, pass it to the rasterizer and then display it. I did have a very sneaky bug in the loader that made the whole feature render wrong, where I just had to negate one value to fully fix it, but now everything fully works. Below you can see the Khronos test asset for texture transforms. (tick means fully working, clearcoat is not yet implemented so it doesn’t show as working)
Added proper OBJ bump map support OBJ bump maps are textures for simulating bumps and wrinkles on models. Blender used to author bump maps as normal maps for some reason, so I made it automatically detect if it’s a normal map disguised as a bump map and handle it well, since there are a lot of old Blender OBJ models in the wild. But it also handles bump maps as bump maps normally, so it’s basically the best of both worlds.
Completely removed gouraud shading mode Gouraud was previously the main shading mode, but now I’ve just completely removed it. It was by far the slowest, while not adding any actual value to the project. Blinn-phong lighting is faster AND it supports more features (normal maps, etc.), so there was just no point in keeping gouraud. Now that I’ve removed it, the project has less code to maintain and a faster default shading mode with more features.
Split the tests into sub-directories The test suite is now very long (20k LOC across 47 files), so i decided to split it into sub-directories instead of just having 47 files in one flat dir. It’s cleaner, more maintainable and looks better.
Pararelized the wireframe shading mode I did a bunch of small things alongside it, but the main feature for this devlog is the pararelization of the wireframe shading mode. It was previously fully single threaded, but it wasn’t that hard to pararelize, i just had to make the function it used to write into the framebuffer (draw_line) CAS atomic, to avoid race conditions. Now wireframe is the fastest shading mode in basically all scenarios. Below, you can see a performance benchmark (built into rasterminal using a flag) with wireframe mode on a super dense mesh and how the wireframe mode looks like (you can also cycle the colors).
Added a release workflow, manpage and changelog I added a github release workflow that works alongside the changelog and released the first pre-release version: v0.1.0-alpha.1 Also added a manpage and an install target to make and cmake that installs the binary, docs and manpage into the path.
Wasted 7 hours of my life Did a bunch of smaller cleanups and fixes, and then I tried to template the unlit and lit paths in the rasterize_flat function, which turned out to be a performance regression. Awesome.
Completely removed the shadow map Before, rasterminal built a shadow map on model load and displayed it during runtime. I now completely removed it, because it was slower during load, slower during runtime, sometimes looked broken on curved surfaces and added essentially no value. Here, the first picture is with the shadow map and the second is without.
Working on portability Did a bunch of small fixes and improvements in the last ~week. Right now I’m on vacation for the next couple of days, so I won’t be active. I am currently working on broader terminal and platform support, so older systems and terminals will be able to run cleanly with some fallbacks or will fail loud with a clear message about what isn’t supported.
Working on adding 256 color support Some older terminals can’t display full 24bit RGB colors and use a 256 color palette instead. I’m adding a fallback so the older terminals can still use rasterminal. It still calculates the full old RGB colors, but then just maps them to the nearest 256 color with LUTs. On a side note, I switched my terminal emulator from Kitty to Ghostty.
Working on terminal color capability detection I am adding automatic terminal capability detection, meaning that rasterminal will get the terminal type and either refuse to render on super old or “dumb” terminals, degrade on some terminals and render normally on modern ones.
Working on a –color compatibility flag The color terminal compatibility thing I was working on has landed in the branch, now I’m adding a –color flag to override the automatic capability detection for situations like ssh, where we almost always degrade to the 256 color pallete for maximum compatibility. So now you’re gonna be able to use the right color mode even if the automatic detection is wrong for your situation.
Changed the 24bit to 256 color palette conversion logic Until now, the conversion picked the closest color possible mathematically. But from testing on a bunch of different models, I’ve realized that it doesn’t actually look very close to the human eye. So I swapped it out for a different method, called CIELAB distance. Now it still doesn’t look perfect, but as a fallback for older terminals it’s close enough.
Finally merged color-fallback, I can move onto other things The branch is finally merged. I’ve accumulated a bunch of usability and code quirks and issues that i can finally get to now that the branch is merged. So now I’ll be reworking all the CLI flags, camera and other components. And we also passed the 700 commit mark with this merge!
Did a bunch of small code quality and usability improvements Fixed a Windows bug that crashed the program on model sizes bigger than 2GB, improved the orbit usability (fixed mouse drag behavior when models are turned upside down), and did a few cleanups and fixes in the CLI parsing. I’m planning on adding a few CLI flags that I think can be very useful for some people, specifically better spin settings, starting camera angle/zoom control and a few more.
Added –spin-speed and –spin-direction flags Added CLI flags for the spin speed and direction. The speed is in deg/s and the directions is simply left or right. Here’s what 1000 deg/s looks like spinning to the right:
Added more CLI flags for startup customizability Added flags to set the camera pitch, yaw and zoom on startup. Now every runtime-settable variable can be set during startup through the CLI. The R button now resets the state to the CLI set state, not to factory defaults.
So, i found two memory bugs in a widely used terminal input library I was researching terminal input libraries to use for this project because my current approach was so buggy that it wasn’t worth fixing. Both of them are memory bugs in the libtermkey library. There are forks of the lib with this fixed, but since many projects still rely on this lib, i submitted them anyways. I’ve also confirmed that the bug is present on my machine on Ubuntu 24.04 LTS on Neovim, because it links the vulnerable shared library. I didn’t mark them as CVEs (hopefully that isn’t a problem). If anyone want’s to look at the bug reports, they are at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142891 and https://bugs.launchpad.net/ubuntu/+source/libtermkey/+bug/2161916
Working on completely rewriting the current input parsing handling The current input handling is subpar at best; it interprets a lot of random keys as escape, which currently quits the program (This will also be changed to Q and Ctrl+C only. Kind of a no-brainer since this is the more standard choice for TUIs - for example btop - and it also means I don’t have to deal with the headache of distinguishing function keys and others from escape) and has a lot of other quirky behavior that needs fixing. I’ll also try to improve robustness against malformed input like a leaky SSH session. There are a lot of various edge cases and situations where you have no way to distinguish real input from malformed input. This is all a very major pain in the ass. And I thought figuring out the raw mode output would be the hard part. And after all this, I’ll end up with way less attention than strictly slower, less robust competitors, just because they already have an audience from other projects. I bet nobody will even read this. I’m basically talking to myself right now. Or maybe, just to spite me, the algorithm will push this more than my other devlogs.
Still working on the input parsing system It is very hard and I keep finding bugs and reasons to redesign it. I’m in pain. I do think I’m getting closer to the final robust design.
Finally committed and pushed the input rework Tested it on both linux and windows and everything seems to work. No inputs interpreted as other inputs, all edge cases handled, just works. Finally can move onto other things.
Did a smaller fix and added a pretty big feature First, let’s talk about the small fix: I Fixed a super long model name showing up in the HUD in it’s full length, often blocking out other HUD elements. Previously, the HUD would display a model name of any length. Now there’s a hard cap of 24 chars, with any name longer than that truncated (middle style truncation) to fit into that limit. And now the big feature: Added a first person noclip-style camera mode. It’s accessed with the –first-person flag and let’s you explore the model as a floating camera (not bound like the default orbit camera). It was honestly easier to implement than I thought it would be. With it, I added two new keybinds special to the first person mode - E and V for going up and down. They don’t do nothing in orbit mode. Also added a second –first-person-speed flag for controlling the initial movement speed. It is also controllable during runtime with scrolling or +/- (I didn’t know what to bind these to in this mode since you can’t zoom like in orbit mode and this was the only place where they fit). In the photos, you can see some angles taken in the first person mode that weren’t possible in the default orbit mode.
Completely redesigned and rewrote the HUD The HUD used to be just a single line at the bottom of the screen aligned to the left. It looked pretty bad, but it did tell the user everything they needed to know. [picture 1] First, I added model name sanitization, so models with control bytes like newline ( \n ), line feed or other symbols like emojis can’t break the whole program when trying to display them in the HUD. Then, I completely redesigned the whole HUD to look better and be more robust, while still telling the user everything they need to know. I went with this design [picture 2]: On the left, you only have the model name. In the middle, first you have the current shading mode (highlighted in cyan), then the lighting mode in plain white and then the background color in gray. All three middle indicators are separated with a dot and are different colors, so nobody can confuse them. On the right, there’s 3 boolean indicators: spin (if the model spin is on), backface cull (if it’s currently culling backfaces) and texture (if it’s showing the texture, isn’t there at all on models without a texture). They are gray if inactive and cyan if active. The last thing on the right is just the fps number. There can also be optional indicators: Wireframe color (in the middle, after the shading mode) which only shows up in wireframe mode. [picture 3] First person speed multiplier (on the right, between the bools and the fps number) which shows up only in first person mode. [picture 4] I also made each “island” cleanly disappear when the terminal’s width is too low instead of just slowly getting cut off letter by letter. I think this design looks better, less cluttered and is pretty easy to understand at a glance. I would very much appreciate a star on GitHub!
Added issue templates + contributing documentation Added templates and a config for submitting GitHub issues, for both bug reports and feature requests. Also added a CONTRIBUTING.md for clear instructions on how to make, structure and audit code contributions. (tests, linters, formatting, etc.) I tried to make some optimizations to the renderer by auditing the compiler generated assembly and looking for inefficiencies, but everything i tried turned out to actually hurt performance. And GitHub actions decided to have a major outage right when i pushed the commits, so that’s awesome
Minor comment cleanup Just did some comment cleanup: Deleted redundant comments and why comments Removed separator comments Compressed or rewrote some really long comments (without removing the info they give)
Working on adding support for the Kitty protocol Some modern terminals like Kitty and Ghostty have support for the Kitty protocol. It’s a feature that allows you to display high resolution content like images and videos in the terminal without it looking super pixelated. There’s also the Sixel protocol, which is basically the same thing but a little worse and more widely supported (even Windows terminal has it). I’ll add Sixel after i merge Kitty to main. It is very clearly a worthwhile feature and I have been planning to add it from the start of the project. Today I finally decided that it’s time. Most of the work is already done on the branch and i’m just polishing out the bugs and issues before I merge. In the photos, you can see the comparison between using just the block characters and using Kitty. It is a night and day difference. Although the performance isn’t great at that high of a resolution, but I’m still working on optimizing that.
Found a bug in Ghostty’s kitty protocol handling Ghostty is a modern and fast terminal emulator that i personally use. While testing the kitty protocol feature in rasterminal, I found a Ghostty bug that lagged my whole computer after a few minutes. I tested it in Kitty (terminal emulator) and there it worked fine. I looked at Ghostty’s code vs Kitty’s, found the bug and reported it to the Ghostty maintainers. Mitchell himself (the creator) fixed it in like 2 hours. Honestly I’m kinda sad I didn’t get to become a contributor and fix the bug, but since it was a small fix and I already described it in the issue, I get why Mitchell just fixed it in main. Here’s the full issue: https://github.com/ghostty-org/ghostty/discussions/13719
Fully merged and done with Kitty Finally completed the kitty protocol implementation. It is kinda slow, since the resolution is so much bigger, so I will try to optimize the high-res performance even more. So now the next two big milestones are: Add Sixel on top of kitty, that’ll be a lot of work Optimize the rasterizer even more I was thinking of maybe adding gpu rendering as an option for super large meshes or high-res scenarios, but idk. I’ll definetly keep the pure cpu renderer for computers without gpus, but I’m not sure about a gpu implementation. It would be hard to do, less portable and it might not even work that well.
Working on adding full Sixel support Working on adding support for the other mainstream terminal pixel protocol of the main two - Sixel. Already did fully implemented the kitty protocol last time, so once I’m done with this one, I’ll be done with terminal protocols (at least for the near future, hopefully). There are some other ones like the iterm2 protocol, but that one’s pretty rare and I won’t add it unless I really don’t have anything better to do. It’s basically done, just need to polish it and test it on a bunch of terminals and operating systems to make sure everything works before merging.
Fully merged sixel Fully merged the sixel protocol implementation. Works on all platforms everywhere that supports it. So now both high-res terminal protocols done. Moving onto other minor things and especially performance.
Working on improving performance With the addition of the high-res protocols, the target resolutions quickly went from hundreds or thousands of pixels to millions. So I now desperately need to improve performance. So far it’s looking promising: A whole model covering the camera 6 moving at 4k went from about 8 fps to 20-30 fps. Not ideal yet, but I think we’re on the right track. Super dense meshes (more than 2 million polygons) improved 2-3x Meshes with transparent parts improved about 2x While these wins may seem really big (they kinda are), the jump in resolutions still means they are barely usable interactively. I do want to add gpu acceleration later (with the cpu path as a fallback), but until then I want to make it as fast as I possibly can.
My reported bug in libtermkey has been fixed in the newest version Just got an email from one of the maintainers that the crash bug i reported a month ago was fixed in the new release. libtermkey is a terminal input parsing library that I considered using and found a crash bug in. The bug was already fixed in neovim’s fork of the library, so i just pointed the maintainers at that fix. For anybody interested, here’s the issue link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142891
Still optimizing… Spent the first ~7 hours trying to find microoptimizations and each one was either a wash or worse somehow. The compiler works in mysterious ways. At some point, I just gave up and let Claude have a go at the optimizing. Surprisingly it actually came up with a lot of interesting optimization techniques and solutions that I definitely couldn’t have come up with on my own. But it found so much, that the whole diff adds 5k lines of code. So now I’ll be cleaning up, testing, and maybe further optimizing that diff…
Finally merging the performance branch It’s finally time to merge the performance branch. I basically redesigned the whole renderer and rasterizer around high resolution workloads, where it would still choose the old high-poly paths where they were faster. Even snuck in some SSE2 SIMD code (picture), although I will probably be switching to a dispatch SIMD library like Google’s Highway. Not entirely sure it will be Highway or even if I will do that yet, that depends on the code complexity and before/after benchmarks.
Cleanup and restructuring changes After I just merged three big feature branches (kitty and sixel graphics protocols and the high-res performance branch), I needed to do some overdue cleanup and refactoring. And so I did: Collapsed the super long changelog entries into way more readable and legible points Restructured the src directory into multiple subdirectories because it had like 50 files already Sadly completely removed the Make build system, so now you can only build with CMake (CMake is very much evil and even more evil but it’s the only one of the two that supports windows and I was tired of managing two build systems) Removed the –graphics-scale flag, so now everything renders at native resolution And some small docs and comment cleanup
Working on assimp integration Yop, I’m adding the Open Asset Import Library as a fallback for any model formats that aren’t natively supported with their own dedicated loader (only ones with dedicated loaders are glTF2, PLY, STL and OBJ). I’m still keeping the dedicated loaders, because they are more feature-complete, to-spec and wayyy faster (especially the glTF one). I added it because I feel like for a 3D model viewer, support for many formats, even niche and obscure ones, is pretty important, even though nobody might use them. This roughly doubled compile time and almost quadrupled binary size, which also made CI take way longer (of course). It somehow made the MacOS runners take 50 minutes to compile (from the previous 3 minutes), but I fixed that by bounding the number of processes CMake can spawn to the number of threads on the runner (previously was using -j which spawns as many as it wants and it was spawning about 230 of them). I’m still testing how it handles various model formats and trying to find any reachable segfaults.
Still working on the assimp intgration Currently trying various models from all the different model formats that assimp loads. So far found a segfault, some weird behavior and integration mistakes that I made. Also found a small bug in assimp itself, for which I’ve submitted the PR with the fix to their GitHub repo. For anyone interested, here’s the PR: https://github.com/assimp/assimp/pull/6799
Fuzzing my assimp wrapper I’m trying a bunch of hand-crafted models from all the formats that I can load and trying to find things that dont load or render properly. Also had AI write me a simple fuzzer in python and I’m just letting it run for a few hours. Also auditing the assimp loader paths against my wrapper to find any format specific behaviour that should be handled. I’ve already found a bunch of things and I’m still finding more. Assimp has a lot of weird quirks and issues that I keep running into. Honestly kinda regretting the decision to integrate it, but since I’m already so deep in, I’ll just keep going.
Merged the full assimp integration into main I really don’t have much to say here, I’ve already put all the info about the branch into the past devlogs. All the formats work and the wrapper is very sturdy. I’ve found more bugs in assimp itself than my code (devlog on that soon). So, rasterminal can now load basically any 3D model you throw at it. Some of the formats assimp supports are so niche, I’ve never even heard of them.
Cutting a release The repo is in a pretty complete and polished state, so I’ll cut a release here. This will also probably be the last release before I ship, so I’m making sure that nothing is broken and everything works on every platform. I’ve still got a lot of work to do though, even after the end of stardance, like animations, glTF PBR, format completeness for every format, GPU acceleration, etc.
Found a bunch of terminal cleanup gaps Most of them are Windows or cmd.exe specific (nothing ever works on Windows), but some are present on POSIX too. The Windows specific ones are: cmd.exe for some unknown reason doesn’t turn off the raw input sequences, so arrow keys don’t work like they should, even though I explicitly turn it off (????????) (I hate Windows, they always have to do something unexplainable for no reason just so your code doesn’t work as it should) when you terminate the program with ctrl+c or ctrl+break while actively dragging the model around, it sometimes leaks mouse escape sequences into the next prompt bunch of other weird small stuff that nobody cares about And the few on POSIX are mostly ctrl+z suspend/resume behaviour not recovering the terminal and the same thing with ctrl+\ (SIGQUIT). I’m still working on fixing these. Most of the windows ones are already fixed, but I haven’t even started with the linux/POSIX ones. I have postponed the planned release to when I fix these + any other issues I find.
I HATE WINDOWS Windows just doesn’t work. It doesn’t work. Nothing works on Windows. Everything breaks. I don’t get it. THE UNIT TESTS PASS ON WINDOWS CI BUT WHEN I ACTUALLY RUN THE TESTS ON WINDOWS IT FAILS????? HOW IS THAT EVEN POSSIBLE. The release is now definitely getting delayed by at least a week because I keep running into more and more and more and more and more and more and more and more and more issues. I hate Windows. Microslop is the only company that could mess up a basic terminal emulator. And I also have to reboot my PC every time I fix something and push it and then reboot to get back to linux. this is torture. At one point I tried to do it on a Windows VM on linux but that was too slow so I just gave up.
Merged the full Windows console restoration branch My nightmare is over. I hopefully won’t have to deal with Windows for a while now. Summary of what is now fixed/handled on Windows: Ctrl+C, Ctrl+Break and Q exits fully recover the terminal’s state Ctrl+C and Ctrl+Break don’t leak mouse escape sequences into the next prompt if you terminate while actively dragging a model A bunch of other minor Windows or cmd.exe specific quirks Only thing that isn’t handled (didn’t find a good way to handle it) is task manager “end process”. It kills the program without cleaning up and sometimes freezes the shell.
Fully fixed and merged the first POSIX cleanup item Well, would you look at that! That took significantly less time than the Windows fix. It is partly because it was a smaller fix and only part whole POSIX fix, while the Windows one was the whole thing and also the foundation had already been laid out from the Windows work and I just integrated the POSIX path into that, but it is also very much because Microsoft is a horrible, terrible company that can’t make good software. I mean, look at GitHub, they have been going downhill ever since they got acquired by Microsoft. Now that I got that out of my system, here’s what was fixed: If the program cannot enable raw mode at startup, it safely fails instead of continuing and corrupting the terminal state If the cleanup gets interrupted, it retries cleanup so it doesn’t leave the terminal state corrupted after one failed attempt Onto the next POSIX fix: handling SIGQUIT and SIGHUP.
Added handling for SIGINT, SIGTERM, SIGQUIT and SIGHUP I don’t really have much to say here, I just added the full per-spec handling for all these. Only remaining POSIX-only gap is now SIGSTOP/SIGCONT (stop/resume process). I’m also starting school now, so I’ll be working on this less.
Working on SIGSTOP and SIGCONT handling SIGSTOP and SIGCONT are POSIX signals for stopping and resuming a running process. I’m working on adding handling for these, so you can safely pause and unpause rasterminal at any time. This is a lot of work, since until now, we just set up the terminal on program start and cleaned up when the program exited. There’s a lot of quirks and weird scenarios that I have to handle, for example if another signal gets sent while cleaning up the terminal for SIGSTOP. I’m trying to catch as many edge cases by just doing random things while using the program and also with the help of AI to come up with potentially uncaught scenarios.
Did some polish and cleanup of the platform layer Did final polish and cleanup of the platform layer since I want to actually finally cut a release relatively soon and I just did a lot of work there. Fixed things like useless tests, outdated or wrong comments and some platform specific quirks. Probably actually gonna cut a release soon (this time for real). Also added early rejections for BVH and CSM files, since they contain no model geometry (they can’t currently be displayed at all) and documented the change. The code is basically done (hopefully, I really don’t want to find another big gap that’s gonna take a week to close), I just want to correct anything wrong in the README, changelog, manpage or help menu and maybe make them look a little better before cutting a release and shipping.
Last pre-release checks and cleanup I’m finally ready to release v0.1.0-alpha.2. Only notable thing I changed here is that I changed the default thread count: It now defaults to hardware concurrency everywhere. Other than that, I of course did final documentation checks and fixes and now I’m just waiting for CI to pass so I can tag it and let the release workflow do the last step. So this is hopefully the last devlog before my ship!
Refactored the platform layer The whole platform layer was just one file until now. Since I did a lot of work on it recently, it grew to over 2400 lines of code. It was super confusing and disorienting. So I decided to refactor it (split it) into 8 files, based on what they handle: console.h - saving/restoring terminal state control.h - termination signal handling file.h - file operations (64bit) input_reader.h - handling input (not parsing, that is it’s own file) shared_memory.h - shared memory handling for the kitty protocol terminal_io.h - writes output to the terminal terminal_query.h - querying the terminal for things like graphics capability, etc. timing.h - frame timing and sleeps
Miscellaneous fixes and improvements Fixed two races in platform code (one MacOS, one Windows) Removed build flags that disabled some compiler security hardening at the cost of a little performance Fixed the test framework to not freak out on NaN in near assertions Improved thread launching and handling in loaders and renderer So overall just boring fixes and improvements, nothing special.
Code quality and CI improvements Finally did the long overdue main loop refactor. The main loop is now way shorter, more readable and more testable. I just split off some of the main loop’s work into it’s own modules, which made them way better looking and also, since they are now standalone modules, actually testable. A big win for repo structure. In the process, I also replaced the input handling’s long if chain that made each character do it’s job with a switch statement. It’s more readable and theoretically faster, although since I compile it with -O3, it probably made no difference or an unnoticeable one at best. I also finally fixed the super long CI times. Until now, CI used to take ~50 minutes (depending on how fast the GitHub runner was) because of cppcheck. Everything else finished in under 10 minutes, but cppcheck stalled it for an hour. It was stalling in mesh_assimp.cpp (the assimp wrapper) for most of it’s runtime. I always thought it was because assimp is a very large library. So I experimented with it a little. I included everything I include in the wrapper into a test file with a little code and ran cppcheck on that. It finished in less than 10 seconds. Eventually, I found out it was somehow taking that long because the main loader function was too long and handled too much by itself. So i just refactored it into 3 separate functions, without changing the behavior at all. Somehow, I still don’t get why, it reduced the whole cppcheck run to 9 minutes. a more than 5x improvement, just because I split a function into more functions. I’m not complaining, but it’s definitely weird. CI is now way faster and adding new things is gonna be way smoother now.
Ships:
rasterminal rasterminal is a 3D model viewer in the terminal Why i decided to build it The original idea didn’t really have any big inspiration, I’ve just always been fascinated by the inner workings of 3D and how that all works. I’ve been wanting to build a project involving 3D for a while and I didn’t want to make just another program that uses libraries and GPU drivers to do all the work. So I came up with the idea: a software rasterizer that renders in the terminal! There are lots of TUIs and lots of boring old software rasterizer projects, so I just combined the two into something unique. And over time, I realized I could make it an actually useful tool, with no real competition: a 3D model viewer in the terminal. Sure, there are some similar projects on GitHub (like taigrr’s trophy), but none are actually usable with heavier models or support pixel graphics. What I learned I learned a lot. I really mean a lot. Anything from math and rendering to how terminals work and how to control them using escape sequences. I don’t want to sit here and name everything I learned over the period of the last 5 months, but I can confidently say that this project really taught me how much work goes into everyday software and how to actually develop and maintain a project professionally. The future of rasterminal The whole project is very far from done. You can see that from the latest release version: v0.1.0-alpha.2. I’ve got a lot of work to do and I’ve roughly got the major landmarks mapped out. Main things I definitely want to change/add at some point before v1 are: Add animation support (currently can only render still meshes) Complete the renderer (complete support for basically every feature of every format that makes sense to support) Add optional GPU acceleration (after I’m satisfied with everything else) Hardware / OS support Supports every major OS (Windows, Linux, MacOS, and any other POSIX-based OS, so practically everything), and every CPU that I could think of (any architecture, 32 or 64bit). You would have to actually try a to find a platform that it doesn’t support (most of the unsupported hardware are big-endian systems, which are basically phased out completely). This is one of the main goals of the project, so (almost) any modern machine with a terminal can run it. Special thanks Special thanks to anyone who followed, liked, helped, or otherwise supported the project in any way. I wouldn’t have had the motivation to push it this far if it wasn’t for you guys....
|
1793105289.4980307
|
1793191689.4980307
|