Great read, and interesting trick with the alpha for proper auto-exposure. I do wonder though, how does it react to viewing almost exclusively the interior of a vehicle? (especially in VR if you look down and/or to the passenger side, as that could make the whole picture alpha-less). Did you maybe try weighing scenery vs sky/interior instead of masking them out entirely?
Another thing that caught my eye is the speed of auto-exposure in the video (really nice to watch by the way, I like the whiteout at the end of the tunnel): it seems a bit too reactive at times, e.g. when driving in and out of the shadows before entering the tunnel, leading to some "blinking" of the sky; the dash also unfortunately becomes illegible, and I assume night driving will result in similar (or worse) lighting scenarios.

Still on the subject of lighting, I'm wondering what tonemapping you are using, and whether a different approach would help with the dynamic range (a popular tonemapper in games being ACES, but I would also like to suggest AgX, as it tends to look more realistic (the Godot Engine made a slightly simplified implementation that is more suited to games than the full version).

Feel free to use us as bug hunters when you can get a test patch out , I'm sure some of us would be more than willing to help beyond just enjoying the shiny update (although many would likely just complain about the crashes instead).

Last edited by Bokujishin, Mon 10 Mar 2025, 17:18.

The current file format for layouts has mostly stayed the same over the years, with some more recent additions (concrete objects) managing to include their data without changing the format.
I would like to propose updating that format to a new version, in order to give more freedom to layout makers, and maybe also make the format more future-proof. For reference, the current format is documented publicly on the LYT format page.

In the current format, after the 12-byte header, we find object blocks, 8 bytes each. I propose the following 16-byte object block instead:

Compared to the current format, we have the following changes:

• Increased resolution for X, Y, Z coordinates, as well as heading
  
• Introduction of object type, which would basically replace the current index byte
  
• Doubled flags size, to fit more data
  
• Repurposing index to serve as index numbers for objects that need those (InSim circles, InSim checkpoints could use those too)
  

Every object would be exactly twice as big as the current format, but let's see what this really means: we have a 12-byte header, and a maximum of 3,000 8-byte objects, so the maximum file size for a layout is 24,012 bytes, or 24kB (let's not get in the kB vs kiB difference here). With my proposed format, we simply double the object data size, and obtain 48,012 bytes, or less than 50kB. With that in mind, I think we can safely increase the object count limit to 6,000 and still keep the maximum layout file size below 100kB.

I mentioned increased resolution for X, Y, Z, and heading, so let's get into that:

• Currently, with shorts for X and Y, we have 16 discrete values per meter, or 6.25cm steps; ints would provide 65,536 values per meter, or about 0.015mm - no more trouble placing objects just the way we want.
  
• Z uses a byte, which translates to 4 values per meter, or 25cm steps; a short would allow for 1,024 values per meter, or just below 1mm steps.
  
• Same story for heading, a byte translates to 256 values for 360 degrees, or about 1.4 degree per step, while using a short would allow roughly 0.005-degree steps.
  

This increased resolution does come with one caveat: it makes it more difficult to align stuff, as very small steps are possible; we would most certainly need a snapping system to help here.

What could the increased flags size allow? Well I will let everyone give their suggestions, but at the very least it could allow storing values per byte, instead of trying to stuff some data on 2 bits, other data on 5 bits, and all of that depending on the object type.
We could also go for variable-size object blocks, by adding a size byte to the object header, thus storing only useful data about each object, at a small fixed cost. This could be used to make customizable signs with a text field, for instance.

Edit: Fixed value for Z steps, it would be about 1mm, not 1cm.

Last edited by Bokujishin, Wed 26 Feb 2025, 19:09.

While I generally agree with the idea, it would probably also help to have stand-in logos for those as well, since I think otherwise everyone goes for their own ideas - for the Laurent Coil Cup, I made Laurent as an anagram from Renault, and made a logo fitting the rhombus based on the L and T in LaurenT, but that's just one of many possibilities.

The mod being for your private use does not enable you to circumvent the rules, as publishing a mod, even if you are the only one able to drive it, still means that the game has to allow downloading the mod - that's where rules are meant to apply. If someone makes a mod containing prohibited content (the content itself or the source of the content), that's illegal, whether you're the only one driving or not.
If you want to make mods *really* for your own private use, you can use the "test in LFS" function - single player only, not online, but there you can do whatever you want.
If you want to be the only one able to drive your mod online, you must follow the rules.

