With this thread, i announce the arrival for the first officially licensed mod in LFS, the Saab 9-3 T16 4x4 from 1997.

The mod is undergoing balancing testing alongside my other 3 RX mods for now.

As soon as they all match up, all 4 mods will become public and leave WIP status.

I would like to thank the LFS dev team (Victor, Eric, Scawen and Geraldine) to make this possible and Saab AB for licensing this project.

For now, i leave the editor mod image and look forward to announcing when it will become public.

A stock 1999 Saab 9-3 Viggen is also under construction.

Greetings

Tim DC

Last edited by timdecnodder, Thu, 3 Nov 2022 12:22.

Winter is approaching and I have decided to do a sequel car to my first effort ...

By the mid-70s slick tyres were available for sports prototypes. The chassis had evolved for a wider track and there is more downforce.

The R74's engine bore increases taking it to 3.0 litres and it revs higher and so is now producing 446bhp @ 10238rpm.

I've chosen to model the car form scratch to my own design in LFS Editor (I'm still too lazy to learn Blender!). Here are some early shots ...

I started by deleting most of the old car and creating "channel sections" over the wheels (all I have to do is fill the gap between them right?!).



With the splitter added and a basic dashboard shape.



Finished wheel design (probably).



Front nearly done. I'm happy with the way it is evolving!



Chassis development is mostly done - it is great to drive and lap times are only slightly slower than the Formula V8. I will keep at it and post again as I continue to get more of this thing out of my head and onto the screen.

Cheers,
T

I think scawen is working on fixing or improving some of the major issues, before making the track editor.
Mainly Multithreading, which will make the game work at a better performance.

Quote from LUNDQUIST MOTORSPORT :

a few years laet here tho but would it be impssible to make other surfaces for concreat slabs? so we atleast can make decent looking irl tracks

Yes, but Scawen has been talking more often in the last year about the possibility of making a Track Editor, and if they do it like a mod system it will be great. We do not know plans of developers for the next updates after the release of graphics on all tracks, nights and physics. It is likely that after these updates, developers can take up a new Track Editor system, since this is the most anticipated feature by most of players according to the poll.

Dear LFS.

Since we've gotten the great Car Editor tool to add our amazing cars to LFS, I've also noticed some limitation in terms of what we can do with heave in general.

Is it possible to add a feature of a third suspension element in the cars for the future so that we don't have to run downforce cars as high as they have been in the past?

In that way it'll be easier to control, ride height as well as dynamic ride height, even though ride height doesn't affect downforce at all in LFS (/yet) certainly the ride height and center of gravity does, and I feel like FO8, BF1, GTR's are heavily affected by finding the compromise between the two, which shouldn't really be the case (especially not for the BF1).

Anyway, I don't exactly know what can be done by this, perhaps a progressive spring option or simply a 3rd element spring/damper that takes over at a certain range of suspension.

EDIT : Also perhaps adding the option of pull-rod suspension, or having certain fixed points that would pivot/rotate around a point to have inboard suspension would make the Open wheelers a bit more lifelike.

Last edited by Dennis93, Tue, 1 Nov 2022 15:32.

Today I feel like a milestone has been reached.

Until now there was a system in place so that if game code (such as multiplayer packets) needed to access D3D code, it could wait for the graphical frame to complete, then do whatever it had to do. That is because two threads must not do D3D calls at the same time as it could (would) cause corruption. One example of this system, when a player left the pits, the car's model was built. This was dealt with as described in the previous report. The car can now leave the pits immediately and the model is created when the car will be drawn. The final example was the creation or deletion of layout objects, when an incoming multiplayer packet was received. This was sorted out yesterday, so today I was able to remove that system completely (it only a small system, a couple of variables, a heavily used critical section and a warning message). The new rule is that game code is no longer allowed to access D3D code at all and therefore will never wait for a frame render to finish.

This morning I solved a related issue (where game code did access D3D) and then, after clearing leaves from gutters, I added "events" to the thread timing graph to illustrate the split car creation. As you can see in the attached image, the sync point every frame is now marked with a red triangle on the main thread. For this thread graph (which was in debug mode so things take a lot of CPU time compared with a release build) I timed one second, and called /ai to add an AI car half way through the second. You can see an orange triangle below the game thread, where the car is created. The orange block represent the processing of game packets, in this case it takes a while as the car is loaded and initialised (ready for physics).

