[Bf-committers] Mesh development freeze

joe joeedh at gmail.com
Tue Apr 14 15:40:59 CEST 2009


On Mon, Apr 13, 2009 at 2:33 PM, Brecht Van Lommel
<brechtvanlommel at gmail.com> > Can you give an estimate for how long
this freeze would be needed?

My current rough estimate is six to eight months.  People would still
be free to help out with the bmesh project, of course.  As I
mentioned, we've been bitten by concurrent work problems before.  The
"freeze" would end when bmesh is at a state to be merged back in to
the 2.5 branch.

It shouldn't take me more then a few weeks (about equivalent to three
or four days working consequatively) to get the initial major refactor
done.  Once that's out of the way, we'll have a buggy, but working
system where:

1. bmesh has replaced editmesh, for editmode and the ***EM functions
in modifiers.
2. editmesh tools will still work, by way of using the accessor
functions I made.
3. mesh dna will still be unchanged, I'm planning on doing that later.
4. derivedmesh will be unchanged.  IMHO, derivedmesh needs to be
completely redone,
    but no one has the time, so most likely we'll end up fixing the
parts the most need
    it, add face iterators so ngons work in e.g. subsurf, etc.  but
I'm currently not planning
    on doing this myself anytime soon.

>
> Which mesh DNA changes are needed? I thought f-gons flags would be
> sufficient at that point?

Fgons rely on tesselations, which are a geometric property of the
mesh.  Relying on geometry to accurately recreate topology causes
issues, since deformed ngons may disappear if they can't be
tessellated correctly.  We also can't use scanfill because of this,
and the algorithm we are currently using (while relatively stable) is
really slow.

Currently I'm thinking of doing both; mfaces will store the
tesselation, while an additional layer will store the original faces.

Joe


More information about the Bf-committers mailing list