Jump to content
AutoDesSys

textures handling very slow


3dworks

Recommended Posts

This is due to the Base 2 memory constraints of texture handling. 

 

"Memory used for an image map is always squared to the next highest power of 2, (512, 1024, 2048, etc.). For example a 1000 x 800 pixel image will have approximately the same memory usage as a 1024 x 1024 image. And a 1030 x 1024 image will have approximately the same memory usage as a 2048 x 2048 image. Each material displays its Memory Usage in the Color Map Options dialog."

 If you resample your image to 4096 x 2816 it will likely be 4x faster.

 

Here is a FormZ tip with the full info:

AutoDesSys | Tips

 

Link to comment
Share on other sites

...but saying that, if there was a way to improve efficiency, it would be welcomed.

 

A side question, does it matter if the images are 8 bit, 16 bit, 32 bit jpeg, tiff, targa, png.  For example does an 8 bit highly compressed jpeg require less memory than a 32 bit tiff image inside FZ?

Link to comment
Share on other sites

thanks for the hint, this is totally true. as an old school 3d artist i already know how to optimize images. but my point was that we cannot handle medium large size images  practically in FZ. the memory base optimization was an important thing 10 years ago, when everything was coded with an eye on RAM and 8 bit limitation, when we had very much smaller computers. but set apart the gaming industry, it is not any more a big rule in modetn 3d applications,  at least it shouldnt... ;-)

 

 suspect that the image handling code in formz is old ages, was never optimized and slow because of this. internally there should be no difference if TIF or JPG, as image data is handeled internally on the same numerical base. JPG will require less memory on your HD but the same amount as the same image as uan ncompressed TIF inside FZ. not sure if FZ can handle 32 bit images internally.

 

 

Link to comment
Share on other sites

It's 2018 and FormZ should handle this automatically. 

 

Having used both Thea and now VRAY extensively, both have the ability to resize the texture maps on demand to reduce overhead.  Our OpenGL based Shaded and Shaded Full needs to be updated to do the same.  I'm not even sure our material system is 64-bit and multi-threaded?  It feels painfully slow when you load a bunch of modern, large sized maps.  This feels very much like it's unable to use all of the system memory that is available, and starts writing to the much slower scratch disk.

 

We need a significant update to our material system to improve it's speed and memory handling.

Link to comment
Share on other sites

I agree, the texture and material handling seems to me a bit slow. Working with materials is not as fluid as it should be.

 

How do you organize your texture maps? Mine are in the different project folders in the server. That is a problem because formZ sometimes uses time to search files from the server. At least I think so.

Link to comment
Share on other sites

I always keep my texture maps in a 'maps' folder with the project files on the local SSD disk.  Even if I have used the same texture map before, I always make a copy and keep it with the new project.  Hard Drive space is cheap, and I'd rather keep everything together for each project for organization.  Having them saved locally on a SSD should be the fastest as well, yet we still experience the same slowness.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...