Then, as mentioned before, the creation of the car's mesh (from editor model to game-ready mesh) takes place during the next graphical frame. The start of that event is marked by a cyan triangle above the main thread. That graphical frame takes a long time - you can see some missing sync points. But the interesting thing is how the game and physics code continue, fairly unaffected after a little catching up. I notice some longer physics frames during that long graphics frame. I'm not sure what the reason for that is but I'm not concerned about it right now.

I have crossed off quite a few more items off my note papers, so I'll start a fresh sheet with some of the last notes from other sheets and try to get through them. It feels like I'm getting near the end of the multithreading conversion.

Here's the log from Saturday to Monday afternoon:

29 Oct
Puzzling about the adding and removing of layout objects (layout editor is multiplayer)
- complication due to the fact they are changed in game code while drawing takes place
- seems easy to deal with adding objects: delay adding to draw lists until next frame
- deleting objects is more complicated as an object could be deleted while being drawn
- object buttons may be visible in layout editor (prefer not to copy all at sync point)
- one solution presents itself: save packets and delay add/delete until the sync point
- this prevents any issues with objects being created or deleted during the draw
- unfortunately it means objects may be changed out of sync with other game packets
- layout objects may define checkpoints or the existence of an autocross start point
- although the delay is only one graphical frame an OOS could arise from this
- seems quite rare, OOS would only occur with unlucky timing but it's not ideal
- possible solution for the game sync issue could be special packet for checkpoints
- in this scenario checkpoints would be worked out on host and broadcast to guests

30 Oct
Morning started with family leaf clearing session...
Implemented layout packet storage using expanding array - processed at sync point
- so this means layout objects are never added or removed during graphical render
- also solves any thread-related issues in the layout editor like selection buttons
- apparently rare multiplayer OOS potential issues will be dealt with by other means
- critical section covering graphics is no longer used by game code so can be removed
- as mentioned before there are still some calls to graphics code by game to be fixed

31 Oct
Removed system that allowed game thread to wait (using critical section) to call D3D
- it is no longer needed - the new rule is that game thread must never use D3D code
Removed issue: restart race while physics objects were moving called graphics code
- issue was deletion of graphical mesh - solution: delay deletion until sync point
- delayed delete system was already in use for moved objects returning to their spot
Cleared leaves from gutters - rain is forecast and we don't like overflowing gutters
Added 'events' to the thread timing graph - used to show sync point and car creation

This week I've been removing the possible conflicts between the game code and graphical code threads. In the case of cars I have prevented the creation of anything graphical until the start of a graphical frame. Previously car creation involved D3D calls as the graphical model was created at that point. So the game code used a critical section to avoid clashing with D3D calls during the main render (or any other D3D activity). That meant the game thread would stall for that whole graphical frame, which is not what we want. So now the physics representation of a car is created immediately but the mesh is built only at the start of the next graphical frame (actually, only when that car will be seen in your view). Sounds simple but a lot of code had to be reorganised. The picture is further complicated when you consider game packets arriving with damage nodes (when a remote car hits something) and the model needs to be dented and updated. More detail and other reasons to rebuild meshes are mentioned in the log below.

I aim to remove all graphical critical sections in the game code so it never has to wait for graphics. Today I've been puzzling about layout objects, which may be added or removed in the game / multiplayer code. It's complicated as without protection they might be deleted during the render which could cause a crash. Possibilities such as delaying their adding or removal could cause an OOS (Out Of Sync) because the layout objects may define the timing system (by use of checkpoints or autocross start) and with unlucky timing that might cause a difference in results. So I'm thinking around the possible solutions.

Here's the update log for Sunday through to Friday:

23 Oct
Mainly day off, part of afternoon looking into things that might cost a bit in graphics
- slight change of code to allow profiler and render counters in the same dev version
- considering a future update to flags to update their motion with a compute shader

