[Bf-python] Doubts while porting VRM to blender 2.6x (sort faces arbitrarily)

[Antonio Ospite]

Hi

I am reusing this thread, AFAICS most of my questions are still valid
with the current BMesh API, see the comments inlined below.

On Wed, 15 Feb 2012 23:37:09 +0100
Antonio Ospite <ospite at studenti.unina.it> wrote:

> I am trying to port VRM (http://vrm.ao2.it) to blender 2.6x and I'd
> like to discuss some of the problems I am facing, in the hope that I can
> save some time in case someone else has solved those problems already,
> or to see if future development in blender (I am thinking to BMesh
> here) could help me to keep the script more manageable. I can release
> it after 2.63, 2.64 or 2.65 I am definitely not in a hurry here.
>
> When I firstly wrote VRM I abused the Mesh and NMesh classes to
> store the result of the various rendering steps (projected coordinates
> of vertices, faces color, info about face visibility, etc.), this way I
> could concentrate more on the algorithms and less on the data
> structures.
> 
> To do that I used to sort objects in a scene and also sort faces in a
> mesh according to certain criteria, removing, adding and splitting
> faces; and the old NMesh class allowed some of these operations.
> 
> The new API appears to be stricter about mesh data processing: data has
> to be taken out, processed and then re-added in to a mesh [...]

BMesh is more flexible about mesh data processing but I am still missing
some features.

> I am listing here some hypothetic API I could use to keep on abusing the
> blender data structures as I am doing right now :), if you have some
> time to think about them I will appreciate if you could tell me if
> those make sense to you too.
> 
> I could use something like:
> scene.objects.sort(key=some key based on objects properties)
> mesh.faces.sort(key=some key [face index?] based on faces and vertices
> properties)
>

This would be handy for my use case, maybe it is a bit of a stretch to
use modeling structures for rendering operations, so I will accept a
"you're doing it wrong" type of comments here :)

> This would allow to do the sorting in a more flexible way,
> bpy.ops.mesh.sort_faces() looks quite limited for my use case.
> 
> Moreover, I would be happy if I was able to split a face along a plane,
> something like:
> mesh.split_face(face_index, plane_co, plane_normal)
>

This has been added to bmesh.utils, thanks!

[...]
> 
> Adding and removing individual faces could be handy too:
> face = mesh.faces.pop(index)
> mesh.faces.insert(new_index, face)

IIUC in BMesh, mesh.faces.remove(BMFace) and mesh.faces.new() cannot be
used to fake pop() and insert(), as removing a face will make it dead.

I see that the index in a BMFace can be altered, so what about
something like BMFaceSeq.sort_by_index() to reorder faces according to
the reordered index values? Mh but we have to ensure that the index
values are valid, so maybe not a great idea.

> The question is: is there any chance that functionalities similar to the
> ones I described could be added to blender? Could these be useful to
> other scripts as well?
>

This question boils down to: is the ability to sort faces arbitrarily
(or other elements) something modeling tools can make use of?

> Alternatively I will end up having my own data structures for scene,
> objects and meshes, which is OK too, but that is not lazy enough for
> my taste.
> 

Thanks again,
   Antonio

P.S. Please reply inline, avoid top-posting if you can, so I can follow
the conversation better.

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?