[Bf-python] ThinMesh

Campbell Barton cbarton at metavr.com
Sun May 8 06:56:04 CEST 2005


joeedh wrote:
> Stephen Swaney wrote:
> 
>> In another thread Cam Barton wrote:
>>
>>  
>>
>>> Keep in mind that some people use Meshes that just
>>> about fill there entire system Ram, so making a copy of ALL NMesh data
>>> ... is not very efficient.
>>>   
>>
>>
>> One of the original bpy design principles was that the bpy interface
>> would be thru thin wrappers around Blender data.  'Thin wrappers' means
>> that the bpy objects do not make copies of blender data, but instead
>> provide a python interface to it.
>>
>> For most modules this is true, but NMesh is an exception.  It spends a 
>> lot
>> of time and memory making duplicate copies of existing arrays.  
>> Obviously,
>> this is not an efficient use of resources.
>>
>> Willian and I have discussed the idea of a ThinMesh type that provides
>> a true thin wrapper around Blender's Mesh objects.  By accessing 
>> blender data directly, we would see big improvements in speed and
>> memory consumption when dealing with large meshes.
>>
>> At one time, this may have been challenging for us, but now that our
>> Python extension skills are much improved, maybe it is time to revisit
>> this idea.  Anyone looking for a project?
>>
>>  
>>
> Main problem: Mesh the structure does everything, and I mean everything, 
> in arrays.  So, say to add a vert you have to reallocate the *entire* 
> array.
> 
> obviously there are some methods of dealing with this, like leaving room 
> for expansion. . .but still, I'm not sure if a thin wrapper would be an 
> improvement for Meshes.
> 
> Implementation-wise, I would probably write a python list object that 
> deals with C arrays and creates wrapper-objects on-the-fly.  Writing it 
> in Pyrex might be a good idea, although me personally, I would write the 
> module in just normal C.
> 
Is what your hinting at- late initialization? This has been suggested 
and is probably the best option. it also could fit seamlesly into the 
current framework.
len(mesh.faces), len(mesh.verts), mash.mode, mesh.name ... etc. should 
be able to be accsessed without initializing the vertex/face data.
Ot might also be worth seperating the vert/face initialization so they 
can be initialized seperately.

- Cam,



- Cam



More information about the Bf-python mailing list