Hi,
I have been thinking really much very to post this thread but ended to start here.

I have been trying several times to make some test when there is less track to be draw in distane and just place a card on track and then moving the view from the place where is no car the the place where is the car standing and I have noticed FPS draw dropped from 250 to 150FPS which looks to me really odd - 40 percent ???.Such a drop just with a few polygons more?

Also this was when the LFS was paused so I guess there was not so many physic calculation done if any.

Just to mention quickly my system spec:A64 3200+,2x512MB,7900GT.Several drivers versions doesnt have any affect on this.

See video as an example how I am moving(ofcourse it cant show the FPS drop). http://home.karneval.cz/0222338601/001.avi

We know LFS 3D engine need more development for S3 but something could be fixed earlier probably.Maybe something is really buggy in the LFS 3D engine and Scawen might overlook it.

What about 3D engine is in some situations exaggeratedly calling to DirectX API which slowdown the performance?When I will have time I am going to install and try out the NVIDIA development kit which is able to show if there is something wrong in some situations.

EDIT:what a shame.This NVPerfHUD doesnt work with LFS because it need DX8.1 and up and it report LFS just as DX8 aplication.

Hmmm the cars don't really have "just a few" polygones - compared to the track it's actually a lot, specially when you disable the lod reduction features. LFS can reduce the cars' lod in a few steps, so you don't end up having more polys then needed. In a very high distance, you might even end up having only one pixel for a handsome of polys, which doesnt make any sense tbh

The tracks have really way less polys than one might think, specially the road segments are very long. So I don't think it's a bug.
On the other hand, the unreal 2 engine could handle the same amount of polygones at like 2 times the fps

Quote from ORION :

Hmmm the cars don't really have "just a few" polygones - compared to the track it's actually a lot, specially when you disable the lod reduction features. LFS can reduce the cars' lod in a few steps, so you don't end up having more polys then needed. In a very high distance, you might even end up having only one pixel for a handsome of polys, which doesnt make any sense tbh

The tracks have really way less polys than one might think, specially the road segments are very long. So I don't think it's a bug.
On the other hand, the unreal 2 engine could handle the same amount of polygones at like 2 times the fps

Well its not so many polygons I would say especially for graphic card like mine which is able to render around 400-500 milinons polygons per seconds.Orion how many polygones show exactly the 3d models in 3D studio MAX.O estimate around 5-10 thousand.
LFS doesnt use any pixel shaders so the effectivity of the card to be able to output such a hight numbers shouldnt be affected.

I dont get it why just 1 car can affect the performance to about 40percent in some situations.5-10 percent would make sense but 40percent drop doesnt unless something is wrong with the 3D engine.

I am not blaming LFS but something looks really wrong.Maybe thats why there is such a huge FPS drops at start because the engine is not able to cope with so many polygons effectively.

I remember my Raceabout GTR had like 14000 polys, so I guess the original had about 13000 (BF1 might be over 20k though). So if the visible part of the track has just 40000 polys or something, the values can be quite right.
But nobody knows how many polys those tracks have...

You must also keep in mind that every poly is still keeping the CPU really busy - the Vertex shaders are just a crappy way to improve things a bit. As the physics engine from LFS is quite a big task as well, you can't have enough CPU power
If the game is paused, the physics calculations should be disabled though, thus we should have more fps. But at least I don't have any difference between paused and not paused game, at least on my notebook, where I just tested this.
So I guess the physics stuff is always calculated for a car that is visible.
I have like 200-250 fps when I dont see any cars, and like 100-150 when I see one car (in hotlappig with LX4 on FE2 that is).

At such high FPS's I wouldn't be too worried about drops, however one thing that LFS seems to lack is proper LOD levels for the cars. Currently there appears to only be a few LOD levels, with the second most detailed one being a quite big drop in detail from the highest one. Because of this with a full grid of cars the performance drops quite alot as most of the cars are drawn with full detail, while alot of the detail drawn is unnecessary and not visible.

I believe it could help performance alot if there would be more, better LOD levels. It would be more work for Eric though.

The fps drop is always excessive. Regardless of the base-fps.
My PC drops from 75 to 40 fps once a single car appears. Though the system never goes below 25 fps for some reason. Might just be a DirectX call that does something wrong, like the reflections or something.

Vain

Lets also try not to forget that FPS is a poor measurement of performance, other than smoothness. Frame time would be a much better calculation to work with.

