Fixed some bugs and issues in F7 game and editor, updated to F8.

Available on the same links in first post.

Since the previous report in March there have been various updates. Most of the time I have worked on LFS but also had to do a few things outside of LFS.

I'm not sure how interesting it is but I can look through the list of updates I sent to Eric and add a few comments.


Towards end of March:

I worked on the render modes, which were kind of a mess and it took a while to reorganise the code a bit.

In the end I came up with 3 render modes: basic / SDR / HDR:

- basic: straight to backbuffer, no antialiasing / exposure / tonemapping
(good for lower-end GPU, uses exposure estimate based on time of day - not good in tunnels or car parks)
- SDR: uses SDR render targets, does antialiasing and exposure, no bloom or tonemapping
(exposure calculation is good but there is no glow around lights and no tonemapping to help with bright sky)
- HDR: visually the same as recent versions but now adding bloom and tonemapping in a single pass
(our best option for good GPU but there is a hit from the bloom processing and HDR render targets)

New system for different settings between VR and non-VR modes

MSAA settings "none" and 2X options in addition to 4X and 8X

Started to work on the Public build of the new version and had to work on the track selection screen. The limits are worked out differently now so some changes had to be made to align paths with map images.


Early April:

Retro tyre model:
FIX: Retro model was heating up tyres too quickly in longitudinal skids
FIX: Retro model could cause a crash with wheelspin at low speed
Implemented skid darkness from New model into Retro model

Both tyre models:
Smoke update - calculated only immediately (without temperature build-up)
Doubled intensity of dust (from dusty surfaces)
Removed the "skin temperature" thin edge on outer surface as no longer needed

Render modes:
Code cleanup allowed only downsize as much as needed for exposure in SDR mode
FIX: screen was sometimes not cleared for a few frames e.g. after pressing V

Vehicle editor:
FIX: Z buffer was not disabled when drawing wheel cross-section
FIX: Tyre cross-section was not shown if Retro model selected

Cars:
LX6 - restored public version tyre size
LX4 - restored public version tyre size / mass / engine power


Towards mid-April:

Shaders:
New compute shader included [think this was for the exposure histogram]

Exposure:
Dashboard brightness now constant regardless of exposure
Avoided black frames when changing views with V or TAB in game
- the black frames were while exposure was calculated on a hidden image
- now the screen is simply not updated during those few frames
Reduced overexposure after TAB/V/restart from dark place (e.g. tunnel)
- initial exposure attempt was then worked out from a whited out image
- the overexposed image didn't show the true excessive brightness
- issues are solved by targeting a standard brightness (after TAB/V)
Exposure is also reset and recalculated when switching Render mode
Exposure is also reset on entering or leaving Free view mode
More accurate histogram (now 256 bins - see in CTRL+E)

Graphics:
FIX: Corrupted lighting (normals) on 3D spectators with scale > 1

Misc:
Faster load of Octree when track is loading
Added progress percent for "Generating" stage

AI:
FIX: Divide by zero updating path for AI in EV (e.g. Formula XR-E @ BL1)


Early May:

I had some distractions in the second half of April but in early May sent another update:

VR: Avoided black frames when tabbing between cars in "TV in VR" view
Avoid debug message about DEFAULT lighting when car drawn as physics LOD
Added Misc option to show ms/frame instead of FPS (removed SHIFT+F5 key)
OPT: avoided setting main render target multiple times per frame
FIX: avoiding mysterious crash in SetForce after losing full screen
OUT OF BOUNDS now displayed if the spawn point is out of bounds
OPT: improved main render function saving around 0.2 - 0.3 ms per frame
FIX: Jittery freeview camera (graphics now synchronised with physics)


Summary:

I'm not intending this to try to stir up conversations, but more to illustrate all the small things I have to work on, in order to get the version finished. Most of these things, you (and I too) probably wouldn't think of but it takes a while to get everything ready after so many changes have been made in the program.

