Following on from the Progress on Multithreading thread, here is a new thread for occasional updates, for those who are interested. It will be of a quite technical nature and mostly point form, a bit like a change log.

A lot of people were interested in the multithreading progress despite the extreme detail and a lot of technical stuff. It helps to understand a bit how one thing leads to another so nearly every task seems to expand more than the original intention, and any time estimates are usually too optimistic. It can give some insight into the reality of game development which again is interesting for some people!

Like the previous thread, I'll keep it closed as I'm not asking for advice and don't want to get bogged down answering questions. There's too much to be getting on with. The style of this new thread will be a bit different, as I won't write a daily diary but more a roughly sequential list of updates.

Eleven days since the last report, here is some more progress. Not much on multithreading but a couple of thread-related bug fixes. This period started with some work on the skin downloads which now work more smoothly and with a smaller glitch when the texture is applied to the car.

More interesting was an increase in the number of available objects. I had to overcome a technical limitation that object indices were 16-bit numbers, for historical reasons, which meant there was a hard limit of 65536 objects in the world. Objects mainly include actual objects, track cross-sections (we call them simply 'sections') and the segments that link sections, with curves and surfaces. Also flags, marshals, trees, and abstract objects like cameras, start points, grids and pit zones count as objects too.

The new South City has been getting close to that limit and I wanted to add a few more, which were related to an improved way of timing laps. Now that timing can be done to an accuracy of 0.001 seconds, the old path-based timing really wasn't up to the task. The path nodes don't align perfectly with the visual finish line which could give some strange results if there was a photo finish. To be fair these new checkpoints would only add 20 or so objects to a track but when I mentioned them to Eric he did talk about the shortage of object slots and that's why I decided to get down and sort that out. Actually it turned out not to be too bad, as in recent years the obstacles preventing me from changing to 32-bit object indices have been removed. Primarily it was the old 'optimiser' data that switched on and off objects as you drove around the track. It was huge data but now we use an occlusion octree that works in a different way and does not store the indices of individual objects.

There is more explanation in the log below. To illustrate the checkpoints update I have attached 3 screenshots. Because timing no longer relies on paths, it is interesting to note that open configs can now naturally do lap timing even without custom checkpoints being added. Paths still have some advantages such as instantly updated race position list and the colour coding for other cars on the small map, and these functions still work on configurations that do have a path.


Log of changes:

Skin downloads are now converted to DDS and saved from the download thread
- this reduces a graphical glitch when a skin is loaded onto a remote car
- simplified some texture loading code that was mixed up with skin saving

Cleaned up more code around texture loading and skin downloading
- the car's model is no longer rebuilt after its skin is downloaded
- instead the car holds a placeholder skin which is replaced behind the scenes

Support for ALPHA in section ends (tracks are made of segments between cross sections)

Fixed crash bug in the unused texture removal system (could remove some still in use)

Noticed a thread-related bug to do with setting the exposure while restarting
- game code does an 'illegal' D3D call that can cause corruption

Separated "set up lighting" into physical and graphical sections to fix the bug
- considered that this section of code has not yet been separated properly
- the physical part should be done every physics frame (sun could affect physics)
- graphical part needs to be done every graphical frame (shader constants, etc)

Realised that Eric was spammed with too many code-related debug messages in editor
- added a debug level option so he can see more relevant but not excessive messages
- used special macros to simplify the adding of messages for 3 different debug levels
- searched for and updated around 600 debug messages to use the new switchable system
- removed obsolete messages, e.g. a config without a defined path is valid these days

Encountered a thread-related crash, again during restart (clash with drawing humans)

Fixed a zoom bug in one type of trackside TV camera (probably was there a long time)

Removed another thread warning message that appeared in track editor (on undo or load)

Made car ambient shadows, lightmap lighting and headlight effect work in track editor

Considered a new timing system that uses proper checkpoints like in the layout editor
- existing timing is based on path nodes and is misaligned with visible finish lines
- Eric mentioned a concern with the number of objects in map approaching a hard limit

Converted object indices to 32-bit to increase the number of objects that can be added
- previous 16-bit indices only allowed a maximum of 65536 objects to be added to a map
- number includes objects, buildings, cameras, track cross sections and segments, etc.
- in the past the occlusion data relied on object indices and took up a lot of memory
- now we have a totally different occlusion system that storage issue no longer exists
- it took only a bit more than a day to update the remaining object indices to 32-bit

Moved onto the new system that allows accurate alignment of checkpoints and finish line
- started by analysing all path nodes over marked track segments to detect checkpoints
- this produces many checkpoints, often duplicates, e.g. a finish line for every config
- the duplicate checkpoints are combined and config switches enable them appropriately
- this leaves fully working checkpoints that Eric can adjust to improve accuracy
- worked on the editor side of it (the checkpoints are a type of invisible object)
- on the driving side, checkpoint detection use existing code for layout checkpoints
- timing is no longer path-based but paths have uses, e.g. instant race position list
- interestingly open configs can now do timing even without adding custom checkpoints