How are the setup limits determined for mods? I tried changing the class of my Laurent Coil Cup mod from touring car to GT, hoping to allow more ARB, but it did not change anything (same when creating a new GT vehicle and giving it the same physics). The Clio's rear ARB is quite stiff because of the way the axle is made, and it can be made even stiffer for the Cup version - if my calculations are not wrong, at least, I would need to try 180 N/mm for the stiffest option, with a base stiffness of 110 N/mm; however, I cannot go past 130, so I can't try it out (currently going with 80 and 130 as a result).
Any possibility to go past that? Other mods (GT3 cars like the Protech 92 for instance) can go up to 330 N/mm, is it related to the engine?

Couldn't this be prevented by adding a good amount of damping in the end stop force? I have to admit I don't know how it's done in other software, but in LFS, reaching the end stop makes the wheel bounce sometimes pretty hard, and if the FFB tries to turn the wheel past the stop, the wheel will keep bouncing until you move it away (this can happen when stopped, typically in grass or gravel, with damaged suspension or maybe just on slopes, or when you spin the car and the wheel travels the whole range, especially on cars that have smaller wheel rotation).

Out of the game, the soft limit on my wheel (1080 degrees, configurable as with all direct drives) feels much better, it stops the wheel (maybe not as firmly as LFS does), but the force then feels like it wants the wheel to stay around the stop, instead of trying to push it away completely - I assume LFS applies a force directly proportional to how far the wheel is over the limit? Maybe a PID would help here?

Anyway that's probably slightly off topic here, but maybe food for thoughts later on.

FWIW, I experimented with using s_plate_alp for driver name and number decals - it's hacky at best, and I have only tried a single number/name combination, so I expect other values to break in one way or another.
You can see the explanation in this post about my Coil Cup mod, screenshots attached here as well.

Edit: Alternatively, having access to a transparent user texture would be nice, although I assume it would be a mess to have that in addition to skins.

Last edited by Bokujishin, Wed 19 Feb 2025, 18:03.

I've been experimenting with driver name and number as window decals - unfortunately, the game does not allow adding those properly, so I made a hacky workaround using the s_plate_alp texture instead (which by the way, does not seem to allow specifying cutouts smaller than the texture? it stays locked at 128x32 for some reason, after I set it once, and won't change anymore even after restarting the editor).

This thing can only work if people use XX YYY as their license plate, where XX is a two-digit number, YYY is the driver's trigram, and adjusting relative positions with spaces (multiple spaces are needed to prevent unwanted bits from appearing).

I *may* keep this as a separate configuration (and will probably replace the "no window paint" version with this), but I would definitely prefer having a proper solution to this (user-configurable car number, driver name, possibly driver flag, available either in s_plate (and s_plate_alp) or a new special texture - bonus points for multi-driver, or at least having the texture change on driver swaps).

Hey, thanks for the feedback! Regarding 1st gear, while I do agree it feels a bit too long, especially on race start, I am following the official specs of the real gearbox (reverse gear is even slightly longer...). You have to play with the clutch to get a good launch, but it tends to heat it up quite a bit.

Center of mass I recently moved up again a little bit as I had made it likely too low, although to be honest I do not know how high it should be - what I can say is I have not managed to roll the car on a flat straight, even with abrupt steering and playing with the brakes. However, it does indeed roll somewhat easily when going on kerbs. My main references for that behavior would be from videos of Jardier's Clio Cup season, there are 2 instances of a car flipping after being hit and turned almost 90 degrees by another car, even on a flat surface (Paul Ricard, but there's another instance at Eau Rouge, Spa), and Jardier himself had to ease the steering to avoid rolling after riding a kerb at Paul Ricard.
Also, another reason for higher CoM is to help the car go 3-wheel, but even as it is now it won't lift the rear as much as the real car.

I unfortunately have no proper reference for the turbo (what pressure I should put in LFS or how much it lags), I kept default settings here, I'll have another look at official documents to see if I can find something useful.

As for the sound, I must admit it's not really to my liking (not close enough to the real sound), I agree it could be a bit louder, I just hope it won't cause clipping if I do that.

Sorry but I will not add ABS to this car, as the Clio Cup does not have it - braking is challenging indeed, as the differential has low preload and almost no coast locking, so if you have trouble there, I would suggest lowering the brake strength and trying to move the brake balance instead. Or you can adjust the differential itself, but I chose values that try to approach the real car's behavior (you can definitely see them lock up in real life).

Vehicle mod: LAURENT COIL CUP
Details page: https://www.lfs.net/files/vehmods/DBF12E

SHORT DESCRIPTION:

Quote :

Race version of a French hatchback

COVER SCREENSHOT:

Thank you, it means a lot coming from you, as you make very high quality models yourself and especially very high quality textures plus all the tips you post as well.
Texturing is somewhat of my nemesis, I've never really had the knack for it, and that's probably why I tend to rely more on geometry, so I'll see how it goes - thank you for the advice! One thing that would definitely help with faking details with textures is normal mapping (it would be especially nice for grilles to make them less flat, but leather, alcantara and other materials would benefit as well, but I'll see what variable shine can do - I assume it's a specular map?).

Today I've also sent an update for review, the mod will be available to all since I have now fixed most issues and added more things in LOD1, and LOD2 has been overhauled (with 5.5k triangles, we'll see how this one goes). It remains WIP though as I still need to model the steering column, interior door panels, touch up on the dashboard, and detail the rear half of the interior.

After that, I plan to reorganize the model a bit (layers, subobjects, cutouts) in hopes of allowing for easier work on variants of the car - Cup is one thing, but RX and Rally5 versions are very close, then there's the road version, and I would also like to make the Rally3 version, so if I can keep a single model for all of those, that will help. All versions would be separate mods rather than configurations, though, as even RX and Rally5 have different masses and weight distributions, in addition to a slightly less powerful engine, and there's also the copilot for rally versions.

Bonus screenshots: finally started working on tail lights this is how they look in the updated mod, still WIP but already better than what I had before.

Last edited by Bokujishin, Mon 17 Feb 2025, 18:29.

I finally fixed the windows (side, rear and windshield), no more holes there either. I also continued working on the interior, adding some details with accessories (footrest, brake pressure limiter and gear stick support), and started playing with adding the safety net too.

I'm honestly worried about hitting the triangle limit now, I'm almost at 62k triangles, and the seat is very very rough, I still don't have a proper interior, especially around doors, the dashboard is still somewhat incomplete on the sides, and I would like to add the fire extinguisher behind the driver seat too.

I may try and optimize some bits, but not sure how much I'll be able to save. How does everyone deal with details? How much can we get away with oversimplified geometry and some proper texturing?

Here's a link to a first release on GitLab: https://gitlab.com/Cykyrios/lfs-setup-validation-tool/-/releases/0.1.0
Feel free to try it and tell me if you have any issue.

For info, I made the batch validation output a text file, so you can actually see the results
You can also set the path to the RAF folder if LFS is not installed at its default location (note that for Windows paths, you need to double the backslashes), you will find the config file for that in the same place as the default path for loading setups (%appdata%\Godot\app_userdata\LFS Setup Validation Tool).

Lovely texturing work!

I made a GUI tool to create offline setup restrictions, that you can then use to automatically validate setups. The intended use is to have drivers send you their setups, so you can batch validate them, which should simplify limited setup races and championships.

The GUI is mostly a reproduction of the setup tabs of the garage view so it's easy to find values. Each setting can be clicked to choose a restriction (unrestricted, fixed value, list of specific values, or allowed range). If the currently loaded setup has values falling out of the restrictions, those will be highlighted in red (restricted fields are highlighted in gold).
The batch part goes through all the setup files in a given directory and simply prints the loaded setups and whether they have any invalid values.

Ideally, I would also like to have an InSim counterpart that can display the restrictions while in the garage view (client side or maybe server side), but I'm not yet sure I'll do this.

I'll have a GitHub repository and binary releases up in the next few days as time allows, in the meanwhile any feedback is appreciated!

Quick note on some caveats: To make this easier to work with, especially in the final drive tab, I am loading the car_info.bin files from the LFS/data/raf directory, which allows me to have the correct differentials, gears and (as a bonus) tyre sizes displayed. Unfortunately, disabled systems cannot be hidden (handbrake, ABS, TC when not allowed in the vehicle itself), unless maybe this can be found in the .veh files. This does require the car_info.bin file to exist, which can be done by pressing O in the garage view. The RAF directory is assumed to exist at C:\LFS\data\raf on Windows and /home/$USER/.wine/drive_c/LFS/data/raf on Linux, I will probably add options for this later on.
All values are interpreted as floats, this is generally not a problem, but requires typing 0 or 1 for off/on (ABS, TC). Differential types, tyre manufacturers and compounds go from 0 to however many values they have (e.g. 0 means R1 tyres, 7 means knobbly tyres).

Last edited by Bokujishin, Tue 11 Feb 2025, 22:25.

I would like to suggest implementing reverse Z depth to mitigate z-fighting visual artifacts that can be observed in the game.

For the non-technical people reading this, this simply means less flickering of geometry that is very close to other geometry: concrete objects in custom layouts, lines and arrows on the ground (which seem to be placed about 1mm over the ground) and other such graphical issues.