D3D11, HDR graphics, dynamic lighting, 1000 Hz physics, shadow maps, multithreading, non-path-based occlusion culling have meant a lot of changes throughout the program and while trying to get things finished, I keep encountering new things that have not been considered, or were thought of as "fix that small thing near the end" but then it is a bit harder to fix than expected.


Ongoing:

I still have to do some more work for certain headlight issues, add some weather options, finish building a releasable public version and whatever comes up in the meantime.

Eric has been doing some more work on South City and has to complete Kyoto Ring where there are still some holes around.

We still can't give a time estimate, we'll just keep doing the important things until it's ready for testing.

“ NOTE: This version of the editor actually uses the "RETRO" tyre model”
I mean yeah, any reason why it wouldn’t use retro physics?🧐🧐

Hello LFS mods users.

We have allowed through review a few "track mods" which use an "object" mod to represent the scenery of a track.

A small central physics object (LOD2 or LOD3) is created and sits on the ground, while LOD1 represents the scenery. There was a problem with the scenery disappearing if the viewpoint was too far from the origin.

Mod creators were able to get around this by using a hacked LOD distance, but we don't want to allow such hacks. It's better to release a fix for the issue.

At the same time, I had a note on my list for the development version about a bad calculation for the view radius of some mod vehicles with subobjects (that has become a problem since the addition of moving subobjects).

Two of these track mods have been waiting to be published and it seemed a good idea to help them and solve the view radius problem at the same time.

Now, the distance from an object is calculated as the distance from the object's bounding sphere instead of the distance from the object centre, which solves the problem. It is impossible for a lower LOD to be selected if you are within the bounding sphere of LOD1.

If you would like to join a server that has a track mod, you should use the new test patch 0.7F7 (or later) available in the test patch forum:
https://www.lfs.net/forum/thread/110607

If you are developing a track mod you should use the new editor test patch 0.7F7 available in the mods forum:
https://www.lfs.net/forum/thread/111321

Future development possibilities:

The track mod support is not very good at this time. It is a bit obscure as a player needs to "drive" the track mod and it has to enter as a physics object and settle on the ground. Our mods system was obviously designed for vehicles only. It would be nice to properly support such objects in the future, for example:

1) A new object type "solid" or "track" which does not enter physics at all and cannot move
2) Increased number of collision triangles for unmovable objects
3) Place a track mod as a layout object instead of using a player slot and start position

Examples (1) and (2) look quite easy to add (in an incompatible version) while (3) is a lot more complicated.
There is no time to develop such features at the moment. I am just pointing out that there is a possible future for track mods that goes beyond this current minor improvement. Track mods might not have to be a whole track but could be a bridge, a podium, or some other type of stationary object.

Last edited by Scawen, Sat 10 May 2025, 17:16.

Hello Mod Creators,

Here is a PATCH for the LFS Editor. Editor 0.7F or later must already be installed!

This is not a thread for random requests regarding the mods system.
For mods suggestions, use the Mods System Suggestions forum section.

This editor patch is a minor update to help support "track mods" and includes a few fixes.


Changes in Editor F11:

FIX: wire overlay was not clearly visible especially in 2D views
32 layers are now available + scroll bar and option to show all


Changes in Editor F10:

FIX: Rear caster angle can now be set in the base default setup
FIX: Avoided the jaggies on generated sky texture near the horizon


Changes in Editor F9:

FIX: Error in moving subobjects after one made invisible by layers
FIX: Object type 'spinner' was not working in Editor F8 (Test inputs)
LX4 - restored public version tyre size / mass / engine power
LX6 - restored public version tyre size


Changes in Editor F8:

FIX: View radius was sometimes reduced unexpectedly in the vehicle editor


Changes in Editor F7:

Improved vehicle view radius calculation (bounding sphere)
- LFS can more accurately detect if a vehicle is currently visible

LOD distance refers to distance from bounding sphere instead of object centre
- previous version did not work well for large objects, e.g. "track mods"