Another week has passed and I've got rid of some more sheets of paper. The bulk of the work was allowing textures to be loaded gradually after the car's 3D model has been built. Initially it was necessary to allow number plates to be updated without rebuilding the car, for the case of a player changing their number plate while their car is on the track. Sounds obscure, but it was the last case of the car mesh being fully rebuilt while already in game. The trick was to keep a different slot for each player so the text on that slot could be updated at any time, so the number plate can change without the car model even being notified.

More obviously important was a system to allow the textures to be loaded in a delayed manner after the car mesh is built. In recent versions, a remote car's model is built only when the car comes into view, but there is a slight glitch at that point (as there always has been). I've now reduced that a lot by initially using existing special system textures for white skins and grey textures, if the texture isn't already in memory. Then the textures are loaded in subsequent frames, one by one. That doesn't take long so now if you see a white car, it won't be for long, and the glitches will be less than they were before.

It probably doesn't sound very exciting but to me it has been quite interesting to see cars loading quickly then their textures rapidly appearing over the next few frames. But I've changed it so when you load a car in the garage or click on someone's car in the game setup screen, it is always an instant load. Also when entering the game in single player or a replay the cars can be fully loaded before presenting the first frame. But for multiplayer we want to get in there as fast as possible as all connected players must be in sync. So in that case you can see cars appearing sequentially (nearest first) then all their textures are loaded and finally the number plates update. It's a better feeling than the long hold on a black screen when everyone has clicked ready.

It seems like most of my immediate notes are going to the paper recycling now. I have to do something to separate the light direction into a physical side (could be used e.g. for track temperatures) and a graphical side. In future that could relate to other weather features. Just like everything else, the physical side needs to be updated by game code and the graphical side will represent or approximate that visually.

A few other things to do and a few bugs to fix, to give me a clear head then maybe I can look at some tyre physics and reassess that, figure out what needs to be adjusted or finished to get nearer to the long awaited release.


Log of changes:

Improved editor colours when showing grids, pit zones, start positions, checkpoints
- makes it easier to find checkpoints as they need to be adjusted on all tracks

Reduced size of vertices sent to GPU by using more efficient storage for normals
- this helps memory bandwidth when drawing each frame and reduces memory usage

Adjustment to number plate system to allow plate to be updated without rebuilding car
- although a rare event this was the last remaining use of old car mesh rebuild system
- previously used to rebuild after a skin download or after pit-out glitch reduction
- now the text can be updated on the number plate texture without car being notified

System to delay loading textures all at once when the car model is built
- this is to replace the old pit-out glitch reduction that had to be removed
- it was never very nice as it resulted in white cars until your own car stopped
- new system creates texture objects in memory initially using a grey system texture
- after the car is loaded, every frame just one car texture is loaded (if not already)
- it was simple enough for the standard dds textures (but complicated a bit by mods)
- more confusing is the use of skins / skins_dds / skins_x / skins_y / mod skin folder
- the trick is to store all settings that control texture load, in the texture object
- changed the temporary texture for skins to white (looks better with user set colours)
- the temporary texture for all other textures remains grey which seems to work well
- number plate textures not updated until next frame after the last texture is loaded
- now car load, model build, texture loads, number plate creation all done separately

Fixed off topic bug: With some vehicles, exposure was noticeably wrong on entering game
- turned out that driver was not created in car setup but only when vehicle first drawn
- so eye position was not available in advance of first frame (used a default position)
- in some vehicles this could put the view in a dark place so exposure turned right up
- a result of exposure adjusting to output image + recent changes to car initialisation
- exposure usually adjusts gradually but it goes instantly to the first frame exposure

Back to the pit-out glitch, the worst remaining glitch is creation of the car model
- much reduced as it does not include loading textures (because of the recent changes)
- more of an issue could be when more than one car model is built in a graphical frame
- for instance turning last corner into pit straight, after some cars joined the race
- seems it should be possible to only allow creation of one car's model in any frame
- this would spread the stutter over a few long frames instead of one really long frame
- tested this by enabling it when entering game - cars appear one by one up the grid
- it's a good test - cars can appear individually then textures appear individually
- now the thing is to stop it happening at times like single player grid or in garage
- nice for me to see the delayed load but it's better not to see that when not needed

Another 12 days have passed and some of you may be interested to read the log. The super short version is I've been fixing things, doing things that needed to be done, getting rid of lists of things to do. I'm trying to get all the important things out of the way ready to focus on tyre physics. Things that are less important, I plan to do after the release (apart from the odd thing here or there that I simply feel like doing).