24 Oct
It's autumn half term holiday - morning started with family leaf clearing session!
On the multithreading list: cars being loaded wait for graphical render to end
- we don't want waits but needed as the new car's model may load textures (D3D call)
- obvious solution is to delay the creation of the graphical mesh until about to draw
- moved some code around to allow this and removed the wait (use of critical section)
- aero physics also depended on wing positions derived from the graphical model
- changed wing, undertray, aero centre positions to come from 'editor model' instead
- notes for next day - number plate creation when car is loaded also needs to be moved
- must investigate similar critical sections in other parts of multiplayer / game code

25 Oct
Had a look at these critical sections, wondering if all "EnterD3DCode" could be removed
- ideally game code would never never need to wait for graphics code to finish drawing
- although these waits are not common, their existence requires other critical sections
- for example main thread also needs critical sections to avoid the graphical conflicts
- if all CS on game thread could be removed then they will not be needed on main thread
- noticed a possible conflict if damage is being added while a mesh is being rebuilt
- started separating the physical (wheels) and graphical (mesh) parts of car damage
- added tiny critical sections to avoid using damage nodes while adding a new node
- this type of critical section doesn't cause threads to wait any noticeable time

26 Oct
A bit of a struggle updating the car mesh regeneration and damage system
- so many reasons for cars to be rebuilt or regenerated, it's quite confusing
- e.g. damage / skin download / delayed texture load / number plate change / editors
- also delayed texture load was an added complication meaning multiple types of reload
- decided to remove that entire system (that caused 'white cars' until texture reload)
- I have a better plan for delayed texture loads (reloading without mesh regeneration)
- approach was to simplify and unify all the regeneration methods until understandable
- finally mesh regeneration is never done by game code and only in the graphical code

27 Oct
Morning with family
Continuing to work through car initialisation, moved number plate init to graphics code
Noticed tyre vertex buffer init was also at car creation time - moved to graphics code
Helmet regeneration now follows similar coding pattern to car regenerate (but simpler)
Noticed that number plate info being set in car (by multiplayer packet) not thread safe
Found crash when regenerating car - snapshot copy of wheel refers to deleted model

28 Oct
Moved graphical elements of wheel (mesh pointers and matrices) to special structure
- avoids the crash noted yesterday evening as invalid pointers are not left around
- separate storage reduces the size of wheel to be copied at snapshot (more efficient)
Only one graphics critical section remains in game code - when adding layout objects
- the reason is because the graphical mesh for a layout object is built at that point
- investigation into removing that will start now as the aim is to avoid them totally
- there are still a few more noted points where graphical code is called by game code
Noticed and fixed shader error causing skids to be too shiny (related to vertex alpha)
Fixed another shader error for names above cars (related to recent alpha blend change)
Fixed a bug about position of a car exiting vehicle editor / now uses good height check

Quote from Aleksandr_124rus :

Somereason forgot answer on that

All tracks will be updated in the upcoming update with new graphics and physics. (if the plan for splitting updates has not remained the same) And there will be new tracks in the new update. In addition, the trackeditor option replaces all new requests for adding new tracks. Because in trackeditor players can make any tracks themselves.

I have really missed all of the things you wrote ( if they really happend ) Where was it mentioned there will be.. track editor.. and plans of splitting the update?

What does ctrl+i do in lfs editor?
On both the modeller and vehicle editor it shows image not loaded in the bottom left corner, but in the modeller it makes the whole screen gray, in the vehicle editor the floor turns grey.

you crazy 🤠 Why do you use the lfs editor? And do you do it in other programs?

Three days later and I've reached the end of a shader update so thought I'd post another of these lists and a few images. Sometimes when updating graphics code I need to be careful not to break something, and that is surely the case when changing the way shaders work. So I produce screenshots from exact locations as I go, to do direct comparison by flicking between them. I realised some more of the shaders should be combined so now 24 shadowable, in game pixel shaders have been narrowed down to 9 with a few options. Actually there are two versions of each (with and without use of shadow maps) so it's really 48 down to 18.

On a day where I was feeling a bit interested in some other things I'd like to try, I felt uneasy with the number of things still on lists so made myself grind through a few fixes on paper and TODO comments in the code. I felt a bit uninspired but got more motivated as I began to cross things off lists.

