Just a quick update. It turned out that I didn’t use any compiler optimizations when testing the renderer. With them the renderer is even faster. I need to do further testing on how faster, but in the meantime you can enjoy this render that took a whopping 4,500 seconds to render! Each pixel is made of 2500 samples and the ray bounce depth is set to 50.
.png)
This will be quite a short one…
So basically this works by “randomizing” the camera’s origin point. So now, when you want, it could be a small disk on which rays will originate randomly! This “defocuses” (adds a depth of field) effect to the image.
This was a very simple change. I basically just split the work (by scanlines) between multiple threads. Right now you have to hard code it into the code but I promise that I will make a UI for the RayTracer some day. Or at least a CLI. The performance gains are significant. On my CPU (Ryzen 7 9800x3d) was the render almost 5x faster. For how simple this change was, its a massive jump.
I have also linted the code with clang tidy so it follows modern conventions and google’s rules.
Also I’m a bit tired of all the balls already. So next I will look into model loading!
.png)
What a 7h this was :D
I started simple with making the UI. For now the UI is pretty simple. Just a timer, acitivity selection and a add activity input.
I wanted the app to be usable for more users at once on multiple devices. This is sadly not possible to do with a simple cookie based data storage, so I had to implement an account system with a database. This proved to be pretty difficult as I never did such a thing. The Auth was simple enough, I found a YouTube tutorial for that and all went well. I decided to go for OAuth with GH, as it was pretty simple. I will probably expand this in the future :).
Oh the db… It was not enjoyable to setup. I went with Prisma to handle the difficult stuff for me, but still, the setup was not smooth. Somehow I think I hit like everything that could go wrong :D But in the end I somehow set it up. Using the db itself for storing and retrieving data is really good and intuitive. So that’s nice.
Next I plan to refine the UI (right now you have to refresh every time you add/remove/change active activity), add some profile page, add login page and add some overview for the tracked activities!
Hi people!
I’ve been getting bored making my LMU Telemetry app, so I started experimenting with ray tracing, and its so fun. You can’t imagine how refreshing is working on a new project!
The first thing I have implemented was the camera. In retrospect it wasn’t even that hard, but let me tell you, it was a pain. Mainly because I had no prior experience with vector math. So I had to learn how to do dot products and cross products and then wrap my head around how the camera functions. Its pretty simple: there is a point in space which is the origin of the camera called the eye. In front of this eye is the viewport. The depth of the viewport is defined by the desired FOV. On this viewport, we need to know which way is right (to positive x in ppm coordinates) and which way is “down” (to positive y in ppm coordinates) so we create 2 vectors in these directions. Then we need to know where the actual pixels are, therefore we find where pixel 00 lives and the deltaX and deltaY to the next pixel and iterate over all those pixels and do the raytracing stuff, which is sending out rays through each pixel and checking what they hit!
After sorting out the camera, I have implemented the sphere! Sphere is possibly the simplest shape for ray tracing, because it has a simple formula: x^2 + y^2 + z^ = r^2 where (x,y,z) is the center of the sphere and r is the radius.
Next we need to give our sphere some material to know what color should the ray have and how should it reflect. I have implemented 2 materials: lambertian, metal, and dielectric. Lambertian is basically a diffuse material. The rays scatter in almost random directions and therefore no reflections can be seen. Metal is basically a mirror, and dielectric is glass.
I antialias the renders by basically torturing the computer! Instead of sending one ray in the dead center of the pixel, I send multiple rays with small random offsets and average them out.
And that’s basically it! I might have forgotten something but that’s probably fine. I have followed the RayTracing in a weekend book and will continue with the next of the triology.
.png)
.png)
.png)
I am slowly redesigning the app to look like the design I made. I started with the sidebar and then the top control panel. All that went well.
But then I got to the Graphs. *Oh, the graphs…
*I wanted to redo the backend for them because the
multiple-thread approach was just straight up stupid. It was a pain to develop and would be a pain to maintain. So, in my infinite wisdom, I have gone for just a simple async function. That means that right now the frontend is requesting each data point instead of subscribing to a stream.
After that, I needed to revise the frontend graph component itself. At first I just wanted to make a non-messy implementation of the old version. However, it turned out that the HTML <canvas> element is really slow.
And I mean realllllllllly slow.
So after I wasted like 2 hours trying to optimize the design with no success, I rage quit and went to watch a movie.
But I don’t give up that easily.
After the movie, I reimplemented the graph view with WebGL through Pixi.js, which wasn’t even that hard like I expected and overall had much better performance.
Well… at least after I fixed one very stupid bug.
I had forgotten everything from the first GraphView.tsx implementation, so I was just mindlessly copying over the code and renaming the variables to what I thought they meant when I first made it.
Then I got to the part which draws the lap (aka the big loop over all the points-up to 10,000 points at a time).
There was an error on one of the variables. It was the length of some array. I just renamed it to the main array length because… *what other thing would it be, right?
*Well…It was the length of the values array, which was always 1 or 2.So I accidentally turned 1 × 10,000 iterations into 10,000^2 iterations.
Somehow the app still wasn’t lagging that much.
It just took like 10 GB of RAM.
Thankfully, the new WebGL + Pixi.js approach is way more efficient, so after fixing that bug the graph rendering performs much better. It still isn’t perfect on the UI side of things but I am getting there!
Do you guys remember how I said that I will take a break ? Yeah… That didn’t happen. Instead I have made a plan for myself on how I am gonna continue in the tool’s development.
The plan Is pretty simple: Design the app in Figma, then build it! I have also made a list of features that will be added. You can find the plan on Github. You can also suggest features if you’re interested!
…oh and before making the plan I have implemented a pretty cool logging feature. Basically it records the currently selected driver and saves all his data to a file along with the lap time and date. It does this only for laps that the game considers valid (aka gives a lap time to.)
This will be just a quick update on how things are looking right now, what’s happening, and the overall state of the project.
The sole UI library is now ShadCN.
There have also been some minor bugfixes and ux improvements. The main being that the app is now working on lower resolutions.
We’ve got a readme. It’s basic, but its there. Also I have added installation instructions and released the 1st alpha version. You can find it in the releases! Both windows and linux packages are there!
I will take a break for the next few days. I will be working on a smaller project for android and I hope that by the time I return I will be full of energy and ideas!
I will continue working on the graph view. Mainly saving and loading reference laps, and overall better UI and UX.
There’s not really much to say about this. You just get a handle on the game’s memory. This was vibecoded but it’s below 100 lines of windows specific code, so I’m gonna allow it. (It was just the 2 function that handle updating the telemetry and the rest is the same.)
After adding windows support, and sending it to a friend to test, I have discovered a massive problem. The app just didn’t work on a lower resolution. Since I have a QHD monitor, I didn’t notice it.
Also when I started writing the app, I did it in pure React without any UI libraries, then I started to use Antd and then MUI and it became a mess.
So I have done some research and decided to rewrite the app using ShadcnUI. I did this because Shadcn has one massive advantage - the code that you use is in your codebase. This means that you can modify the components however you want. It is also one of the more popular ones out there. For icons, I will be using Tabular, because they have a lot of them, and I like their look.
So for the past few days I was implementing a layouts feature for the Graphs view in my app.
You can do all of that in the Edit Mode. This mode is accessible via the layout selection dropdown. In edit mode you have options to change the graphs as said, remove the layout you’re editing, to save it as a new one or to save it (basically override the last one). All of this is persistent between sessions.
Note that the UI in the screenshots is probably gonna be changed in the future and is just a development placeholder :)
DevLog 4
Today I have started implementing the layouts feature.
There’s not much to really say. The graphs can be vertically adjusted in size, their color and type can be changed and there is a whole new edit mode for that. And that’s what I did for 5h today… (I really hate frontend :D) The design of the whole thing is unfinished but hey, it works. Even though some features (mainly saving and loading layouts) are missing its turning out great. I will continue developing this feature for the time being.
DevLog 3
This one will be more about the organization of the project.
I have split up the src directory into a few different subdirectories mainly pages directory which is further split up into directories for each page and a components directory for reusable components like the sidebar.
Furthermore I have implemented logging on the backend. (It’s also callable from the frontend but that’s not that convenient at least in case of debugging so I won’t be using it as much.)
Next I have started implementing a top bar for the telemetry view. On there will be some important controls and information regarding that view.
Just note that in the screenshot the game is not open therefore the driver dropdown isn’t populated with any text. This will probably change in the future. And the layout dropdown is there just for the looks for now ;)
Today i have fixed a bug where threads would spawn infinitely. I’ve been at it for 3h… Yeah it was kinda pain.
So I basically have this architecture, where my backend spawns a new thread for each graph ( to provide information more responsibly. ) However whenever the graph element unloaded, it didn’t unsubscribe from that thread. A simple fix, just unsubscribe it, right ? Yup basically. However my lack of expertise in this kind of stuff led me on a wild goose chase. After I realized that what I am doing is stupid, it was just a simple hook that the spawn function returned, when spawning the new thread. Well we all make mistakes :D
Hi! I’m Karlito, and this is my first devlog. I’d like to use this devlog to introduce my project, explain its current state, and share my plans for the future.
The TL;DR is that it’s a telemetry tool for Le Mans Ultimate. However, many people don’t know what that means, so I’ll explain it here.
In short, Le Mans Ultimate is a racing simulator. Unlike traditional racing games, it doesn’t simply say “the car accelerates when you press W.” Instead, it simulates the engine, tires, driveshafts, brakes, track grip, and many other factors to provide a realistic driving experience.
Telemetry is a way for simulators to output simulation data, such as speed, position, engine temperature, and much more. At a lower level, it’s essentially a chunk of memory containing numbers that are constantly updated with current information.
LMU Telemetry aims to visualize these data points in a way that’s easy to understand and can help users improve their driving. It does this in several ways. For example, one feature draws real-time graphs of various metrics such as speed or delta time compared to your best lap.
The app is currently little more than a glorified demo. It has some rough UI elements and only plots graphs for a hardcoded car (index 0). While this works in private lobbies, where you’re always the first car, the system fails in most other situations.
In short, the app isn’t very useful yet, but it’s a start.
Right now, I’ll focus on getting the app to its MVP state. This means refining the UI, fixing bugs, and, most importantly, making the app genuinely useful.
Well, that was quite a long one, wasn’t it?
