New extrude code was accessing an uninitialized
variable. Why this sort of thing doesn't cause
crashes on windows, I dont have a clue!
Note for Joe: I see a lot of 'logic' going on in
the client code for extrude that should possibly
put inside the BMOP system itself (aside from the
part about modifiers). This should be cleaned up
in future maybe...
that handles some non-manifold situations better without failing.
Also made edge subdivide use a more specializzed internal version
of BM_Connect_Verts, that should hopefully always split the correct face.
Dissolve verts also now has checks to not accidentally dissolve
unselected vertices. It's not kindof a hybrid tool, using dissolve
faces where it can to dissolve verts for robustness, and using
BM_Dissolve_Verts where it cannot.
And removed some cruft from a few API functions.
that does that needed to be split in two. this made dissolve faces sometimes
not work.
also added some api functions to recalculate normals for verts, edges and
faces. and added a new flag, BM_NONORMCALC, to prevent this from happening
on individual fgon faces after they are tesselated. and made dissolve faces
happen on fkey in all the selection modes, not just face select.
how original edge loop worked, and made it so if it starts
at a boundary edge, it walks across the boundary. I'm not
sure if this is bad, most of the time I do that I want it
to do that anyway.
Used it to implement the dissolve faces operation (previous
incarnation was just a debugging hack). The code works by
creating one giant new face per region of faces.
The dissolve verts (xkey->collapse, heh need to rename it)
operator now invokes dissolve faces on the faces around verts.
This is less error-prone then a pure topological/euler based
solution.
Join Face Kill Edge now checks to make sure it wont create
a face where the same vertex appears twice in the loop cycle.
Note to Joe:
This is what we talked about on IRC a while back. It
seems to work from here, but you should probably give it a
really good test in the vert dissolve code.
Added a new euler that will take as an argument a face
that is part of a disk and a vertex in the face. The euler
will then 'unglue' this region. An example of this would
be two cones joined at the tip...
Note that this code is untested and probably will have
bugs so shouldnt be trusted yet...
* implementation of a proposal from during Wintercamp:
- with SHIFT-LMB drag of area corner the area gets
duplicated into a new window.
This is the old "Rip Area" operator with a new,
better name. The old menu and hotkey are now gone.
This means we have currently split, join and now
duplicate/copy area into new window in the area
actionzones.
removed epy docstrings from RNA python api, since Python can get this info from rna. (could be redone in python if getting doc's on RNA is needed)
epy_doc_gen works again
like so:
[opname] [slotname]=%[format code]
Before it was relying on the input format codes being in the same proper
order as the slots, which seemed like a potential maintainance nightmare to
me. Also the flags for creating buffers from bmop flags or header flags,
now support additional modifiers for combining vert/edge/face inputs.
E.g. %hfvef would accept all geometry with a header flag, and
%fef would accept edges and faces with a certain bmop flag set.
Example from the UI code:
if (!EDBM_CallOpf(em, op, "del geom=%hf context=%d", BM_SELECT, DEL_ONLYFACES))
return OPERATOR_CANCELLED;
(remember EDBM_CallOpf is the UI wrapper for this that does conversion,
error reporting, etc).
On todo is cleaning up/splitting bmesh_operators.h,
since it's kindof a mesh right now. I'm thinking of adding the slot
names in comments next to the slot ids, but I definitely would have to
clean up bmesh_operators.h first, or it'd just be too chaotic for me.
BTW, the operator API should now have enough meta info to wrap with
a scripting language, not that it matters since that's not happening till
much much later.
Also hopefully corrected some SConscripts, fix mostly provided by Elia Sarti,
though I also copied some SConscripts from 2.5 (not sure if doing
so was especially helpful).
Finally, I refactored a few places to use the new operator calling api,
as an example of how this is beneficial.
- WIP commit
- bookmarks toggling (region collapsing needs to be done still)
- switching between display types in header (long filenames needs to be done still)
code, and also because calling operators was such a pain. The basic form of the format
is "opname %[code]", where each % matches to an argument.
The codes are fairly simple:
d - int
i - int
f - float
h[v/e/f] - all verts/edges/faces with a certain header flag.
f[v/e/f] - all verts/edges/faces with a certain flag.
For example:
EDBM_CallOpf(em, op, "dissolveverts %hv", BM_SELECT)
will call the dissolve verts operator.
The relevent functions are:
//calls a bmesh operator, doing necassary conversions and error reporting.
int EDBM_CallOpf(EditMesh *em, struct wmOperator *op, char *fmt, ...);
//execute an operator
int BMO_CallOpf(BMesh *bm, char *fmt, ...);
//initializes but doesn't execute an op.
int BMO_InitOpf(BMesh *bm, BMOperator *op, char *fmt, ...);
//vlist version of above.
int BMO_VInitOpf(BMesh *bm, BMOperator *op, char *fmt, va_list vlist);
Note this system is dependant on getting the slot codes from the argument
order. I'd like to make it better, possibly pass in slot names, but that'd
mean actually giving the slots names (which I can do, but wanted to discuss with
Briggs and others what I have now first).
