<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div><br class="webkit-block-placeholder"></div><div>Last couple of weeks I experimented with numpy to enable scalable</div><div>interactive animations of swarms. The current BPY is not very suited for swarms.</div><div>Manipulating large amounts of individual objects on frame events is too slow,</div><div>and more efficient techniques like DupliVerts or ShapeKeys don't facilitate individual r/w access.</div><div>And the getData() of keyblock is copying data in a very clumsy and read-only way.</div><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Helvetica; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" style="font: 12.0px Helvetica; letter-spacing: 0.0px">So I extended the Key.KeyBlock interface with getBuffer() returning a r/w Python buffer wrapping without copying the underlying keyverts. Then I could handle in numpy the different aspects like positions, rotations, and scales of all subjects as algebraic manipulation of multi-dimensional index matrices without having any loop in Python !</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I did not incorporate yet lost buffers, but I think that a publish/subscribe of buffers for this is more flexible than</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">using tracking IDs and forced 1-1 relations (pybuffers do have a slot to be made NULL when data is gone).</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Using the standard pybuffer protocol for wrapping any contiguous memory-data is very simple, general, fast</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">and save, and removes the burden to do this specific for each Blender type. Specifying types and strides can</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">simply be postponed to the Python level.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Conclusion: when scalability is an issue like in swarms one should prefer direct adressable buffers</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to iterator for loops and list/object conversions at a Python level. And numpy is amazingly suitable</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to bring efficient manipulation of low-level Blender data at an elegant mathematical level.</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br class="webkit-block-placeholder"></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Theo</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><br class="webkit-block-placeholder"></div> </div></body></html>