NOTE: This version of the editor actually uses the "RETRO" tyre model
- this is not expected to result in any noticeable changes in the editor


DOWNLOAD:

LFS Editor PATCH 7F to 7F11 [If you already have LFS Editor 0.7F or later]
Editor 0.7F or later must already be installed!
https://www.lfs.net/file_lfs.php?name=LFS_EDITOR_PATCH_7F_TO_7F11.zip (1.6 MB)

Last edited by Scawen, Tue 10 Jun 2025, 15:07.

Some people use LFS Editor to create the entire 3D model, others use Blender to create the 3D model, then export it as an OBJ file, which can be then imported into LFS Editor.

LFS Editor manual
LFS Editor video tutorials

Maybe it could be:

The mods stored on the server and downloaded to LFS could be in an encrypted form that LFS game can read but LFS editor cannot read.

Then the only legitimate way to load things into your editor is by downloading the mod manually in editor form (not encrypted) via legitimate means, e.g. from mod's page when it allows derivatives, or direct from the author.

Problems with this:

1) All the mods currently on the server are in editor form and not ready to be downloaded in the proposed format. So a big switchover operation might be needed.

2) As mentioned before, this type of encryption, that anyone's S3 license can decrypt, can be easily cracked. Someone would release a decryption tool for encrypted mods, to convert game-ready mods into editor mods.

I don't know if this low level of security would be enough. It's not something I'll be doing in the near future though as you know what I am still working on.

+1 with this idea, since i dont know how to 3d in blender but i perfectly know how to 3d in lfs editor, so for example i can build my own things in lfs editor, then export to obj, then put it on sketchfab for example. But in my opinion, it should be only on your own works, not derivitave allowed models made by others.

I guess I'll have to go on thinking over time, as it appears the simple function is too controversial without other security measures, but those security measures are a much more complicated subject.

Maybe it's more like, the simple function should be in there, as a simple function and without its own security measures, but the protected model itself should be prevented from loading into the editor by unauthorised people.

But that is a whole new level of complication and I don't have any time to start trying to figure that out.

I also know in advance that is the least satisfying type of work, if I ever do it, I would have to work for many hours or days implementing things into the editor, the web server, the game, and all the while knowing that hackers will easily flip the switch, undo the encryption, etc. Setting out on a task that you know for certain will fail is never very enticing.

Hello, that's my new car, designed from scratch, using LFS Editor only.

A small electric vehicle heavily inspired by Citröen AMI.

Ideal for fun races with jumps, ramps, obstacles etc

Here is a picture album showing how I approached the modelling of the car

https://imgur.com/a/aa8aTG9

You can be certain someone will quickly find a way to look at the file with a hex editor to compare a locked/non-locked version of the same mod to know how this works, unfortunately such security is weak at best. In a way however, it reminds me of concerns about code reverse-engineering: people typically want their source code to be obfuscated in their release binaries, so people cannot (easily) just grab the code and do whatever with it (this is a topic that comes about here and there in the Godot community for instance) - the goal of encryption/obfuscation is not to make it bulletproof, but rather to deter "script kiddies" from having easy access, leaving only the more experimented and willing to invest time to worry about.

In general, having some security is better than none, especially in a legal setting, so you can say "my resource was protected and they stole it" - and in that sense, allowing OBJ export nulls that argument, because any mod can be loaded into the editor.
But then again, having the ability to export to OBJ would be useful, so it's a difficult topic

obj export will be very useful but the security is the only issue here, im sure alot of other modders like me who create mods from scratch for lfs will agree that anyone can access and rip those models or sell them somewhere on the internet.

so what if we get suggestion every time we export mod for upload that says "do you want to lock this mod" if select yes then the "veh" file will be locked and if anybody try to load it on editor after taking it from game files will get an error message that says its locked.

that way the security will be enhanced and the obj export can be possible option.

Quote from HOUSSEM.221B :