200 FPS = 1000 / 200 = 5ms per frame
150 FPS = 1000 / 150 = 6.67 per frame
100 FPS = 1000 / 100 = 10 ms per frame
50 FPS = 1000 / 50 = 20 ms per frame

As you can see from above the difference in draw times between high values of FPS are fairly small, but start becoming more significant at lower values.

Quote from Kegetys :

At such high FPS's I wouldn't be too worried about drops, however one thing that LFS seems to lack is proper LOD levels for the cars. Currently there appears to only be a few LOD levels, with the second most detailed one being a quite big drop in detail from the highest one. Because of this with a full grid of cars the performance drops quite alot as most of the cars are drawn with full detail, while alot of the detail drawn is unnecessary and not visible.

I believe it could help performance alot if there would be more, better LOD levels. It would be more work for Eric though.

The purpose is not about my FPS drop like from 250-150FPS.I really doesnt care abput this unless my FPS drop below 40-50.

I was just trying to show there might be some problem iwith LFS 3D engine making some unnecessary or wrong calls to API,drivers or what so ever as such a drop on powerfull graphic card is really weird/doesnt make sense and it more point towards something doesnt work as it should.

I wanted to try NVIDIA NVPerfHUD which has so many usefull things to show/debug (http://download.nvidia.com/dev ... 0/NVPerfHUD_UserGuide.pdf) but unfortunately this doesnt work with LFS because its just DX8 aplication and these Development software just support DX8.1 and above.What a real shame as I would like to help here.

I am maybe totally wrong about this performance drop and it should work like that but I have personall feeling it shouldnt be like that.

LFS is one of a few modern games that still run on my oldish laptop (with a Mobile Radeon 7500) with an acceptable framerate. That makes me believe that LFS's 3D engine is pretty good.

Well it is DirectX 8, and most post-millenium systems should be able to run LFS just fine .

But I think the topic here is the quality/detail of the car's polys and stuff. Not my area of expertise... so I'll be quiet (but yeah, I can say this... the cars are low poly and VERY simple)

Scawen,
I think this is more question for you as you are probably the only one who can answer from where come this unefective drawing of models and huge drop of FPS on hardware which is capable to draw(with a good performance)beyond what LFS offer currently.

The help of graphic cards doing vertex shading is not fully implemented?Any bug in 3D engine or something else?Lack of optimisation?I really dont know.

I am not moaning about my FPS drop from 250 to 150FPS because I still have FPS which is beyond my eyes to notice.
This is really not the problem I would be thinking about however such a drop might be similar for less powerfull graphic hardware and for example when it drop for someone same way like 40 percent from 60FPS to 24FPS then it is a problem.Its just I cant explain my self these huge drops in any reasonable way :-(

Maybe the FPS drop at start everyone have is not really related to heavy physic calcuation with all the cars around but the the 3D engine which might have some issues.

This is really my pure specualation so I am not blaming LFS.Maybe just something to think about.

Hope we can get any feedback from Scawen on this.

I remember that at the time without hardware vertex shading (early S1), the car reflections had a huge impact on FPS. Thanks to hvs it's not that much anymore, but maybe they still cost a lot of CPU power. The tracks don't have many reflections (only windows and the lakes), so it's not that noticeable there.

Suggested CPU Optimizations

• Reduce Resource Locking

- Avoid locking/reading from a surface you were previously
rendering to.
- Avoid writing to a surface that the GPU is reading from, like a
texture or a vertex buffer.
• Minimize Number of Draw Calls

- Use degenerate triangles to stitch together disjoint triangle strips.
- Use texture pages.
- Use the vertex shader constant memory as a lookup table of
matrices.
- Use geometry instancing if you have multiple copies of the same
mesh in your scene.• Reduce Cost of Vertex Transfers

- Use the smallest possible vertex format.
- Generate potentially derivable vertex attributes inside the vertex
program instead of storing them inside of the input vertex format.
- Use 16-bit indices instead of 32-bit indices.
- Access vertex data in a relatively sequential manner.
• Allocate Resources Efficiently

- Create all vertex buffers, index buffers, and textures ahead of
time, and reuse them with DISCARD.

Thats what suggested NVIDIA .

As I said I would really like to see where is this huge performance drop as I described and showed above coming from...

You have to admit that what I have described above shouldnt be really like that.