Great that Daniel's program is helping people load textures so much faster!
That depends on the track. Originally when LFS saved textures as dds, saving space was the main consideration. But later (I think when Blackwood was being updated) I noticed that some of the mipmaps (particularly some of the transparent ones) created by DirectX on loading were not very good, so I tried saving with mipmaps that had been created directly by LFS from the original raw files. That's when I found out about the much faster load times as well, so that's how LFS does it now. But we did not re-export all the old textures from all the other tracks, which would have made a big patch. I just thought we would release them when any track was updated. I guess it's BL and SO that have the mipmaps saved in their textures.
I was in doubt too, but as I have some relatively big ADS it took quite some time to load. Only dds folder converted about 18s, after conversion of textures in pic folder it was like 4s. That is huge improvement if you are using hi-res ADS.
IrfanView (which I use) can open just fine everything in pic folder after conversion, no matter if jpg, dds, ... thing is Windows Photo Viewer cannot open dds, which I believe most people use
If you don't like having pic in dds, you can always restore a backup after conversion
Neat tool, there is definitely a speed improvement However, I'm not sure I like to lose the visual details in the pic folder. I wonder if there is a big performance difference if you only the convert the dds files.
Probably the reason is devs wanned to keep texture folder at lower disk space, mipmaps infact increase size a bit (114 MB compared to 101 MB – original textures). That little increase if often compensated by more significant decrease caused by wrong formats in hi-res textures.
Failed to open? Do you have these textures in your dds folder? Did LFS run at the time? If texture is opened by LFS probably program won't be able to convert it.
You can hit Pause/Break button if it doesn't go too fast or increase Command Prompt line buffer size so you can view log from start.
Re-runing shouldn't hurt, already converted textures will go much faster than first time (format check, ...)
Thanks for the explanation Daniel .
I was not understanding why lfs' own converter (raw to dds) would not convert the textures to the best format for its use (one time process, not every time when loading the track).
Anyways, thanks for the program, it's always nice to speedup loading something .
About raw files, this is probably the post you are referring to.
As far as I know raw files won't speedup load process at all, LFS just can convert them. Other than can there is no real advantage. This program doesn't convert textures to raw.
All textures are saved in dds format, default, user made, ... However there are still various formats in dds so called pixel formats, program convert textures between those pixel formats. LFS by default use DXT1 (for regular textures) and DXT3 (for some alpha textures). Difference primarily is that DXT3 allow explicit alpha e.g. you set 30% alpha... DXT1 has only one bit for alpha, which means pixel is transparent or not. As LFS request textures to be in specified formats DirectX has to convert them on load if the format is not right, for example if LFS request DXT1, but texture is saved in DXT5 DirectX will have to convert texture prior to load. And thing is that conversion happen each time you load track, which is absolutely not needed. Moreover DXT3 use 2x more space compared to DXT1, so by removing "wrong" textures you get some extra space and faster load (additional details are lost anyway when LFS convert textures).
Also each time LFS load textures it has to make mipmaps of textures, my program will generate all mipmaps to minimize need for any calculation by LFS. While creating mipmaps I use triangle sampling, that why some textures may look different (power lines) hopefully better
Also some may have noticed that ADS in pic folder are no longer openable with some simple picture viewer, the reason for that is they are now in DDS DXT1 format while still keeping .jpg extension. That is much more elegant solution than JPG when using hi-res ADS, for example my ADS in 4096x4096 JPG took 4s to load per file!, after conversion to DDS it is <0.01s. JPG is highly uneffiecient!
What do you mean ?
I remember reading somewhere (also devs' recommendation) to save a DIY texture to raw format and then LFS will automatically convert it to dds. And this only the first time. So why reconvert the dds ? Or are you referring only to the textures made by "others" who didn't know to save as raw ?
IMPORTANT:
Converting textures is now implemented in LFS !!!
Removed links as they are not needed anymore
Ever since I started LFS I use hi-res textures, and one thing that has bothered me a lot is slow track load. Using lower resolution textures was not an option. Recently I started doing some tests regarding LFS texture load. First I pregenerated mipmaps* for all files in my dds folder. I recorded approximately 30% faster load of track.
*Mipmap - original texture converted to a series of lower resolution ones used when viewing from a distance
Somehow I felt there is still more room for improvement. Scawen kindly advised me to use original dds format as LFS use. I did that and achieve quite a remarkable results. For most tracks load time has decreased three times or more.
Thing is most of user made textures are saved in "wrong" format which require LFS to convert them each time while loading track. Saving in those "wrong" formats doesn't benefit from neither side : more waiting, details which user perhaps tried to save are lost anyway after conversion by LFS and often these formats use more space (my dds folder dropped from 1,8GB to 1,4GB).
I made little program which can convert your textures too!
1. [B]Backup your dds and pic folder! (original files are overwritten)[/B] 2. Download program and extract it to root of your LFS folder 3. Run program, it will take some time to convert
That's pretty much it, enjoy faster LFS.
Benchmark (stopwatch) and post your load times before and after.
Before my BL would load in 65 s, after conversion approximately 5s.
Are you using the newest version of LFS (0.6E)? Could you provide us some more details and screenshots of the error? If you get a windows error reporting window (or what's that), click on details and paste the log here. Finally, you can try the newest test patch to find out if that's an error which is now fixed or not. (0.6E15: https://www.lfsforum.net/showthread.php?t=85807)
EDIT: I saw that you started a thread in which you ask for the original dds files because you want to install a night mod and so on ... Try reinstalling LFS completely, maybe you installed/replaced so many or important files that makes LFS unstable. Dunno.
Google for "dds plugin gimp".
Pick one and install.
Open lfs\data\dds folder (preferably backup the folder too),open one of the files. Understand what texture it is and edit by your liking. Save.
Relaunch LFS.
Brag.
Yeah, there is something bizarre going on with gimp. No matter what I do I get white skin in ac. (Gimp is annoyingly strange program to use anyways. It is totally unintuitive and for every tool I need to do a google search and learn to use it. With psp I never needed to google anything...). Anyways I finally figured out an imaginative way to make skins with gimp.
1. Make your skin and save it as psd or xcf or whatever the best file for saving the work in gimp is.
2. save a copy of it as png
3. go this site: online-converting.com/image/convert2dds/ And upload your png there. Choose the ARGB 8888 32 bit format and click to generate mipmaps and convert and download the dds.
4. download the skin and put it in your ac skin folder
There is something really strange with either gimp or that dds tool that messes up the dds file. I think it is the alpha layers in gimp which are just f****g bizarre. No matter how I tried to color or delete the alpha files all I got was just a white skin. But the above version does work kind of...
All I need to figure out now is if I can create the alpha/bump map layer as separate file because otherwise all my skins will be shiny as hell: http://i62.tinypic.com/f50meu.jpg
I did also find this: http://www.racedepartment.com/ ... tware.22570/#post-1203429
But I have no clue what he is trying to do with copy pasteing those alpha layers seemingly randomly. When I tried to follow that I got some strange error about not being to copy a mask to new layer or something...
There seems to be a problem with skins created with CS as in layers. If layers are created they don't show in Gimp or PSP even if you use the PSD files.
I have found this as a really nice gentlemen created T7R skins for me, and because he used layers etc etc, you cannot view them in anything else but CS.
I hope that explains it, to the best of my ability
From what I know, you need the PSD files to then create a DDS file, as its the DDS file that works with AC. Like I said, I am no expert, that is just what I have been told
Damn it. When trying the tech preview I had so much fun I got aneurysm and broke my monitor after throwing money at my screen.
At least now I get to see what my skins look like in-game
You people who have made skins for ac have you messed with the bump maps? I'm using gimp and I'm wondering what and how should I save the bump map dds so it shows correctly in-game?
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.
Hi everyone, I'm starting a small skin and DDS workshop here.
This will be where I release my skins, dds-mods etc.
Hope you like what you see, and please, do have fun with it.
I would appreciate if you used the Adfly link, but added in direct link if you are in a hurry
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.