Discordant Harmony

Author: crowan26

  • Mid-October Update: Blender 3D “Badge Engineering” Project Underway

    Mid-October Update: Blender 3D “Badge Engineering” Project Underway

    This month’s update is vastly more successful and Blender-oriented than the previous few; instead of just engaging in long back-and-forth chat conversations and never really getting anywhere with a model, I’ve finally completed my first small Blender/BeamNG project: adding a missing badge to a vehicle mod.

    A couple weeks ago, while looking for new and interesting real-vehicle mods to try out in BeamNG, I downloaded the 2011-2014 Dodge Charger mod by the popular creators Flanje and NMG. Being a mod from ModLand, I didn’t have high expectations for the quality or accuracy; however, I was somewhat surprised when the vehicle loaded in-game looking pretty close to the actual vehicle. The interior was mostly well-modeled, the exterior was accurate, and there were no glitching parts.

    However, there were a few big problems. First, the sound was completely wrong (which is a totally separate small BeamNG engineering project I completed last week), and second, there were no badges beyond the standard “Charger” and “Dodge” lettering on the trunk. While this wasn’t a huge gameplay issue, it seriously broke the immersion when you loaded in a stock R/T configuration and there wasn’t any R/T badge on the trunk. Why would a modder go to the trouble of modeling most of the other standard badges on the vehicle, but leave out a few random important ones?

    Modeling the R/T badge

    This became the premise for my next big Blender project: “finish the modder’s work” by modeling the other badges, including the R/T badge, the HEMI side badge, and potentially the SXT/SRT8 trunk emblems as well if I had time. I started last Monday (October 5) by pulling down some reference images off of sellers on Ebay, finding straight-on shots of the R/T badge first, since that was my top priority. I actually found a pretty good image without too much digging, which (unfortunately) I’m not sure I can say confidently about the other badges. To ensure that I was going to create a badge sized correctly, I got the actual dimensions of the R/T badge and scaled the image such that the badge in the photo matched those dimensions.

    So I was able to get started pretty quickly in Blender; to begin tracing the badge in the software, I didn’t hunt for custom fonts or try to type out the letters and the slash, because that would be way too imprecise. I found out that the better solution for modeling a badge is to start with a Bezier curve, which allows you to place vertices at key points on the badge and connect them via a curved line. This sounded like a great setup for the R/T badge, so I Ctrl+right-clicked on the corners of the R, slash, and T to get a total of about 27 vertices (81 with the triple baking).

    The early stage of the project, with eight true vertices created around the edges of the “T”. Currently, the badge displayed is the reference image only.

    Once I had vertices in for all of the important corners of the badge, it was time to smooth the points around the bowl of the R, as they were quite jagged to start due to not enough resolution. To do this, I added additional points to the arc around the bowl via a Subdivide operation, moved them onto the lip, and spaced them out equally to ensure that the curve traced the bowl properly. This was the most tedious step of the process, as it required ultra-precise mouse movements and constant tweaking as points gradually got out of line. I spent about a day on this step (likely Tuesday by now) before I got to the smoothed-over version of the R, shown below with the curve in solid form:

    The completed curve on both the outer and inner portions of the “R”, with the Bezier curve now shown as solid.

    Now that the curve was relatively smoothed-over (with a couple more areas to correct before the next step, which I’m sure you can identify from the above photo), it was time to ditch the reference image and convert the curve to a mesh. I honestly wasn’t expecting much at this point, since I had been working solely with that image and had no real experience seeing what this transformation would look like. However, I was quite surprised when I changed it to a mesh and discovered that the badge actually looked pretty convincing. To ensure that the depth (or thickness) of the badge was correct, I extruded it by 1.5mm, and confirmed that it looked accurate afterwards. The result of this is shown below.

    The meshified and extruded badge, with some minor corrections made around the slash area. Looking pretty accurate; for comparison, see that green reference image at the top.

    After this step, I performed some quick checks on the mesh (Non-Manifold, origin and position verifications), and moved into the UV-mapping/shading phase. The badge should obviously be chrome, but to get to that part, I first had to apply a Shade Smooth by Angle modifier to ensure that the chrome wouldn’t be bent or reflected in odd ways to the jagged edges on the tip of the T, for example. I applied the modifier to 30 degrees to ensure that nothing seemed too subdivided still. I also generated a simple UV map of the badge in Blender, resulting in an interesting-looking diagram of the islands and squares representing the different caps of the badge.

    To actually apply the material, I used the already-existing chrome material provided by the mod, which had been used for the “Charger” left-side badge and the “Dodge” lettering. I simply went to the Materials tab in Blender, added this new material (ensuring that the name matched exactly with what was in the mod’s materials.json file), and turned up the Chrominess setting. Nothing changed in the viewport, of course, since the chrome material would only be rendered in-game, after export. At this point (this was around Thursday/Friday), I was pretty much ready to export the badge. However, I observed an issue with the bowl of the “R” just before doing so: there was still a slight facet on the bowl, making it appear as if it had been creased (shown below).

    The slight facet on the bowl of the R–this is what “cause for concern” looks like in case you’re doing something similar. On the right-hand pane, you can see the chrome material has been added.

    While it might not be so noticeable in-game, there was a possibility it could mess up the chrome reflections, as with previous issues. To fix it, I raised the angle on the “Smooth by Angle” modifier to 45 degrees, and the facet disappeared. I also turned on the “Ignore Sharpness” setting, which improved the result even further. With this change completed, I baked (applied) the modifier, hid the reference objects (they’ll have their time later!) and exported as a .dae file for BeamNG.

    Sidenote: If you’re wondering how in hell I got Blender 5.0.1 to export a .dae file, which was supposedly discontinued many major versions ago, here’s the answer. I’m using a custom Blender add-in from the BeamNG modder Grille, which adds the ability to both import and export .cdae/.dae files. This is a vital tool for modern BeamNG modders looking to use the latest Blender versions, since the Blender developers have thrown native .dae support in the trash can and never looked back.

    With the badge exported, there was only one phase left before it could have a chance of appearing on the vehicle in-game: the coding phase.

    Setting up the JBeam files

    To ensure that BeamNG recognized the badge’s existence and put it in the right location, I added a simple line to the mod’s Trunk jbeam file, since that’s where the badge ends up going. (See below for a real-world image of the 2011-2014 Charger R/T’s trunk lid).

    This line would add an additional component to the trunk, called “charger_badge_rt_trunk”, map it to the trunk part, and set the pos and rot values for the badge (position and rotation). The line was hardcoded in the flexbodies section of the JBeam file; my future goal is to have the badge set up as a slot in the vehicle configuration menu so you can choose to apply the badge or not. I used some dummy pos numbers at first before loading in the game, just to see how it would load in. Surprisingly, those guesses weren’t far off, but there were a couple of problems.

    The R/T badge having been loaded into the vehicle “successfully”. Can you spot the issues? (They’re quite obvious).

    Well, first of all, the left edge of the R was clipping through the trunk material. Second, the badge was positioned a little bit too low; in the real-world image above, you can see it’s a little bit closer to the bottom edge of the taillight. I thought these were going to be simple position issues–and they technically were–but it took over an hour of constant tweaking and screaming back and forth between Blender and BeamNG to get it to look correctly-positioned. The result of this intermediary screeching is shown below:

    Now, you might be noticing something about this current badge. While it looks pretty convincing (and probably wouldn’t raise any suspicion when viewed from a greater distance), it also looks a little flat and dull from certain angles. Of course, this is a game, and the reflections can only go so far, but when comparing the appearance of the R/T badge to the Charger badge on the left, there’s a slight difference in the roudedness, or chrominess, of the badge. I noticed this as well after the preliminary tests; to fix this, I ended up applying a 0.5mm bevel/chamfer on the badge via Blender.

    However, I worried this wouldn’t be enough. Even previewing the badge again in Blender, it seemed that it didn’t really change all that much (although the numbers and statistics in the upper-left corner directly confirmed that something had happened). So I went with a different strategy: apply a bend to the badge so that it sticks out in the middle region vertically, and curves outward to match the flow of the trunk lid. I hoped that this would help it capture a bit more of the gloss, as I noticed a similar kind of bending on the Charger badge upon close inspection. I used Blender’s Simple Deform modifier to make this change, doing one on the X-axis and one on the Z-axis. The X-axis curve went to an angle of about 15 degrees, and the Z-axis I kept at 8 degrees, since I noticed some strange streaking/chrome aberrations on the surface due to the competing bends if I went too far above that.

    After re-exporting the badge and loading it into the game, I realized that the change had made a significnat improvement. These photos can’t really do justice here due to their smaller size and WordPress compression, but in-game, they looked quite a bit better than the initial pass.

    And with that, I approved the final version of the R/T badge, saved all the changes, and closed out of the first badge-modeling phase. From a distance and close-up, the badge looked more than convincing: the reflection and bevel on the model worked wonders for the chrome appearance. I’ll now be taking some more natural photos in an actual map (not the Gridmap testing area), such as the parking garage in West Coast, USA.

    Next steps

    While the logical next step is to start working on the HEMI side badge, there is an additional thing that I’d like to ideally take care of before I get the HEMI badge into the game. Right now, the R/T badge loads onto the vehicle no matter what configuration you choose; there’s no taking it off since it’s hard-coded into the flexbodies section of the trunk JBeam file. I’d like to find a way to create an additional slot in the Vehicle Configurator, something like “Trunk Trim Lettering”, that allows you to choose between Empty, R/T, SXT (potentially), and SRT8 (potentially). This would be a more coding-heavy undertaking, which can become quite problematic in BeamNG due to the strict syntax requirements, so we’ll see how that goes.

    The reason why I’d like to have that done before the HEMI badge goes on is I don’t want the two badges to start competing and causing conflicts if I have to hardcode both of them onto the vehicle. It would be better to have a slot for the side badge and a slot for the trunk badge, which is the accepted convention for BeamNG mods.

    Well, as this “badge-engineering” project gets further underway, and I start working into the side badge as well, I’ll post more updates and photos on here throughout the process. Hopefully things won’t fall apart once things start getting vastly more complicated–the black edges on that HEMI badge look quite difficult. Stay tuned for more info!

  • September Update: Portfolio Sites, AI Reboot & Alternate Reality

    September Update: Portfolio Sites, AI Reboot & Alternate Reality

    Welcome back to Discordant Harmony! It’s been a few weeks since the last update, but I’m now back with the September update on how various projects have been going. In this blog, I’ll discuss a new alternate reality game/narrative I’m working on, some new video editing projects, and new AI/machine learning endeavors including the Painting Classifier AI Project and Quarto sites.

    AI, Machine Learning, and Portfolio Sites

    The homepage of my new Quarto portfolio site for active model experimentation

    First up, I suppose, will be my various attempts at restarting the machine learning projects I’ve been working on. They have been sitting around for a couple of months now, ever since fast.ai broke something in their code and prevented users from building anything back at the end of June. Those issues have now been fixed, and I’ve moved away from trying to use the deprecated fastpages anyway to host live versions of my models. Instead, I discovered the much better successor to fast.ai called Quarto, which allows you to host Jupyter Notebooks, blogs, and model embeds through GitHub Pages.

    This is what I’ve been working on over the past week. I now have a live, working Quarto portfolio with the latest Ashryver Painting Classifier (via a HuggingFace embed) and, finally, the CIFAR-10 Image Classification Model I trained last year, during the inset event. Additionally, I’ve put up the QuickDraw Shape Recognition Model that I recently refurbished from August 2025, and it worked surprisingly well with the Gradio Sketchpad integration on HuggingFace. This is something that I’ve been working towards for quite a while–back in June, I stated that I was “really trying to move away from models that exist only within a Visual Studio Code window and require extensive amounts of effort on the part of the user to get it working on their own machine.” Well, that move has finally been made.

    As of Thursday, I now have a working blog set up on the Quarto site, where I can add posts containing notebooks, code snippets, and anything else that allows me to do detailed data storytelling and visual analysis. The Quarto interface is a little bit clunky behind the scenes–you have to deal with both a .qmd page and an .html page and update both whenever you want to insert a blog. However, it’s much better than alternatives like Netlify or the deprecated fastpages if you want to showcase personal models (not production-ready content) and post blogs containing Jupyter Notebooks.

    At the moment, I have no plans to host any of these models on large, production-ready sites like Vercel or ChatCode. This may come later if I find that I need more hosting space or interaction with users, but for now Quarto works perfectly fine for displaying these projects so people can actually use them. I’ve heard that Quarto is highly flexible when it comes to inserting runnable notebooks, which is something that’s pretty important for the kind of work I’m doing right now. And the process for uploading the models to Quarto really wasn’t so bad: all I had to do was get the .h5 or .keras model files, upload them first to a HuggingFace/Gradio space, and then link that space as an embed to the Quarto site.

    Now that the Quarto site is pretty much done for now, I’ll be looking at (perhaps) designing a custom interface for the HuggingFace embeds, using HTML and JavaScript, so that they can look a little bit better. There’s nothing wrong with them now; however, for the future, it may help if I have even more of a flexible interface. Then, it’ll be straight into Unit 3 of the Practical Deep Learning course. There isn’t any need to continue interating on the painting classifier right now; it works perfectly fine and it’s already been three months since I started the second unit.

    I noticed that fast.ai’s Practical Deep Learning for Coders course is woefully outdated in several key areas; notebooks do not work, workspaces are deprecated, and packages are broken entirely. If this becomes prohibitive as I continue to work through the course, I may switch away from this and personally explore some other ML topics. At the same time, I might start a new Intro to Machine Learning course on MIT’s Open Learning Library; most of the content will be a review but it’s good to make sure I’m not forgetting the fundamentals, anyway.

    The Alternate Reality Project

    “Olivia’s relationship with her brother can best be described as intimate, careful, and at times, playful…she very rarely becomes outwardly upset with other people, [but] will sometimes rant about frustrations to her brother behind closed doors.”

    — the Episodic Alternate Reality Narrative, volume 01

    I’m guessing that you’re wholly gobsmacked by the above quote. After such a serious, concrete discussion about machine learning models and AI courses, we have . . . what?! A paragraph that reads like it’s from some kind of elaborate personal databse file? No, fear not. This is simply one of the opening sentences of my latest undertaking, the episodic Alternative Reality Narrative, Volume 01, or e-ARN 01.

    What is it, exactly? Consider it a space where I’m experimenting what life woud be like now (and in recent times) if things had gone very differently many years in the past. In the narrative, I’m writing prose, third-person descriptions, or brutally-honest observations on life in what I like to call the Alternate/Augmented Universe. Every section and every account in the narrative is designed to sound as real as possible, although it of course is only fiction here in the Prime Universe. Detailed narratives are engineered to read like lengthy Ready Writing prompt responses, except without a clear direction and more focused on the presence of our new alternate-reality character.

    And, because this is a bit more than just a narrative, I have created additional artifacts (such as online, for example) that complement the project. Most notable is the Fuzzy Thoughts AoPS blog, which I recently created alongside my prime-universe random ramblings blog as the official writing site of our alternate character. As our character (codenamed claudaroo in the alternate universe) is extremely busy, posts only happen once or twice a week. However, having a dedicated alternate-universe blog allows me to more precisely craft a new character, showcsae their interests, and engage in fictional back-and-forth conversations with them. (There is no other person on the other side of the computer screen, of course. I’m merely playing both sides of the field; skronkmonster is wholly responsible for the creation of the blog).

    My plan is to focus on the handwritten narrative format (yes, handwritten) and progress through several volumes of the e-ARN 01 to fully develop this character. Why handwritten, you ask? Simply because I feel that I think more creatively while in bed, poised over a notebook and determined to uncover what, exactly, life would be like in this very different Alternate Universe. It’s sort of like superimposing a brand-new individual on top of your everyday adventures, which can be both enlightening, fascinating, and frightening all at once. Shown below is the cover page of volume one, which is currently in progress and set to take up about twenty-one pages. (This all appears in the official SIA Time Capsule Notebook).

    The title says it all (no inferences required). I will, of course, be scanning all twenty-one pages into a secure location on the DiskStation and the Google Drive once volume one is complete.

    Stay tuned for further information on this up-and-coming alternate reality project. It’s one of my most unusual undertakings yet, and I’m excited to see where it goes.

    Other Projects

    I’m sure there are a whole lot of other things that I’m missing, but one thing I can think of right now is Flames of Rebellion, Book 4. This project has been sort of put on hold, as the AI stuff has taken the center stage and several new submissions and competiton applications have been taking place. That’s not to mention the Labor Day Animal Concert coming up next week, and several new jazz-related musical compositions that actually tie in closely with the alternate reality narrative (yes, everything seems to come back to that lately). So I’m letting the machine learning, the BeamNG.drive video editing, and the various short stories I’m working on take the stage, because Flames of Rebellion doesn’t really have too much of a deadline. (I’d like to try to finish the series before Int-Offshore 2027, but I think that’s pretty unlikely at this point).

    I’ve now been a member of the BeamNG Roleplay subreddit for almost four months, which is pretty hard to believe. I’ve not been as active on there lately, but after this weekend, I might have some new posts–and short videos to upload on the main BeamNG subreddit. I’ve been getting into the cutting-up side of BeamNG, and I’ve flagged a new map mod and traffic mod to download for more immersive cutting-up sessions. Bonus points if I can get the insane in-simulation motion blur to cooperate, because that really improves the realism of the whole environment.

    Well, that’ll be all for now. Don’t forget to check out the updated AI & Machine Learning Projects page, which now has new links and images. Until then, I’ll see what happens with all these endeavors!

  • Projects Update: A Mystery Image, Bumper 3D Modeling, New Minecraft Ideas

    Projects Update: A Mystery Image, Bumper 3D Modeling, New Minecraft Ideas

    Quite a bit has been accomplished since my last check-in on this site. I’ve kept going on the Blender 3D modeling project of the Toyota Soluna (see the previous blog post for more details), finished Unit 3000 in the New Andaman Beach Villa project (Minecraft), and planning a new complex of forest-located builds on a smaller scale. Among all of this, Flames of Rebellion has cracked 43,000 words, and I predict it’s about halfway to completion now. On top of this, the AoPS Academic Year classes (Algebra 2 in this case) have now started back up. So as you can imagine, things have been a little bit busier than normal!

    I’ve also begun a completely new and unrelated project, which I’ll introduce with a single photo at the end of this post.

    The 3D Modeling Project

    The front view of the current 3D modeling process, allowing you to see the progress made on the headlight cutout area.

    I’ve taken a brief one-day break from going insane in Blender, but over the course of the past week I’ve made significant progress on the front bumper cutouts for the Soluna. On Tuesday, I finished the headlight cutout (or at least the inner portion), after comparing extensively against the photo and subdividing into hundreds of vertices to get the contour right. The grille cutout is also done, although it seems a little crude and I might have to go back and refine it later. The next step will be the turn signal cutout, which extends to the side and wraps around to the other end of the vehicle in the reference photos. Assuming nothing goes catastrophically wrong (which you never know with this project), it’ll probably be another 2-3 weeks before the bumper is done.

    Given the speed of this project, I’d probably re-calculate my estimate of finishing the 3D model to next spring or next summer. That gives me plenty of time to do the rear bumper, shape the hood and windshield, model the badges, model the openable doors, and actually set a working interior color (unlike some other Mercedes-Benz C250 mods where you can’t change the interior color!). Of course, the JBEAMING, SCREAMING, and UV MAPPING will need to be done after that, so time will need to be factored in for those advanced processes.

    Below is the closer side-view look at the image shown at the beginning of this section, and you can really see all the vertices I’ve added around the headlight cutout to fully shape the area.

    Minecraft Projects and Flames of Rebellion

    Front view of the New Andaman Beach Villa #3000 at sunset

    Flames of Rebellion soared to over 43,000 words this week, with more coming every day. This places the book now at 192 pages, which is at about the halfway point considering that this will be another 380-400 page book. I just finished writing a highly intense scene involving Hikotage, who wound up stranded in World Zero after a serious Common Cause attack, and I’m now proceeding to get into some of the most tense parts of the book. I’m still on track for completing the writing portion around November-December 2026, with the publication date to be around January-February 2027 including cover design and proofreading.

    However, I can’t really get a definitive estimate on this, because the proofreading for the previous book consumed quite a bit of time (over 8 months) and caused quite the delay in getting the book out. I’m not sure what’s going to happen this time, but hopefully it won’t be a full eight months.

    On the subject of the Minecraft projects, I recently finished editing the tour video for New Andaman Beach Villa Unit 3000, and started crafting the floor plans for the next series of forest villas. The tour video is now posted on the official Minecraft Builds website, along with the complete photo gallery. I’m considering remastering the tour video for Unit 1000 as well, but this may not actually occur since I’ll be focusing on building the next few forest villas.

    That next project is set to be codenamed the New Andaman Enclave, and will feature much smaller one-story villas when compared to the lush beachfront ones. These will probably come in four to five configurations, both one-bedroom and two-bedroom, and will be nestled in a small complex with plenty of vegetation, right in the middle of the forest. My plan right now is to build four villas per configuration, making a total of around sixteen villas, but this may change depending on the H situation and how much time I have to create these villas. Along with various competing BeamNG scenario projects and calamitous C250 photo-taking sessions, these Minecraft projects may be temporarily pushed to the back burner.

    The Mystery Project

    To close off this week’s report, here’s a photo of Day One of my latest Mystery Project. I won’t say what it is yet, but the answer could be revealed in a future blog post. This is another one of my long-term endeavors that are tied to International Offshore 2027 (or so we believe, for now).

    Well, that’s going to be it for this update. Good luck figuring out what the hell is being represented by the above photo!

  • Wednesday Update: New 3D Modeling Project & Flames of Rebellion Progress

    Wednesday Update: New 3D Modeling Project & Flames of Rebellion Progress

    It’s been a little while since the last update on this site, but then again, I’ve been quite preoccupied with various projects ever since the downfall of the Ashryver Models situation. (That’s right: the Ashryver V1 painting classifier and everything related to it has now been destroyed, and no longer works. This is the result of a full-scale pivot to more reliable, worthwile, and engaging projects). I’m now mainly focusing on the final main book in the Flames of Rebellion Series, and a Blender 3D modeling project for a BeamNG.drive mod.

    In this update, it’s time to take a look at what’s been going on lately. I’ll also provide some rough estimates and plans for the Flames of Rebellion series, and when the next couple of books might be coming out.

    Blender 3D Modeling: the Soluna Project

    My current progress in Blender. I’ve increased the width of the vehicle’s body as it seemed much too narrow before, but at the same time, I may have gone too far.

    This is my latest (and primary) undertaking. I started working on this 3D modeling project about three weeks ago, and it was inspired by the lack of any AL50 Toyota Soluna (1998-2002) mods on the BeamNG.drive community. This is because it’s not a very well-known vehicle; with this project, I intend to fill that gap.

    My first step in this project will obviously be to get a basic 3D model. This is proving to be a very challenging and time-consuming process; however, I have completed the body outline, all four wheel arches, and now starting on shaping the hood after three weeks. My current estimate is that it’ll take another few months to get this model done if I continue working at this pace; December or January of next year is a good estimate.

    After that, I’ll need to move into the nodes & beams phase of the modeling process. This involves using the 3D model as a framework and adding the BeamNG core components around it, including the nodes, which are like the vertices in a complex chemical structure, and the beams, which connect the nodes together. There could easily be thousands of nodes and beams for a fully beamed (or JBEAMED) vehicle, so this might take another 4-5 months.

    The final phase will likely involve doing some UV mapping, sorting out the myriad bugs that I’m sure will emerge, and getting all the configurations set up. And this will likely just be for the basic Soluna copy with the standard interior and openable doors. This particular version of the project will be released on third-party sites like Modland only, since BeamNG prohibits the distribution of copyrighted vehicles on their own site.

    However, I have a workaround for that. Once I’m satisfied with the base Soluna mod, my intention is to go back and creatively modify the vehicle so that it fits with BeamNG’s in-game Ibishu brand. This should work well, since Ibishu is BeamNG’s equivalent of Toyota; from there, I can subtly change the taillight design and the gauge cluster, for example, so that I can market a lore-friendly Soluna version on the BeamNG repository. (This whole mod will obviously be free, of course. I don’t believe in charging money for mods of any kind, no matter how many apps are supported by the game’s ‘CarPlay’ screen, or how many ‘hours per day’ I spend on the mod).

    Right now, all of this is sounding rather daunting as I’m only on the 3D modeling stage. Honestly, though, I’ve made a whole lot more progress than I’ve expected in the psat few weeks–and certainly since the first blog post I wrote about this modeling project, when the Soluna was still a shapeless box. I’ve encountered numerous troubles along the way, most notably with the wheel arches. For some reason the geometry got destroyed as I was trying to fill in points surrounding the rear arch; the fan got all tangled up and cluttered. I had to completely reset the rear arch and start over; fortunately, that fixed the problem after a couple days’ of work. I can only hope that I’ll be able to push through similar challenges as this gets more complex, becuase I know these issues will be coming.

    Below is another view of the current state of the Soluna project; I’ve just diagnosed an issue with the main soluna_body being far too narrow. Hopefully I haven’t inadvertently broken anything else.

    Flames of Rebellion Book 4

    As you may recall, the previous book in the Flames of Rebellion series (book 3.5) was published just back in April. That was Reckoning of the Past, a medium-length in-between novel detailing a side plot in the series. Now, I’m moving hard on Book 4 in the Flames of Rebellion series, currently called The Conquest of Peace. This will likely be a longer book, in the 410-420 page range, as this is the series finale and needs to tie up all the loose plot ends. Right now, I’m sitting at about 30,000 words and 135 pages, putting me at about 35% through the book. I can’t release a target month right now, as it’s still a bit too early for that, but I’m hoping it can be published around winter 2026 (December 2026 to maybe January 2027).

    After that, only one book will be left: the prequel. This will be book 0.5, examining what came before the First World and the Thirteen Worlds and everything taking place in the main series. Book 0.5 will be set in around GY 23, which is the World Zero equivalent of about seven hundred years prior to the main novels. It will focus on the ancient Cymantian Empire, explaining the political conflicts and conquests that split apart the empire and led to the turbulent formation of the First World. While Jonathan, Lily, Phoenix, Ember, and Grace will not be a part of the prequel (at least, not right now), there will be many other new and intriguing characters, plus old villains like Aaron Fisker and the Cymantus itself. I’m still figuring out the best way to introduce this ancient world without making readers feel too confused.

    My current end-of-series target is summer 2027, or about a year from now. If possible, I’d like to get the Flames of Rebellion universe closed out before the next International-Offshore Excursion, which is still tentatively set for summer 2027 as well. This will provide clean break for the next project, which might be something completely different, and much more grounded in reality. Stay tuned for that.

    Well, with that, I think that’s everything for this site update. I’ll be updating the Flames of Rebellion page soon with some more details about Book 4, and expect more updates as the Blender 3D modeling project progresses. Hopefully I won’t destroy any more geometry!

  • New BeamNG Modding Project: Toyota Soluna AL50/Ibishu SLN-10

    New BeamNG Modding Project: Toyota Soluna AL50/Ibishu SLN-10

    Having gotten tired of broken AI models, destroyed repositories, lagging GitHub environments, and broken fast.ai courses, I pivoted to an entirely new project this week: BeamNG modding. The vehicle mod I’m intending to build is based on the 1998-2002 Toyota Soluna AL50; the first step is to create an exact replica of that mod for third-party free distribution. Then, a more refined lore-friendly Ibishu version will be released.

    For quite a long time, I’ve been intending to get into the BeamNG vehicle modding universe. However, the issue has been the 3D modeling segment of the project, which is where I’ve always gotten stuck. Up until this week, the most I’d been able to achieve was getting the reference images positioned into the environment with none of the actual vehicle whatsoever; now, though, it seems I’ve made some progress. Read on for some details on my current undertakings, some screenshots, and plans for what I’m going to do next.

    The Project

    This is the vehicle I’m trying to model right now. Read more on Wikipedia for a brief overview.

    Not wanting to spend ten months designing an elaborate electronic gauge cluster and setting up emergency braking with automatic headlights and drink dispensers, I decided to choose a relatively basic, bare-bones vehicle to model. I ended up going with the Asia-exclusive Toyota Soluna, which is only sold in a right-hand drive configuration. It’s slightly smaller than the early-2000s Toyota Corolla, and has much less in the way of features. However, it’s a functional, reliable vehicle, and seems to be pretty easy to model.

    I’ve started off by obtaining reference photos of various angles of the vehicle, including a side view, front view, and rear view. I’ve then placed these inside the Blender environment so I can better structure the blocking boxes (which will be discussed in the next section). The plan is to only offer the vehicle in an RHD configuration when distributing it through Modland; after all, this initial stage of replicating the exact vehicle is partly for my benefit and for the enjoyment of actually experiencing an in-game Toyota Soluna. (There is currently NO Soluna mod widely available for BeamNG – not even close).

    After that’s done, I intend to go back and refine the mod for distribution on the internal, strict BeamNG Repository. Here, you are prohibited from uploading mods of real life vehicles, so I’ll need to modify the vehicle so it fits in with the fictional in-game car company Ibishu. This actually works perfectly, since Ibishu has always been represented as BeamNG’s version of Toyota. The Soluna’s lines fit well with Ibishu vehicles in that era (Covet, Pessima Mk1, etc.) and should be a good lore-friendly project.

    The Process

    As of right now (Friday, July 17, 2026), I currently have a complete blockout of the Soluna, and I’ve added some loop cuts to signify some basic panel divisions. A “blockout” essentially represents the skeleton of the vehicle; you have the full envelope, the roof, all four doors, the trunk lid, and the hood. This makes for a total of ten boxes, including the front and rear bumpers as well, which you might be able to see in the above image. This blockout will provide me with a starting point for pulling vertices and shaping the curvature of the vehicle; that’s the next step I’ll be moving onto shortly.

    To start off with this mod, I’ve decided to make use of Blender Python, or .bpy scripts, to generate some of the geometry. Doing some of that stuff by hand would be very tedious, so I have used scripts to add mirror modifiers (so that changes I make on the driver’s side will be mirrored to the passenger side, for example) and find the exact specifications of the vehicle. This measurement-finding has actually been the most time-consuming part of the process so far: I’ve had to line up all the boxes exactly to the reference images, making sure the front overhang is the correct length and checking all values in the script against official measurements.

    Hopefully I haven’t made any serious mistakes in aligning the vehicle against the images, but from what I can tell, everything seems to be working out. In the image above, I’m looking at the environment in the 3D perspective; if you were to switch to right orthographic or front orthographic view, you’d see the vehicle lined up closely to the reference image. An example of the side perspective is shown below:

    The right orthographic view of the blocking boxes. You can see the three loop cuts I’ve added on the soluna_body box, which represent the front fender arch, the B-pillar (midpoint of the two doors), and the rear-fender arch. There’s also a loop cut on the hood box representing the windshield-to-hood divider, but that’s not visible as the hood box is not currently selected.

    I spent the most time yesterday on getting those insane loop cuts to actually go in. At first, I was just spamming Ctrl+R, clicking helplessly, and nothing was happening. Then, after some searching and usage of AI agents, I discovered the proper sequence of clicks and presses to make those loop cuts appear. I had to re-generate the entire blockout in the process, though, because somewhere along the way the environment had gotten muddled and unable to process any new loop cuts. Now that I have four cuts, though, I’m going to start extruding and pulling vertices to shape the vehicle, which might involve some more frustration and Blender Python scripts.

    Next Steps

    Here it is: the trademark “Next Steps” section that I always manage to include in these project update posts. Well, when it comes to this Toyota Soluna mod, the primary next step is going to be to continue working on shaping out the vehicle and creating a real structure. Right now, I just have some vague boxes for where the various panels and portions are; over the next few weeks I’d like to refine the shape of the vehicle and maybe have a hood/trunk curvature laid out. This is probably the most time-consuming portion of the modding process, although the whole JBEAMING situation might be difficult as well.

    With the fabled BeamNG v0.39 update in a confused state, I’m not sure how it’s going to affect this process. It could be released this Sunday, or this September–or even next year. When it does come out, though, I really hope the devs won’t break the jbeaming interface or drastically change anything related to the modding process, because it means I’ll have to relearn everything to do with Lua and possibly contend with out-of-date and broken models. If that happens, it’s time to return to the Ashryver models!

    Stay tuned for further updates. Time to continue working on the modeling.

  • Ashryver V1 Painting Classifier: Release Summary

    Ashryver V1 Painting Classifier: Release Summary

    Today, I finally finished setting up the Ashryver V1 Painting Classifier, my latest interactive web-based model, and placed a live embed on the AI, ML, and Web Projects page. You can now interact with the model right from your browser, and upload any painting you choose for the model to make predictions. Although the embed is a little small, and the formatting is still on the uneven side due to WordPress’s lack of flexibility, I hope to have these issues sorted out soon. Besides, my ultimate plan (perhaps once the final, non-prototype Ashryver V2 model comes out) is to place an active HuggingFace API instance of the model on one of my websites. I’ll have to wait until HuggingFace and Gradio sort out a CORS issue first, though, as there have been known issues across all platforms for the past few weeks.

    In this post, I’ll provide a brief summary of the training process, the overall model performance, and my future goals now that this project is “finished”.

    The Training Process

    I started working on the Ashryver V1 model about a week ago. I used the fast.ai foundational framework for this project, moving away from the clunky and cumbersome Tensorflow libraries I had been familiar with before. fast.ai is just an upper layer of Pytorch, which is the latest and most efficient machine learning library. I was blown away by how easy it is to instantly create and train a deep learning model; all it takes is just a few different code cells and some DataBlocks.

    As a brief reminder, this Ashryver V1 model is a painting classifier trained on images of 20 different Impressionistic and modern artists; I aimed for about 300-400 images per artist, yielding a total dataset of about 2,700 images (about 500 of which were split off for validation). Although this is a relatively modest dataset size, it ended up doing the job very well. I did have to go through several training runs to get the accuracy above its initial poor score of 0.60, but things turned out well in the end.

    At first I was using the resnet34 model, which was rumored to be exceptionally good at classifying paintings. This is one of PyTorch’s pretrained models, and it’s called resnet34 because it has 34 layers in its convolutional neural network. This worked out okay, but generally you want to be achieving higher than 0.60 validation accuracy for a classification model. So I decided to switch to the resnet50 model, which prefers an image size of 224 x 224 pixels and has 50 layers in its CNN. This model performed substantially better, first achieving an accuracy of 0.77 on the initial 1800-image dataset, and then 0.89 on the final 2700-image dataset.

    Once you have your data in the artist folders, this is all you need to do to train your model -- just two simple code cells.

