Texture Replacing And Dealing With Repeats.
-
After looking through gtaV's texture files I realized so many textures are repeated, for example there is a grass texture alone in x64g >>> gtxd.rpf that is repeated 12 times for the different areas around the map (i can't believe rockstar are even doing it this way, it seems really dumb (like really dumb)). My question is if there is a way in which I could replace all the same textures at once so that they would appear the same throughout the map instead of doing one by one per area. One idea I had was to export all the textures and create a .bat file which would replace all the same named textures in all subfolders, and then import them again to their correct location using OpenIV. But I have taken a mind blank and would like some other opinions.
-
@zombieguy It might seem like a bad idea but it can be better to repeat a single texture to get access to it, rather than load a whole asset set for an area they're not using, just to get access to a single texture.
As far as the map creation went, there was probably just a single texture but the asset packager would have created packages that optimise the usage. Automation does strange things sometimes.
-
@LeeC2202 Maybe for buildings, but for terrain textures which are not massively different for most areas, it makes next to no sense, they should have had shared textures for the whole "terrain" (I know it is made of multiple models instead of one) they have just added more draw calls to the game for no reason with no performance or graphical gain.
-
@zombieguy said in Texture Replacing And Dealing With Repeats.:
they have just added more draw calls to the game for no reason
Actually, if you've looked at those textures, you will have noticed that whilst the texture dictionary name is different, the texture file name is not. I presume you're talking about im_grass10b and im_grass11b, it is called the exact same name in each texture dictionary. So as far as the final draw code is concerned, it's drawing from the same texture... so no additional draw calls are required.
The asset system will get the dictionary and when it comes to extract the assets, it will already know that the asset is in game memory... and this is exactly the point I was making about asset bundles or packages. Every area can have its own set of dictionaries but where the contents of those dictionaries are shared, the same assets are used from pre-loaded versions that have already been used. It might load a different dictionary but it won't re-load the same file. Intelligent asset systems are not as dumb as you think.
Look at the contents of the dictionary to determine what is repeated, not just the fact that the same file appears to be repeated in multiple dictionaries.
-
@LeeC2202 Interesting, however, if they did this method, it has caused them to make the game size bigger from repeated textures, with again no benefit. Also if this is so, wouldn't editing the first texture group where you spawn in/ what gets cached first, cause the surrounding areas to change to those textures? If this is how they did it, it could explain the amount of people having problems with texture popping and lag when leaving certain areas or having the game run for a while,I mean at the end of the day if this wasn't a thing we could have had better textures and smaller game sizes.
-
@zombieguy The benefit is the memory footprint in RAM and VRAM from not using shared texture sets. On disk the textures are packed, so take up little space. It's easier to fit an extra 100MB of repeated textures into a 65GB installation, than try and get an extra 100MB into limited amounts of VRAM using shared textures.
The point about texture caching is an interesting one and on the face of it, seems to create a flaw in my way of thinking. And in all honesty, I would not (or should not for that matter) say that my way of thinking is exactly why they have chosen this approach. I guess in that sense, I have represented my thinking on why it works as being their reason for doing it. That was probably a bit too much of a leap on my part... I was basing it on why I would do that given this kind of situation.
But saying that, maybe there is some checking in place that says
If the textures are identical, use the cached texture.
If the textures are different, use the newer version.If that was the case, maybe the newer textures are rejected and the existing cached ones are used. That mehod would allow them to switch in alternate sizes of the same texture if required and still not affect any of the draw calls. The game doesn't care what size the textures are and UV coordinates map universally on a 0 - 1 basis, irrespective of the texture being 64x64 or 4K.
I don't know... I can speculate based on educated guesses as to why they have done this, the reality is that only they know. I do still maintain that shared textures in such diverse map changes, could damage the overall fidelity of the graphics.
-
@LeeC2202 Fair point, I also just remembered that the game came out in 2013 and had been in development for some time before that, more focused on a console release, and not to mention the development team size, meaning it was probably more time efficient to just use the same texture again in each area that was being developed at a time. The main problem for me is that it affects modding textures where to change one texture I would have to change it in X amount of folders, and if I Increase the res of the texture by 1mb that could make the game in just this one case 12mb bigger or 100mb of textures would make the game over 1gb, its just adding an exponential rise in install size. As for making this fast for myself I ended up creating a tool to replace all texture files with the same name as the texture I input, but unless there is a way around having to do this like so, my plan to fix some terrain textures will be ruined by size as it would mean downloading next to the size of the game.
-
@zombieguy I think the L.A. Roads mods are so big because of this problem, L.A. Vegetation probably equally so. It is a real pain for modders, there's no doubt.
I know I've tried changing textures myself and not only do you have the files in the rpf files to worry about, you also might have the same textures in the embedded textures on some model files. That's a problem that LA Roads really suffers from, as there is texture switching on LODs all over the place. I uninstalled it because it was driving me crazy.
I modded one t-shirt and a set of posters... that was all I could take.
I admire the dedication of anyone who take this kind of task on and 100% completes it.
-
@LeeC2202 Tell me about it, For testing I just replaced a couple of the grass textures (1k textures in .dds format) in what looks like less than 10% of the map, and it has added over 300mb to the game I would admire anyone who would download such a thing
, as many would need to use a mods folder with the x64 files which have been modified, which could easily bring the game to 200gb in no time at all (and nobody wants that). I should of got a free 1tb drive from rockstar when I bought the game.
-
@zombieguy Have you (or anyone else) tried creating a dlc.rpf with just the modified texture dictionaries/files in, much like an addon vehicle, to see if that would overwrite the existing ytd files in the x64?.rpf files?
I saw it mentioned in another thread and it struck me as being a good idea, I just don't know if it would work. It would mean that if you only change one texture in one of the x64?.rpf files, you wouldn't need that 2GB file in your mods folder just to use it.
-
@LeeC2202 Yeah I was thinking about using the update folder before to only update the needed files, but it would still be heavy in size in some cases only a bit smaller (still better though). Another problem I think is that you need to replace the .ytd in full and not just a .ytd with one texture file in it being the one you wish to change. I might try messing about with the DLC/update stuff, however I would have thought by now if there was a way around people would be using it by now.