During that time, another shader bugged me a bit, as there was a certain inconsistency in the shaders. Previously just one type of alpha shader had been a special case. The shiny windows shader (for e.g. the marshall boxes at Rockingham, and now several South City buildings) had previously been the only one that needed a different alpha blending state, where the source output from the pixel shader is not multiplied by the alpha value. Otherwise because such a transparent material (glass) would have a low alpha value that would remove the shine on the window, which is nearly all you can see. So in that shader the source reduction is done within the shader. But that one special case was no longer the only one, as the new shader I reported in the previous update also needed that change. But the remaining shaders didn't need to be how they were and could also move to the same method. Through a series of updates I've been able to make that the same in all the alpha shaders, so now there are no changes of blend state when drawing the alpha pass. Well I guess there are, if headlights are shining on things, but I'm talking about the majority of objects. So that cleans up the code a bit and removes hundreds of state changes.

Again, it's not a big change but I sometimes need to take a bit of time to clean up the code after some new things are added over the years, otherwise it becomes unmanageable. In this case there was a slight change to the output of other of the shaders, which was due to a change that I interpret as a 'bug' in the old system. But as it caused a slight change to the shine on transparent objects, I had to confirm that with Eric.

So I hope that's a little more insight into the way things go. It's not really related to multithreading but I don't see any reason to be on shaders next week.

The attached images show the reduction in calls to SetBlendState, through first an increase, then a bug, then the final result. They are described in the "22 Oct" paragraph.

Here's the log of updates:

20 Oct
Some other shaders with only tiny differences came to mind, decided to combine them
- now the shadowable, main world pixel shaders have been reduced from 24 to 9 total
- also there were was some more cleaning up and documentation needed in the shaders

21 Oct
Would like to try some ideas but must finish and fix a few things even if boring
Did some TODOs and fixed a bug in editor 'new car' related to storing setup in car
Spotted and fixed a bug in game setup screen that caused car to constantly reload
Fixed an already noted bug causing single player to superspeed a while after unpause
Updated exit from path editor that referenced Race - now use new style exit function
Fixed crash in game after exiting from animation editor if any AI drivers on track
Something was still bugging me about one of the shaders which seems inconsistent
- the variable shine / alpha shader effectively multiplies diffuse by alpha twice
- possible to correct this with a few changes, including a change to alpha blend state
- struggled a while with an 'impossible' bug that turned out to be a compiler error :-/
- blend state now consistent with other alpha shaders which used that for other reasons
- there is a slight change to appearance, did comparisons and asked Eric to check if OK

22 Oct
Now that alpha + vshine shader is consistent with others, improvements are possible
- there should be no need to change the alpha blending state during the alpha passes
- as seen in recent screenshots, counters can display frame state changes in real time
- D3D11 does render state changes in blocks instead of individual states as in D3D9
- state counters 'SetRenderState' and 'SetSamplerState' were left from D3D9 version
- removed them and added SetBlendState, SetRasterState, SetDepthState, SetSamplerState
- screenshots show original number of states then 1st update *increased* SetBlendState
- that is because one shader, used for trees, SrcBlend is still D3D11_BLEND_SRC_ALPHA
- 3rd image now all alpha shaders updated, so no calls to SetBlendState in alpha pass
- but there is a bug, see the distant trees, fog appears on their transparent parts
- that is due to the alpha blending change, now fixed in shader - 4th image all good
- clean up: some state requests were no longer needed, now constant during alpha pass

Quote from Benzinass :

quick question, how to toggle fogs in game? I see the option to assign them in the editor, but no clue to to active.

There is no such option currently,I assume they are in editor as future extension possibility.

quick question, how to toggle fogs in game? I see the option to assign them in the editor, but no clue to to active.

I wouldn't worry about that graphical error in the frame screen, firstly you're not meant to drag my VEH file into editor and look at that, secondly I know exactly what causes it and it's actually a crucial part to the current feel of the bike and will absolutely be staying.

The lights work, I'm no longer working around the current light system in the game. They look the way I want them to look in the editor and I'm assuming the system in the editor is what the game will adopt when the night mode update comes out. Either way lights are superficial in the game right now.

