Hello, Polycount.
I've been doing this scene for a while now. I started modeling a gun, a Smith & Wesson volcanic repeater pistol. I finished the baking and the NDO pass and i thought: why just a gun? Why not table, a case and some objects to be around as well? Then i started modeling these things. This is the low poly scene: the table, the pistol original case, a turnscrew, some cleaning rods, a volcanic bullets box, a little carpet, a flannel, a flask and an oil lamp:
But then, after mapping all these things i noticed a discrepancy. I first mapped the gun, making it occupy the whole UV space -- i'm planning on doing 4k textures for it:
The table is using two maps: one for the circular top and some other parts, and other for the bottom and the drawers. So my first obstacle was to figure the following problem: How do i keep the same resolution for the table as the gun? If i select both and, in the Unwrap UVW, i press the rescale elements, the table coordinates become giant islands, way too huge to be place inside the UV space... Same goes for the objects. After days of lonely conjectures, i mapped the whole scene, and i came with this (the discrepancy i was talking about):
As you can see, the mapping is not consistent. Is this too aberrant or can i proceed with this the way it is?
This whole texel density thing has been haunting me for a long time now, i read and read but i can't get over it. Because there is, in one hand, the scale of the UV coordinates, and you can (using max or textools) make them consistent around assets; on the other hand there is texture resolution (1024, 2048 etc.)!
I thought about reducing the pistol to a 2048 map, and then on the larger stuff (the table) using a 4k map, but where does it go my wish of making muh next gen scene?
I plan on exporting it to a Marmoset Viewer, but before this i want some up close screenshots with bigger textures.
I hope some of the bright minds populating this community can send me some light.
Sorry for the long post, my intention was to be as specific as possible.
Sry for bed engrish.
Replies
This is a portfolio piece though, so you can be a bit looser with memory budgets. It's always nice to see someone make a great-looking asset that also is memory efficient. But that's not the most important part. Looking good is.
To solve your issue, use several textures. Table = 1 texture. Gun = 1 texture. Gun case and bits inside it = 1 texture. Lamp and papers and other things on table = 1 texture.
To make consistent-sized texels (texture pixels on 3d surfaces) choose texture sizes relative to the object sizes. A quick way to do this is to make a couple checkermap textures at different resolutions (512,1024,2048) but with the same size checkers (maybe 32x32).
Apply these to the models. Choose the biggest map for the largest object (the table) and choose the other ones so those models' checkers most closely match each other and the table.
They won't match exactly, and that's OK.
You can also use non-square textures to get closer to your target texel density. 2048x1024 for example.
@Eric Chadwick I was only looking for a "wow" factor of the close ups... i'll discard that and make a game ready asset instead.
I guess i was missing a method. What you proposed looks promising, i am going to do what you said. Thanks a lot for the writing! I'll report back once i applied it and have something tangible. Cheers.
For the gun, the case and the table i used a 4k checker; the objects, the box and the small carpet, a 2k one. I think it looks good, consistent and high resolution for screenshots.
However, in order to export to Marmoset Viewer i need smaller textures. 2k is acceptable, but 4k is a lot for the web. How do i proceed in that case? if downgrade the 4k maps to half, in order to keep consistency i do need to do it to the 2k maps as well, and 1k maps seems to low for me.
Am i wrong?
Thanks!
Please don't be mad
Alright! I'll grow some balls and eyeball this shit. Maybe even export the viewer with some camera constraints, if it turns out too ugly hehe
Thanks a lot, Eric! Big fan of your arduous work on Polycount.