Showing results for 
Search instead for 
Did you mean: 

scene object memory is full



I'm trying to display a 3D object with sensor values depending on my DAQ I want to change the color of the sensor objects. When I'm displaying the model for a few minutes I get an memory error. I do the color update in a while loop and a for loop but I'm not creating new objects so I really don't know what I'm putting in the memory so it can overflow...




Best regards Stijn

0 Kudos
Message 1 of 5

Hi Stijn,


It seems that your While loop is running as fast as possible. Which is not really a good idea.

You should try to add a 'Wait (next ms multiple)' function to slow it down.

Then maybe you could try to change the colors only when needed and not continuously. Otherwise I guess it forces the scene to be redrawn at each loop.

Next thing when using references, try to only get once the ref to your object (method get object to place outside of the While loop) and close ref that you don't need anymore when you're done using them. I guess that could help ...


View Cyril Gambini's profile on LinkedIn
0 Kudos
Message 2 of 5

Yeah, closing references is a MUST when wirking with the 3D picture control.  Try to create your code ins mall building blocks and make sure every step of the way that you are closing all references by letting the code run millions of times and look at the momory requirements.


Even if you're getting a reference to an existing object, the pointer you are retrieving is created, that's 4 bytes per call.  These will NOT be released until you close LabVIEW.  It's imperative that after you set the new ambient peoperties that you close the object reference.


In short: Take theoutput reference of the node "Material.Ambient" and close it.


PS I haven't worked with materials in the 3D picture control so this is speculation but..... If the closing of the reference outlined above doesn't help the code may actually instantiate a new material reference each time you want to cahnge the parameters.  Working with textures can be similarly frought with dangers of lots of multiple texture objects floating around in memory.

0 Kudos
Message 3 of 5

I just checked the object properties for material parameters.  Forget the second part I wrote, the material data is not instantiated (isn't a separate reference like Texture) and as such shouldn't lead to a mamory leak.


Closing the object reference is still recommended though.

0 Kudos
Message 4 of 5



first I slowed down the loop, than the crash happened less often. Second I closed the reference and rebuilded and it looks like this solved the problem


Best regards Stijn

0 Kudos
Message 5 of 5