To give a few actual examples:

• South City, behind the grand stands across the main pitlane at /cp 20174427 4722383 9957501 19884 15474 0.0 60.0 - any time you move the camera, you can see the arrows flicker.
  
• Concrete parts: place a few concrete slabs next to each other, with some intersections, and you will also have severe flickering.
  
• In the Laurent Coil Cup mod I'm working on, I chose to have the sunshield as separate geometry above the windshield, because I need some of the windshield's geometry to be double-sided (the black part on the edges), and I also want to use the same windshield for the non-cup version, which doesn't have the sunshield; I need to separate the geometry by over 4mm to stop z-fighting from being visible in long-range shots, but in closeup shots you can actually see that offset.
  

This is currently alleviated somewhat by offsetting the geometry, that's why the arrows and other markings on the ground are slightly above it (if you go to /cp -6264565 6547061 674862 -30063 4209 0.0 60.0 in Blackwood, you can actually see that offset for the pit boxes through the camera's near clip plane). The racing line darkening, as well as the thinner lines visible on Blackwood especially, are actually offset by several centimeters! (/cp 756993 -11233401 -6824 -3991 3694 0.0 60.0)

There exists an efficient method to fight this, called reverse Z depth, which I believe is not currently used. Here are a couple links to articles talking about it and its implementation: NVIDIA article, example and additional links
This technique should have little to no performance impact, but should greatly improve the z-depth sorting, which would reduce graphical glitches and maybe even allow for less geometry offset.

Last edited by Bokujishin, Sun 9 Feb 2025, 22:12.

21/Read & Understood

I was thinking about this again, and came up with related features on the InSim side:

• we should be able to retrieve this info (either as an addition to IS_NPL or a separate packet, IS_NPL doesn't seem to have much spare room for this)
  
• an action should be added to IS_JRR to refuse a join request if the selected number is already taken by another car
  

Dashboard update: now mostly hole-free! Yes, even the vents are air-tight
I still have to model the ends of the dashboard on either side, and fix the transition from the dashboard itself to the vents.

In addition to the license plate (and its textures s_plate and s_plate_alp that we can use for mods), it would be really nice to also have a way to add a number and a name (I suppose max. 3 digits and probably around 15 characters for the name (or whatever number fits the variables I suppose)), with associated textures s_name/s_number and s_name_alp/s_number_alp, so we could display them on mods without having to rely on adding a special spot in the skin template. Not only that, skins do not support alpha, so we cannot put name/number on windows without making the surrounding region opaque.

Since event signups were just recently updated, and we can choose our number when signing up, it would make sense, at some point, that said number actually be used in game (and automatically assigned if you signed up for the event?).

Most frequent use case for racing, if I'm not mistaken: name and/or number displayed on windshield, rear or side windows, and/or on the dashboard.

EDIT: I might as well ask for driver flag as well, since it's pretty common to see it next to a driver's name, and the game already has those flags.

Last edited by Bokujishin, Sat 8 Feb 2025, 14:59.

I worked on LOD2 since I was basically using the version you can see in my first few posts up until now, and now I'm actually done with LOD2 before LOD1

I ended up with about 5.5k triangles, I hope this won't be considered to be "very high"... To be perfectly honest, I would really hate to lower the count down to even 2k, as it would completely destroy the visual fidelity of the car - with 5.5k, I basically cannot see the transition to LOD2, which is the second purpose of levels of detail, after optimization. Below 2k or even 1k triangles should, in my opinion, only be for a third visual LOD (not the one LFS uses for collisions).

Anyway, now I need to get back to modeling the interior (mainly missing air vents on the dashboard, then I can add some detail on the tunnel and the back), and iron out some details on the exterior (properly plug the gaps here and there, refine some rough shapes, especially on the front grilles, and those pesky tail lights).

GodotInSim v1.5 is now available on GitHub.
It updates the AI control packets following the changes in LFS 0.7F5.

You can also check out this very serious project using those packets and a custom mod.

Having that IS_RAI definitely makes sense, instead of having to poll the state manually.

Regarding the gear error, I can get the "Avoided GEAR_REVERSE" and "Avoided GEAR_FIRST" messages in my own car, with a sequential gearbox, by staying in neutral, not pressing the clutch, and quickly pressing shift up and then shift down while still holding shift up (and the other way around for the other message); I have never encountered such messages in other situations though.

Scawen was quick to release 0.7F4, so I made the "final" version:

The indicators are blinking to the beat, 2 columns use flash and do have some blinking artifacts, and there seem to be some wrong pixels here and there, but I won't worry about this, my main objective is complete