[How-to] Optimize texture size | Fixing oversized assets | Bring any texture dictionary under 16 MB physical memory

When I get onto OPENIV and go through platform then textures the texture folder is empty?

This happens with almost every texture when using xnresize

Also, does anyone know how to optimize a script? I now have my server running at 2.0 ms which I think is quite high, I want to be around 1.20 if possible. I did see that my ELSPLUS grabs 0.15 to 0.20 approximately.

would this work with a clothing pack too? I have a LOT of modded clothing and it shows a similar message in the console when loading.

Hello,
Community is lots of questions you all might find the video very useful in downsizing your resources for vehicles. TUTORIAL: FiveM Oversized Asset Error Fix - Vehicle Texture Optimization Tutorial - YouTube

1 Like

thank you

1 Like

XnResize doesn’t preserve or regenerate mipmaps so while this will make the warnings go away, I would presume the issues people have posted are due to not having mipmaps when the originals did have them and/or the issues I mention below.

Another issue I found is that when you change all texture formats to DXT1, DXT3, or DXT5 a lot of times textures that were meant to be black will have a yellow or green tint to them. So I always do A8R8B8G8 for textures that need to be black to prevent the tint.

I also like to keep textures maximum width or height to be 512 so if it was 1024x512 I would resize it to 512x256. Some stuff also have textures that aren’t in powers of 2 and so by resizing in bulk to a specific resolution (say 512x512) you will mess up the uvmaps and cause textures to glitch in game.

Until there is a tool that will let you intelligently resize all dds files to have a specific minimum height or width measurement (depending on the file) and just resize textures that aren’t powers of 2 to 512xSOMETHING (keeping original WxH ratio) as well as regenerating mipmaps depending on if the original dds file had them and keep the same format as the original dds files, all of these reasons above are why I prefer to resize textures manually using PaintDOTnet to make sure I don’t make any mistakes or forget mipmaps etc…

I wrote a guide on how to mass optimize .ytds and packs which contain them, which takes into account the format problem on carbon textures, as well on *light* and *emissive*. It also replaces <4x4 textures upsize to 4x4, as <4x4 textures don’t work, e.g. self-defined colors, blank textures, which as a side effect may repair textures. It also doesn’t screw up *script_rt* (and by extension script_rt_dials) textures.

It’s not well polished and is slightly hard to use but I’ve fixed all the bugs that I got, the process could be a lot swifter and in the future I plan for it to only work on larger textures - re:TO DO. In case you do use it, please send feedback.

1 Like

Hello, I used this on my car but the kmh display and the radio inside is then the texture is broken or upside down, please help.

Kind regards Max

I know this is a crazy question. Instead of resizing textures, is there a way to increase virtual/physical memory?

1 Like

Yes actually, virtual memory available on a server is determined by the amount of RAM installed, as well as any page file or swap space settings that have been configured.

Where is this yft tutorial? I need it :slight_smile:

This is really not ideal unless we know exactly what we need to resize… Lighting can really get messed up doing this.

Don’t resize any script_rt* or emissive files as a rule of thumb, everything else depends on the specific model - you’ll need to play around and maybe do a few tries to figure out the best way

Any Updates?