Maximum Texture size
kzamor
Posts: 0
Hello everyone, I need your help.
I am planning on making a few character textures, and I need some pointers on how far I could go so that everyone could render comfortably. For my own use, 4000 X 4000 for the whole body just isn't enough. Too many fine details are lost if you do a torso closeup.
Therefore, I would like to know how big I could go so that the average user could still fit at least 2 Hi-Res characters in a scene plus props
and render in a decent amount of time.
How much RAM and how fast a processor does most users have?
Thanks!
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I agree that better/higher resolution textures are needed, so i support your efforts. For me, I have a few sets i reduced the textures on for use on background figures if i use more than a few, but since I usually do single figures and closeups, I prefer the best quality I can get, but unfortunately I haven't found any with higher resolutions than 4096x4096. I also prefer textures in .png or .tif since .jpegs degrade to much.
Your absolute maximum size is what your video card/OpenGL will support...if it gets bigger than that, it may not display in the viewport.
It may have changed but it use to be that poser could not use larger than 4000X4000. If I remember correctly studio in windows (no clue about mac) follows by twos. If a texture map is 3000x3000 then the computer is going to use the same amount of processing power as if is 4096x4096. If you make it 6000x6000 then its going to use the same power as if it were 8192x8192. A texture that is 9000x9000 would count as if it were 18000 and so on. I think most computers these days can swing 4096x4096 but I'm not sure how many can swing multiple maps at 8192. You also start getting into file size issues. I regularly do textures that are 4000x4000 and total file size on textures gets huge fast. If your doing free products it may or may not be an issue but some brokerages do have polices about how large products can be overall.
A 4096 x 4096 tif or bmp is going to look a lot better than the same size jpg...
Thanks guys. It steers me in the right direction.
I know that most vendors don't like to give numbers, but I will ask, just in case.
How many units do good textures sell, on average? I just need to have a rough idea, to know how far I can go to hire models and spend time on the textures.
Also, how much RAM do most users have in their machines?
Most users have on average of 4-8GB of RAM. Your right most vendors won't divulge that in public but I will PM you.
What your finding there is that the UV templates aren't scaled properly, a 4kx4k torso map might seem hi res to some, but it's actually low res when compared next to the 4kx4k head map, and it's still a lower res when you compare it to the 4kx4k limb map. Sadly even though some of the vender's have moved to Genesis and DS they still insist on creating these out of scale crappy low res textures.
I wont even mention what I think of their secondary textures as it would likely get me banned.
Has anyone released a (female) texture set larger larger than 4096x4096? I've yet to see one.
Also, for those suggesting BMP or TIF, please don't. Use PNG instead. You get the same lossless image, but with MUCH better compression. Especially when run through PNG optimizers like optipng and pngcrush.
Yes and no...
If you are planning on making them as hi-res as you can, then you really must not be worried about file size...so why bother with compression at all? I suppose that if you are concerned with final file size, then png would be the best option. The reason I said tif is the fact that 3delight's native format for textures is tif...that leaves out a conversion or three. Yes, tdlmake will still run and create mipmaps, but it won't convert the texture file. Tif is hit or miss in LuxRender, though. Many other render engines can use tif directly without any conversion, too (Indigo, MR, Houdini...)
Lossless compression is still compression. The best would be to not even convert them, but unless you are taking your own photo references or generating the texture completely by painting it, then it's likely to not be a BMP or RAW image to begin with...sometimes you can find bmp or tif reference/resource files. The worst thing is to convert formats, several times.
But the whole point is moot, if the image is using anything that was at one time in jpg format...which, unfortunately is the output format of most cameras
Most DAZ PA's make there textures 4000x4000. We get numerous complaints if we go higher than that cause of the file size.
Most DAZ PA's make there textures 4000x4000. We get numerous complaints if we go higher than that cause of the file size.
4096 would be a better 'standard'...
Conversion of lossless formats is LOSSLESS. That's the whole point of lossless. I would be very surprised if 3Delight is doing anything differently than other renderers like LuxRender, where it reads whatever file format is given to it straight into an in-memory buffer. There is no conversion taking place when it reads a PNG instead of a TIF.
Yes, you want to avoid conversion when using lossy compression formats, like JPEG. But lossless formats, you will have the exact same data regardless of how many times you convert them. The only thing you might lose is metadata like ICCP profile that the renderers ignore, anyway. So why not use the most efficient lossless format? BMP and TIFs are ancient relics of computing. A PNG will actually load faster because the I/O is the most expensive part of reading the file, dwarfing the CPU effort required to decompress it.
Ran a simple test...
Created a 4000 x 4000 image in GIMP. (A simple gradient background with some cloud brushes used to paint some clouds) and a similar 4096 x 4096 one. I then saved each one, at the highest quality settings for each format, in bmp, png, jpg and tif.
Then in DS I went an put them on a simple plane and rendered.
Then I rendered each image...
The surprising results was that the tif image texture at 4096 rendered fastest...and looked the best, even though it was the largest file size.
The next best, time/looks, was the 4000 tif followed very closely by the 4096 png.
The worst on both counts were the jpgs.
This is the render of the 4096 tif
Full sized it looked even better...
Psuedo-science. "Looks better" is subjective and will be influenced by personal bias. Ignore the different resolutions, higher is always going to be better. Take the TIF and PNG for the 4096 resolution and open them in your editor. Subtract one from the other. You should have a completely black image, since they cancel themselves perfectly because they are both the exact same pixel data. If they don't, then you saved one of them differently (e.g., the tif might be saved as a 16-bit, while the PNG got saved as 8-bit (even though it also supports 16-bit)). Then do the same for the rendered images of the same resolution. They should also cancel. If they don't, then it's more likely due to the random generator in the renderer creating rays to trace than a difference in the input file. You can test that by re-running the render with the same input file multiple times and doing the subtraction test on the resultant images.
Just ran another test...this time I stuck each image on a separate plane and rendered them all at once...and on the full size (not made for the web image) it's more noticeable that side by side that all of them are better looking than the jpgs....with tif and bmp being the best (tif actually having a slight lead, since there wasn't a 'conversion' done to it...it has a 'crispness' that even the bmp misses)
This has been a fun little exercise...I guess for my own stuff I'm going to start using tif images and then packing them as pngs for distribution...jpgs really suck.
Oh...top row 4000; bottom 4096.
Something else that hasn't really been addressed...don't assume 'most users'. Go by the minimum specs that the software calls for. which, I think is 2 GB of RAM...
2GB of RAM gets filled up pretty fast.
I believe 4000x4000 became standard because at one time the Mac version of Poser had that maximum. I presume that's no longer the case.
Yeah...my quick little tif image weighed in at 45 MB...so a couple of those in a scene and it would fill up real quick.
All these elements are really interesting since I'm also developing 4096x4096 textures.
I had a slightly different technical question here, but in the same idea, concerning the weight of a file for a given number of pixels and a same format (jpg in my case).
If you have a 4096x4096 jpg image of approximately 10Mo, and you reduce its quality without changing the number of pixel, just in order to reduce the file weight (down to 2 Mo), will it help users to have fastest renders or less memory usage? Or does it depend only on the number of pixel of the image and not at all on the size in Mo of the file?
I'd assume the average user has the minimum specs for DS4.5, that way it should hopefully work on most users machines without too much difficulty
I have to admit, 4096x4096 is usually more than enough for my needs, though it is nice sometimes to get some good close-ups. Most of the textures I buy are as high resolution as possible, simply because I love having the details available should the camera be near to the character. I'd be interested to see just what a difference a 'super' high resolution texture would do in terms of render time and quality.
At the end of the day, it's all about whether that extra detail is noticeable enough to make the longer render times worth the wait.
I havent' tested this, but I reckon only dimensions in pixels and maybe bit depth affect memory usage while rendering. The renderer doesn't access the compressed data of a JPEG, it's decompressed into a buffer just like any other image. Compressed (i.e. smaller on disk) images are better in terms of performance because they are faster to read from disk and take up less space in the operating system's file system cache.
Edit: had to remove a nonsensical portion which was a response to something else entirely. Oops.
File size really only affects disk space usage, and very marginally render start-up time as a larger file will require more I/O to read. But that startup time is typically dwarfed by the actual render time, so the one-time start-up cost can be ignored.
When the renderer reads the image into memory, it is decompressed and stored at raw resolution and bit depth. So it will always use the same amount of memory for a given pixel resolution and bit depth, regardless of the size of the input file. E.g., an 8-bit RGB 4096x4096 texture will always use 49152MB of memory.
File size really only affects disk space usage, and very marginally render start-up time as a larger file will require more I/O to read. But that startup time is typically dwarfed by the actual render time, so the one-time start-up cost can be ignored.
When the renderer reads the image into memory, it is decompressed and stored at raw resolution and bit depth. So it will always use the same amount of memory for a given pixel resolution and bit depth, regardless of the size of the input file. E.g., an 8-bit RGB 4096x4096 texture will always use 49152MB of memory.
While that is true of the renderer, DS itself will use the compressed image for display purposes...so in reality you will have any given image loaded into memory twice, when you start to render (along with it being written to a disk cache/temp file).
Wow, wow, wow!
Thank you so much everybody!!!
I did really not expect to have so many clear and technical answers!
I'm really happy with all I read here, total pixel result in RAM, but file size well... results mainly in file size on disk!
Thank to all of you, I got my last day busy remaking all my textures with full resolution jpg now, allowing to keep all the small close up details I was so sad to lose before.
Thanks again, and may you have a great and happy day!