Feedback My UV/Materials thoughts

Before asking my question, i want to give an example.
Have you ever downloaded a few assets from the store, only to find out they don't really match?
And you find out its because one asset use brighter color wood than the other, or they dont have the same wood-"worn" style to them? Well I have, and often the UV and Texture has been packed into one texture in "islands" making it impossible to correct and match my need. If only i could use my existing materials such as wood and iron etc to replace the wood/iron on the model.

The reason from what i know and just researched again, is mostly performance.
And although performance is a huge deal in games, I often find that as mentioned, most assets don't match each other.

So, about a month ago i started making models to sell on the store. Each model has a separate material to match the .. well material. One for wood one for stone one for iron etc.. One of the models has 5 materials on it. Most materials are reused, meaning the same type of wood is used for different models. The UV scale is not the same though, so it doesnt look exactly the same. But, it looks a whole lot better than a room with furniture from 7 different assets where all furniture are made of different kind of wood materials and in different resolutions.
To make a long story short(too late), here are my questions.

How much does it matter to have 6 materials instead of 1? would you refrain from buying an asset that was made in this way? (I have made it so materials in my asset match, meaning one can easily switch out one type of wood for an other, or iron for an other type of rusted iron etc, and the wooden textures all flow in horizontal so they can be replaced easily as well)
The size of UVs. Often increasing the size of the UV can make it look better. So e.g. on a wooden board i would increase the size of the UV on a seamless wood texture. Does the size of the UV matter performance wise?
One of my items is a chest with 6 materials both on the LOD0 and 1. On some models i have used a 512 texture on lod1 and a 1024 on lod0 for performance sake.


Please leave constructive critism and explain any pros and cons and enlighten me, I really want to learn from all you clever and wise people
Oh and please refrain from replying "what your doing is crap and you should do it the right way", or similar remarks. They serve no purpose what so ever, except stating your IQ to everybody reading this long post - and annoying me somewhat.

 

First of all, you can take any asset and modify the textures to have the same look, by hue/color adjustments, in a prog like Gimp, or photoshop, so your assets have the same look and feel. Another thing is to use Atlas Textures (combining all textures for that model, all together into 1 texture), and theres a few assets on the store which will make atlas textures for you, this will help with performance, but be sure to set the textures resolution/detail.

Answer to question: you want to use the least amount of textures per asset/model (to lower draw calls), as possible, hence Atlas Textures. The actual size of UV's isnt the most important part (performance-wise), the texture resolution settings and atlas textures is. Example: View your model/asset and start lowering the texture resolution till it starts to effect the visual/look of the asset, then you can set the lowest resolution without effecting visual/look. Now, as i said before, open the textures in say Gimp, now adjust the color/hue to your liking, to make all assets "blend" together well. Just because you get assets from the store, doesnt mean you cant mod/adjust them, and use an atlas texture to improve performance.

Hell, theres been times ive used just the model itself from the store, and made my own textures to fit my project. Best of luck my friend, get back to work!

 

Thank you for your reply, i really appreciate it.

I got two follow up thoughts.

1. If you saw my package on the store, and you knew the UV mapping was not set up nicely in islands and such, and not using atlas texturing, then for that reason alone you would not buy it?

2.
Lets imagine there are 100 prefabs, 100 materials and 5 textures(pbr, size 1k) for each material. All prefabs use about 5 of the pool of 100 materials.(not atlas textures)
That would mean all 500 textures would be "loaded" or drawcalled. But the texture size is only 1k.
Making an atlas texture of each prefab would make the size of the texture at least 4k, and likely much more correct? and wouldnt that make it worse performance wise to have 500 larger size textures called? I don't know the technicals of drawcalls, just heard it mentioned here and there.

Thank you again for your input.

 

It could potentially result in x6 the amount of draw calls, which is bad.

To make an analogy with painting, materials are like paint: every time you switch to a another material, the engine must wipe the brush clean, dip it into the new material, and continue painting. So it's best to minimize the amount of times you switch between materials.

Meshes are like strokes: each mesh is a stroke on the canvas.

What batching does is it identifies meshes that use the same material, and schedules drawing in a way that minimizes the amount of switching. It will also merge multiple meshes together to draw them in a single drawcall (brush stroke), as long as they have the same material. This gets you a performance benefit from:

A) minimizing material switching (draw everything that's yellow, then everything that's red, instead of going back and forth between colors)

B) minimizing the amount of draw calls (few large burst strokes are better than many small brush strokes)

Now, depending on whether your object is static or dynamic, batching works slightly differently. While static batching can merge many large meshes into a single one (for a single drawcall), dynamic batching has a limit: it can only merge meshes with less than 255 vertices or 900 vertex attributes in total (attributes being position, normal, uv coord, color, etc). This is because dynamic batching is done at runtime, so it has some CPU overhead: batching large dynamic meshes together would save the GPU work, but would put a burden on the CPU that negates any benefit. Btw, dynamic batching is not currently supported in HDRP.

So your approach would only work well for objects that are supposed to be static (unmovable, part of the scenery) or dynamic objects that have very little geometry, in these case Unity will batch sub meshes together.

I would be hesitant, depending on which kind of meshes they are, how I'm going to use them, and which render pipeline I'm using, because of what I outlined above. There's potential performance issues lurking around.

For example: if I had the treasure chest as a dynamic object that can be tossed around or opened/closed, and each submesh had a substantial amount of geometry it would require 6 draw calls to draw just one chest instance, not good.

Not a problem. Detail textures are often tiny textures tiled a lot of times, should not impact performance at all.