# Create the Datablock
dls = DataBlock(
    blocks=(ImageBlock, CategoryBlock), 
    get_items=get_image_files, 
    splitter=RandomSplitter(valid_pct=0.2, seed=42), # split 20% of the data off for validation
    get_y=parent_label,
    item_tfms=[Resize(448, method='squish')]
).dataloaders(painting_data_updated, bs=32)

dls.show_batch(max_n=20) # show a sample of 20 images that the model will be trained upon

# Train the resnet50 model
learn = vision_learner(dls, resnet50, metrics=error_rate)
learn.fine_tune(4) # train for 4 epochs

    The Production Process

    Once I finished training the model and was satisfied with the result, I moved onto the production process. In the previous blog post, I touched on the difficulties I was having with HuggingFace in setting up a space for the model; I managed to resolve these issues a few days ago and get moving. The Ashryver V1 model (and any successive models) are running in a HuggingFace space, which I’ve set up and named ‘erilea-models’ to embody the fictional continent of Erilea. This space behaves somewhat like a GitHub repository, which you can clone down to your computer to add code and add models that can be represented using HuggingFace’s UI. All I had to do with this repository was drop in my pre-trained model in the form of a PKL file, and then call that file to make predictions using a simple notebook. That notebook then launched a Gradio interface (essentially what creates the graphical UI you see on the space itself) that allowed the model to make live predictions.

    This way, you don’t have to clone down the entire repository and install a bunch of insane packages to play around with the model. You can just go to the HuggingFace space (which I’ve made public), upload your own images, and have it make predictions. There’s actually even more I could do with this model, like using the Gradio API to place it on one of my own websites and use some custom JavaScript to make it look a bit different. However, the current HuggingFace solution works perfectly fine for this V1 model; I may consider switching to a more advanced API solution for V2.

    Next Steps

    Speaking of V2, let’s take a final look at my next steps for the Ashryver model. I’d like to improve the model’s reliability on Matisse paintings; right now it continually misclassifies Matisse’s tape drawing The Bees. I’m not sure how to deal with this one, as it isn’t a “painting” in the traditional sense, but users might still want to predict with that image. There have also been some isolated issues with other artists, where incorrect predictions crop up every so often.

    For V2, my plan is to find some way to deal with the ridiculous watermarked images or those that contain overlaid text in the training process, as these really seem to be sabotaging the model. I also would like to add a bit more data if possible, maybe for certain artists only, so the model can get a more comprehensive view of what’s going on. I may also add some additional artist categories (although this is optional), and I would definitely like to add a “sister” model that is designed to recognize the artistic era or period of a painting, and use that model to make “backup predictions” of a painting’s era in addition to the artist, in case you give the model a painting that it’s not familiar with. These enhancements should make the Ashryver model much smarter overall as a painting classifier; once I get these improvements done, I should be ready to move onto Unit 3 of the fast.ai Practical Deep Learning course.

    Don’t forget to check out the model on HuggingFace, or go to the AI, ML & Web Projects page to play around with the widget. Stay tuned for more updates!

  • Deep Learning Debacle: Deploying the Ashryver V1 Model (Painting Classifier)

    Deep Learning Debacle: Deploying the Ashryver V1 Model (Painting Classifier)

    Today (and this entire week) has been quite the adventure when it comes to deep learning AI models. I finally got off the ground on my latest project, the Ashryver model (the easy-to-remember codename for the 20-artist painting classifier). After building it locally with Jupyter Notebooks and Kaggle, I advanced to the next unit in the fast.ai Practical Deep Learning course, and started attempting to deploy it on a HuggingFace/Gradio space…

    …and promptly entered into a world of calamity.

    Creating an account on HuggingFace and setting up a space was pretty easy. But that was just the tip of the iceberg, as you might imagine. After that I had to figure out a way to set up an API key, clone HuggingFace’s Github-adjacent-but-not-really-Github repository down to my computer, add my pickle files for the Ashryver model, and deal with all the humongous files and conflicts. This quickly spiraled into hell. First of all, the API keys kept getting “into a stuck state” when attempting to commit changes to HuggingFace; apparently HuggingFace had deprecated a core feature that allowed users to authenticate with their HuggingFace password back in 2023, and you now had to use your cryptic API key. So I was forced to generate the in-universe “aelin” API key and use that, which fortunately worked.

    However, that wasn’t the end of the troubles. I then encountered issues committing any changes at all to HuggingFace, due to binary file limitations and Git LFS complications. At this point I was engaging in a lengthy back-and-forth conversation with Google Gemini, trying to figure out the best course of action for what I was facing. Every time I tried to turn on LFS or add the files, pushing any staged files would just lead to more and more errors. Eventually I just gave up and followed two core pieces of ML management advice: never upload your .PKL files or dataset files to source control because they can be a target for malware and bloat your repo. For now, I’m just leaving them untracked on my laptop, and not committing them to HuggingFace. After all, the model will be able to run live; users shouldn’t need to poke around in the source code this time.

    Speaking of poking around in the source code and my future plans for the Ashryver architecture, let’s dig into those topics now…

    Future Plans, Links, and Naming Conventions

    The current state of the HuggingFace space, displaying all model files

    Click to view the current HuggingFace space, which is still very work-in-progress.

    You may have noticed the rather unconventional name of the space itself, erilea-models, and the interesting name for the painting-classifier model architecture, Ashryver. If you’ve really been poking around in the Files section of the HuggingFace space, you may have noticed references to an “Aelin” or “Sam Cortland”. If you’re really receptive, you may have made the proper neural network connections and surmised that these are characters from a fictional series.

    If so, congratulations. To make things more interesting, and detract from the tradition of naming repositories and models boring things “like Testing Area 1 and Deep Learning Architecture System Version 1”, I decided to spice things up and give this space and its models some creative names. These are not so much “original” as “easy-to-remember”, which makes it more convenient to key in GitHub commands when all your filenames and model names are simple names. I plan on naming each successive model I release after a different character, improving upon each one with clear version numbers.

    As for my plans at the moment, I intend to continue working on getting the Ashryver V1 model into production. When that’s done, you’ll be able to go directly to that HuggingFace space (linked above), upload your own paintings, and have the model instantly make predictions. Right now, although the model has consistently been getting 0.89 accuracy on test runs, it still makes the occasional error when it comes to Henri Matisse’s paintings and tape drawings. This is an issue I plan to correct in Ashryver V2, which is where I might also introduce more artist categories. For now, though, all my time is probably going to be spent on getting Ashryver V1 into production.

    What all this means is that users will no longer have to clone cumbersome GitHub repositories and figure out ways to get my code to work on their very different machine, which sounds like a recipe for disaster. I’m planning on uploading my past models into that same HuggingFace space as well, or maybe a different one to improve organization. I’ll at least put the CIFAR Image Classifier on there, and maybe even the QuickDraw model if I can get it to work. After that, I intend to work on some more computer vision models, deep learning projects, and put something even more substantive than Ashryver out on the web.

    I’ll probably put up links to my various HuggingFace spaces eventually on this website, and they will serve as the “showcase sites” or portfolio pieces for the various AI models. This is what I’ve been working up to for quite a while, and it’s good that I’ve finally started working on a way to get these models into production.

    Well, that’s all for now on the deep learning front. Stay tuned for more calamitous updates!

  • Site Update: New Creative Works, Comments, and Inspirations

    I made some major changes to this website’s content and aesthetics this week, which you may or may not have noticed. First, I modified some of the fonts that are used, and installed a new minimalistic font that I felt went a bit better with the site’s theme. That font is now used on some of the page headings and titles across the website. Second, I completely revamped the Short Stories & Poetry page to better showcase my various poems and stories in a grid layout. Each piece has its own Inspirations & Comments section, where I attempt to convey what led me to compose the piece, and the meaning behind it.

    I’m still working on adding more of my poetry and short stories, but I have a semi-comprehensive list on the Short Stories & Poetry home page. In fact, I’m working on a rather unusual coming-of-age short story right now; it might be the submission for the 2027 Scholastic Art & Writing awards. Once that’s done, I’ll attempt to upload it to the website, and attach some comments. I’m contemplating adding a background-header sort of picture to the short stories & poetry page, similar to the large one on the homepage. However, I’d like the text to be overlaid upon the background image, and thus far, I haven’t found a way to do that with clunky WordPress.

    I’ve also made some minor tweaks to the Musical Works page, changing the names of some tabs and linking some of the most recent compositions. As a quick note, it is now possible for people to fill out the site’s Contact form to obtain copies of the scores; there is a one-page preview image available for some of the more recent pieces and a button to get to the Contact form. I don’t plan on charging money for the scores; this is just a mechanism to prevent bots (or people) from coming on and scamming the scores to a wide variety of unauthorized individuals.

    Deep Learning Course: Finally, Some Progress

    A code cell and output from the fast.ai painting classifier, displaying some sample photos that will be used to train the model.

    After about a week of screaming and coming close to quitting the entire course, I finally started making some progress on the fast.ai Practical Deep Learning for Coders course. Yesterday, I finished training the first major project, which is a painting classifier designed to identify the artist of a given painting image. Right now, I’m training it on the works of twenty different Impressionistic artists, with some more modern painters also included. I’m amazed at how much easier it is to use PyTorch to create a classifier than Tensorflow; all you need to do is pull down your images, create a DataBlock, and initiate your learner.

    The reason why I was getting so blocked on this model before was the stupid DuckDuckGo search issues, combined with issues with Kaggle. This sort of classifier relies on pulling down batch images from the DuckDuckGo search API, which is flaky at best and catastrophically time-consuming at worst. So why am I using DuckDuckGo, of all search APIs? Because Microsoft has gone bad and locked their Bing Search API behind a paywall. In a similar way, Google’s search system requires several different API keys, extensive verification, and massive amounts of credentials that make no sense for a small project like this one.

    At first, I thought I was going to have to quit out of this project and find a different data setup that didn’t rely on DuckDuckGo. But then, on Monday morning, I “magically” stopped getting 403 Ratelimit errors, and started downloading images as normal. So I jumped on the opportunity and immediately trained the model to completion with all 4,000 images; after doing some brief testing, it looked like the model was actually pretty good. I’m going to obtain some empirical data on the model’s performance–accuracy, loss, and others–shortly, and use that data to experiment with some different model architectures and data configurations.

    I also did some minor refactoring of the model’s code, which is now available in my official fast.ai course repository on GitHub (though I don’t recommend doing anything with it yet, as it’s still very preliminary, and the repo is still a mess). In unit 2 of the fast.ai deep learning course, I aim to release this painting classifier via a web API so you can interact with it directly; when that’s done I won’t have to deal with muddled GitHub repositories, local files, and broken Kaggle runtimes because the model is released into production already.

    Well, that concludes this regular site update. Stay tuned for further news on AI projects and creative pieces!

  • Update: New ML Courses and Deep Learning Exploration

    Update: New ML Courses and Deep Learning Exploration

    Subscribe to continue reading

    Subscribe to get access to the rest of this post and other subscriber-only content.

  • Reflection: 2026 Chamber Music Perspectives Workshop

    It’s been quite a busy past couple of weeks. The 2026 Chamber Music Perspectives composition workshop mentioned in the previous blog post has now ended, so it’s time to dig into a brief reflection on what happened and the interesting skills I learned during this camp. This will be a “bite-sized” reflection, an interesting technique to explore that forces you to compress your thoughts into a succinct 200-300 words.

    Collaborating and cueing other musicians

    This is probably one of the most important and valuable skills I took away from this workshop. When performing a piece, whether in rehearsal or otherwise, you must take care to Breathe Together in order to inform the other musicians where you are, and when you’ll be starting. If you don’t breathe together, you’ll end up starting off or getting off later in the piece. Another important part of this skill is maintaining a good balance- you don’t want too much of one instrument to soak through and disrupt the careful balance of the ensemble.

    The conductor will usually stop the situation and flag players that are disrupting this sound, but it’s important to recognize imbalances on your own so you can correct them by adjusting the playing.

    Know what the instruments can and cannot do

    This is more of a composition-related skill. When composing a piece for unfamiliar instruments (whether that’s a cello or a ranat ek), you have to be aware of the limits of the instrument, including the range, the intervals, the restrictions on playing techniques, and so on.

    Some instruments can’t play chords with four or five notes all at once without stranging the note or turning it into an appogiatura. I attempted to compose a piece containing several strange intervals that were not only difficult to play, but were very un-violinistic and un-cellinistic. I then had to go back and update this intervals, with the specific techniques and abilities of the violin and cello in mind, and use fourth and sixth intervals instead that are more commonly used. Other individuals who attempted to compose for unfamiliar instruments composed pieces that were on the more boring or uninteresting side, primarily because they were unable to leverage the specific powers of thsoe instruments.

    Improvisation isn’t just about making random screams in the ensemble

    When we started the Improv game near the beginning of the workshop, not knowing what the rules were and how to execuate a fully improvsed piece, we just thought it was about making random noises without any specific rules. However, it turned out that this wasn’t the case at all. Improvisation is actually about listening to what’s going on around you in the ensemble, and changing things up to respond to the other players. For example, in the piece we learned as the Improv game–a special arrangement of An Eye for Optical Theory by Michael Nyman–some of the violinists had the option to take off on their own and do a solo. In response, the four hands piano might end up dropping out temporarily to let the violin have a moment. If one of the cellos started playing a noisy pattern, the piano might double that pattern to increase the volume. These are the kinds of things that actually make Improv games organized and fun.

    Concluding remarks

    These bite-sized skills and interesting points I picked up over the course of the chamber music workshop don’t just apply to these specific pieces or ensembles. They’re useful for all kinds of musical collaborations and composition projects, and they enable you to see the larger picture when it comes to composing music or playing with others. Through this workshop, I discovered some extremely useful insights when it comes to how string instruments are played, as the composition I created was performed by actual string players. The improvisation games added a nice touch and extra material to the chamber music performance; I also learned several new composition techniques that take advantage of the unique abilities of all instruments.

    Stay tuned for more updates and news!