If this is due to the hi-res texture pack that I am using then I am sorry for posting this..but LFS seems to be very slow at loading the textures, generating and reloading the tracks, is there a way to make the textures for everything in lfs load a bit faster?
Slow texture load [not a bug - custom textures using wrong format]
(16 posts, started )
Slow texture load [not a bug - custom textures using wrong format]
whats your system specs and what textures are you using ?
I've tried both my laptop and desktop, lfs still seems to take a considerable amount of time to load textures.
Laptop: Sony VAIO Intel Core 2 duo CPU T7250 @ 2.OOGHz, 2 Logical Processor(s), NVIDIA GeForce 8400M GT, 2.00GB of RAM
Desktop: Dell Precision 390, Intel Pentium D 326 / 2.66 GHz, ATI Radeon FireGL v7200, 2.00GB of RAM
I can say with certainty the cause are hi-res texture pack you're using. I know this because I have experienced the same in the past. All the textures have to be transfered from the HDD to the VRAM so they larger they are the longer the wait. This is mostly relevant the first time you load a track, any consecutive loads might be much faster depending on the amount of VRAM and the needed textures still present in it.
I can't tell for sure but it seems highly unlikely that this is LFS specific slowdown you're experiencing. I would guess thats the case because it happens is all apps where you add more visual content to be loaded, and because it would seem logical that, by now, this loading process is very old and very much standardized so every game uses more or less the same process. If this is correct then it's not a bug
I can't tell for sure but it seems highly unlikely that this is LFS specific slowdown you're experiencing. I would guess thats the case because it happens is all apps where you add more visual content to be loaded, and because it would seem logical that, by now, this loading process is very old and very much standardized so every game uses more or less the same process. If this is correct then it's not a bug
I think you are right, however the HDD on my desktop hardly has anything on it, it is a fast pc for it's age and so is my laptop, I downloaded Daniel CRO's dds file via a youtube video he posted on this forum, if he is having trouble with slow texture loading times then maybe it is a bug or just simply the dds files are ridiculously big? But I want to reduce the load times so shall I just download another texture pack, re install lfs to default settings or just try everything I can to make it load faster?
#6
- DANIEL-CRO
I can confirm that
I plan for quite some time now to decrease size of textures (primarly some textures far from track), but I'm not really into that field of LFS lately
Before I upgraded my PC I was seriously mad about loading times, I tried stuff like RAM Disk, ... nothing helped, in fact it was even slower for some reason
On new PC things are much better, HDD has average read speed of 160 MB/s so its much less of a problem. Though I still don't understand why LFS doesn't benefit at all from SSD/RAMDisk 
Are there another programs accessing the HDD is the background? Such as updaters, scanners, downloaders, defragmenters, various unneeded windows services, perhaps unknown to you, working silently and automatically. They would be identifiable through the process/service list i reckon.
My HDD is pretty average in terms of speed as were the older ones i used. But they all have common shortcoming: lets say you want to run two programs, one after another and total time needed for them to complete their job is 30 secs in total. But if I decided to run them both at the same time then time until completion becomes 60+ instead. Similar thing might be happening if textures are being scanned for viruses as they are being read or who knows what else
One time, while i ran complete system virus scan i also ran LFS and went online. During the track load I could easily read the % progress as it changed - 1 sec at a time.
For reference sake my load times increased considerably by installing Hi-Res stuff, in the ballpark of about 2.5+ times. You could do a short test with vanilla and modded to compare. If it takes similar time then there is no problem, not in a sense that it is a LFS bug that is.
If you really like how the textures look but you're bothered by loading times and have some spare time you can try to resize the image (resolution) of the modded texture file to a smaller one. But before that you would need to know what size is acceptable to LFS if that is even the case. Again, compare to vanilla texture sizes. You get to keep the looks and gain speed
@Daniel
It does sound weird what you said about SSD, are you really sure? Gimme sum tests of yours
I wish to know how much I benefit from avoiding SSDs
My HDD is pretty average in terms of speed as were the older ones i used. But they all have common shortcoming: lets say you want to run two programs, one after another and total time needed for them to complete their job is 30 secs in total. But if I decided to run them both at the same time then time until completion becomes 60+ instead. Similar thing might be happening if textures are being scanned for viruses as they are being read or who knows what else
One time, while i ran complete system virus scan i also ran LFS and went online. During the track load I could easily read the % progress as it changed - 1 sec at a time.
For reference sake my load times increased considerably by installing Hi-Res stuff, in the ballpark of about 2.5+ times. You could do a short test with vanilla and modded to compare. If it takes similar time then there is no problem, not in a sense that it is a LFS bug that is.
If you really like how the textures look but you're bothered by loading times and have some spare time you can try to resize the image (resolution) of the modded texture file to a smaller one. But before that you would need to know what size is acceptable to LFS if that is even the case. Again, compare to vanilla texture sizes. You get to keep the looks and gain speed
@Daniel
It does sound weird what you said about SSD, are you really sure? Gimme sum tests of yours
I wish to know how much I benefit from avoiding SSDs
#8
- DANIEL-CRO
I tried RAMDisk once, as I was pretty disappointed with results (I didn't understand why are they so bad) I asked if anyone have similar behaviour. Dustin said to me that LFS don't really benefit from SSD speeds much. It was bothering me for quite some time why is that...
Later I figured that if you are transferring one large file from RAMDisk to RAMDisk, you can achieve full speed of RAM something like ~8 GB/s (old PC). However, if you transfer whole bunch of small files (like dds folder), speed will decrease greatly. Now we are talking about ~20MB/s. Couple of months ago I got my hands on one SSD, thing was similar to my RAMDisk experience.
I guess loading times will decrease a lot if there was just one file containing textures to load. If I still remember well, GTA have couple of files each like 1GB of a size, so even enormous GBs doesn't make it so slow. And, for texture moding you would have to use some unpacker.
Later I figured that if you are transferring one large file from RAMDisk to RAMDisk, you can achieve full speed of RAM something like ~8 GB/s (old PC). However, if you transfer whole bunch of small files (like dds folder), speed will decrease greatly. Now we are talking about ~20MB/s. Couple of months ago I got my hands on one SSD, thing was similar to my RAMDisk experience.
I guess loading times will decrease a lot if there was just one file containing textures to load. If I still remember well, GTA have couple of files each like 1GB of a size, so even enormous GBs doesn't make it so slow. And, for texture moding you would have to use some unpacker.
Not so good with this graphic stuff but maybe it is something like this:
File size is not only factory that has effect on load times.
DDS textures include several versions of the image, in different resolution, for better image quality. (=mipmaps, mipmapping)
Example: http://www.unrealtexture.com/M ... ictures/MipMapExample.jpg
Or how this:
becomes this:
At close distance a higher version of the texture is used than at far distance. Better image quality, more fps.
Usually this mipmap thing is generated by the game maker/modder but there are also games that generate them during loading. Generating them during loading takes longer of course.
If the textures-version-things are in a different format than what the game expects it might still decide to generate them itself.
On LFS loadscreen it also says "Loading textures, generating, rebuilding" so seems it "does something" with the textures even after loading. With higher resolution that might take longer.
File size is not only factory that has effect on load times.
DDS textures include several versions of the image, in different resolution, for better image quality. (=mipmaps, mipmapping)
Example: http://www.unrealtexture.com/M ... ictures/MipMapExample.jpg
Or how this:
becomes this:
At close distance a higher version of the texture is used than at far distance. Better image quality, more fps.
Usually this mipmap thing is generated by the game maker/modder but there are also games that generate them during loading. Generating them during loading takes longer of course.
If the textures-version-things are in a different format than what the game expects it might still decide to generate them itself.
On LFS loadscreen it also says "Loading textures, generating, rebuilding" so seems it "does something" with the textures even after loading. With higher resolution that might take longer.
I'm also not good at graphic, only speaking from experience which isn't unique to myself and some logic tied to it so they hold some merit i would hope. Until someone proves me wrong that is. And i try to add 'not sure' or something similar when i'm about to say something i am, well, not sure of
LFS does not use pixel shader technology so the texture mapping doesn't play a role in loading time because it doesn't exist. Would it play a role should it exist? Yes but not by very much. It's not as large in size as a texture but it's more of an information calculated on the fly, every frame, then added to texture surface information, resulting in change of its appearance. Such as rainy roads, shiny metal surfaces in bright light conditions, adding visual appearance of bumpy surface on an perfectly flat texture, stuff like that. When done with care it makes a more immersive environment. It's down size is very heavy GPU load. Not in loading time but pure processing power. It is still more efficient then adding more polygons to achieve the same level of visual detail.
In LFS the roads are simple flat polygons except on places where two polygons join at different angles. But, if you look the suspension forces while driving on a visually flat surface like Blackwood back straight it appears you're constantly driving over bumps. But they aren't there, so what are they? My theory from when i first saw that is that those bumps are programed into track elevation info or something. Kinda like the shader stuff but it results not in visual appearance but a virtual physical force, affecting handling. Way to save on GPU power and is pretty neat how it's done.
Those different colored copies of the images i don't think are textures as we know but information how to stick shaders to it. If that shader info was 4x larger as indicated on your picture the texture loading part would take 4x times longer, but from my experience that isn't the case. My experience shows negligible difference in loading times without using shaders compared to slight increase of using it (different game ofc).
Different sizes of them are what you have said - LOD textures that are used at far distances. Commonly used is open game areas to save on memory so that environment closer to you can be presented in more detail. And lower resolution textures also look better at far distances because the high detail of high res textures would be lost on the relatively big sized pixels on the LCD monitor making it look like blurry, jittery (when moving) mess.
Nice example of that are the high resolution road textures for LFS. The detail is so high that it is smaller then the pixels are able to present and it ends up looking like one shade of gray from anywhere above 10m distance and/or lower view angles. Depends on monitor resolution but not by much.
Those generating and rebuilding can mean anything, only the author knows for sure
My guess is they are expressions for various stages of texture loading and placing them in 3D space. Nothing too fancy.
LFS does not use pixel shader technology so the texture mapping doesn't play a role in loading time because it doesn't exist. Would it play a role should it exist? Yes but not by very much. It's not as large in size as a texture but it's more of an information calculated on the fly, every frame, then added to texture surface information, resulting in change of its appearance. Such as rainy roads, shiny metal surfaces in bright light conditions, adding visual appearance of bumpy surface on an perfectly flat texture, stuff like that. When done with care it makes a more immersive environment. It's down size is very heavy GPU load. Not in loading time but pure processing power. It is still more efficient then adding more polygons to achieve the same level of visual detail.
In LFS the roads are simple flat polygons except on places where two polygons join at different angles. But, if you look the suspension forces while driving on a visually flat surface like Blackwood back straight it appears you're constantly driving over bumps. But they aren't there, so what are they? My theory from when i first saw that is that those bumps are programed into track elevation info or something. Kinda like the shader stuff but it results not in visual appearance but a virtual physical force, affecting handling. Way to save on GPU power and is pretty neat how it's done.
Those different colored copies of the images i don't think are textures as we know but information how to stick shaders to it. If that shader info was 4x larger as indicated on your picture the texture loading part would take 4x times longer, but from my experience that isn't the case. My experience shows negligible difference in loading times without using shaders compared to slight increase of using it (different game ofc).
Different sizes of them are what you have said - LOD textures that are used at far distances. Commonly used is open game areas to save on memory so that environment closer to you can be presented in more detail. And lower resolution textures also look better at far distances because the high detail of high res textures would be lost on the relatively big sized pixels on the LCD monitor making it look like blurry, jittery (when moving) mess.
Nice example of that are the high resolution road textures for LFS. The detail is so high that it is smaller then the pixels are able to present and it ends up looking like one shade of gray from anywhere above 10m distance and/or lower view angles. Depends on monitor resolution but not by much.
Those generating and rebuilding can mean anything, only the author knows for sure
My guess is they are expressions for various stages of texture loading and placing them in 3D space. Nothing too fancy.
No. But my bad, that picture was bit misleading because I forgot to include the link to wikipedia: http://en.wikipedia.org/wiki/Mipmap#How_it_works
Basically it explains why texture with mipmaps need more memory than one without, and how much.
What I wanted to say is that dds is complex format.
It is not as easy as high resolution = bigger = loads longer.
As test I saved the same texture as .dds with various options.
It is always the same texture, always the same resolution.
Ingame those textures would look basically the same but the file sizes are very different.
Oh damn, it wasn't your bad. It was mine 
The "mapping" suffix lead me to think it was about the shaders. Sorry
My understanding is that dds is basically GPU friendly file format. If the textures are made for example in jpg they would get converted into dds before being used by GPU. By being in dds there is no need for conversion, resulting in faster loading times and less VRAM usage.
Mipmapping I haven't seen used in LFS. I reckon it would be most noticeable on the distant tree textures but there is none of that. I also checked a few dds files and didn't notice mip patterns. The only place that is affected by LFS's LOD setting is the exterior geometry of the car as I am aware of.
There doesn't seem to be a place for mipmapping to be used at this point, with texture sizes and VRAM usage contained with all loading very fast. From modders point of view, who generally like to make larger and more detailed textures, this is something to tackle with.
The "mapping" suffix lead me to think it was about the shaders. Sorry
My understanding is that dds is basically GPU friendly file format. If the textures are made for example in jpg they would get converted into dds before being used by GPU. By being in dds there is no need for conversion, resulting in faster loading times and less VRAM usage.
Mipmapping I haven't seen used in LFS. I reckon it would be most noticeable on the distant tree textures but there is none of that. I also checked a few dds files and didn't notice mip patterns. The only place that is affected by LFS's LOD setting is the exterior geometry of the car as I am aware of.
There doesn't seem to be a place for mipmapping to be used at this point, with texture sizes and VRAM usage contained with all loading very fast. From modders point of view, who generally like to make larger and more detailed textures, this is something to tackle with.
Stumbled upon this link while performing some random browsing tonight:
http://en.wikipedia.org/wiki/Texture_filtering
and... as much as i hate to say it, my understanding of mipmapping vastly differed from reality again. After reading the summarized version in the link (scroll down a bit) I finally understood what you were saying. Ah, better late then never 
It looks like mipmapping could be used after all in a way you described it. We won't see the RGB versions in the sub-folders because hey are apparently precalculated and stored in the VRAM on the fly (possibly "generating, rebuilding").
This time i mistook mipmapping with more visible LOD texture quality change (not including geometry changes). You know, the type when the texture quality radically changes before your eyes when you get closer to it. Maybe it is the same thing with a different name to it but the one in LFS made way more subtle, I don't know.
I wasn't even aware that mipmapping existed in a way it's described until tonight. It seemed too simple to have it's own precalcualtion and even it's own name. An assumption which hindered my understanding of it sooner. The summarized version helped, the longer one sidetracked me into thinking it was LOD thingy, which could be the same thing, only I thoguht it wasn't
One thing that is true: larger texture filesize = longer loading time. Done simplest by resizing texture resolution to a lower value.
Had to post again in hope of rectifying my own mipmapping explanation in previous post
http://en.wikipedia.org/wiki/Texture_filtering
and... as much as i hate to say it, my understanding of mipmapping vastly differed from reality again
. After reading the summarized version in the link (scroll down a bit) I finally understood what you were saying. Ah, better late then never It looks like mipmapping could be used after all in a way you described it. We won't see the RGB versions in the sub-folders because hey are apparently precalculated and stored in the VRAM on the fly (possibly "generating, rebuilding").
This time i mistook mipmapping with more visible LOD texture quality change (not including geometry changes). You know, the type when the texture quality radically changes before your eyes when you get closer to it. Maybe it is the same thing with a different name to it but the one in LFS made way more subtle, I don't know.
I wasn't even aware that mipmapping existed in a way it's described until tonight. It seemed too simple to have it's own precalcualtion and even it's own name. An assumption which hindered my understanding of it sooner. The summarized version helped, the longer one sidetracked me into thinking it was LOD thingy, which could be the same thing, only I thoguht it wasn't
One thing that is true: larger texture filesize = longer loading time. Done simplest by resizing texture resolution to a lower value.
Had to post again in hope of rectifying my own mipmapping explanation in previous post
I don't see how can this help you load textures any faster.
Problem while loading HiRes textures isn't HDD speed at all, but its CPU that makes it slow even on newest PCs. Open up Task Manager on one part of screen and keep an eye on CPU usage for LFS while loading the track, you'll see that one core is fully utilised. What does it exactly do, I don't know. But there for sure are several ways around it, save textures on HDD in state which doesn't require (as much) converting, or make this part of code multithreaded (which I don't find that hard).
Actually multithreaded texture load would benefit in other cases too. For example when someone leave pits with a new car, LFS hangs until it load textures. Doing so would probably eliminate most of the glitches.
Problem while loading HiRes textures isn't HDD speed at all, but its CPU that makes it slow even on newest PCs. Open up Task Manager on one part of screen and keep an eye on CPU usage for LFS while loading the track, you'll see that one core is fully utilised. What does it exactly do, I don't know. But there for sure are several ways around it, save textures on HDD in state which doesn't require (as much) converting, or make this part of code multithreaded (which I don't find that hard).
Actually multithreaded texture load would benefit in other cases too. For example when someone leave pits with a new car, LFS hangs until it load textures. Doing so would probably eliminate most of the glitches.
** Best answer **
The cause of slow texture loading is partly high resolution textures. They must be loaded from disc and transferred to your video card so clearly that can take time.
But the worst offenders for your CPU time are:
1) The wrong type of DXT file. Many of the custom textures use the wrong format (i.e. not the same as the original texture) and LFS then converts it on loading to the required format. That means, the DirectX code must expand the texture and re-encode it in the correct format.
2) Failure to provide mipmaps. A complete mipmap chain should be provided so that DirectX does not have to create the chain when loading the texture.
But the worst offenders for your CPU time are:
1) The wrong type of DXT file. Many of the custom textures use the wrong format (i.e. not the same as the original texture) and LFS then converts it on loading to the required format. That means, the DirectX code must expand the texture and re-encode it in the correct format.
2) Failure to provide mipmaps. A complete mipmap chain should be provided so that DirectX does not have to create the chain when loading the texture.
To bypass problems mentioned by Scawen, you can use : LFS Texture Converter – speed up hi-res texture load
Slow texture load [not a bug - custom textures using wrong format]
(16 posts, started )
FGED GREDG RDFGDR GSFDG