The attached images show what tyre smoke looks like in a tunnel with and without a lightmap!


Log of changes:

Some small tasks to finish the delayed texture loading system
- updated per-frame task sequencer so if a car model was built a texture is not loaded
- renamed / reorganised some of the new functions to make more sense when reading code
- prevented delayed texture loading in modeller and vehicle editor (prefer instant)
- fixed single frame with headless driver standing up when exiting animation editor
- the option to switch between compressed and full skins now uses new reload system
- used MP replay to test switching between high and low resolution auto-download skins
- added critical section to make sure DDS saving cannot coincide with loading DDS skin

Spent a day on Fern Bay in the editor - various fixes (not creative work)
- unlike other tracks, Eric does not plan major Fern Bay updates in the near future
- there were shadow holes due to buildings and footbridges without top surfaces
- as an old favourite I wanted to see it in good condition suitable for release
- it's good for me to spend a little time in the track editor occasionally

Fixed minor issue: players joining in entry screen could trigger texture purge events
- host and guests did a quick load and delete of the new player's car to check setup
- as this car was loaded in "in-game" mode it would trigger a check for unused textures
- but cars no longer point to a setup in the player so this seemed to have no purpose
- so instead of preventing the cars triggering a texture purge, simply avoid this code

Off-topic interface update: Provide a left and right arrow for multi-state options
- it bugged me that to switch off replay saving I had to pass through an extra state
- now I can simply click left arrow to switch off saving / right arrow to enable
- the arrow button is greyed out if you reach the last option in that direction
- the 'greyed out' logic was easily applied to option slider bars so did that too
- tempting to do it for the integer nudge buttons but would have to change all calls
- too much to do so will forget that until the inconsistency bugs me in the future

Some development version updates
- new feature to help search for textures in the editor (in objects and world mappings)
- fixed system to load most recent version of a track for a lesson (not exact match)
- update to allow replays to load most recent version of a track (or currently loaded)
- fixed a thread protection notification exiting from editor using the window X button

Training lesson fixes
- fixed start time of training lessons which were always at midnight on 1 January 1601
- fixed some small issues around loading tracks that triggered thread warning messages
- fixed a "Game call from main thread" thread warning message during training lessons

General fixes
- fix for a thread protection notification when LFS does a full D3D recovery
(I have not seen a D3D recovery other than by deliberately forcing it to happen)

Fix for a problem noticed in MPR but would affect multiplayer generally
- symptom was a puff of smoke when clicking timeline to a certain point in the replay
- took a while to track down the cause (depended on where car was before fast forward)
- related to tyre's 'previous ground position' which is compared with current position
- this previous position was wrong if car was at a different angle before pos packet
- this has very minimal difference if pos packet is for a car that is currently viewed
- bigger difference if moving to a car that has not been viewed (physics not updated)
- solution is to get a good estimate for previous position using velocity and rotation
- testing shows that car velocity gives a good estimate so will leave out rotation now

The problem described above took me into angular momentum, rotation, position updates
- some things were still waiting since the 1000Hz updates (on my notes for months)
- now there is no sub-update, some things can be rearranged a little (for accuracy)
- a position accumulator is needed for low speeds (to avoid a 'minimum speed' issue)
- seems good to be pulling me back into physics as the tyre updates are waiting
- converted old variable FloatPos (was related to sub-updates) to position accumulator
- now super-slow speeds are possible and car cannot be stuck on 'digital rails' (xyz)

Have noticed an issue for some time - physics objects resisted starting to move
- seems to be related to 1000Hz update: object velocity not fast enough after 1 frame
- fixed by reducing the speed at which an object is considered to have started moving

Cleaned up code from recent changes / discarded finished notes / browsed old notes
- copied a few things from the old notes onto a short list of tasks to do for release
- although we are still a way from there I want to know what remains other than tyres
- random OT: made arrow keys work to move between options screens (seems like should)
- old notes reminded me that smoke particles do not pick up lighting from lightmap
- the lightmap stores info about artificial light and sky visibility, in an octree
- that means smoke looks black in the night and also too bright in tunnel during day
- made smoke particles read lightmap - see the attached images for before and after

After a longer gap than usual there are a few things to report.

Soon after the last report, after fixing a few things that were sitting on lists, I added a new type of object that can be used in the track editor to connect up other objects more easily. Instead of the usual cross-sections connected by segments (with curves) this new system allows the simple addition of triangles. As if in the modeller, but between different cross-sections. It's hard to explain but it does simplify tasks by making it a lot easier to fill odd-shaped holes!