The animation system for bikes just doesn't work well and isn't worth putting much more time into. The guy moves based on the angle of the forks not the lean. I just leaned the rider forward and flared out the knees a little so it doesn't look completely ridiculous when you're racing. I have other animations that look even better racing but you guys wouldn't like how it looks when cruising.

First ride, feels pretty good, there are some shading issues and the animation isnt that great, but the feel of the bike feels pretty damn good. Idk whats with the frame bugging out in editor, as the COG is centered according to editor

Quote from felplacerad :

Not LFS, exactly, but Scawen and Eric was mentioned (and praised!) in this documentary about Black & White! 👍

Why has Black & White Been Abandoned? - Noclip Greatest Hits
https://m.youtube.com/watch?v=GtNvEna6bxc

Direct link to the segment:
https://m.youtube.com/watch?v=GtNvEna6bxc&t=348s

Thanks for the link! I watched it with the family yesterday evening. Interesting to see how Peter has changed. Well, I remember I was in my late 20s when we all went to his 40th birthday party, and now I'm 50, so he must be in his 60s now.

Nice that Eric and I were kindly mentioned.

Quote from felplacerad :

Quite a funny story of how Scawen got the job! @Scawen, is it true? 😂

That story about how we met isn't quite true though it's based on facts. That's kind of what Peter does.

In fact I did work as a motorbike courier for a company called Black & White that was based in Twickenham. But I was looking for a job as a programmer (I had previously worked at a company called Digital Integration, on the Hind helicopter simulator) so I contacted a recruitment agency that specialised in game jobs. Quite quickly they came up with this interview, with someone who I would surely admire (Peter Molyneux). Actually I hadn't even heard of him before but went for the interview as it sounded good. I rode down on my bike and had a good meeting there, in which we of course talked about my job at Black & White, which was funny as the interview was about working on the game called Black & White.

I had a nice demo (with an animated car and some people and dogs that could walk around on a lumpy landscape - actually it's the same program that evolved into LFS) so they were able to offer me the job on the spot. I said, thanks and I'll consider it. But he looked a bit shocked and said, why aren't you accepting the job now? I said, well I thought that it was the right thing to do... and actually I decided to just accept it then anyway. That was the right move as it was a very good job in the end although there were ups and downs.

Quote from mbutcher :

That's brilliant. I want to play it now

We got it running a few years ago, using a boxed game and the fan patches you can find online. Leo and Nicole enjoyed it quite a bit.

Quote from nacim :

Funny how if you look closely at the game editor at 6:00, it look really close to the original theme of LFS UI

Quote from felplacerad :

Woah, I didn't realize that at first. But yeah, it most certainly does!

...

I'm sure you can find menus in LFS that resembles B&W even more closely. Autocross editor, perhaps?

How about this attached picture from the video, you can see a creature editor I built in game, using my own buttons system that I had imported into Black and White.

Compare that with the attached image of the vehicle editor.

The early LFS in-game menu style was more inspired by Quake 3 Arena.

Quote from nacim :

Funny how if you look closely at the game editor at 6:00, it look really close to the original theme of LFS UI

Woah, I didn't realize that at first. But yeah, it most certainly does!





I'm sure you can find menus in LFS that resembles B&W even more closely. Autocross editor, perhaps?

Funny how if you look closely at the game editor at 6:00, it look really close to the original theme of LFS UI

One week later... where did that time go!

I've been doing a variety of updates including a bit of off topic into shaders that is finished for now. Some cleaning up and organising. Sometimes I add a line of code in a convenient place. Then something conceptually similar comes along and I add it at the same place. Then that happens again and again and it's taking up a lot of space in the original source file. So it becomes a new system in itself, or at least something that should be packaged in its own function, and might end up with its own source code file. This time that happened for the "sync point" which was starting to get messy right at the end of the main loop. Some other clutter from Main.cpp went along into SyncPoint.cpp too. The Sync Point is a very useful place for LFS to do things, because for that tiny slice of time, only the main thread is running and the game/physics thread is waiting, so it's a safe time for things that need safety. As a random example, suppose the user refreshed controllers. It is done at the sync point, so the controller can't be updated half way through a game update. Anyway that was really just a minor change. Randomly I noticed that I wanted to use SHIFT+J or SHIFT+S sometimes in Garage and Free View but those keys weren't available. So veered off topic a while to sort that out.

I realised there were more ways to check thread-safety and did something for the "Physics" system which manages the interactions between and updates of cars and other moving objects. I gave it a protected access function like I had done for Race and Snapshot before.

Eric noticed an issue with something involving two layers of alpha textures. I ended up solving a newly introduced editor crash and also went full off-topic for a while adding a new shader which is really for a new type of transparent window on buildings that will be useful in a few places. It can use a single pass instead of two passes which is always preferable. But it was a bit confusing at first so I reorganised the shader definitions, to the point where I got a new understanding of them and was able to come up a with a way to reduce the number of shaders. It is to help avoid a phenomenon called the "Shader Permutation Explosion" which is where the number of shaders in use can get out of hand. Well LFS hadn't got to the point of an "explosion" yet but it was bugging me that some shaders were extremely similar and I found a way to use a few options (in the form of shader constants) to produce the different effects instead of increasing the number of shaders. The attached images show the reduction in calls to "SetPixelShader" so that is a slight saving (although I couldn't actually measure a change in frame rate with such small numbers).

