Category: Long Read

above 2000 words

  • 2024 Unreal Engine 5 tryout

    2024 Unreal Engine 5 tryout

    ⏱️Overview

    I’ve spend over 1 month in total, exploring the Unreal Engine 5.3 on Linux and gathered some opinions about it. I’ll say upfront: I don’t really like it and this version is not even fully working on Linux. And no: I will not make or port Stunt Rally to it, I know for sure now. This isn’t a strict tutorial, but my gathered experience, many complaints, with some useful links.

    📂Gallery🏞️

    Short gallery with showcase here.
    Long gallery with many more things shown and including visible bugs.

    ✍️Motivation

    Well I have been using Ogre rendering engine since about 2007. Over a year ago moved to OgreNext, which is even less popular. I can simply say there is just one person (the developer) who is able to, and does usually answer my questions, or fixes issues.

    Naturally at some point I wanted to get at least a basic knowledge of other engines. Since they’re so highly popular and have big forums and communities. And get my own opinion, also regarding what’s best for Stunt Rally (rendering only since we already have simulation and even own track editor).

    I made 3 initial choices due to highest popularity: Unreal, Unity, Godot.
    I did already check them in 2022, and wrote a little in my Rendering “tutorial”. But ultimately for me, Unity died a sudden death due to their freaking license changes (which shocked lots of developers and made them move). I did check out Godot and so far its best demo for terrain and nature, and it didn’t seem too great at performing there. Which seems also a popular opinion that it doesn’t handle big 3D scenes that well.

    So, the goal was not really to move SR to any of them. It was to assess if that’d be even reasonable, and logically prove that it’s not (even only for rendering purpose). Last and quite important reason was to learn “the other side”, new effects and technologies, and know what would be possible to achieve in SR too (someday).

    📜Earlier try

    I did try UE on my old PC. Back then in 2020, UE5 had to be built from sources on Linux. Took me like 50 GB of space to download. And few tries to finish, as there was no info (and I had a small SSD). Then few hours to even build. Lastly at start it took 30 min to compile over 5000 freaking shaders. So ugh, yeah, clearly my PC was too old for UE5. I did try later after I bought a new PC. It does still need 5 min for shaders now. And that’s needed when major options are changed.
    Still, my impression is that most people would need to buy a new PC to use UE5, unless they already got a new gaming PC. It is really demanding on hardware.

    🔍Observations, Issues

    Of course, these are specific to me, using it on Linux. Also to what I was testing: for Stunt Rally try, so in 3D, mainly for driving cars, on gravel and for stunts.
    Also I didn’t spend years using UE just maybe over 1 month total. I could be wrong, or assumed something using my anti-commercial logic, or just didn’t care to investigate longer.

    I list here all my issues I had using UE5.

    • UE is a big commercial hub, feels like a shop. Not for true FOSS projects. Lots of assets, meant to be used for Unreal projects only. Nothing is CC Licensed. They also have own binary file format for everything, only .ini readable for options. I did import e.g. trees from .fbx (which can be exported from Blender) but that needed more work, making materials later.
    • Aimed at Windows and making big profits. Obviously if someone paid for Windows, they’re more likely to pay for its software. Linux is the least popular so least supported.
    • Not meant to be used on Linux only. Nothing can be downloaded, as this needs the freaking Launcher application which has only msi installer. Even their demos don’t support Linux, e.g. this and that. Thus IMO they don’t fully support Linux, just wanted to add it to platforms list, as only the engine works but not the rest of their ecosystem. The Quixel Bridge is also not working at all. I don’t care about that integration, to add assets directly to project content. I’m a fan of simple download buttons or repositories. But big companies progress by buying other companies and so “improving”, which is also a way to be more monopolistic.
    • Editor GUI. IMO it’s utter garbage and a mess. I wouldn’t enjoy using it daily. There is a “magical” way to scale whole GUI. But no real options to choose font sizes, icons, themes or other visual stuff. Seriously, in such a big editor, used by so many people every day? Sounds like a joke to me. I can’t take seriously any* programs which don’t allow user to (at least) change their theme and font size. *even small, but except my own. I have made my own themes for every software I used for longer.
    • Tons of properties, written in same tiny, plain text, no idea which important, no icons for settings or e.g. even colors or bigger fonts for more important/significant ones. No way to bookmark properties or settings to know which I want to remember easily. Should I like write them on paper or something like in middle ages, or remember all that? Some have tooltips (white) with decent text, some very little. At least the worst stuff is bottom in properties usually. And the (rhi) statistics texts are even smaller and less readable. I made my own Fps and statistics bar in SR and it has few detail modes now, medium size font, and even coloring from value, if it’s red that’s bad.
    • Editing terrain. Seriously cumbersome. If you ever seen or used Stunt Rally Track Editor, it should be pretty clear what I mean. Sure, I wrote it myself so it has what I find best already. I mean using just mouse wheel to adjust brush size and force. Also having keys that increase those. Then plenty of terrain brushes to choose from. All brushes using floats and computed for needed size. I could go on. We made over 200 tracks just using those tools. Seems like UE doesn’t care much about such tools. There are some other software programs (big and commercial too) that will make a terrain which you can import instead of editing. BTW I saw no way to import raw float heightmaps which we use since years for best quality.
    • Gizmo. Well it may be my personal hatred for that thing. But how am I supposed to drag that one axis if it’s covered by another. Probably need to focus, rotate around or use ctrl, meh. We don’t have a gizmo in SR editor, yes it may not be obvious how you’ll move etc, but you’ll always be able to do it, directly from anywhere.
    • Physics. I’ve seen some opinions on internet that it got worse in UE5 (has Chaos), from UE4 (had PhysX) if I got it right. So far I had plenty of sudden car jumps because of what looked to be normal wheel force from contact, getting weirdly high. Also had some sudden object jumps, flying far very quickly. All not looking good or real, seems like an unstability. I did increase substeps and decrease interval to get better simulation at high speeds, and I did surprisingly fix that wheels wobbling suspension. I could drive even over 600 km/h in big glass pipe loop and 450 in smaller one. That’s probably the only thing better than in SR with Bullet physics, but I’m still using old version and didn’t try new in years.
    • As of UE 5.3 which I tried, I was not able to turn on Nanite at all, and neither HW ray tracing. And those are UE’s biggest, prominent features. I used Debian 12 and AMD GPU with Vulkan. Saw some post that 5.4 could fix it, maybe.
    • Lumen software reflections. Man, those look laughable. I guess most would use HW ray tracing now or in few years. But I’d rather have my own cubemap rendered and used for other parts too. Instead of looking at Screen Space Reflections (a recent disease) or those blobs (done by Lumen software reflections) when screen space didn’t cover. Plus I’ve never seen car underside reflected properly here. Lastly I tried adding reflection captures and thoses didn’t work. Could be my fault, whatever.
    • Many effects are iterative, updated partly over time, and so they work best when not moving. E.g. volumetric fog lit from car lights, is moving inside car when driving. Reflections also have some noise, changing pixels. Global Illumination with Lumen, also does fluctuate and spread unevenly over time. Sure, it’s new technology and best if it didn’t melt GPUs doing impossible today. But it feels to me like these are just targeted for those indoor furniture designs and static shots, not games.
    • Many things even vehicle parameters need that Compile pressed after changing, then running to test. Really not convenient. The default vehicle simulation is completely nonsense. I guess it could be good for basic arcade games. That’s to be expected. Can’t touch dedicated C++ code for vehicle simulation like VDrift or even RoR with deformation. I found an older UE4 vehicle simulation, whole made with blueprints. Is good to learn from, didn’t feel great to drive though, but I’ve spend not much time with it.
    • Lots of thins are still done from console with typing commands. I guess no need to add them to that pile of unrecognizable settings list yet, probably translated though. But on the up side, there are plenty of options to customize for sure.
    • Crashes. Last but not least. IDK if it’s just because I use Linux, or Vulkan, or AMD, or their drivers. Doesn’t matter, either way I had many UE crashes. Luckily I didn’t loose much, seemed to be at end mostly. Still, not a good sign, not for stable software, not for daily use. Also seems to me like UE is favoring NVidia GPUs or maybe they have better hardware ray tracing, IDK and don’t have time to investigate. Ah and trying to start profilegpu did reset my PC instead.
    • Whenever you change key options it will be building over 5000 shaders again, which takes for me 5 min. And Package project at first takes like 30 min, but later it does much faster even less than 1 min. There are slow downs of like 5-15 sec whenever you save a material etc, there are structures in UE that need to be rebuild and this a slow delay when editing.

    🎛️Blueprints

    I’m kind of in the middle with this topic. Both good and bad.

    Quite a lot of stuff can be done using Blueprints. There are games made just using them.
    But then you’ll be dependent on them, which means no full control over what’s happening, and just doing what others tell you to do their (commercial) way. There is no avoiding blueprints, even with C++ code.
    Another thing is that the list with blocks in blueprints is again huge. Here even a video with main ones. So usually you’ll have to type more to find a block. Even if + or * etc is enough to get simple operations, that’s still just ridiculous for me as a programmer to put a block and connect those lines to it, instead just typing + in code.
    But yes, they’re easier to understand for non programmers. Still, I felt like I didn’t know how to do anything at all, when I was starting with blueprints. So it’s not like those were easier to start, just less to set up (no external IDE, compiler).
    Lastly big, complex games would require a lot of code, which in blueprints means few times more clicking connecting, picking blocks, to me it feels like slow playing with toys instead of developing. And then area is huge, also hard to find stuff, lots of moving around and zooming. Sure there are comments, same as in code. But much more code can fit in text editor. And it doesn’t go both vertical and horizontal (when done right). Doesn’t need zooming. I find code easier to navigate (definitions, references) too. All can be done faster by keyboard.

    There is a cool webiste with lots of blueprints here.
    One good part for blueprints (similar to scripts) is their safety, since they show errors, won’t break, etc. While code can crash, corrupt memory, loop infinitely etc. And could take more time to build and test too.

    ☑️ Good parts

    At least at start, because I seem to end them with a view that’s not good.

    • A lot of stuff working already. But as the saying goes: if something is good for everything it’s also good for nothing (i.e. not great for anything particular). Also if you wanted a change in their sources then it’s a huge amount of it to even grasp (like 50 GB total). And more games using UE will mean more will look the same due to its technology.
    • Plenty of (free) Plugins. Even fancy things like Niagara (3D smoke and fluids simulation, rather not for my/current hardware). But Water is still Experimental (yet essential), and I had some bugs with it (underwater fog was bad at times, even white flashes, then after publish it was at random level above sometimes). Very many plugins are also in Beta and version 0.1. Seems like it’s still too early. IDK maybe UE5 is still too young. I’m obviously only considering free plugins.
    • Useful modelling tools included. E.g. video. Can quickly edit and draft a scene with basic models, already inside UE. For me not needed, as we already have our assets, and tracks made.
    • Many possibilites to generate and place stuff (meshes, vegetation etc) with PCG. Still, those are rather new UE features. Which I’d expect much earlier. E.g. someone using UE4 didn’t have them, years ago. And frankly, in Stunt Rally we had automatic vegetation placing and road generation with LODs since the beginning in 2010.
    • Can move camera with W,S,A,D and Q,E, that’s cool, even bookmark places. But I didn’t find a way to change the speed by keys, and sliders don’t allow any values just predefined, IDK.
    • Plenty of debugging view modes and visualizations. Well the rendering engine is very complicated and “heavy” (high HW requirements) so these will be needed to optimize, probably even if you don’t want to. A very good (but older UE4) video series pipeline bottlenecks, passes.
    • Seems like Visual Studio is again default for C++ but at least VS Code is supported. So my setup with clang and VSCodium won’t work. And OgreNext supports clang officially. UE C++ is also in its own style. Quite old, not even similar to new C++ versions. All variables used and methods use big letters. Video here. Yes it’s a matter of preference (or getting used to) but yeah I dislike this too.
    • Many resources to learn from. Still those are commercials for Unreal and their addons etc but if you filter this out and ignore, then there can be plenty of useful, or universal information to learn in general.
    • UE is definitely huge and complex. With high popularity and big community it’s easy to find solutions to problems. But that doesn’t mean less problems. Actually I found many topics on forum which didn’t solve anything and seemed like unnecessary distraction, like from people not knowing English not only UE. Surely it was easy to find out why I got gray models after Packaging, but why on Earth weren’t shared wrap samplers the default, causing this issue. I think there is a lot of detail to be known to get UE working for any project.

    ⏳Summary

    Well definitely you can learn a lot, not only from using UE in practice, but also from that big number of videos either in their playlist, or lots of other videos from creators around UE. There is also a decent amount of documentation. This can help when starting or using UE, but also for getting information on various subjects around rendering or games etc (just at a smaller fraction).

    So it was a cool experience, completely opposite to mine. I mean using an advanced rendering only engine, built from C++ sources. Not just installed, and already with most needed tools. There is a gigantic gap or difference between those. And not only in software size and thus difficulty, but also in the community. It’s a complete opposite too. In UE (or Unity, Godot etc) you can simply even put your question in youtube and find a video (or few) with answer. When I was searching for UE vehicle tutorials there were even few playlists with that.

    Still, it’s not reasonable to change rendering or game engine far in production. Only possible at start. And SR is and already was far in production, having my own coded features, even when those engines weren’t available, that popular or so feature full. So clearly just because of that I won’t really be able to change engine. And neither would I have patience to spend 2 years or so, right after I’ve spend over 1 year to move “just” from Ogre to OgreNext.

    UE is big, and very commercial, so Windows, NVidia, Visual Studio are default, if not only option here for all things to work. So definitely not for me as a Linux only developer. I think they also use some telemetry, I’m not sure, but I saw urls, sent to their website from UE, as warnings in log, when I didn’t have internet.

    Lastly there are plenty open source engines, e.g. listed here, or new list here, also tools here, and a big collection of engine related links here with lots of libraries and sources.

  • 2021 RC Drift car 🚗

    2021 RC Drift car 🚗

    ⏱️Overview

    At end of 2021 I bought a WLtoys K969 RC drift car. I will describe here all the modifications I made to it. Also with few review remarks about it, less important comments and rants are italic.

    📷Pictures

    In gallery here.

    ▶️Videos

    Video here. Drifting in empty office on carpet and kitchen floor (best of montage).
    Camera was just from old phone: LG K10 2017
    Car camera: Ion Snapcam LE, like mentioned below
    Software used to for video eiditing: Kdenlive on Debian GNU/Linux with KDE

    📜History

    I guess I should write this chapter here, since being almost 40 requires (an attempt for) an explanation ?.
    Well, as a child I only had a few (probably Russian) cars from 80s, Two did have a cable from controller, and the one that was radio controlled had only 1 button to go backward, which also made it turn. Yeah I also can’t even.
    As a teenager, at some point I got an RC car. It had rear wheel drive and used 27MHz. I think I drove it only 2 times. It was fast and meant to drive outside. It had rubber tires so it stuck to asphalt and would rather flip over instead of sliding. It seemed kind of hopeless (compared to today RC toys) and felt like something is missing.

    ✍️Motivation

    In the mean time I got interested in WRC and 4WD on gravel, played a couple of such games too. And finally made my own Stunt Rally. There was a time when I was a lot interested in tires and car simulation.

    Recently, once a while I was watching various videos about RC toys. Technology moved forwards a lot in them too.
    This way, I found out about RC drift cars of 1:28 scale, and after days of watching videos and researching what would be cheap, but still good for drifting at home (or office) I found this WLtoys K969 and saw how it drifts at home.
    I think I watched later other 1:28 cars (like Mini-Z, Mini-Q etc.), and realized that even thought they are much more expensive they aren’t much better. At least for me as a first car, I don’t intend to drive RC professionally or on tracks. There are also cars and people who prefer RWD only drifting (front wheels move freely), but I was never a fan of that.

    So I think this RC is a nice, real life example, even if in smaller scale. It surely reacts and changes direction much faster than real cars. But is certainly less complicated, has no: LSDiffs, torque curve, gearbox, central differential, etc. In this RC all wheels rotate the same, electric motors don’t even need gearbox, suspension has only stiff springs, and there is no flexibility in tires, since those are from hard plastic here.

    🛠️Modifications

    So the things that I changed and added first to last are as follows:

    • Moved the pin from servo‘s steering arm higher for more steering angle range.
      There is a video here where it was easy..
      But, a huge but here, as it turned out (for me) the upper hole for this screw is wider and I couldn’t just simply use the same screw from lower hole.
      Thus I had to go creative to achieve this. Since I soldered a lot, I came out with a solution of putting few wires together for right diameter, then soldering one end to a tiny PCB part (with 1 hole), and just bending 2 wires out of the other end. It still holds well. Visible on my last picture.
      I guess this isn’t that important but is very good to have. Without this, steering angle is lower, making wider turns, but you still can make tight turns by drifting with quickly spinning wheels to oversteer (lose grip on car rear).
    • Made throttle range adjustable. How to video here. BTW I recommend that channel, it has many good videos including for this RC car.
      This is actually the most important one. Without this it will be difficult to not spin out wheels all the time. For small rooms, throttle range needs to be even lower. Of course they made the car to be cheapest, and even didn’t add the most important adjustment to it, I didn’t need those side buttons, so why not having this instead. Meh, always have to make things usable myself.
    • Added more weight on front.
      I cut out a universal PCB (my favorite kind) and made a place to solder down wires holding extra weights, they fit well. I used 4 in total, 2 on each side. One weights 4.5g, so this is 18g added on front wheels. This made center of gravity to shift (like 6mm or so) towards front and made the car oversteer even more, it drives better. There were some videos on doing that, just gluing 10g weight.
      Isn’t crucial though, still can drift without this. My front PCB is also used for lights and wires.
    • Added front and rear car lights.
      They are good for better orientation of how the car is rotating and what’s its direction. I mean it is actually easier (for me) to tell this by seeing those lights on floor, especially if car is far.
      The only way of doing this is making holes in chassis and hot gluing LEDs to it.
      I’ve spent too much time with lights, first making them in car. This way anytime I hit something harder they would change angle, go loose or break off.
      I also made a second mistake and made holes bigger to have LEDs with cases. It turned out the cases were too big and so long that made wheels hit them, if chassis is low. I will cut them to minimum and glue again. Good thing about that hot glue is that I can actually melt it with soldering iron again when I change my mind.
    • Made the RF sender battery use a 18650 LiPo.
      I don’t get why they didn’t already (was probably cheaper). When full, 4 AAs give 6V, LiPo is 4.2V, but RF sender still works. I thought it would be more difficult, but it was really easy. Just throw out 4AAs compartment and place the 18650 or any other LiPo here. Doesn’t seem to use much power, I didn’t charge it for a month or more. I only don’t know if it maybe decreases range? But with all being digital it may not be affected.
    • Added bottom lights.
      I had some old LEDs lying around, now 2 are on rear before wheels and 2 on front before wheels. Their location with chassis holes makes this cool blue X on floor now.
      I had only two 3mm LEDs so I also used 2 SMD LEDs, which I soldered out from those LiPo chargers (who needs them, red when charging is enough, and were so bright that I couldn’t even?).
      Then I added two 5mm LEDs (too big, SMD are better) green on left side, yellow-orange on right, located right after and above wheels. This turned out to be useful to know even better how the car is rotated from distance. So later I added same (close) colors to front, behind wheels.
      I soldered all on small cuts of universal PCBs.
    • Changed to a bigger car battery.
      The included 400mAh battery allowing 30 min runtime is laughable. Yeah I can’t imagine drones with 15 or less minutes at all.
      It was cheap and light, which is why they made it, right. After all, the freaking top speed has to be highest, like it was important at all. It drifts at much lower speed already.
      My new battery is 1200mAh and allows 1h 30 min drive time (so 3x more).
      It was made from two LiPo 603450 batteries, each size: 50x34x6mm. Glued with tape, fits nicely in same place, is just much higher and it weighs 45g. Secured it with some cardboard and mouse pad fragments on sides and wire (with thick insulation).
      I just had to remove their protection, because with it, it would stop for few seconds when pressing throttle too rapidly (very annoying).
    • With new battery I’ve also done new electrics in car. namely:
      1. 4 pin socket for battery, normally plugged in.
      2. ON-OFF switch. I used a 6 pin Tactile Power Micro Switch (self lock on) 7*7mm to switch + from both LiPo batteries.
      3. 4 pin socket for charger, plugged in when charging.
      4. 4 micro switches for lights (on-off, one small package). I added 47Ω resistors at end of each. I call this a fuse box, their purpose is prevent battery short circuit if by accident some wires connect.
      5. 5 pin socket (3 used now) to connect chassis lights.
      6. 2 trimmer potentiometers 1kΩ, for dimming car lights and bottom lights.
      7. All this required access, so I made a “door” in half of car’s front windshield.
      8. In total, the boards with bottom LEDs and all electrics weight 27g. Seems too much, but whatever?‍♂️.
        Each LED has a 330Ω resistor before. LED calc can be used if needed.
    • Charger
      Made using 2 popular modules: TP4056 / TC4056A Lithium Battery Charger and Protection Module.
      Just added 4 goldpin connector for car socket and that standard 4 pin PC connector for 5V.
      It does charge the battery in about 1h 30min. I’m not sure if it’s too fast or okay. The 4056 chips are heating a bit too much (at start), so I’m using a small copper radiator on them.
      Besides of removing blue LEDs from chargers (mentioned earlier) I also reduced the red LEDs brightness, resistors are now 20kΩ (way more). I hate this approach of adding LEDs, even for “turned on” indication and making all LEDs as bright as it can be. I guess if they could they’d made them visible from space or neighboring countries, that would be the best commercial?.
    • Radiator for main motor.
      Having more time to drive showed that it heats a lot, especially in smaller rooms.
      So I used thermal glue and glued some small aluminum radiators (1 cut to match motor length) bottom to motor and side to car bottom, which is aluminum, so good for cooling too.
      I’m guessing an even better way could be using copper tape around motor and gluing that to car bottom? Not sure. Either way some cooling is needed and would be better to have it done already.
    • Added some rubbers (cuts from mouse pad) below chassis mounting points (I saw something similar in a video).
      And later some foam around the car, better late than never. This is to soften hard hits, those happen a lot at start when first learning to drive, especially without reduced throttle.
      Additionally, at home I do jumps sometimes, banked and U turns (up to like 80 degrees, on a bent sheet of metal I had in cellar) and flip overs can happen this way etc.
    • At some point while reversing I almost broke one differential end (those, like all parts are plastic). I only noticed when one wheel wasn’t driven. But I managed to put it together with a wire soldered around it, so it doesn’t fall apart completely and works, a bit uneven though.
      Parts are freaking expensive, probably few times more than their worth. I hate this approach. If someone bought all parts separately it would cost like 2 or 3 times more than the car itself. Plus the waiting for shipment takes time.
    • After some bigger hit, I broke the thing that holds chassis on front. It is filled with holes and plastic, so no wonder.
      I made something stronger (and heavier like all I did) from a metal part, M2 and M3 screws. Is more difficult to use but should last longer, if I don’t break the plastic part that it’s mounted to.
    • Added a mount for camera on roof.
      Camera is Ion Snapcam LE, it weights 28g, with its own battery. It even lasted longer than car drive. I didn’t yet make it lighter by using car’s battery. Not sure if I will.
      Unfortunately, videos are horribly shaking when driving, because of uneven wheels.
    • In total the car with camera weights now 288g. So it is a lot more (was 160g at start) and the front suspension won’t allow more. Without camera and extra weights it is about 240g.
      I think it still drives well despite the extra weight. But surely when lighter it was quicker and more responsive (less mass and inertia).
    • Now I’m waiting for new wheels, with aluminum rims.
      The default wheels on this cars are cheap, all-plastic and uneven. Even like 1mm difference in height when rotating. This makes the car shake a bit. Surprisingly it doesn’t affect driving somehow, and it wasn’t easy to spot. Only slow time videos showed it and those from car camera, which are rather unusable.
    • Maybe for future (not sure if I’ll try/do any of these):
      I was thinking of making the controller use IR distance detection for throttle (instead of potentiometer which I already once cleaned since dust made it go chaotic). Using a MCU (Teensy 3.2 which I have lying around doing nothing) with LCD, buttons and rotary encoder for a GUI that allows adjusting all ranges and offsets without potentiometers.
      I also had an idea about having a light MCU in car to use RF (e.g. NRF24L01 2.4GHz modules) to send some measurements to controller MCU, like: battery voltage (for remaining drive time), motor temperature, car acceleration, rotation and direction (from those popular new accelerometer chips), and making all car lights toggleable and dimmable (with PWM) from controller.
      Lastly very doubtful, but maybe if I used PC mouse optics and chip I could get real velocity and position on some surface.

    ⌛Conclusions / Review

    I personally can’t imagine having fun with an outdoor, fast / touring car, with rubber tires. Neither with a smaller car that doesn’t have 4WD and drift. And those big RC cars that can slide on gravel (and jump up few meters) are quite big, very expensive (I seriously would buy a new PC instead) and require a big area or a track. And outdoor and indoor tracks aren’t close, are likely paid per hour and have other people. Plus parts for more expensive cars are of course more expensive.

    To summarize, I would recommend the WLtoys K969 car, especially as first RC car for indoor use, with more fun because of drifting. But with a few remarks.

    I don’t really recommend driving this car without modification 2 (throttle range adjust). I did it at start and it was chaotic. Some say modification 1 (more steering) is also crucial.

    Another thing that many say, is that the 2 smallest gears wear out rather fast. Those that drive each differential, both from plastic again. Why on earth aren’t all gears from metal.

    Well as I mentioned few times already, nearly all parts are from plastic, which can be a problem. Surely is for small gears. Later if you drive on uneven surfaces or jump, etc. then mountings for suspension will wear out or break (since closest to floor and from plastic).
    Still (and maybe that’s why) there are many metal upgrade parts and kits, but I don’t recommend any, at all. I have seen too many negative comments from people who say that those don’t even fit together, are bigger, leave less clearance etc. So they just look cool, and that’s it.

    The rest of my modifications were optional and just an easy hobby, that lets me spend some fun time, but not with my PC as usual.

  • 2019 DoubleCmd Fork 📂

    2019 DoubleCmd Fork 📂

    ⏱️Overview

    This is my modified version (a fork) of Double Commander (DC), a two panel file manager. I first forked it in 2017 and in 2019 I finally moved to using it daily instead of Total Commander. I will describe few aspects here.

    ℹ️How to start with DC

    Here is a short paragraph upfront, for those who didn’t use a commander or are new to DC and want to start using it (or give it a try). I recommend the main website (for download and support) and the documentation (help) about how to use its functions.

    Double Commander

    DC is cross platform, so it runs on Windows and GNU/Linux. It is inspired by TC. There are of course many other file managers, (some even in text mode like MC), but I think DC is perfect for me and I highly recommend it.

    The best features of DC though (for me), are being Open Source (FOSS, this gives Freedom) and still developed. What it means (especially for me) is that I can learn how it works and can change it myself. Or even add new features, including those that only I will use. And I can contribute to the project.

    📜My History

    I started using a file manager as a kid, already on my first PC which had DOS. It was Norton Commander (NC, in text mode). I quickly got to using it daily, as my main program to do all file and directory operations. I didn’t even know how to do them using DOS commands for a while. Well I barely started learning English and wasn’t able to read any documentation too (it wasn’t needed BTW).

    When I was moving to Windows 98 (around 1999), I naturally wanted a similar program. I didn’t like Windows Explorer at all or even windows in general (I was still sometimes going back to DOS). Fortunately there was a similar program, at the time simply called Windows Commander (WC ?). It was later renamed to Total Commander (TC). Using NC in Windows was possible, but not always, since DOS had short file names and Windows has longer.

    WC was better than NC, my favorite feature probably being that it could color file names by extension. I think it’s when I started adding my colors for file extensions I got to work with.

    Naturally, when I started using Kubuntu and later Debian, I wanted something like TC.

    ⏳Before I started

    I actually reported a couple of bugs that affected me the most and honestly prevented me from using DC. I was also too inexperienced to even try fixing them myself. Lastly those weren’t easy things to fix.

    These were:

    • Very slow File Filters. It took 4 seconds of delay to view 24000 files in a directory with my settings having 123 file filters. Directories over 1000 files were already entered with noticeable delay. And yes, my file extensions list grew and became something that I enjoy since years. Surely not something that I would throw away and just not use it.
    • Freeze on entering unreachable network paths. It happened often at work (where I had to use DC not TC) and also for more people. Application froze for nearly a minute. So quite an inconvenience to kill the process every time someone accidentally tries an unreachable path or a tab with it.
    • Compare by Contents not Implemented from Search result and archives. A simpler bug for a useful feature.

    After a few months the first issue was fixed. So I started making my own program to deal with my file extensions list for both DC and TC. I had a lot of them 96 in 2017 and 239 in 2019, this is just the count of unique colors (file filters), though I split some for readability (e.g. for Stunt Rally track sceneries).

    The program has its own page and is called Crystal Color Center. I’m sharing it with my list included. It allows an managing the list on an even higher level, with features like: groups, search, quicker editing (with R,G,B sliders) and of course import / export for both DC and TC. Thanks to it, moving my list from TC to DC was easy and any changes to it is fast and conveniently done in my program.

    The second bug was fixed after a year (still, I can’t complain since I didn’t do it earlier). But earlier it became not that needed anymore for me.

    After that it was probably the time, when I realized I should fix the rest of my issues with DC. I mean just missing things from TC that I got so used to. It also turned to a nice learning experience and woken up old memories from Pascal.

    ✍️How I started

    Well the start is the hardest part of any software (program or game) or even any project in general. To start, the page Building from source is crucial. And I believe it’s probably the most important page for any FOSS project. Of course beside a good documentation for users. Fortunately the instruction is not long or difficult.

    Sources are surely different, because DC is written in FreePascal. Lucky for me, I knew Pascal since DOS and later Delphi in Windows. So I had some start and the rest is nicely explained on internet and in language documentation and wiki. But basically I prefer to just search on internet for particular problem. It doesn’t matter where I land (doc, wiki, forum, stackoverflow, etc.) to read the solution or hints.

    At first I was building just from command line. After installing packages for Lazarus IDE (a bit more trouble) I could develop in it. Naturally I created my own color theme for Lazarus IDE as a result. And I also saw that weird build “Internal error 200611031″ plenty of times (well count – 1 too many).

    FreePascal

    The DC code is quite big and it surely requires time to get a hang of it. Learning FreePascal adds even more time. But it is a very nice (almost funny) language which also reminded me of my earliest years of programming (at college I moved to C++ and later also C#).

    Pascal language doesn’t use so many symbols, making other languages look more like a forest. Pascal code looks more like a book. Not a phone book, a novel. An English book where people write what should happen. Assuming that comments are written in English too, which I recommend always.

    Well let’s have an example, I have cut and pasted few very readable lines here:

    uses
      Forms, Controls, Dialogs, Buttons, Menus, Classes;
    
    procedure LoadSettings;
    function GetOptionsForm: TfrmOptions;
    function GetAName: String; virtual; abstract;
    destructor Destroy; override;
    
    const
      allowed : set of char = [ '-', '.', '_', '~' ];
    
    var
      I: Char;
    begin
      for I := #0 to #255 do
      begin
        case I of
          '_', 'a'..'z', 'A'..'Z', '0'..'9': Identifiers[I] := True;
        else
    
    implementation
    
    if not Assigned(Operation) then Exit;
    Operation.Execute;
    
    with Operation as TMultiArchiveCopyInOperation do
      begin
      if cbEncrypt.Checked then
        repeat
          ..
        until sPassword = sPasswordTmp;
    
    finally
      Free;

    ⚖️Pascal vs C++, quick rants

    Well I can’t say I’m finally free yet ?, but surely many things from Pascal are great and make it very nice to read. E.g. that uses statement at start, compared to #include each in own line in C++. Or the with do statement that shortens a whole block below.

    C++ is a horribly unreadable at start. And just to mention, some terrible mistakes made by just one symbol, like if (i = 0), instead of ==, that compiles fine. But I did like { } brackets for blocks, instead of begin and end, how many times did I spell them wrong.

    I also remember my favorite thing from Turbo Pascal: F9 key to build project, if there is an error it jumps to it in code. Far too many times in Visual Studio I pressed: F1 to show error list, Enter to go to error and Shift-Esc to close that bloody thing. I can’t even ? (and those are my own shortcuts, just Esc won’t work).

    It is much better with C# where it compiles in background and underlines bad expressions in code already.

    One great thing in Lazarus IDE is that it makes tabs for each search you do. Why on earth can’t VS do it??

    I could go on. But the point is, it was really nice (for a change) to code in a completely different language. I think I’d put Pascal after C++ and before C#. Okay then, that’s it from off topic.


    📊My version

    Now we finally arrive at the main and most interesting part (at least for me).

    After I was able to use Lazarus IDE and felt good with Pascal (again), I wrote new features and customized DC to my liking. I also made source patches for some features on DC BugTracker.

    📂Sources

    Full list of my changes (in commits) can be browsed here (or locally after cloning with Git).

    Here is what I changed and why:

    • Undo Close Tab
      I simply can’t imagine having dynamic tabs anywhere without this. We’ll see if it gets into final DC release, and when.
    • Multi Rename tool
      More compact look and new functions listed here. Probably the biggest update.
      I use this tool a lot at home, e.g. dealing with thousands of screenshots, deleting later half or one third of them, re-enumerating them with this tool and doing it again.
    • Status bar
      New look, visible on screenshot above.
      I really like to have a different status bar (text and color) for when anything is selected.
      I once had selected files, not visible at cursor, forgot them, wanted to delete a file at cursor and deleted them all.
    • Size colors
      Next, why shouldn’t I have different colors for different sizes (K, M, G etc)?
      Sure for some it’d be too much color. But I’m using the same idea in my audio player (cAmp), coloring track times and I find it informative.
    • Gradient for cursor (blue) and selection (orange).
      Also visible on screenshot above. I think it’s nice, more futuristic.
    • Follow links to destination.
      With Ctrl – (Left,Right or Up), quite a useful thing.
      I have few dirs with just such links (.lnk files) and use them as my starting point e.g. when developing one of my projects.
      And BTW a quick feature to use Ctrl-Shift-S on cursor to make a link to it, without asking.
    • Find Files results, Color by file types.
      Another useful extension. Seems natural for me, to have any list of files use coloring by file type (extensions) especially when I have so many in my list.
    • Some smaller things.
      Not very important, but definitely nice to have and a cool exercise to find it in code.

    Another thing of mine is file and directory rating. I use it constantly since years too. This is visible on screenshot above as symbols ` ^ ~ + after name. It makes it easy to spot more interesting files/dirs and makes them change color (usually intensity). It is also an internal feature of my player to apply the symbols to filenames.

    ⚙️Contributing (in general)

    There are a few different change types to software, that anyone can report, contribute, or have on own fork.

    • Bug or issue reports.
      This is relatively easy to do as user. And is surely a good thing to receive as a developer. With more features in project and more systems where it can run, it is difficult to catch bugs. I didn’t like those reports as a Stunt Rally developer, but without them it would be a more buggy game.
      But still, there is probably nothing worse than a post “help, it doesn’t work”, without any (not to mention all) data required like version, OS, steps, etc. In that case it’s better not to post.
      There is a general guide for “how to report a bug” and some project have specific ones.
    • Bug fixes.
      Like those above, but better. They requires programming skills though. It’s when you fix a bug yourself and submit it (to developers).
      In Git that would be a pull request (from your fork, name is surely misleading). It is less trouble to merge and test, also more convenient to discuss (on website Codeberg, GitLab, Github, Bitbucket, etc.). But sometimes a patch is enough.
    • Ideas.
      Well that’s just the worst IMO. Everyone has them, just having is not much worth. Discussing them could mean wasted time on development. And developers have usually their own ideas and vision of project. Having more doesn’t help. But, I guess, it could be some help for starting projects, with not set vision yet.
    • New features, implemented.
      That is way better than just having ideas. Being able to turn them into reality. One can submit those to developers. But there is a catch. Not all will be attractive to put into project. Having too many features makes a project more difficult to test and more bugs are possible. And could make it more cluttered in GUI or Options (wasn’t an issue in my projects).
    • Custom own features.
      This is why I have so many forks. I do have plenty of ideas, I implemented them and I’m pretty sure nobody (from the developers) would care or want to add them (reasons above).
      Additionally, since I have a lot of preferences, it is natural to keep them in my own forks. This way I can keep up to date with upstream (main) project versions and have my stuff too. Priority for me is to keep my stuff.
      But merging upstream versions is needed too (once a while) even if it takes time. If not done, it would at some point accumulate too much, making upstream update too time consuming. Sometimes in that case, it could be possible to apply (merge) own changes (only if not too many) to a fresh upstream version.

    ⏳Conclusions

    My move to DC was surely long and took many steps. But I’m glad to use FOSS, not just as an alternative to commercial, but to prove that it’s simply the only logical way for me. It was obvious already earlier, when I created my own audio player (I use it everyday).

    If you’d ask me why I didn’t yet move to GNU/Linux (from that Windows crap) it is because of all those steps needed. DC was one of them. Rewriting my audio player for GNU/Linux is next. There are few other programs I customized and got used to (Video player, Image browser, etc.) but those two (DC and my cAmp) are crucial.

    I think I also showed some aspects of FOSS and the great things it brings. In particular, opportunities to: learn, express creativity and adjust to own needs.

  • 2010-15 Stunt Rally 🏁

    2010-15 Stunt Rally 🏁

    ⏱️Overview

    Stunt Rally is the game I started in Dec 2009, having first release in Apr 2010 and last (2.6) in Sep 2015. It was my biggest project by far, I developed it for 5 years almost continuously.

    Update: I started developing again after about 5 years break, and continued with new version 2.7 and moved to newer Ogre-Next in upcoming Stunt Rally 3.

    The game works on GNU/Linux and Windows. It features its own Track Editor. Simulation for cars comes from VDrift and rendering using OGRE 3D engine, more info here.

    I’m proud of what it became, but most importantly from the people I met, who contributed to this project, especially developers and track creators. The experiences gained and things learned with this project are significant. And it was a lot of fun.

    🔍Detail

    I created the 📖SR presentation book, it has 196 pages with lots of screenshots and explanations of the whole project (until version 2.6).

    You can read and see more on Stunt Rally website.

    There are few gameplay Videos and a huge Gallery (about 2000 screenshots) with a fun development gallery of same size. You can find complete documentation and even Track and Vehicle browsers.

    So, the game’s documentation will tell you everything about the game, track editor and tools.
    But it won’t tell you the history behind it. While the presentation book covers whole project (both the game and editor) in general, this post tells how it all started.

    That’s why I made this page. It’s also my dearest project and I get very sentimental every time I play it or even look at screens or videos. So I think it deserves it, and could be informative.

    📜History

    Around Dec 2009 I started looking for open source racing games, from which I could use the simulation code. My previous projects from 2008 and 2007 already showed me the limits of using only physics engine’s included car demo’s code for games. So PhysX and Newton Dynamics respectively. Bullet had its own car/vehicle demo too, so I knew it could only be fit for a basic arcade game.

    I was aiming at a simulation and wanted the most complicated code. After all I was playing Richard Burns Rally already for a long time (on keyboard), liked WRC (on gravel and from 2004-6 mostly) and actually despised any other car simulation games for being too simple (maybe RBR fans of that time know what I mean).

    Open source racing games

    There were actually just 3 games: some old code from Racer, TORCS (now SpeedDreams) and VDrift. I played them somewhat, then compiled all and tested. After that and decided that VDrift is the best, simulation code was quite sophisticated.

    The projects I didn’t consider were: SuperTuxCart (too basic, and for kids) and RigsOfRods (not a racing game, just a sophisticated vehicle simulation, but also using OGRE).

    VDrift was also still actively developed at the time. And I liked their move to also use bullet. That was simply needed to have any collision with environment.

    I edited the .car file a lot to find if it is possible to use VDrfit for gravel rally, later posting the results. It was good and fun, I played VDrift somewhat with my setups (gravel, wet, ice) since the original game was quite unplayable for me.

    Compiling VDrift and adding OGRE

    The beginning part was the most difficult. I was at the time just Windows programmer (but really liked GNU/Linux thanks to this project). So compiling a Linux project on Windows in Visual Studio wasn’t easy. When I finally managed to do it (IIRC after 2-3 weeks), I started tinkering with it, removing code I don’t want, etc. Still using the OpenGL renderer.

    Then on side, I started a simple OGRE app with just few models on scene. Later connected both. Getting the VDrift meshes to show right was a bit work (different x,y,z axes, 3D models). But without it, I wouldn’t see anything, so it was crucial.

    Once all worked I made the first release pack in April 2010. Was Windows only and most likely it wouldn’t even start without proper MSVC framework installed and such.

    It had only 1 car, VDrift tracks and no GUI. I compared the performance and started a topic on VDrift forum. It was terribly bad because of their tracks having thousands of meshes. So using OGRE for VDrift would be a bad idea. But that wasn’t my point. I knew OGRE already and in my previous attempt had a big terrain with good look and performance. I knew what I wanted in my own game and how to do it now.

    What happened next was fast (given only my free time) and needed a lot of coding and testing. But it was easier than the previous part. You can check the screenshots of funny situations from versions 0.1 to 0.5 in the first development gallery.

    Terrain

    I quickly added tire trails and particles, since they were already in OGRE and it was easy. Trails were never in VDrift and particles weren’t great. At the time VDrift moved to using bullet and that was perfect, since it was needed for any car collisions with environment. Then I added the Terrain component and tweaked code to have proper fitted heightmap triangles in bullet world too.

    Next I added PagedGeometry (I knew it already) to have some jungle vegetation, that came with Ogitor (same project we had textures from, for a very long time).

    Later I also added MyGUI. The options looked quite similar to my previous project, but this GUI system was much better and there were already more tabs.

    Also included 2 more cars. Then made the 0.2 release pack in Jun 2010, and started the topic on OGRE forum.

    Road

    Since there was no road plugin for OGRE, I started coding my own. Based on a Catmull-Rom spline, which is probably the easiest to edit and most intuitive, it just interpolates between points.

    Terrain already had its own LOD (level of detail) system. Road surely needed one too, to not quickly produce extreme counts of triangles visible. I thought of just 4 LOD levels for each road segment (auto generated in code), and a simple distance to camera check to pick one accordingly, showing less triangles further. Picture here. It wasn’t the easiest code to write, but I’m glad that I did it. It became the base for road and was extended few times later. Nothing else would fit so perfectly as own written system.

    📖Presentation

    I focused on creating the SR presentation book, which covers not just our history but the whole project with all of its aspects and implementation.
    The presentation has 196 pages with lots of screenshots and explanations.

    ⏩Fast Forward

    • 📜History of added features in each release in Old changelog.
    • 📈Statistics. Showing releases and data increases.

    What came next is summarized below in short points, in more detail than on presentation.

    Key steps of project:

    1. As described on previous pages the start was in Dec 2009 when I found VDrift and experimented with its car settings.
    2. I created the project on Google Code in 2010 to hold releases.
    3. My first release was in Apr 2010.
    4. Then came first issues.
    5. The game ran only on Windows at start. I suspected it would be rather easy to port to GNU/Linux (since both VDrift and OGRE did work).
    6. I was doing screenshot galleries on each release and game video every few. In a year I made nearly 10 releases (“Release quickly, release often”). I didn’t have a repo.
    7. After a year in Mar 2011 two guys (scrawl and Tapio) have joined and did quickly port game to Linux. Also added CMake build system.
    8. Also in Mar 2011 I created repository. Initially was Mercurial, because Google Code didn’t have Git. But then we quickly moved to GitHub (in Apr 2011 or so).
    9. At the same time we started using IRC on freenode to quickly communicate,
    10. Translations was surely one good thing done by new guys at start.
    11. In version 1.0 (Jan 2011) my track editor was ready and fully functional. I made a series of tutorials on how to use it. I was developing it further too (only I did that).
    12. Game was featured on freegamer blog, first with version 1.0. It did boost game’s popularity. Every time a post appeared after too.
    13. Since version 1.2, we started uploading the Releases to Source Forge. Google Code and its 100 then 200 MB limit were a problem. At that point it only was for homepage and issues (that view was very nice and customizable though).
    14. At some point the game was also added on playdeb, and on lgdb. I think those were (or are) the biggest Linux gaming sites and they helped with game’s popularity too.
    15. Scrawl did many things in the game. A lot of related to input (for controllers), post process effects, shaders, split screen, water in 1.5, etc.
    16. In version 1.5 we finally finalized multiplayer, done by Tapio. I was doing the Gui part. It took him a year to finish it, but I was glad anyway, since I could do other things at the time. I posted on Vdrift forum. I think, VDrift project was developing more slowly then.
    17. Scrawl did a wonderful task of creating a material generator once, and then even a second version called shiny (as a separate library for OGRE). And this thing made us reach a great look with nicely coded shaders (generated for both DirectX and OpenGL) at a higher level. I loved using it.
    18. Scrawl and Tapio were mainly active for about a year. Then I was developing alone again.
    19. We started a forum for the project, somewhat later in version 1.8, Nov 2012.
    20. Forum was great on freegamer, since there were many users already.
      It attracted the greatest people, artists creating tracks (and even sceneries) for the game using my track editor that I was also developed with the game. The best being: rubberduck who also made many buildings and objects, and Wuzzy.
    21. I guess I should also mention Calinou. He was always on IRC and had an opinion whenever I asked. This is already a useful skill. A couple of his many tracks went into the game.
    22. At some point I found out the greatest Nobiax CC0 textures and replaced all tracks terrain look, also implementing own blendmap with noise (for mixing them). There were a few such revamps of all tracks (big artistic task, bit tedious), for shaders, waters, skies. Terrain was the biggest.
    23. Project’s website was done very late in 2015, more info about it here.

    ⚖️Contributors

    There were few other people e.g. a guy who let me use his IRC bouncer. Tapio was later doing translation syncs, until I someday finally learned that. He was also hosting multiplayer game list server on his PC for years. Scrawl did later a VM setup and was making GNU/Linux binary packages on each version release. There were also few people translating the game to other languages than English (9, 5 of them fully).
    Finally, I can not forget to mention all those artist sharing their CC-BY 3D models on blendswap, also textures, vegetation, objects, and even 0 A.D. buildings. I was gathering all authors and website urls in txt files in our data/ directory each time I added something (later visible in Credits page in game).
    Naturally all the open source libraries used (including OGRE and VDrift) have to be mentioned here too, since without them the game would be completely different.

    All that was great and helpful. I want to thank all who contributed to this project.

    ➡️Break

    I was constantly developing Stunt Rally for 4.5 years. I was thinking of finishing the development a couple of times.

    I first ended developing in Nov 2014. But I returned after about 9 months for 3 more, rewriting sound system, replay files, adding pace notes and more.

    I announced development end on 19 Sep 2015. It was version 2.6, the 26th since start.

    Lastly, I have to add, it wasn’t just the 5 years it took to create all this. I took many years before that, of me learning from my projects, and having more experience every year doing so.

    Update: It wasn’t the end, but a few years break. I resumed the project 6 years later as Stunt Rally 3 since 2022.

  • 2010-15 SR Track Editor 🏗️

    2010-15 SR Track Editor 🏗️

    ⏱️Overview

    SR Track Editor is the program that comes with Stunt Rally and was used to create and edit all of its tracks. It first featured in version 0.6 (6th release in Nov 2010) and in version 1.0 (10th release, in Jan 2011) it was already fully functional (could edit all track features, at that time).

    I will describe here its features, from the latest version. It surely evolved with the project and changed its look in time. Unlike the Stunt Rally page, which shows the whole history, here I’m describing the present (it is free and open). And I focus on features, visible on GUI.

    🔍Detail

    Since the program is rich in features this page will be long. But also explanatory, for unique tracks and game features. I also reference any tracks that show off a particular feature with links to our online track browser.

    Editor is 100% designed and coded by me. There were many contributions to the game, but none to editor. I customized it to be a fast tool for editing, as I was also the main user of it. There were few awesome people using it too and creating tracks for the game.

    There is a series of ▶video tutorials for using it (from older versions though) and a Wiki page. If using editor, keep in mind that many places (GUI controls) have hints, so mousing over them can show a tooltip, possibly with useful information. Editor itself has help pages, listing key and mouse actions for each mode. Having seen all this, it should be easy to use it.

    📊Features

    One main aspect of editor is that it doesn’t feature an Undo/Redo, for me this feature was never needed and too time consuming to implement. We use quick Save F4 and Reload F5. One can also make backups manually of the directory. It is recommended to save often and on mistake just reloading.

    Track tab

    Track tab is the first I’ll explain. It takes some time to understand all what is visible here. Knowing it will help picking your base track to edit. Or finding an interesting track to drive.

    First, on left we have the list of tracks (172 total in version 2.6).

    In the middle there is an image with view of the track. Usually camera is high to show most of it.

    Below a short description. It is sometimes crucial to read it on difficult tracks, as it may contain useful warnings and hints. It’s writable in editor.

    Right bottom image is the minimap (view from top). It has useful info too. Background shows terrain shape. Flat road is black line, bumpy or banked road gets more gray. Bridges are cyan, pipes yellow. Half pipes will be green (0.5 mix between cyan and yellow). And lastly On-Pipe driven sections are orange.

    The track list (on left) has 2 extra columns: difficulty and rating (*). You can sort on them to easier find the tracks you want to drive. This is the default short view. The detailed view has many columns and can be toggled using the buttons above it [  |  ] and [ ||| ]. Some useful columns are N: (track index, sorting to get oldest to newest order), Scenery (we have 34) and ver (game version when track first appeared).

    Next button [  Y  ] toggles an additional, complicated filter window. It has sliders for min and max values for all columns and checkboxes to toggle their visibility (possible in both views).

    Since the tracks count is very high, we have a find box (bottom left, Ctrl-F), where you can type name or phrase to search.

    Use track load button or press Enter to load it. Arrow keys move in list (with Ctrl by 5).

    Duplicate button will make new track which is a copy of loaded one. There is no New button since it’s easier and faster to start from an existing track with similar scenery.

    Track icons (extra)

    Just above minimap we have a row of icons with small values indicating various things on track (they disappear when zero). Those are as follows: fluids (water or mud areas), bumps, jumps, loops, pipes, banked bridges, frenzy (curly road), obstacles and objects (dynamic). Of course hints for them will show under mouse. The higher the value of each, the more will be there on track and thus it will become difficult.

    Above this row on left we have track difficulty (most important) value: 1 (green, easy) to 6 (red, extreme). Next is rating (star icon), it is my personal quality assessment of the track. The third icon (red vertical line) is general (coarse) length.

    All those show in columns in detailed view and the list can be sorted by one. This allows searching for tracks with e.g. most loops or fluids etc.

    They all are set manually (be me) for official tracks and stored in tracks.ini file. User tracks have none.

    Track stats

    The next group of road stats is above icons and those are automatically computed by the road system. They are: length (in km), area (just side length of the always square map), average width, height difference (between highest and lowest road point). Below in middle center, with icons are: bridges percentage (cyan), pipe % (yellow) and on pipe % (red) on right. Above on right are road banking angle values (average and maximum).

    So that was a lot, and this is only the first tab. But it’s also present in game, and nearly the same.

    Sun

    Sun tab has all the options for sky, light and weather (and fog on next sub-tab). If in editor, you can read hints from tooltips for more info.

    Sky can be rotated to better fit track. Sun direction has rotation too (yaw), and pitch sliders. For example small pitch will make long tree shadows.

    These angles will be set when picking sky from list (if checkbox for it is set there).

    Pressing sky name button will show pick list with all available skies. Tab key is the shortcut for this (on other tabs too).

    Weather has 2 possible slots. Each can have one of many different particle types: rain, snow, fine, heavy, storm etc.

    Their intensity (emit rate) is set with sliders.

    Since it’s usually not needed to see weather emitting while editing track, it is toggleable here (or with key I).

    There can only be 1 light source in game. It is directional and is called sun.

    For this light, we have 3 parameters: Ambient, Diffuse and Specular. Ambient is the constant background color. Diffuse depends on surface angle (sun direction versus surface normal). And Specular is similar but has also power, it is the shininess.

    All colors here have: Hue, Saturation and Value (Brightness), which are obvious. But additionally, Value can go above 1, lightening more, used e.g. on deserts (Dunes etc). And there is a new Negative value, very rarely used. It can act as a negative light, decreasing brightness, e.g. a blackening sun on BlueHell.

    Fog

    It is a cheap effect, already present in earliest games. But quite good and present on most tracks.

    Fog itself is linear and has 2 sliders: start and end. Until start distance there is no fog at all. And above end distance, there is full opacity fog.

    Fog can have 2 colors. If not needed those can be the same. Useful for example on a sunset sky where one color is orange near sun and other can be gray on the opposite side.

    Height fog is an additional type (with own color) added to there regular fog. It depends on height, so gets denser when lower. Start and end parameters are here too (to allow own values for distance). Height and smooth values determine where it will be and how fast will it be dense (opaque).

    Fog colors (beside the Hue, Saturation, Value and Negative) can all also have Alpha (transparency). When below 1, fog never reaches full opaque in end, allowing some visibility.

    Higher than 1 for Value results in glowing fog, seen as light. Present e.g. on tracks: Pipeline, Crematoria, GreenStar and more.

    Last thing for fog, it can deal damage (over time) to vehicle. Happens inside lava, acid, radioactive pool etc. E.g. on Craters, Radioactive and AcidLakes.

    Video tutorial here (from version 2.1).

    Road

    Road is made using a Catmull-Rom, 3D spline. It can go in any direction. The system building geometry for it (segments, with LOD) was also coded completely by me. Started in the earliest versions and developed further to support bridges, columns, pipes etc.

    Let’s start with the simplest features.

    Points

    Road consists of points. Each point has several parameter values. Point is associated with road segment. As can be seen on picture, the blue spheres are road points. Selected point is violet. It also has a bigger red sphere beside it, which is used to show rotation for banked bridges.

    Points are inserted inside the glowing segment. The simplest road point parameter is width. Road width gets smoothed between points.

    Checkpoints

    A point can have a checkpoint sphere radius set. For road on terrain it’s recommended to be wider than road e.g. 1.6, but this will vary in places, bridges and pipes naturally have 1.

    Checkpoints are set manually for each track and used for many things: driving progress percentage, direction arrow (where to drive), also a beam (in place there), and most importantly to show Wrong Checkpoint, if driver misses it, while being too off road. They are explained in this video.

    Bridges

    Those were points On Terrain. Now if you toggle this snap off (Home), it will allow moving point vertically and automatically produce bridges, with side and bottom walls and columns.

    Materials

    Next easy topic for start is road materials. There can be only 4 (for performance) and they are set in Road tab. There is also a pick list to choose from all.

    Materials are changed with keys per road point, and this will blend (transition) in and out the material from close segments.

    Also on Road tab, we can change wall material, and column geometry (radius, sides). Columns are added automatically, always in half of segment. They can be toggled off. But manual placing isn’t possible. Adding more road points, evenly can fix it. There is only 1 wall and column material per whole road (also performance).

    Now let’s get back to the point.

    Banked

    Having a point in middle air lets you rotate it. Changing roll angle will make banked road. This allows side turns and skewed loops like shown here (Refinery).

    Pitch is never set, it is automatic. Yaw also, but it can be adjusted. It decreases width, but is sometimes needed, e.g. when creating loops (upside down road part).

    Tracks with a lot of banked roads are e.g. Web, Spider.

    Loops

    Loops require 8 points or more to be good and smooth. And as we can see, having full control of each point gives freedom to create any types and original shapes of loops. Since they have walls, it’s hard to fall off of them, except when upside down and driving too slow, or for difficult, skewed ones.

    Tracks with many loops are Loops, LoopBasic, Scorpio, Refinery, BlueHell, Crematoria.

    Selection

    At this point, it is worth saying that: (many) road segments (with points) can be selected.

    Besides that one point (or none) can be picked.

    The selection can be:

    • Moved (all at once)
    • Rotated (yaw, around picked or center), or Roll (used rarely)
    • Scaled (to center or picked)
    • Copied and then
    • Pasted (even on different track), or Pasted reversed
    • Mirrored (reverses order of points)
    • Changed, i.e. some parameter value change, for all at once

    And lastly picked points parameters can be copied, so when inserting, new one(s) will get same values. Makes it easy to e.g. continue a bridge in air at some height or split segment (add an extra point inside) etc.

    Pacenotes

    This track Factory, shows pacenotes in editor.

    The system making them is (almost) fully automatic. This code was also challenging to write. But it proved my idea, we had already so many tracks and auto generated pacenotes for all turns were the way to go (saved an imaginable amount of tedious work if it had to be manual, also for any future edits). It is not perfect, as it sometimes does 2 turns where it could be just 1 but otherwise is great.

    There are a few exceptions. Loop types (regular, side, barrel, 2 in 1, etc) have to be set on point manually as extra parameter. There was already one to mark a loop for game camera change. Next, jumps for their text with speed are using recorded track’s ghost, which means without it there is no info and also means that values will be exact only for ES car. All others will be scaled and may not match if aerodynamics is different. And lastly some roads have invisible parts that only tweak something and we don’t want any pacenotes there, another parameter to mark them not real was added.

    Pipes

    Introduced early and quite fun. Actually easy to drive in, since they direction the car in turns when driving fast. But will play tricks otherwise with beginners.

    Also sometimes steering is needed in turns, or to counter act car inertia. And driving too fast will damage car bottom due to high acceleration acting too much on suspension (just like in loops).

    Pipes require more triangles to be smooth and have own advanced parameters for geometry in Road tab. The most difficult part here though was making the transitions. They can start from bridge or terrain road, and both have a huge difference of width vertices compared to pipe. This value has to inc/decrease smoothly and make triangles/faces accordingly. Picture here.

    Tracks with many Pipes are e.g. Infinity, PipeCoil, Pipeline, Ocean, Obstacles, Winding, PipeCurl, Pipes.

    Half-Pipes

    A pipe itself is just a value of parameter pipe for road point set to 1. This allows many other possibilities and having around 0.5 had the name of half-pipes. And few own tracks: Snake, HalfPipes, Knotted, MagicFog.

    They are also one of coolest things in the game. Are more difficult than pipes, since you can fall out of them.

    Of course pipe is a factor for each point and it can have any value from 0 to 1. E.g. 0.1 will be nearly flat bridge (with no borders) and 0.9 will give a not yet fully closed pipe.

    Since pipes were very easy, at some point obstacles were introduced inside them. More on that later in Objects section.

    On Pipe

    Introduced later in game. Pipes are difficult to drive on them (and easy inside). This happens because you can fall out easily. Being on center is crucial for straight road, but in turns finding the right place can be tricky and fun. This screen is from Industrial, a heavy and long track that has most of it driven on pipe. There is also DangerRoad which has full on-pipe drive and thus is very difficult.

    On pipe loops were probably the most difficult stunt element. It’s very difficult not to fall off and tricky to stay center until end of it.

    Jumps

    Were also quite early. But a bit more problematic for the simulation. Car suspension has to be stiff to land well and usually the tolerance of speed is narrow (i.e. too little won’t jump across and too much will land badly and roll over).

    At first they weren’t open. At some time a new hidden material (-1) was introduced and they started to look well. Shown here is one of first tracks with them. Also, notice the  spheres on ground between jumps. This was the first way and isn’t the best. Having those single points higher than jumps is better since, the auto pitch (of road) will make jump ends go straight into sky, and not turn lower like here.

    Fortunately it is easy to select both jump end points and move them up. Or select all jump segments and then: move, rotate, scale or copy them.

    This track Platforms (left) has many jumps. Version 2.6 has introduced Pacenotes system to the game. And added an extra text showing required / minimal vehicle speed to jump across. An original idea and track using it was PipeJumps (right).

    Other tracks with many jumps are: CrossJumps, TopTwist, Scorpio, Mars, JumpCrazy, HighJumps, Abyss.

    Terrain – Layers

    Terrain is using OGRE terrain component with additions from shiny material generator. Due to limits of shader texture units and using 1 pass, it can have maximum 4 layers.

    Each layer is a set of 2 textures, 1 having diffuse+specular and 1 with normal+height data. In practice an example for 4 layers would be: grass (or sand), other grass or mud, rocks, snowy rocks. The more are used the worse performance, but 3 or 4 look best. We have 6 layer tabs and enable checkboxes just for convenience.

    We have a huge number of textures (109) mainly 1k size, CC0 licensed, pack and info here. This gives a great base for the variety of our sceneries.

    There is a pick list with all available. It also fills scale. It is a very important parameter. We don’t want to much texture repeat and on the other hand we can’t have them stretched too much (or just have unrealistic size).

    Another important aspect is where the layer will appear. We can customize this by telling terrain angles range, and also height range. For example: sand at 0m level and below, grass otherwise, but not higher than 50m and additionally mountains if terrain angle is higher than e.g. 22 degrees. Layer painting is not implemented and not really needed. It would be sometimes useful though to have some manual feature. But otherwise this system saves artists time to decorate terrain.

    Noise

    Also each layer can additionally have noise, that can blend into next+1, next+2, or previous -1 layers. Each has own slider, giving 3 factors total. This allows e.g. the first (sand) layer having spots of second and third in other places, making it more unique and less repeating. Also the last (mountains) layer can have spots from previous. Example shown here on picture, from track HighPeaks.

    Blendmap

    Blendmap is the texture that will have information of how to finally blend layers on terrain. There is a helpful visualization for it (Test F9), shown on picture. When done well, it should show Red, Green, Blue colors, mostly separated (and White when 4 layers). Even if this track is flat and small and dense with grasses, it has 3 mixing terrain layers.

    Advanced

    There are some extra parameters for terrain, rarely changed. The sliders are shown in next chapter heightmap below.

    Terrain can emit light i.e. have emissive layer. This has a checkbox to turn on, and a slider for scale. It will disable normal specular light though, instead using it for emissive map.

    An example here is lava e.g. on Crematoria, Craters. Without it the look would be too dull and unrealistic. And others examples on Radioactive, Magic, Wild.

    Next, normals scale and specular power change terrain lighting as whole.

    Terrain heightmap

    On terrain tab we got parameters that setup the heightmap. It will always be square grid. But larger maps need more area. Heightmap size can only be power of two. It also decreases performance when high and additionally makes track bigger on disk. So 2048 should never be used. And if track isn’t big, 512 should be good.

    Once set it shouldn’t be changed. But there is a button on Tools tab, to half the value, as a last resort to make track have more Fps (better performance).

    Triangle size is a real number and it can be scaled freely. But recommended is the size of 1-2 meters, since if too big it doesn’t feel real when driving. The resulting size in meters (side length) is computed and shown here too.

    Terrain brushes

    Having good looking terrain means putting some time to paint it. It is like a canvas for an artist. Best to paint in each place and also using different brushes. It’s also good practice to decorate terrain more, after road is final.

    We have 4 types of brushes: Deform, Smooth, Filter and Height set. All brushes have common factors like radius (size) and intensity (strength).

    Deform can make terrain lower or higher, by factors from brush. The simplest are of course just a solid sinus circle, most effective in center and not at all on borders. Smooth brush will tend to flatten terrain in place, it was made first, and sometimes needed. Better and new is the Filter brush. Filter brush can fix all your problems (except real life ones). It smooths terrain without loosing shape, it is a filter that reduces high frequencies (noise) on terrain. Also has a parameter for kernel radius. Height brush sets a height value in place. The value can be adjusted with mouse. It can create flat place

    There are several terrain brush presets, shown here on screens. The first row is just the basic circle tools with different type, radius and intensity. The rest is various deform with noise presets. And last 2 rows have fancy regular shapes. Below each image there is a number with radius. Also hints show a name, but image is mostly sufficient.

    Terrain – Generator

    Terrain generator is a great start for tracks. Especially those big, scenic, nature tracks. It isn’t enough to just use it, manual painting gives unique feel and character.

    It is a functionality that generates noise, the size of whole terrain. Preview of it is shown in left bottom corner. It has many parameters available on sliders. Like with every slider, clicking RMB on it will reset value. The resulting noise can be moved around with offset and scaled to real heights. Clicking buttons can either Add that to the terrain, Subtract or Multiply it with. Thus multiple uses are possible. It can also ignore road, so be used even after road was placed on terrain, but need adjusting bridge ends then.

    The generator inspired creating Spikeland track and JungleCanyons.

    Tools

    Align Terrain to Road is a very useful tool. It is shown in a video here. It has own test track that demonstrates the result. The tool needs a road with selected segments. Road needs to be in air (bridge, otherwise nothing is needed). Upon using it will adjust terrain heights so it ends to be where bridge road was. Then road can go On Terrain instead of bridge, preserving shape. It also has 3 sliders for smoothing terrain a bit to the road on borders for small distance.

    Other tools available here are from top, the ability to copy various things from other track to current. On Track tab there is a button set as copy source, so once another track is picked and button clicked, we can use buttons on Tools tab to copy stuff from it. E.g. Vegetation, Sun and weather, Terrain layers, Road parameters etc.

    There are Delete buttons here too. Since there is no new track, just duplicate, you may want to delete various things like Road, Fluids, Objects for your new track.

    Lastly on this tab, we have scaling ability. One can scale whole track by factor from slider (and editbox) or scale just the terrain height. This is useful, since when driven after editing, track may feel too big, stretched out and it’s an easy fix by scaling it below 1.0. Contrary if it feels to big, above 1.0 can fix it. For compensation, terrain height can also be scaled.

    Game setup

    Game setup tab is quite new and unique. It actually has settings for the game, on this track.

    So gravity, which is different on Mars and other planets.

    New in version 2.6 of the game we have reverb sound effect on track for ambience feel. There are presets here in combobox to pick from.

    Wind is present on track Sandstorm also lesser on Twister and here is its strength.

    Damage multiplier is less than 1.0 on very difficult and long stunt tracks. Otherwise it wouldn’t be possible or too difficult to drive them until end.

    Grasses

    Grass is done with PagedGeometry plugin for OGRE. It also shows the same old approach and enforces things that wouldn’t be done today. Namely the page size. Which is a constant value used for optimizing view and reducing drawn batches.

    Main page with properties has the slider for global grass density, it’s the first thing to adjust.

    Also present here are grass sway (from wind) parameters. They were rarely changed, and added late. Smooth parameter makes the transition from road to grass more natural and less sudden. It blurs the grass density map.

    Next tab has more options.

    Here you can actually pick grasses, and see the texture on right, to check its look.

    Then adjust its vertical and horizontal size ranges (x,y min and max).

    Each grass also has its own density.

    There is a color map, picked from combo to slightly adjust final color.

    Grasses can be picked from another long colored list, that helps finding particular types. Picking can also auto set parameters for faster change.

    After change either press V twice to disable and enable vegetation showing or press Update (F8).

    Grass channels

    Grass channels are optional. But useful for different grass setups, e.g. regular forest grass and other one appearing in snowy mountain parts.

    In more detail you pick a channel for each grass. A channel has common parameters for terrain like its height and angle ranges. And other parameters for noise and road distance.

    Vegetation

    Vegetation here means: trees, rocks, ferns, mushrooms etc. Basically everything natural that repeats a lot and is automatically placed on track, basing on terrain.

    It uses the PagedGeometry component (unfortunately not Instancing) and comes from an old era, when meshes were batched on CPU into larger pages, to reduce batch count of single meshes. At distance meshes are displayed as flat billboards called impostors, prerendered at few angles and cached on disk for later.

    The key parameter in properties is density, which is global for whole track’s vegetation.

    The same page size as for grass is also here, just with different values. Also distance which is basically the same as page and impostors distance, at which trees will be flat billboards.

    Usually tweaked for each track to optimize batches draw versus triangle count. Higher size pages will create lag and make more triangles, while lower would visually switch more and create more batches.

    On next tab, individual Models are picked and and their properties adjusted.

    Main are density and size range.

    Next useful are road distance (could be e.g. higher for trees and lower for ferns).

    And the same terrain properties: height and angle ranges, where this model can appear on track.

    Lastly fluid depth allows excluding models from water, mud etc. It can allow few meters submerge.

    It is recommended to use 4 to 6 models. It depends on count, but generally more models will mean lower Fps, more lag, etc.

    As for grasses, to see the change change either press V twice or press Update (F8).

    As before for grasses, you can also  see the long pick list here for finding models. They are colored with scenery color (same as tracks) and can also auto set few parameters when picked.

    Provided here is the 3D view of rotating model. And the numbers above it are real size after scaling, min and max values. This way you can get an idea of size and compare it to e.g. real life size of a tree.

    After the density slider is the actual count of occurrences for this model on track.

    Fluids

    By fluids I mean water (mostly), mud (few types) and other special ones like acid, lava, ice.

    Here you can see the water, depth map, which is made by editor, making deeper water appear more dark and also transition smoothly to terrain.

    Fluids are just rectangular areas moved and sized by mouse. While editing depth map is disabled.

    You can also change their depth. This could allow more than one at different heights on track. I think this wasn’t used though.

    Mud has 3 basic types: slippery (light), medium and hard (dense, dark), giving different friction when submerged. Next 3 types have a modulation for direction to not be so linear.

    The most intensive fluid/mud tracks are: MudMad, MudBath, MudFlats, Swamp, Muddy, Temple.

    Solid fluids (introduced recently) are rigid and can be driven on, e.g. hard lava, ice.

    Damage can happen from lava (and acid).

    Present on tracks: LavaPools, IcyRiver.

    Objects

    Objects were featured a bit later in game and are a quite essential part of every editor.

    Static object allow placing a mesh like rock, cave, building, obstacle, statue, balloon, etc.

    They can be moved, rotated and scaled freely. There is also multi select option (similarly to road points). Allowing faster manipulation for many at once.

    Dynamic objects are the ones you can hit in game and will move or fly away. They cannot be scaled, but otherwise are placed and edited the same way.

    They have a special simulation mode in editor. It is meant to be turned on, so they can settle on the ground. Then turned off and track can be saved. This is to save the game from doing that on each track loaded. Thus game creates them all in asleep (not moving) mode.

    Shown here on screen are the lists with object types. Dynamic ones are in blue on left. Rest is static. Single ones are in white list. Rocks and caves have special, orange column. And lastly buildings in yellow. Since there are many of them, they have another short list with categories, that upon picking will fill the buildings list.

    Obstacles were introduced later by contributors and are a great way to make driving in pipes more difficult and also have some surprising sections on tracks too. Possibly for decorating too. They don’t move with road so are meant to be placed rather as last. Changing road would then require moving them accordingly.

    Warnings

    Last feature of editor is showing some warnings for things done bad or just not optimal for performance. By default checked on track save. A video shows the various things checked. Wiki page lists all.

    Those are very simple checks for performance and some tracks (that reach the graphics limits of old OGRE) can have warnings.

    Also road system, checkpoints and car start warnings are here.

    Settings

    Editor has also a tab with settings, where you can adjust e.g. minimap, camera speed and intertia, road points size, startup options, etc. Also jumping camera to track start, or predefined views.

    It also features a basic but functional material tweaker, on Settings – Tweak tab. When picked material in combobox, it will show editboxes and slider and allow adjusting its parameters in real-time. Very useful for creating new materials, fluids and tweaking colors.