Listening to the radio, driving, taking a shower, lying in bed moments before sleep, chatting with any anonymous person about anything pertinent to life. The key to this very unordered list is the category “places where ideas can strike you.”

I chatted briefly with a woman who sets up and maintains greeting card displays for a living. I was looking for a card and she happened to be there straightening up the displays after inventory, so I hunted while she straightened. We talked about people’s varying tastes and how one card that might be hilariously funny to some people could be ultimately offense to some wimps somewhere. Well, that was my take on it, I won’t put words in her mouth.

My conversation with the card lady, who I’m choosing just now to call Maureen, ended when I found my cards and she finished her work but not before we stumbled onto a good idea for a website/social network. There’s little likelihood I’ll ever build it or even think much about it after today or this week, but something about an idea getting tossed around between two people who know basically nothing about each other interests me.

As a constant idea tosser, I spend a good part of every day cooking up grand (and not so grand) schemes for everything from a shorter route to work by bicycle to pondering what little I understand of the world’s distribution of power and wealth. Whether alone or with a Maureen, ideas come along at very strange times. As long as the ideator keeps her or his mind open to new concepts and/or complete abandonments of old ones, the possibilities are endless for what you might stumble into conceptually.

Having the thought, owning the thought, and executing on the thought are of course three very different things. For me, most thoughts (probably rightfully) end shortly after they start with no harm done to anyone aside from the lost brain cells others incur when I can’t keep them to myself. However, there have been several that have really stuck with me. A few of which I am executing on, the world be wary.

I suppose now that I’m reaching the end of my appetite for writing that I didn’t really have much of a point, except to mention what I’m sure many others have noted: ideas come along in unexpected circumstances. Maureen, wherever you are now, whatever cards you are arranging, the world (or at least archive.org and Google’s cache) will remember we talked. *Sniff*

Working on a large Papervision3D project, I had begun to notice a constant increase in RAM usage as the Scene was running. This particular scene does a lot of updating of BitmapMaterials and Planes, responding to user input by transforming a thumbnail plane into a larger full view plane. The animations run about 1 second, with roughly (on faster machines) 30 frames per second. On most machines out in the ether I’m hoping to maintain 20 FPS.

So, what I noticed was that there was a pretty large spike in memory usage when the scene first loads–no problem, I’m loading a couple hundred images in, I should expect that. However, I noticed also that as I transitioned from one image to the next (the smaller to the larger), RAM use would jump up about 10 megabytes. Where is garbage collection when I need it?

The trouble turned out to be that I was re-instantiating a BitmapMaterial object during each from of the animation. For whatever reason (I haven’t had time to walk through the BitmapMaterial and MaterialObject3D classes carefully yet), BitmapMaterial objects seem never to leave memory. The issue may be more complex than this though, as I’m also reinstantiating a plane each frame as well to accommodate the changing siz. Perhaps the Plane is not leaving memory either?

Combing the web, I found an article on the Papervisio3D 2.0 Alpha “Great White” (http://thebackbutton.com/blog/47/materialmanager-memory-leak-in-papervision3d-great-white/) in which he mentions the whoas of a certain Singleton object that goes by the name of MaterialManager.

I scrubbed my Papervision3D 1.5 hierarchy for the same and found nothing. Looking a little further though, I found in the SceneObject3D class a reference to a class called MovieMaterial, which has in it a Singletonish static method called updateAnimatedBitmaps. This function references the animatedMaterials dictionary, containing (presumably) references to every material in the Scene including the one’s that I want, expressly, to die.

My apologies to anyone expecting a clearer outline of what’s going on with the animatedMaterials dictionary. You won’t find it here. You will however find a couple of fixes for this particular flavor of memory leak.

The first fix I found was to create a private class property of a BitmapMaterial object for each item that gets displayed. The class arrangement I am using has an composed DisplayObject3D inside of a class that handles event assignment, etc. So, by instantiating this BitmapMaterial once and simply changing it’s texture property each frame of animation instead of reinstantiating it, the animatedMaterials dictionary doesn’t get bloated with invisible BitmaMaterials, and the RAM uses stays where it should. Each frame I would then reapply the material to the newly resized plane.

A second fix, taking a note from Alex Bustin (see link above), is to simply comment out the lines of code in the SceneObject3D class that run the updateAnimatedBitmaps function. Both of these fixes seem to do the trick, I’ll leave it up to you decide which feels better.

I hope someone else might find this useful. Maybe you can spare yourself the three hours of trouble shooting. =P.