Another quick change solved an audio problem and got something off a list of things to do. You can see in the attached image, the audio updates (shown in yellow) occur at approximately 100Hz and are not affected by graphical frame rate. This is the maximum update rate I can get with the current system and results in the most responsive sound, even if the graphical frame rate drops a bit.

From tomorrow I plan to try and get a few more things off lists as I'd like to get to the end of the multithreading subject as soon as possible.

Here's the diary of updates.

13 Oct
Wanted to remove the last remaining old-style reference to Race, in Misc options
- needed another "must do x" in the sync point in the main loop, but getting messy
- added a new source code file for things to do at the sync point, cleaned up a bit
- removed Race from external visibility, now only accessible through protected function
Off topic update: added SHIFT+J and SHIFT+S keys to garage screen and free view mode
- this also involved quite a bit of cleaning up and improving some packet functions
- also added SHIFT+P to free view mode (SHIFT+P/J no check for unsaved layout changes)

14 Oct
Some quick fixes around cars in garage and other screens accessing Race when loading
Went through a list of source code files to check if they accessed anything wrongly
Decided to update the 'Physics' system to use a thread-safe access check like Race
- the Physics system is the code that manages all the moving objects (Cars and Solids)
- like Race it must not be accessed from the main / graphics code at the wrong time
- not a big task in this case but again identified issues and improvements were made

15 Oct
Most of morning with family
Off topic: researched an issue for Eric - modeller object appeared different in game
- after the research my version crashed when exiting from Track Editor using X button
- it turned out this was due to a new 'thread-safe' method of exiting track editor
- but the correct exit function was not called when using the window's X button
- implemented a way to provide a special exit function for any screen, used on TrackEd
- found & fixed a bug exiting from the modeller in TrackEd, related to Map Squares
- continued to track down non-thread-safe code switching into and out of TrackEd

16 Oct
Morning with family
Off topic: tried a new shader to allow something like 'overlay' but transparent
- in current version of LFS an 'overlay' shader is available for black (solid) windows
- went through code to allow overlay with ALPHA materials and added a new shader for it

17 Oct
Fixed a bug reported by Eric and checked another bug that had already been fixed
Off topic: cleaned up the shader defines that control the creation of various shaders
- many of the shaders are from one hlsl file with various sections enabled or disabled
- the organisation of these switches was confusing and could be improved / simplified
- this was done carefully with plenty of testing so as not to break any of the shaders
- it is now a lot easier to understand the similarities and differences between shaders

18 Oct
Bit of leaf clearing from gutters in the morning - house below 3 large beech trees...
Some more renaming and organising of the shader names and specifications in game code
Investigation into possibility of using shader options to reduce number of shaders
- some of the shaders are so similar with just a couple of different multipliers

