Yikes, quite a lot going on in this thread! I apologize for the lack of updates in this area, and will try to clear things up a bit.
Just got me thinking how nice it would be to work in Blender this way, but there’s not really been any news on Bmesh for six months or so…
The work to be completed is fairly straightforward and I have a pretty clear idea of what needs to be done still. However I really don’t have too much time for it as of late. “Real life” concerns like work and social obligations have kept me away from coding on it too much. I’m still working on getting the final bits of the API polished here and there where I get a chance, but even when that is finished, it will still take quite a bit of work to integrate it as an edit-mode/modifier stack replacement. This is actually something that would take a competent coder only month or couple weeks of full-time work to accomplish. Doing it piece-meal is rather difficult however, so any coder who is willing to take on the burden of integration work would get my full support/input.
The slowdown of wings is not down to Ngons per se, rather the “winged edge” data format, where every edge needs to know about its relationship to all the other edges in the mesh (or something like that anyway), which makes models get slow really quickly when the poly count goes up…
My ears perked up when you said this, hope you don’t mind me commenting on it
The storage requirements for winged edge and access times are actually very good(scale linearly if I recall correctly). As far as I know, the slowdown of Wings has more to do with the Erlang language. Its a huge memory hog and wasn’t really designed for use in applications like Wings. Despite that Erlang is really nice to code in (I wrote the RWX exporter for wings yonks ago).
Another problem with Winged Edge is that it is really quite old and offers little (or no) advantages over other structures like Half-Edge. Thats a technical detail however, and the author of Wings has done a phenomenal job with the application which provides a benchmark for other modeling applications to live up to.
But I don’t know how will be the performance for a ngons subdivision scheme with a new data structure,maybe can even be faster,what I’m sure is that blender now is a bit slower than some years ago with subdivision and for me the best advantage compared to maya and 3dstudio max was the fast subdivision,I simply hope things don’t get worse(maybe I’m arrogant but I have never had problem in
Blenders subdivision modifier currently uses N-gons for its internal data structures. Its performance should remain the same regardless of B-Mesh.
Personally I’m against n-gons,I prefer clean modelling, I hope that the new bmesh will be fast(at least as fast than now),I don’t like slowness when moving point,3 years ago blender had the fastest subdivision modelling tool on the market,now is slower than previous(modifier have advantage but not on speed),going down again for me should be a real pain…
Performance is a difficult subject to discuss, because there are so many factors involved. However it seems what you are concerned most with is draw/refresh rate, which is an issue that can be tackled apart from the underlying mesh structure. Blender’s draw code uses what was ‘best practice’ for OpenGL a decade or so ago. Massive speedups in this area can be seen with a more modern approach.
It should be noted that B-Mesh does have higher memory requirements than the current Edit-Mesh structure. However this is a cost that can be more than offset through better infrastructure.
I would also like to thank the Blender community for continued interest in this project. Hopefully there will be more news to report on it soon!