Decimator reducing skin textures?

Superdog

I'm trying to reduce the size of Genesis and G2 characters. I've been able to reduce the size of the figure polys with Decimator but is it possible to reduce the size of the skin textures?

The reason I ask is that in Octane Render the size of the object is determined by the textures so a blank Genesis takes up only about 10 MB memory but when the skin is added it jumps up to about 500 MB. My GPU has 3 GB VRAM so I'd like to create some low poly/ low texture figures to conserve VRAM.

Is it possible to reduce the size of skin textures?

SixDs

Unfortunately the only way to reduce the size of textures (assuming that you mean file size) is to reduce the resolution. Reducing the resolution is, of course, going to reduce detail and may not give you the results you are expecting. You can always experiment to see what gives you acceptable results, remembering to create renamed copies as you go so not to overwrite your original textures.

Chohole

Just as a matter of interest (I don't use Octane) does Octane use the compressed textures (jpg) or does it do the same as Bryce does and un-compress the textures so they become the same kb size as a BMP or Tiff?.

if it does you could try reducing the pixel size of the textures in a paint prgram such as Photoshop or PSP and save in an uncompressed format and experiment to see how that affects the quality. When I do this for Bryce I tend to use png format as then they also contain an automatic alpha map but are not so heavy on kb as a tiff would be.

SixDs

As I understand it, Cho, Bryce uses procedural textures, so it needs to convert textures in the form of image files like .jpgs to procedural channels. Technically, .jpg files cannot be uncompressed like a .zip archive, since the compression algorithm used to create them is "lossy" - it achieves a compressed or smaller file size by actually discarding some of the image data. Once it is gone, it is gone for good. It is possible to increase resolution with .jpgs, but it involves a cheat of sorts - the extra pixels are simply filled by using the data from the adjacent original pixels. Naturally, some quality is sacrificed in doing so.

I don't have or use Octane either, so I don't know whether the issue is the same or not (i.e. conversion to procedurals). It may simply be that the image files are huge to begin with, although files of the order being mentioned would seem excessive. It is probably a question that would be better asked in an Octane forum in my opinion.

EDIT: In re-reading the original post, I realized that the poster was talking about memory usage, rather than file size perse. While the size of the data files being used will affect memory usage, the memory being used is (in the example given 10 vs 500 MB) not simply a function of the size of the files being processed, but also of the data being created, as data passes back and forth between the processor(s) and memory. Naturally it involves far less resources to create a render from a simple texture like the plain Genesis base texture than is required for a more complex one. Again, an Octane-specific user forum might offer some insight into what sort of memory use is normal under various scenarios. Frankly, I've never really monitored memory usage during a render, so I don't even know what is normal for 3Delight, Firefly or Lux. I haven't really encountered a problem, so far, so it has never occured to me to do so.

Superdog

Thanks for your replies. I'm not sure how OR handles texture files or if memory usage is to do with processing rather than the actual file size. I'll try to find out from the OTOY forums and report back.