19 Oct
Change to sound/audio code, sound updates are done at maximum rate of 100 per second
Previous changes resulted in 1 sound update per graphical frame which solved an issue
- the original problem was that sound updates could delay the sync point and graphics
- intermediate solution was to only do sound on the next update after the sync point
- but that was less immediate and caused poor sound quality if the frame rate dropped
- new solution: update whenever possible but delay 1ms if main thread waiting for sync
- you can see the audio updates (yellow) in the attached thread timing graph
- I produce these timing graphs in the debug version to exaggerate the CPU time
- another thing to notice is that every 10th physics update is longer than usual
- this is due to only checking for contact collisions every 0.01 second
- checking against the environment was the main CPU cost of the 1000Hz physics
- so contact points that are not currently touching wait 10 updates before next check
A new shader update combines 6 groups of 3 pixel shaders into 6 shaders total
- the idea is to reduce the number of extremely similar shaders in memory
- changing from one shader to another involves a tiny time penalty so good to reduce
- the new version uses shader constants to create the different effects instead
- these minor differences were about shine level and diffuse colour depending on alpha
- as you can see in the attached images there are now fewer calls to "SetPixelShader"
- it's not a big change but means the new shader has not resulted in even more shaders

Last edited by Scawen, Wed, 19 Oct 2022 18:53.

Quote from Flame CZE :

Ah yes, my bad. The way is to select all triangles and then click “select connected points”, then hide those.

Thank you!

Quote from Benzinass :

How to load LOD2 from file? when I try to load with LOD2 selected the the main object just gets replaced.

1 Load *.obj with lod2 (it will replace everything and became main object)
2 Save that main object from Modeller (mesh editor)

3 Load whole Vehicle again
4 Place triangles from main object to any other than first layer (must be empty)
5 Add "new subobject"
6 Load saved subobject from (2) by subobject > load

7 "merge into main"
8 Go to main object and select all triangles from first layer (that's why in (4) you need clean first layer - former subobject moved to it and now it's easy to select only lod2 triangles)
9 "add to : lod2"
10 remove lod2 tris from lod1

Hi, here's some more progress to report. Again, I'll give a short summary and post the diary of updates.

Apart from continuing to make things thread-safe, I think the most interesting thing is a new system to make sure that a good part of the game code and data (the "Race" structure which holds Players and a lot of other data, for the game code) is not accessed by the graphics code, and also a smaller system to make sure the "Snapshot" (which is for rendering 3D and text) is not accessed by the game code. Considering that it would be quite impossible to find every line of code that is accessed in the wrong way, it's a great help to have these systems that can point out such issues whenever I come across them. It also helps me to devise more ways of restructuring the code to enforce thread safety.

Another interesting thing, at least to me is the live profiling graphs, which you can see in the attached images. LFS has always had one and it helps me to see which code uses a lot of CPU, (either because it's not well optimised or maybe there's a bug there). But it wasn't working recently due to the multithreading. I did have a CPU usage issue that forced me to sort out the multithreading version of the live profiler so I could track down the bug. Now I can select a profiler for the physics or graphics thread. The nice thing is these graphs are hierarchical, so I can click on the + buttons to see inside any section. I guess you'll know what I'm talking about if you have a look at the images. The first image shows the graphics thread CPU usage and the second image shows the physics thread CPU usage.

Here's the diary of updates:

6 Oct
Most of the day on home things (not LFS)
Afternoon / evening looked into the sound updates which can be improved
- in the most recent time graph you can see different length sound updates
- they are roughly in a 2:2:1 pattern, due to sounds being updated in 0.01s blocks
- it would be better to have variable length updates that can match frame lengths

7 Oct
Looked into sound improvements, changed the code to support variable length updates
- encountered various bugs, audio code is sometimes tricky to debug (due to timing)
- final bug was with the echo, realised there is a limit to the size of sound updates
- another obstacle I found is that the audio write point only moves in steps of 0.01s
- so it turns out I can't easily achieve the aim of variable length sound updates
- improvements have allowed me to split the sound updates over multiple physics frames
- another solution could be separate audio thread but it's too much work at the moment
Looked at FF rate - although 1000Hz is possible the options display still read 100Hz
Encountered (and fixed) thread-related crash when refreshing controllers in options
Fixed bug 'Flicker on car reset' which was thread related (wrongly reset draw values)

