Brick Size vs Texel Density + Bonus Question
I'm working on an environment piece for my portfolio and have set my texel density to 5.12/cm for the project. There's 20 x 60 bricks in a 2k texture to get the correct brick size at 5.12/cm. Perhaps this is okay as the texture will have less repetition, but also limits the possible fidelity (resolution) in each brick (and mortar lines).
Should I just stick with the large number of bricks in the texture or reduce the number of bricks and tile the texture (breaking established texel density)? Obviously flexible in the case of a personal project, but also curious how this would be handled in production.
Bonus question about handling bricks at corners. Vertical mortar lines at corners are no good. I'm thinking about making a shader that blends a separate texture set (horizontal mortar lines only) in at 90 degree angles. Are there other techniques to solve this problem? Trim geometry that's mapped differently maybe?
Thanks!
Replies
If you're willing to break your texel density rule why bother setting it?
However.
Doubling and halving texture size doesn't interfere with the benefits of having a consistent texel density. Your texture still covers the same physical area and thus the textures can be swapped and shared freely across assets without requiring UV rework
@poopipe Well the project is still in the early stages so I could still increase the texel density to 10.24/cm across all assets without needing to re-work a bunch of stuff, but I know this wouldn't necessarily be possible in the context of a large production.
Wouldn't I be increasing the texel density to 10.24/cm if I half the number of bricks in the texture and tile it 2x to get more resolution / correct brick scale?
Texel density is only ever a guideline, not a rule - its a place to start, and a target to hit. You may very well (almost certainly) adjust texel density of assets after they're in the project, by reducing res of textures to balance the budget. A 1k texture becomes a 512, your texel density is now halved.
I highly encourage you to try all your ideas out, and see what works best. Post on polycount, share your findings - learning by experimentation is going to teach you far more than some grizzled veteran telling you 'how its done'. :)
The guideline thing is sort of true but not in the way most people will interpret it - which is to say they'll push texel density to the point where they need unique textures on everything and then be all butthurt when they're told to halve the sizes cos it won't fit on a console.
If you're worried about not getting the fidelity you need on textures it's better to try and do something clever with materials rather than throw larger and larger textures at the problem or break with your standardised authoring process.
Decide on how large an area you want most of your textures to cover, 4m seems to work for most applications in my experience but for a corridor shooter you might get away with 2.
Dont feel like you have to make every asset class follow the same rule - eg. you don't want to be dealing with a large landscape 4m at a time - but it will pay to be consistent across a given asset class (wall texture, floor texture etc.)
This isn't necessarily the most resource efficient way to colour stuff in (can be) but it is the most effective way of predicting and maintaining control of the total resource cost of your art content.
Eg. You can choose to drop a brick wall texture and replace it with an existing one in order to save memory without having to re-uv anything
"The guideline thing is sort of true but not in the way most people will interpret it - which is to say they'll push texel density to the point where they need unique textures on everything and then be all butthurt when they're told to halve the sizes cos it won't fit on a console."
Fair point 🤣