View Full Version : Adding texture to surface of Primitive Type - Shape

03-22-2019, 06:02 AM
Adding texture to a surface of "Primitive Type - Shape" doubles the amount of allocated RAM for this texture. Can someone please tell me if this is a bug, and not "by design"?

EDIT: and the same is with Volumetric type

03-26-2019, 03:34 AM
Can you provide more detail here? When you say "texture", do you mean an image or a procedural, for instance?


03-26-2019, 04:08 AM
Hi BeeVee,

by texture I mean bitmap like MyPicture.tiff for example. Procedural should not consume considerable amount of RAM like bitmaps in Image Editor, right? So I load a texture let say 1,5GB compressed TIFF (11GB uncompressed in RAM). At that time Layout allocates aprox. 11 GB of RAM. Add null, Primitive Type to Shape. Go to surface editor, add node for 2D Textures > Image, select that texture previously loaded in to the Image Editor and Layout RAM consumption jump to 22GB.

03-30-2019, 09:18 AM
Just an update. I did some additional more precise testing and found out that this kind of behavior is normal within Lightwave. It is just how image loading works. For some reason image loaded in F6 window does not consume as much RAM as image actually loaded/used in a node editor. It seems that Lightwave saves RAM with images not used anywhere, so only when image is actually used somewhere LW decompresses it. The same behavior is in LW 2015 / 18 / 19. So, everything is OK.

03-31-2019, 05:06 AM
But, because this thing still bothering me how it is behaving compared to the LW2015 I did some additional tests. First I must say that this case caught my eye when LW 2019 began crashing without any LW message and that was probably due to insufficient RAM, but not according to the task manager (short version). I am working with some large compressed TIFF images witch needs a lot of RAM. My current PC is a HP workstation with 96GB of RAM and pagefile.sys manually limited to 1GB for max performance. For this test I am using discovery edition of 2015 and 2019, and licensed 2018. I was planning to upgrade to 2019 till today, but this plan is off the table for now I think. The test includes one 8 bit image (compressed TIFF, size on hdd=400MB) and a 16bit image (compressed TIFF, size on hdd=4,1GB). Below are some results done on win7 and OSX how much RAM the layout consumes when image is loaded into "F6" window (w/o node) and actually image used in some node network (w node). Images are used for either surfacing or displacement.

osx 2015.3
8bit image w/o node=4,21gb w node=8,3gb
osx 2018.07
8bit image w/o node=4,27gb w node=8,4gb

win7 2015.3
8bit image w/o node=4,4gb w node=8,7gb
win7 2018.07
8bit image w/o node=4,5gb w node=21,7gb
win7 2019.03
8bit image w/o node=4,5gb w node=21,7gb

win7 2015.3
2 x 16bit image w/o node=6gb w node=12gb
win7 2018.07
2 x 16bit image w/o node=24gb w node=48gb

I think that is obviously that there is some sort of a bug in Windows LW 2018 / 2019. In worst case LW2018 uses as much as four times more RAM in Windows compared to LW 2015. OSX version seems to work as expected. Can anybody confirm my observations?