[Bf-python] PutRaw()

[Gilbert, Joseph]

-----Original Message-----
From: Willian Padovani Germano [mailto:wgermano at ig.com.br] 
Sent: Friday, September 19, 2003 12:14 AM
To: bf-python at blender.org
Subject: Re: [Bf-python] PutRaw()

Hi,

From: <models at paposo.com>
> Ok. This is sorta a separate post. I was looking at putRaw() and noticed
the
> following:

Boy, this NMesh module is quite peculiar, mm?  I thought I knew the code,
but had to read and re-read carefully your email : ) ...

The original idea was that:

- To grab a mesh for reading data (export, probably) or make changes to it,
we should use GetRaw() and, if changed, nmesh.update().

- To create a new mesh: New().  To 'make it real': PutRaw().

So an existing mesh doesn't need PutRaw unless the user wants to save it as
another mesh -- to copy it, changing the mesh linked to an object, if
me->id.us > 0.

> Problem #1:
> One of the problems here is with 3) when the datablock exists but has no
> users - the call to set_mesh leaves a default datablock hanging around:

Ok, I'll talk to Ton to see what he thinks about freeing mesh datablocks.
If this is fine we can follow your suggestion.  Some workaround is also
possible, to create an object without adding a default mesh to it (maybe
creating an empty then changing its type, or simply postponing creation of
the ob->data).

> Problem #2:
> This one's no so obvious.
> When calling PutRaw(nmesh) with no 2nd parameter the following line gets
> called:
>
>  else if (nmesh->name && nmesh->name != Py_None)
>        new_id(&(G.main->mesh), &mesh->id, PyString_AsString(nmesh->name));
>
> This executes only when the nmesh came from GetRaw() or
GetRawFromObject().
> This is because all other nmesh's have Py_None as a name.

Not necessarily, users can set the name before using PutRaw.  There's
actually a high change that they'll do it, so we can't assume Py_None.

>   if (name) //renames mesh datablock
>    new_id(&(G.main->mesh), &mesh->id, name);
>
> the above else if will only execute when nmesh is derived from an existing
> mesh and we are calling PutRaw().  If there are user counts (i.e. it's
> linked) it will follow what normally happens in situation 2 - it will
update
> the mesh, else it will create a new object and link the datablock. No more
> floating default meshes!! yes.

If we avoid or get rid of the default add_object() mesh, there should be no
problem with id's, there's lengthy code there to grab the first free "slot"
in Name, Name.001, .002, etc., from what I remember.

So if there's no support already for creating data-less objects, I'll talk
to Ton about freeing libblocks internally.

To help standardize the interface, I'm also thinking about adding
NMesh.Get() as another name for NMesh.GetRaw(); same for NMesh.Put() ==
NMesh.PutRaw() and then only documenting the shorter names.  Minor thing,
but can help a little in separating the normal interface (Get, New) from the
peculiarities of GetRawFromObject and PutRaw -- with proper documentation of
PutRaw and nmesh.update, of course.

Thanks again, Joseph : ).

--
Willian, wgermano at ig.com.br

_______________________________________________
Bf-python mailing list
Bf-python at blender.org
http://www.blender.org/mailman/listinfo/bf-python