i mean i fixed it, and updated it almost 2 hours ago, but somereason LFS dont have it...and new version not published
Did you receive an email from lfstech?
Something like this: "LFS Vehicle Mod - name_of_the_mod - status update: REQUIRES CHANGES"
Something like this: "LFS Vehicle Mod - name_of_the_mod - status update: REQUIRES CHANGES"
Im am not into mods at all, but maybe updates need to be approved before being visible?
Yeah, I was just been dumb and forgot to check the second config where the polygon limit was exceeded
This was the first time for me so I didn't understand what happened.Mod published.
Changes:
Changed dashboard to more bright colors and new icons.
Removed all errors in mesh.
Fixed some mappings.
Changed rims to fit in limits.
Changed some mappings, added more dark points (on steering wheel and dashboard)
Changed engine sound.
Added muffler animation.
Fixed lod2 skin mapping.
Changes:
Changed dashboard to more bright colors and new icons.
Removed all errors in mesh.
Fixed some mappings.
Changed rims to fit in limits.
Changed some mappings, added more dark points (on steering wheel and dashboard)
Changed engine sound.
Added muffler animation.
Fixed lod2 skin mapping.
Awesome car! really good model and chassis.
Thanks, I updated the mod a couple more times to finally fix the rims and dashboard.
It's a very nice looking mod but I have been wondering what causes the slowdowns when watching on Simbroadcasts. My investigations are not complete. I'm stopping for the day but have some observations. It's not all about the number of triangles.
Incorrect setting "Concealed driver" - this should be YES - absolutely this vehicle has a concealed driver (it's not a motorbike or a kart). This one setting appears to waste around 3% of CPU with 32 on the grid.
By the way, "Wheel visibility" should be "inside covered" though I think this is only for looks now. It's not an open wheel racing car, so this will produce a better lighting effect on the wheels.
Another graphical cost is lack of texture sharing. For example the wheel objects are slower to draw than they could be because the alpha cutouts use 3 different textures. The 3 different transparent textures should share a single texture page, so LFS does not have to waste CPU time instructing D3D to switch between textures (texture switching is slow). If you set this right, then when drawing wheel alpha, instead of 3 texture switches and 3 draw calls, it would do a single texture switch and a single draw call.
There could be similar case in the main object (or other subobjects) but I haven't looked much. I do see an S and a backwards S using the same texture but flipped. Can't you use the same texture but flip the cutout?
Of course "repeating textures" cannot share a texture page. But some other textures can, and this can avoid switching between textures during the render of the car, saving CPU time.
EDIT: (next morning)
You can easily get the spoke object down to one single texture instead of 5 at the moment. How to do that:
1) Combine the 4 256 textures onto a single 512 page, the obvious way.
2) For the "unnamed" (no texture) cutout use a small white square on the new texture page. There is space beside the bolts.
More optimisations:
- If possible, combine the hub object into the spoke object. Every moving subobject is a frame rate hit.
- Change "muffler" subobject into an attachment. "Attachment" subobjects are merged into the main object so they don't cause the same frame rate hits as a moving subobject. The vibrating muffler gimmick isn't worth the frame rate hit.
- Steering wheel subobject can be made way more efficient by combining textures. The 11 small button textures could be combined onto a single texture. The [no texture] page can be eliminated by using a small square from the new texture. And the "plain transparent" texture at the end of the list can also be combined into the same texture page. So this combines 13 textures into a single texture page. Only the two repeating textures need to be left on their own page. 15 textures on the steering wheel now, can be reduced to only 3.
Let's do some maths, for 40 cars on the grid.
For the wheel objects described above, we save 4 texture changes per wheel = 16 per car = 640 per graphical frame.
For the steering wheel optimisation, we save 12 texture changes per car = 480 per graphical frame.
So by these simple changes we save 1120 calls to "Set texture" every graphical frame.
Also don't use "TEA" (Tree Edge Alpha). Tree Edge Alpha is not supported for vehicles, it's a special thing for trees with intersecting polygons that only works for world objects. Applied to a car it looks exactly the same as ALPHA so you are adding one more material for no reason.
[I notice one bug, in cutout mode when a subobject is selected: "materials : X" at the top is showing the number for the main object. I'll fix this in next editor test patch. You really should be aiming to reduce the number of materials so that number would help.]
Incorrect setting "Concealed driver" - this should be YES - absolutely this vehicle has a concealed driver (it's not a motorbike or a kart). This one setting appears to waste around 3% of CPU with 32 on the grid.
By the way, "Wheel visibility" should be "inside covered" though I think this is only for looks now. It's not an open wheel racing car, so this will produce a better lighting effect on the wheels.
Another graphical cost is lack of texture sharing. For example the wheel objects are slower to draw than they could be because the alpha cutouts use 3 different textures. The 3 different transparent textures should share a single texture page, so LFS does not have to waste CPU time instructing D3D to switch between textures (texture switching is slow). If you set this right, then when drawing wheel alpha, instead of 3 texture switches and 3 draw calls, it would do a single texture switch and a single draw call.
There could be similar case in the main object (or other subobjects) but I haven't looked much. I do see an S and a backwards S using the same texture but flipped. Can't you use the same texture but flip the cutout?
Of course "repeating textures" cannot share a texture page. But some other textures can, and this can avoid switching between textures during the render of the car, saving CPU time.
EDIT: (next morning)
You can easily get the spoke object down to one single texture instead of 5 at the moment. How to do that:
1) Combine the 4 256 textures onto a single 512 page, the obvious way.
2) For the "unnamed" (no texture) cutout use a small white square on the new texture page. There is space beside the bolts.
More optimisations:
- If possible, combine the hub object into the spoke object. Every moving subobject is a frame rate hit.
- Change "muffler" subobject into an attachment. "Attachment" subobjects are merged into the main object so they don't cause the same frame rate hits as a moving subobject. The vibrating muffler gimmick isn't worth the frame rate hit.
- Steering wheel subobject can be made way more efficient by combining textures. The 11 small button textures could be combined onto a single texture. The [no texture] page can be eliminated by using a small square from the new texture. And the "plain transparent" texture at the end of the list can also be combined into the same texture page. So this combines 13 textures into a single texture page. Only the two repeating textures need to be left on their own page. 15 textures on the steering wheel now, can be reduced to only 3.
Let's do some maths, for 40 cars on the grid.
For the wheel objects described above, we save 4 texture changes per wheel = 16 per car = 640 per graphical frame.
For the steering wheel optimisation, we save 12 texture changes per car = 480 per graphical frame.
So by these simple changes we save 1120 calls to "Set texture" every graphical frame.
Also don't use "TEA" (Tree Edge Alpha). Tree Edge Alpha is not supported for vehicles, it's a special thing for trees with intersecting polygons that only works for world objects. Applied to a car it looks exactly the same as ALPHA so you are adding one more material for no reason.
[I notice one bug, in cutout mode when a subobject is selected: "materials : X" at the top is showing the number for the main object. I'll fix this in next editor test patch. You really should be aiming to reduce the number of materials so that number would help.]
Thank you for your time and explanation of how to better optimize the mod, I will definitely do it as soon as I have free time. But I wonder if the problem here is really in the textures or the number of subobjects. Lags during the broadcast occur during the crash of several cars. Is it possible that this is somehow related to the damage model of the high-polygonal mesh or something like that?
You are right about combining textures in one subobject.
But from this another question arises, what is the best way to optimize the mod? I should not use the same large texture in several subobjects, or make separate small textures for them. So if you use one big texture in two subobjects it double the graphics workload (or something like that) or not cuz it the same texture?
No problem, I was just interested, as I saw the frame rate hits, when a lot of cars were on screen, and also seemingly in panning shots with a few cars on screen.
I wondered if there were any problems in LFS so I built a profiler version to see what's up and I spotted a lot of CPU usage in "Draw driver" and "Draw meshes" (that includes subobjects) and "Draw wheels" (includes spoke objects) and also similar issues in the alpha pass. This particular CPU usage is not related in any way to number of polygons. Thousands of polygons may be drawn in a single draw call, which is also the same for one single triangle. LFS does a good job of combining all triangles of a single material, into a single draw call. No matter how many cutouts you use, they will still be combined together if they are using a single material and in a single object.
This heavy CPU usage which is (I think, roughly) double that of an XR turbo led me to look in the model a bit, specially near subobjects and spoke objects. That's where I noticed this use of multiple textures. Also the concealed driver thing which is just one switch to fix.
When the cars are initially generated (when leaving pits) and when there is a collision, this is when the number of triangles (actually vertices) is a problem. All these vertices and triangles must be created on the CPU and then sent to the graphics card. When damage occurs, the model must be deformed and it is all sent to the graphics card again.
But for a modern graphics card, this number of vertices isn't really a problem regarding drawing the car each frame (when there is no collision). The number of materials is more of a problem, and also subobjects that are not "attachments". Each movable subobject requires a new matrix to be sent to the graphics card and of course a whole batch of draw calls for its materials (which cannot be combined with the main object's materials).
Taking the example of the steering wheel, if those textures are all used only in the steering wheel, then it is a perfect case to make a special texture for that steering wheel. I imagine those 11 (or was it 12) 128x128 textures I talked about, going onto a new texture of 512x512 and you use the 16 squares, leaving a few spare.
It is not a problem to use the same texture in two different subobjects if that is convenient, or for subobjects to share a texture with the main object. But it brings no specific benefit, other than maybe reducing the total size of textures in the whole model. That is more about what texture cutouts you can fit on what pages.
For example, I wouldn't suggest using really massive textures to try to share everything in the whole model. It can be good to use smaller textures, if that is convenient for one (or a few) subobjects. So... don't worry about different subobjects sharing a texture, that is OK, but don't go mad and try to combine everything, which would require extra big textures for no benefit.
However, "attachment" subobjects are a different case, as they don't move, they are combined with the main object. So it's a good idea to share textures with the main object (and/or other attachments) in that case.
I want to help with the materials display in the cutout editor (as described, there is a bug). I am interested to try and add a CPU display in the vehicle editor so you can see the results of your improvements.
EDIT: added image showing materials in my fixed version, that will be more helpful to see the results after you share textures.
EDIT2: added another image showing the combined list of materials, when attachments are combined with main object.
New version of editor allows you to check the number of materials in subobjects: https://www.lfs.net/forum/thread/106792
Mod updated:
Enabled concealed driver for optimization.
Wheel visibility - inside covered.
Some material\texture optimization.
Some mapping fixing.
Some mesh fixing.
Muffler is back to static attachment for optimization.
Change size rear lights to more realistic.
Enabled concealed driver for optimization.
Wheel visibility - inside covered.
Some material\texture optimization.
Some mapping fixing.
Some mesh fixing.
Muffler is back to static attachment for optimization.
Change size rear lights to more realistic.
Some CPU results here. Note: this is an old (but still good) computer. I locked frame rate at 30 fps with a full AI grid, paused, at South City. The reason for locking frame rate is so the CPU usage results are comparable between the two versions.
I post relevant results for CPU usage. The 1st number is version 19, 2nd number is version 20 of the mod.
Solid pass:
Render car (total): 56.41 -> 47.59
Includes:
- Draw driver: 5.90 -> 2.57
- Draw meshes: 18.00 -> 14.64
- Wheel objects: 14.29 -> 12.29
Alpha sorted: 11.56 -> 8.31 (of which ~1% is fences etc)
So in total (solid + alpha, TV camera, 32 cars at 30 fps on my PC) approx: 67.0% -> 54.9%
A 12% of CPU reduction from 67% of CPU is ~18% CPU saving per car.
NOTE: This is the CPU usage. It does not consider GPU usage but we are unlikely to be GPU bound.
I post relevant results for CPU usage. The 1st number is version 19, 2nd number is version 20 of the mod.
Solid pass:
Render car (total): 56.41 -> 47.59
Includes:
- Draw driver: 5.90 -> 2.57
- Draw meshes: 18.00 -> 14.64
- Wheel objects: 14.29 -> 12.29
Alpha sorted: 11.56 -> 8.31 (of which ~1% is fences etc)
So in total (solid + alpha, TV camera, 32 cars at 30 fps on my PC) approx: 67.0% -> 54.9%
A 12% of CPU reduction from 67% of CPU is ~18% CPU saving per car.
NOTE: This is the CPU usage. It does not consider GPU usage but we are unlikely to be GPU bound.
Wow, that's great, I hope I can optimize the mod even better. Thanks for this information, it is quite useful to know.
Nissan 400Z (N.400S) GT4 vers.
(64 posts, started )
FGED GREDG RDFGDR GSFDG