After my day of fixes on Fern Bay, Eric decided to have a quick go at it, really just fixes for the new lighting system. There were still some holes to fill, which are important for shadows, and he wanted to add some shine (specular effect) to the roads. He updated a few textures here and there in addition to the road surfaces but did the bare minimum of modelling. As stated before, there isn't time to bring Fern Bay up to the modern standard before the coming release, but it was certainly worth a few days tidying up.

After Eric sent me the update, I noticed a few remaining issues that I could improve with the use of new editor functions that I quickly coded. It is useful for me to spend a little time in the track editor because I often think of a few new functions or improvements to do.

Trying to get things finished can be a lengthy process! After the Fern Bay update we ended up taking on an extra task, almost by mistake. Eric wanted to update some of the layout objects which looked quite tired and old. His plan was just a few days brushing up a few objects. Quickly the task expanded and we started to make use of the new mapping configuration and monochrome colours system, that help maintain variety in the track editor, now extended to the layout objects. With a single object selected there can be several variations on the texture cutouts that are displayed. There was community involvement and we took on some of the ideas. There are definite benefits, so it was worth a week on the job. Even if that week turned out to be two weeks! We're near the end of layout updates for now!
Public thread about layout objects: https://www.lfs.net/forum/thread/101752

Eric and I have discussed the need to try to get to the release and only do what is necessary from now on. We want to do a lot of things but they can be done after the release.

On my side I have another day or two on layout functions, and there are some editor features to look at that could help Eric complete South City. Sometimes when buildings follow the edges of existing roads they can end up quite complex and bring up issues that can be made easier by certain new editor functions. I enjoy doing editor functions but of course, I am trying to get off graphics to finish the tyre physics and get to that public beta as quickly as possible.


Log of updates:

Layout marshals also needed to pick up lighting from lightmap (objects already do)
- marshals are done a different way and do a single lightmap reading when first drawn

Improved track editor function for setting height of multiple points
- also generally updated initialisation of text entry to the new style in a few places

Added a new type of surface that can be added in the track editor
- an extension of "section end triangles" but now can connect to other cross-sections
- as arbitrary triangles between track objects they can make it easier to fill holes
- turned out this is was a bit more work than expected in the track editor
- when objects can refer to others a lot of care must be taken with delete functions

Fix: track editor bug - surface properties were not updated correctly when changed
Fix: a physics surface debug display was not using the thread-safe copy of wheels
Fix: suspension diagram was also not yet updated to use thread-safe variables
Fix: time could move on up to 30 sec in track editor then car would catch up on exit

Eric sent a minor update of Fern Bay with specular lighting added to road textures
- other small updates as well including filling all the holes as seen from above
- although it's not a full update these are important fixes for the shadow system
- also improved a few textures around that needed brightening up in addition to shine
- the general effect is improved as you can see in the attached screenshots

I spotted a few remaining Fern Bay issues and went into the track editor to fix them
- changed/added editor functions that helped with searching/updating multiple objects
- a benefit of me spending time in editor is I sometimes come up with useful functions

Eric started to do a quick update on the layout objects that would take a few days
- it is not really the highest priority but seemed like a quick improvement at first
- job got a little bigger as we added support for selectable "mapping configurations"
- these, along with a colour selector, allow more variety without more object slots
- so we can have e.g. more signs or cone colours using the new improved objects

Discussion with Eric about the new world triangles hole filling system
- it can help fill holes in South City, either large holes out of town or small holes
- Eric showed me some of the challenging things at South City to finish in a good way
- looking at the real situations that come up, we thought of some helpful improvements

Worked on the updated (and new) layout objects
- asked community members if they had suggestions for a few useful objects
- some useful things came from that thread: https://www.lfs.net/forum/thread/101752
- using the new mapping configurations and monochrome colours, more variety is possible
- with a single object selected, multiple configurations can be chosen (e.g. letters)
- in the screenshot you can see most of the new objects but not showing all variations

Degats has kindly generated comparison shots between old and new Fern Bay!

https://imx.tc-g.uk/fe202212/01
https://imx.tc-g.uk/fe202212/02
https://imx.tc-g.uk/fe202212/03

Thank you!

I know a lot of people would like to hear more progress.

I've been working on tyre physics but I'm not ready to do a proper report yet.

Just to say for now that a tyre model may be broken into:

- carcass model
- tread model
- friction model

The carcass model is about how the tyre's structure and pressure affect the output forces depending on the state of the wheel. I can use my simulated tyre carcass (non-realtime) to see how some of these forces vary. I've been making changes to the in-game realtime model to more closely match the simulated tyre.

I don't claim that the simulated tyre is an extremely accurate model of a real tyre but it does give an insight into distortion and deflection and how that changes with tyre proportions and pressure.

I'm experimenting, adjusting and thinking a lot so will report some results eventually!