or it can be allowed only for mods that have "Derivatives are allowed : YES".

Quote from Egor K :

I agree with Houssem, although it's strange that this needs to be discussed at all.

This seems impractical, I'm just talking about a simple function to export an OBJ. I can't even start to think how the suggestion could be implemented, somehow with the Editor connected online and having knowledge of where every model came from, and even track that if they saved out and reloaded the model? It's not really possible, I think.

This is only about a simple export from the modeller. As far as I know, this is a common feature for 3D software and I'm not sure if LFS Editor should be different.

Quote from Egor K :

What you're saying is like: ‘lock pics are already available, so it's no big deal to leave home door unlocked’.

I'm interested to understand what is the main concern.

Of course, LFS models can already be easily saved for reload in LFS editor.

So what is the main worry, is it that people might rip LFS mods and use them in other games?
(Although they can do it anyway but the new feature would make it easier to save a clean model)

Quote from Flame CZE :

This will also make it easier to get access to 3D models that were purchased...

Very true, It's the same with other popular free programs as they all have export ability's so I could rip / buy a model and share the original or re-exported file to others.
Actually a problem on sketchfab is this concept, you can tell the non-textured grey high triangle count models are (most always) rips from popular games.

It's a hard question to solve... A answer could be to hand select allowed individuals, and have a "dev" version of the editor that just includes exporting functionality?

It's only a matter of sharing LFS EDITOR file types between different editing programs through the site / discord for me. I enjoy the editor and others are starting there, while others are used to Blender or SketchUp, cad, etc.

We've found that people who want to steal models will find a way with popular tools where normal modellers have to resort to the ripping tools to just pull their derivative models / parts out to work in common external programs.

I've asked the mod reviewers about this but we didn't come to any strong conclusions.

I'd like to consider a simple (and limited) exporter to OBJ format, from LFS editor, that allows the plain grey model to be loaded into other 3D software.

It wouldn't export the mappings. Our type of mapping isn't supported in the OBJ format. Although I think it is possible (but not really easy to code) to export mapped models, there is no way to read LFS style mappings from an OBJ model. So from LFS editor point of view it's not worth coding to export with textures at this time.

Although I haven't looked in detail, I think it is simple enough to allow an OBJ export of the points, triangles and normals. I understand this could be useful and I wouldn't mind doing a few hours on that at some point.

So we are left with, what problems could arise? The only issue I see is that someone could load a mod in our editor and export the plain grey model, which might be a breach of someone's "no derivatives" license. The proposed export function just makes it easier to get a 3D model out from an LFS mod, to be used somewhere else. It doesn't really allow anything that wasn't possible anyway, just makes it easier.

Hello everyone, in this thread I will leave updates on the conversion and some improvements to this Maverick GT model, there are a lot of things that I don't like and I will improve within the LFS EDITOR

And also to receive tips and help with the model or with the LFS EDITOR

Original Link: https://3dwarehouse.sketchup.com/model/1284e63e-cc48-4532-8932-cdac23043405/Maverick-GT-1975

I cleaned up my PTH and SMX parsers, took this opportunity to create an SMX file for Layout Square (still WIP, I have the 4x4 km area but the ends are not 1:1 with LFS), and GodotInSim now has camera utility functions to convert a camera from Godot to LFS and the other way around; it's easy then to synchronize a camera between the two, and since this allows me to overlay Godot on top of LFS, I went ahead and modeled the layout editor objects (procedurally, because why not...).

All objects now have a 3D mesh in GodotInSim (except marshals), and you can easily have it load an SMX environment, load a layout, and synchronize the layout's state with LFS. This also enables editing a layout directly from GodotInSim, but there are currently no editor-like tools for that (whether I make some remains to be determined).

Also, one obvious caveat: some SMX files are outdated (Blackwood, especially the car park and industrial area) or missing entirely (Rockingham, and Layout Square for which I made my own replacement). It is also quite likely that South City and Kyoto will become outdated when their overhauled versions are released.

