3dworks Posted September 30, 2015 Share Posted September 30, 2015 this is an old issue, but as soon as i am using larger than 2-3K sized textures, FZ starts to show the beach ball each time an object with such a material is activated, even in wireframe mode. in my specific case i am using a JPG (but i also tried PNG) with 9K x 6K resolution as an underlay reference mapped on a plane. as underlay tools are missing some features i need to have a real plane mapped with my high resolution reference bitmap plan. now i would like to ask you to speed up FZ operations involving larger bitmaps. with 64 bit, super fast opengl and a modern program architecture it should be possible to display those textures in a decently fast way, or not? honestly i know no other 3d application being so slow when it comes handling large size image maps. i am using a decent mac pro with 48 G of RAM and dual 6 core CPU and a nvidia GTX 980ti card with 6 G of RAM, which should be fast. but maybe it's a mac only issue, anyone else experiencing this? regards markus Link to comment Share on other sites More sharing options...
Tech Posted September 30, 2015 Share Posted September 30, 2015 Hi Markus, Yes, that should be a good fast machine. Can you please send a simple file and your very large map so we can test this here? (We did a quick test but that did not reproduce what you report, and there could be a lot of different variables...) Link to comment Share on other sites More sharing options...
3dworks Posted September 30, 2015 Author Share Posted September 30, 2015 yes i can send you the test file tomorrow! thanks for investigating. Link to comment Share on other sites More sharing options...
rich f Posted October 1, 2015 Share Posted October 1, 2015 You might try a .tif with LZW compression rather than a jpeg... I seem to recall having issues with excessively large jpegs. It also helps to keep the texture map sizes to powers of two (at least in the largest dimension.) So if you can reduce your 9k image down to 8192 x whatever that may help. As it is now your 9k x 6k image is using the same memory as a 16384x16384 image, which is huge. I generally try to avoid anything bigger than 4096x4096. Link to comment Share on other sites More sharing options...
Tech Posted October 1, 2015 Share Posted October 1, 2015 Hi Rich, Yes, reducing the file to powers of 2, especially to 4096 made the file nice and quick again. We will see what we can do about the 9k image, but the 4k image looked fine (at least to us). Thanks for sending the file Markus... Link to comment Share on other sites More sharing options...
3dworks Posted October 2, 2015 Author Share Posted October 2, 2015 hah, the old powers of 2 trick - it is so 90's (LOL) - but seriously, nowadays a 9K sized texture should not slow down any 3d program, especially if 8 bit... Link to comment Share on other sites More sharing options...
rich f Posted October 2, 2015 Share Posted October 2, 2015 hah, the old powers of 2 trick - it is so 90's (LOL) - but seriously, nowadays a 9K sized texture should not slow down any 3d program, especially if 8 bit... Well, computers are still binary, its not like the fundamental tech has changed... Consider that (as I understand it - maybe Z can weigh in) an image gets uncompressed when it renders. That 9k image reserves equivalent space to a 16k x 16k image, which is a 768MB uncompressed file. Maybe other programs would handle it better, I don't know, but it seems to me that size map would bog anything down. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.