8 Oct
Morning with family
Looked into an issue where garage screen was initialised by game code when pitting
- that is against the rules of thread-safe behaviour in LFS code
- easily solved using a message from game code to main code to enter garage when safe
Found some bugs in Escape Menu - fixed them and improved the code for future proofing
Fixed thread-related and other minor issues with the Vehicle Editor
Moved position of "AutoJoin" which is for restarting autocross in multiplayer mode
Encountered a crash when second player joins race - related to drawing car alpha

9 Oct
Morning with family
Car alpha crash was due to removal of alpha LOD reset when car reset (bug fix 7 Oct)
- fixed by resetting alpha LOD to "do not draw" when car is created (not on reset)
Came up with another check to find code that is not thread-safe
- access "Race" structure (players, results, etc) through an access function
- this function can check that Race is only accessed from game code (not graphics)
- only trouble is the Race is accessed from around 900 lines of code... get started!
- stopped for the day after updating 400 of these lines to the new style access
- quick test already showed up two bugs for a quick fix and one more to note

10 Oct
Fixed yesterday evening's noted issue and carried on with converting Race references
Actually doing the changes makes me encounter various issues to fix along the way
It occurs to me that the Snapshot should also have the same type of protection as Race
- Race is for Game/Physics code and Snapshot (recently added system) is for graphics
Went ahead with restructuring Snapshot to an access protected version (fairly quick)
- Snapshot now contains a straight copy of the Race structure, excluding Players
- simplifies snapshot creation and makes it easier to convert code to use Snapshot
Stopped updating Race references for the day with only 164 remaining to deal with

11 Oct
Remaining references to Race have been updated to the new style after 2 hours
That is excluding some code related to skin resolution on the Misc Options screen
A race condition is revealed by the new check on switching from game setup to in-game
Also accesses to Race structure while drawing text in-game are revealed by the check
Fixed the text and entering game issues / made some changes to best lap announcement
MPR testing showed up bugs on restarting replay: crashes then invisible world issue
Clicking time bar at later point in replay is sometimes slow, sometimes fast
- learned how to reproduce the slow / fast versions of replay time clicking
- difficulty finding what extra processing takes place in the slow version
- built-in CPU profiler is currently unusable as it is not thread-safe
- looks like time to sort that out and that'll be another thing off the list
- profiler now selectable graphics / physics - used it to find the time clicking bug
Stop for the day, will fix "disappearing world on MPR restart" tomorrow

12 Oct
Fixed disappearing world on MPR restart - probably old bug unrelated to recent changes
- if layout objects were there, the occlusion octree was cleared when replay restarted
- needed to repopulate octree in that case - bug probably there since octree introduced
- for more info about the occlusion Octree see our September 2020 progress report
Back to fixing code that is not thread-safe (some identified by the new systems)
Garage was using (Player in) Race to decide which buttons to draw - now uses Snapshot
Spectate/Join wrongly used Snapshot copy of selected view (should use Game original)
Check for "Join reject" (first 12 seconds of race) needed Game and Snapshot versions
Something related to tyre warmers was called whenever a new Car was created in memory
Fixed that then spent a while cleaning up Car and Engine constructors for efficiency

I downloaded it and indeed doesn't load in LFS. Not sure if Illustrator being a vector graphics editor have something to do with it, which I doubt, but you never know ¯\_(ツ)_/¯

But then I copied the image instead of saving it, pasted it in paint.net, saved as jpg and it worked. Maybe try using a different image editor (preferably a raster editor e.g. paint.net, Photoshop, GIMP, etc etc) and see if it works?

The labels next to undo & redo buttons in the bottom part of layout editor are not available in the translations file.

Texts like "add object", "adjust position" etc.



Could these be added?

Thanks


A bit more progress


Tried to fix door vents size, which took absolutely ages with the editor (and now goes across the whole length),
and abit more stuffs.


Next attention (most of) goes to interior. Started with FXO top dash for the shape base. Most probably gonna use RB4's for most of the buttons etc to make life abit easier. The rest would probably just tracing from the textures.


Aand since there's finally another A80 in the making (link, and link), should I actually keep going on this (other than having fun)?

The mod goes to be build in LFS Editor/Modeller and it's a replica of 2023 Ford Bronco Raptor.
The current progress screen's are attached.

Off topic: Will be nice if we had a option to build 6x6 vehicles in the future. @Scawen