Texture size depending on model bounds

[Qrsr]

What size would be ideal if we keep model bounds as reference concerning meshes and textures.

Or Which ratio if we keep model size and texture

Like

• a baby bottle should use 256x256
• a terminal 512x512
• a machine kit 1024x1024
• a wall 2048x2048

In other words, if the shape of object X has measurements of Y it should no bigger than texture size Z.

Any ideas?

Im asking because im doing some texture work and FO4 has many oversized, to high detailed textures for very small objects which in turn doesnt make sense especially if its junk objects, the game is full of it, which turn keep load on the renderer for no reason.

[NeinGaming]

How close you normally get to something also plays a role. E.g. a chimney is way bigger than a fridge, but you often bump into fridges up close, chimneys not so much.

About performance, I think below the point where reading texture data is the bottleneck you don't gain anything, but where that point is depends on the GPU. If I reduced all textures to 1024 I might get some FPS, but then further reducing it to 16x16 wouldn't gain me more, because at that point draw calls and CPU are the bottlenecks for me, not texture bandwidth.

And while I don't know how good FO4 is with that when loading them, once a texture is in GPU memory, they're really good at reading from the appropriate mipmap level directly.

[South8028]

There is nothing better than full UV. UV 4k and 8k eat up VRam less than many 1k and 2k textures. Therefore, the smartest thing is to make one UV for many objects. For example, thematically. All panels of one theme (for example, all panels for a hospital) on one texture. You can make uv 4k×8k, 8k×4k, 4k×4k, 8k×8k. Even in fullHD resolution 2k is not enough, and in 2k resolution all the borders of the meshes nearby will come out as a dotted line.The engine works in such a way that if one material is used for 100 models, then only one set of textures eats up memory. And if each model has its own material, then all these textures are loaded. Also... On an average video card, the engine can pull ~300 million polygons per scene without a significant drop in fps, textures load more than geometry. Therefore, more polygons are better than textures.

Edited April 28 by South8028

[Qrsr]

This helps.

So an overhaul on the meshes must be done first, to unify many texture paths correct? And this would have a super effect probably.

This would also proof my theory with the SCOL vs PreVis and PreCombination research.

It all comes down to unification.

 

[Qrsr]

  On 4/28/2025 at 10:55 PM, South8028 said:

The engine works in such a way that if one material is used for 100 models, then only one set of textures eats up memory.

Expand  

If i undertstand correctly having all the Skyskrapers drain from one texture would already be faster than having all drain from many textures, this would mean less color variance would already stabilize gaming experience ?

[South8028]

  On 4/29/2025 at 12:31 AM, Qrsr said:

If i undertstand correctly having all the Skyskrapers drain from one texture would already be faster than having all drain from many textures, this would mean less color variance would already stabilize gaming experience ?

Expand  

Technically, yes, but you can't cram everything into one 8k texture. I don't bother with vanilla resources at all, I just make one UV when I make my own. For example, I make panels for a factory. All the walls and ceilings are on one 4k UV. All the metal structures are on one 4k UV, complex mechanisms still won't fit on one texture. That's why construction - themed UVs, complex models - each has its own UV. You can also try placing textures for different materials on one UV. For example, all types of metal. One 4k will fit 16 1k textures. This will save VRam, in the long run, 4 times more.Then you can simply move the UV to the texture positions 0.25, 0; 0.5, 0... 0, 0.25, etc. in the materials.

Edited April 29 by South8028

[Qrsr]

I understand. I call by Color Remapindex correct?

If thats so smart which im pretty sure it is, why TF is this not more used in the base game? Limitations with rendering at some point?

It sounds to good to be true.

 

I noticed that hard loaded textures such as landscape and the architecture like i said, are not UV. The impact in having them merged would be enmore, correct?

[South8028]

  On 4/29/2025 at 7:36 AM, Qrsr said:

I understand. I call by Color Remapindex correct?

If thats so smart which im pretty sure it is, why TF is this not more used in the base game? Limitations with rendering at some point?

It sounds to good to be true.

 

I noticed that hard loaded textures such as landscape and the architecture like i said, are not UV. The impact in having them merged would be enmore, correct?

Expand  

You can control the offset of UV coordinates in: bsEffectFx, bsLightingFx materials directly in 3ds, in the very bottom line U,V. In bgsm/bgem materials in the very top lines of the General panel (OffsetU/OffsetV). In nifscope. In the BsLightingShaderProperty material parameters, in the UV offset line.

Why was this not used much in vanilla? Answer: Because Bethesda didn't care. Any activity of any commercial company is regulated by the principle of minimum investment for maximum profit. No one will do anything more than what is already working well.

[Qrsr]

Did you ever measured the difference or does it have a noticeable effect on mouse movement and overall microstuttering?

I can say that just by replacing textures of grass without a GPU usage, there is alot of difference notiable already. So using UVs sounds like a huge improvement. When did BGS started to remove or introduce them do you know ?

[South8028]

  On 5/4/2025 at 3:53 AM, Qrsr said:

Did you ever measured the difference or does it have a noticeable effect on mouse movement and overall microstuttering?

I can say that just by replacing textures of grass without a GPU usage, there is alot of difference notiable already. So using UVs sounds like a huge improvement. When did BGS started to remove or introduce them do you know ?

Expand  

What difference can there be on a modern average PC? Very insignificant. I have ~11 gigabytes of VRam, the game is locked at 60 fps, I play in regular full HD. There will be no difference until I assemble some gigantic location. For bgs, any such process is called optimization. Fo4 is moderately optimized, and optimizing a 10-year-old game looks even more illogical.

I mean that transitions will freeze regardless of the weight of textures. This is loading geometry and physics. If the actor moves - there are freezes.If the actor does not move - there is no freezing. I assume that the physics of havok has the maximum effect, more than the textures. It is the cpu, not the gpu. You can experiment. Throw objects with physics and look at the freezes.

Edited May 4 by South8028