Garbage collection

Coding Python Support
1

Hi!

Qustion on python.

I use 3 separate NMesh objects to call three times a subroutine
with different parameters, then I collect all mesh data
in a fourth mesh object.

This fourth is the only for wich PutRaw is invoked.

All this is actually within a subroutine

More or less:



	MeshQ1 = NMesh.GetRaw()
	MeshQ2 = NMesh.GetRaw()
	MeshQ3 = NMesh.GetRaw()
	QuadMesh(v1,va1,va4,va3,N,MeshQ1)
	QuadMesh(v2,va2,va4,va1,N,MeshQ2)
	QuadMesh(v3,va3,va4,va2,N,MeshQ3)

	MeshT = NMesh.GetRaw()
	for v in MeshQ1.verts:
		MeshT.verts.append(v)
	for f in MeshQ1.faces:
		MeshT.faces.append(f)
	for v in MeshQ2.verts:
		MeshT.verts.append(v)
	for f in MeshQ2.faces:
		MeshT.faces.append(f)
	for v in MeshQ3.verts:
		MeshT.verts.append(v)
	for f in MeshQ3.faces:
		MeshT.faces.append(f)

	NMesh.PutRaw(MeshT)

Except that MeshT is actually between the arguments of this subroutine and the PutRaw happens in the caller.

Question is:

Those three meshes MeshQ1,MeshQ2 and MeshQ3 needs to be
explicitely destroyed at the end of the subroutine
to prevent memory leaks?

And if yes, how?

THis subroutine is going to be called 8 to 20 times in a row and meshes can be quite big, and user can call it more than once…

Thanx in advance

Stefano

2

-Use the garbage collector module(gc) from python:

import gc
gc.enable()
3 
del variable

Martin

4

Unrelated to your question, but this:


  for v in MeshQ1.verts: 
    MeshT.verts.append(v) 
  for f in MeshQ1.faces: 
    MeshT.faces.append(f)

can be shortened to this:


MeshT.verts.extend(MeshQ1.verts)
MeshT.faces.extend(MeshQ1.faces)
5

Thats pretty cool you guys. I’m glad you started this thread S68. I’ve been wondering about garbage collection for a bit.

Blend On!

6

Thanx, I’ll give both suggestions (del and sortening) a try.

In any case script runs the first time, and crashes Blender on second run. Furthermore newely created objecs are single sided (?) usually with AutoSmooth on and sometimes SubSurfed…

something weird is happening here.

Stefano

7

just before you do

NMesh.PutRaw(MeshT)

set the drawmode of the mesh explicitely to not subsurfaced and twosided with:

MeshT.mode = 260

as jms pointed out overhere: https://blenderartists.org/forum/viewtopic.php?t=16581

wim

8

Aw, thanx for this tip too!

I’l check script on a good machine today, if it still crashes Blender I’ll ask for other helps!

Stefano

9

Hehe… was a NT 4.0 bug!

On Win 2k I don’t even have the singleside-Autosmooth issues!

Anyhow I’ll add that line :slight_smile:

Stefano

Beware! BWF 0.0.8 next to be released!

10

Blender python objects usually have a pointer to a datablock of info (malloc() allocated), but NMesh is a little different.
Calling getRaw() without a parameter will not link the mesh datablock (malloc() allocated) to the python mesh you created (this is normal behavior). Instead it will create a python representation of the data, and set the python object’s data pointer to NULL.
Calling update() on a python mesh creates a new datablock which represents the python mesh’s values.
Also calling PutRaw() will free the datablock (if any) pointed to and the write/rewrite it using the ‘python mesh’ data.
So in your case you are simply overwriting the python mesh’s data and there have been no calls to malloc() to allocate data. (at least until you call putRaw())

As a slide note heres a little blip about blenders gc:(copies out of datablock.c)
" *Blender Objects have their own ‘reference counting’, e.g. a Mesh datablock used by two Objects has a user count of 2. Datablocks with user count of 0 are not saved to Disk – this is the current way Blender does
‘garbage collection’ Therefore, an object should normally not be deleted by Python, but rather unlinked from its parent object. …"

Setting modes(from the python API):
This might be a better way :). Call myMesh.setMode(). Parameters: “NoVNormalsFlip”, “TwoSided”, “AutoSmooth”, “SubSurf”

Anyway sorry for the overkill. :o