As a bonus related to my Layout Square SMX, I now have a working GLTF to SMX converter included (which, granted is quite limited in purpose, but if someone were to update Blackwood or create a mesh for Rockingham...).

Last edited by Bokujishin, Mon 14 Apr 2025, 07:28.

One is RGB, the other is RGBA.

You need to end the filename in _ALP for the RGBA to work, and you need _ALP to not be there for RGB to work.

IE, if you have an RGB image called texture1.png and you convert it to RGBA, it must be renamed to texture1_ALP.png before it'll work properly in the editor.

Could someone explain what happened to the lamp photo that it won't load in Live for Speed ​​Editor? If someone could fix it, of course the author would be a contributor to the mod.

regards.

problem with 2nd picture

Some AI racing games use that way for racing. Codemaster. EA Sports. and sometimes Beamng.drive (Depending on the car they're using.)

And Full Physics...

we can re-create Similar physics. Just Like rFactor.

They don't use the player Physics but a different Physics that isn't the same. but on track it's quite the same. but what it's the difference? They do more overtakes. More Mistakes. More Crashes. and Faster AI.

and of course for S3 Mods. they gonna keep the LFS Physics. or a Custom Made Physics which it can be made on the LFS Editor.


And About Rolling start and formation. The cars will have 2 types of System for that.

1. The normal AI.

2. Forced AI.

The normal AI will be the same as the LFS. Just driving and trying to win.

Whoever the Forced AI. will NOT apply Physics. The cars will have 2-4 Different Lines for the Rolling start. to NOT cause a crash. and after the Green flag the Normal AI will be switched up again. and the setups won't be applied until the green flag.

Why not Physics?

They probably will glitch out after spawning. and preventing crashes.

Why not Applying Setups?

Just imagine 0 Downforce. No pressure and skinny tires and scrapping suspension. the cars will go straight into the barriers. to avoid that. we won't apply Setups until the green flag it's out.

Last edited by Antonnio Giovannazi, Sat 12 Apr 2025, 02:31.

Both Macan GTS and custom got some important work especially in the interior.


Custom macan got new rims & seats:
























In editor:



















Interior for the custom macan (leather texture got changed, added alcantara texture in some parts, added colorable stitch):










a major update in the centre for both custom and gts:







changed the carbon in the interior to aluminum for the current macan gts:

Hi there , this it's my C218 from : https://sketchfab.com/3d-models/mersedes-cls-63-a6453fa2846a4d62b869aecfc0276da2

This car develops around 580 hp and 800 nm of torque.

This project was done in 2 days... I took the mod from Sketchfab, reduced it in a 3d modeling application, added the project to Lfs Editor. The reduced mod in the application had around 80k tris, and I reduced the details on Lfs Editor to 65k tris, then I started mapping, texturing the car and its details. I made a new set of rims specific to this model using a Blueprint, repaired the small holes left from the reduction of details, then started working on the handling.

This mod is a work in progress, so there will be more updates.


Rim Blueprint : https://www.oemwheelshop.com/cdn/shop/products/115102_01_700x700.jpg?v=1704353697&hl=ro-RO


(I'm not at my PC right now and I don't have access to the pictures of how the mod was created, but I'll leave here 3 pictures sent to a friend)

Last edited by Eduard.kbg, Wed 9 Apr 2025, 11:53.

https://imgur.com/a/hrqAlzh

here are pictures of the development process, all in LFS Editor

Quote from OmegaX :

the ABS pulse rate should be ~15hz

This is not possible to set up in LFS editor - ABS yes or no,no other options available to set up ABS function.

started doing a custom macan with a V8 few days ago, and that's how it looks so far:



















Nothing is done in the interior or the rims yet.

All work/modifications made in LFS Editor. No blueprints, just some references / irl pictures.



Inspired by / source: CMST Tuning

Last edited by M7md1467, Wed 2 Apr 2025, 22:24.