Hi, i have same problem with editor.
I read the lfsmanual and i renamed the textures. I added .png and _ALP.png but nothing works. I should mention that the other 7 textures work after I changed the format from dds to png. These two don't work. Can someone help?
https://ibb.co/yWBrTBz
I read the lfsmanual and i renamed the textures. I added .png and _ALP.png but nothing works. I should mention that the other 7 textures work after I changed the format from dds to png. These two don't work. Can someone help?
https://ibb.co/yWBrTBz
If you ask me, even S2 licence has enough tracks and cars. No one so far has mastered all of them, let alone S3 and introductions of mods where sky is the limit. The collection of very good mods will increase over time, as people get more familiar and comfortable with lfs editor. Your idea is nice, no question about that, just that Scawen has something else in mind. I think we should just let him do as he feels and great things will come for LFS.
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
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
Last edited by Scawen, .
Reason : correction - the white and grey textures already exist (are not loaded)
Work in progress screenshots from the editor
Do I read that right:
The editor already has support for material types that do not work ingame yet?
Is that a steering wheel claw thingy?
The editor already has support for material types that do not work ingame yet?
Is that a steering wheel claw thingy?
Yeah, I always wondered how Eric or Scawen made all the tracks and cars back in the past. The answer is simple - Scawen made the car and track editors first. We are lucky that he decided to upgrate car editor a little bit and publish it. Same thing might happen for track editor as well. What I'm afraid of is that many moons may pass before we see someone make a track that is anywhere near as good as the LFS tracks..
I assume that is just the track editor interface used by Eric - not intended to be released to the public.
I see screenshots of the track editor for the first time, user interface is looks to be a as thoughtful for the user as the lfs editor. Cant wait for this 
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
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
Continued :
Another cool addition to this would also be the possibility to change roll centers on the car, I.E adjust the wishbones up and down by 10cm+/- to fine adjust setup, it's something you can do in the editor and I think it should be a option to have in the setup as well, it has quite a big impact on the way the cars handle, puts energy through the tires and how the chassis reacts to it.
Another cool addition to this would also be the possibility to change roll centers on the car, I.E adjust the wishbones up and down by 10cm+/- to fine adjust setup, it's something you can do in the editor and I think it should be a option to have in the setup as well, it has quite a big impact on the way the cars handle, puts energy through the tires and how the chassis reacts to it.
When you install LFS on your computer it only allows you to use demo content until you unlock the licenced content with your account details.
IIRC maximum number of unlocks was increased from 3 to 4 since the release of LFS Editor because that needs to be unlocked separately.
Hopefully this is detailed enough answer
IIRC maximum number of unlocks was increased from 3 to 4 since the release of LFS Editor because that needs to be unlocked separately.
Hopefully this is detailed enough answer
Super! More rally cross tracks with soil, or cover concrete with soil in the auto editor)
First officially licensed mod has arrived!
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
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, .
Wessex R74SP - a mid 70's sports prototype
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
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.
Mainly Multithreading, which will make the game work at a better performance.
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.
General suspensions overhaul suggestion
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.
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, .
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
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
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
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.
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.
FGED GREDG RDFGDR GSFDG