Hi, 

I side with Hannes on this. I see, you have some python components in your definition. If there is no need to maintain this exact methodology , I strongly suggest to rebuild your definition using the embedded v3d component. You'll achieve the same result with only a few components and avoid data tree miss-matches. 

well, my gh is quite up-to-date, and I am indeed using a gh v3d component -it's right there..I know that it's still messy :P The python components are absolutely necessary (unfortunately) and they serve very different purpose ( it allows to move from layer to layer and perform the same action). Ok, let's forget about my definition-- what other options do I have if I want to deform 3d voronois? seeing that they always form into a normal rectilinear bounding-box? Hannes, I don't get very well your idea for the spherical point cloud, I would really appreciate it if you  could elaborate :)

Ok Sofia, i think i managed it! The definition is a bit long, complicated and slow to process - but you can always improve and 'clean' it ;)

The main strategy was the following: because when you 'squeeze' the box there is a deformation on the top side of the box, what i did was populate the deformed surface with 'cell centers' (points) and add them to the collection of points inside the box (that also move according to the deformation). This final 'merged' collection of points will then generate the voronoi cells.

The voronoi cells' shapes depend on the relations (positions and distances) between the generative points - so in the end this would be what you would change, not the end geometry.

Hope it works for you; i'll be waiting for critiques and commentaries ;)

Take care!