3d picture texture memory leak?

[Intaris]

I'm further investigating using the 3D picture controla nd have found out a couple of really cool things.

1. Object instantiation : You can add lots of copies of objects to a scene which allows them to share much data (The "Drawable" item is shared) but allows applying individual scaling, transformation, texturing and so on.  This saves a HUGE amount of memory when instantiating lots of objects.

2. Viewports: You can define several different viewports for a 3D picture which allows limiting the display of an object to a certain portion of the 3D picture.

3. "WindowtoObjectCoords" allows for an easy method to "pin" an object at a specific point on the 3D picture display.  Coupled with a Viewport, we can implement a nice rotating 3D coordinate display which doesn't pan or scale with the rest of the picture.

I then got greedy.  I wanted to start instantiating several thousand primitives, but applying a different texture to each to give a multicoloured effect.  This works fine but whenever I run the program, I get a memory leak and I can't figure out how to get rid of this.  Following image has 8192 instances of a single box with different textures, rotations and translations applied to each.

If anyone could have a look to see what I'm actually doing wrong, that would be greatly appreciated.  The solar system example doesn't seem to suffer from this problem, but it doesn't use multiple instantiation of objects.....

I've had this problem before.  I feel it's related to texturing but I'm not sure.  Maybe the memory leak is only noticeable when texturing is used due to the much larger memory footprint.

Shane.

[Barp]

Shane

For each object you create using "Add Object", you have to close the reference, as this code below. Also, you have close the Set Texture reference too. This should avoid a large amount of references opened and giving you memory leak. If you look at the example for 3D picture control in 2013, you will see the new VIs and examples that try to avoid this issue you are running into.

Hope this helps,

 

[Intaris]

Well, my original code was really uptight about closing ALL references and even used a recursive object deletion (from Vugie's 3D demo) to try to free up memory.  I even went through all objects deleting textures, all to no avail.

Nothing helped.

I looked at the solarsystem example which uses a couple of textured objects and does not close a single reference.  It has no memory leak that I was able to detect.  The functions for adding the objects also states that you only need to close the references IF the output is wired.

So if you want to go ahead and try that option and tell me if the memory leak is gone, that'd be a great help.  I had tried that and I had exactly the same leak as now.  If you get into a state where no memory leak occurs, I'd be very interested in the result.

Shane.

[Intaris]

The ability to free up memory of multiinstanced textured objects is of extreme importance to me.  I'm investigating leveraging the 3D picture control for a future version of our software.  It offers some huge benefits, but if I can't find a way to free up the memory properly, it's going to be a very short evaluation period.....

If there is an official way to free up texture memory (which I presume is the problem here) then could someone please write a tutorial on it?  And if THAT works, can anyone verify that the freeing of memory also works when a single object is instanced many times eachw ith individual textures?

Shane.

[Intaris]

I think I've figured it out.

I need to read the texture reference from the object, then remove the texture and finally close the texture reference.  This seems to result in a HUGE decrease in memory when the VI finishes.  It takes rather al ong time though, but maybe I'll find a way of speeding it up.

Previously I was removing the texture, but not destroying it.  Thus the memory leak.

Shane.

Grr Spoke too soon, I have a memory leak again

[Intaris]

Ok, last post, I promise.

When freeing up memory used for a 3D picture like this, using a recursive method needs to take care to obtain a reference to each object's "Drawable" and "Texture" before removing the texture and ultimately destroying the object.  Then the Drawable and the Texture need to be destroyed also (close Reference).  Done properly it seems to be do-able.  This is because the "Drawable" and "Texture" are pointers to other data structures which are not freed up by destroying the object using them.  They need to be destroyed individually.

So I think I have a working version.  I can instantiate over 65000 objects, each with their own texture, rotation and translation and I can release them after execution with a "wobble" in the LabVIEW.exe idle memory of about 2MB.  That is to say, it increases the first few times and then stays pretty much stable.  The memory usage goes up more than 200MB when running.

Shane.

[drjdpowell]

Do you mind posting the modifications needed to stop your posted example having a memory leak?  I've been working with the 3D picture myself and it sure takes a lot of trial and error to work one's way up the learning curve.

-- James

[Intaris]

I'll post it tomorrow when I re-connect to my work PC.

Shane.

[Intaris]

Turns out plugging the very last of the memory leaks is proving a bit difficult.  At the moment I'm leaking exactly one 32-bit pointer for each multiinstanced object.....

Can't for the life of me figure out where I'm going wrong.

[Intaris]

Here's the now messy code.

I am already close to giving up.