| Age | Commit message (Collapse) | Author |
|---|
|
to true/false in code using them).
|
|
also remove CDDM_Check, theres no need for it.
|
|
|
|
|
|
arrays.
|
|
render engines). Replaced generating orco_index by filling the UV loop data
directly which is easier and all that needed to be done anyway.
|
|
|
|
ideally these would be used as generated coordinates, but this is tricly because cycles calculates its own orco's and doesnt know about curve settings.
|
|
Refactored code a bit to make naming a bit more clear and added a
function to create mesh from given display list rather than from
object's displist.
Tested using plain curves (which doesn't imply using derived meshes)
and curves with constructive modifiers (which are using derived meshed).
|
|
|
|
|
|
for speed (it was being called when it didnt need to), but for CDDM meshes without face normal layers this should still be called.
|
|
also remove large, duplicate comments from sunsky.h
|
|
|
|
- spelling - turns out we had tessellation spelt wrong all over.
- use \directive for doxy (not @directive)
- remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
|
|
- copy & rename EditMesh stricts for use with scanfill (remove unused members)
|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
the input to be a CDDM.
remove conversions to CDDM for edge split and bevel (will give some
speedup).
|
|
Renamed CDDM_get_face() to CDDM_get_poly() to match array access
functions. Added function definitions for CDDM_get_loop() and
CDDM_get_poly().
|
|
this function caused too many conflicts and in most cases was zero anyway.
|
|
- were tesselating 2 times and didnt need to.
also comment array modifier from flushing selection flags.
|
|
also add a workaround for CDDM_recalc_tesselation_ex() which would add a CD_NORMAL to dm->fdata and then overwrite immediate
|
|
no functional changes since all callers use this so far.
|
|
* CDDM_calc_edges --> CDDM_calc_edges_tessface
* CDDM_calc_edges_poly --> CDDM_calc_edges
|
|
* CDDM_calc_normals
* CDDM_calc_normals_tessface
these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
|
|
|
|
|
|
|
|
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
|
|
|
|
Multires interpolation is considerably better
now, though it still has a problem with occasionally
producing little random tangent spikes. Still, it's
far better then it was.
Also fixed a bug in dissolve faces.
|
|
Coded a new modifier, "Precision UV Interpolation",
that triangulates, subdivides, then uses brecht's mean
value interpolation to interpolate face data.
Textures on ngon faces get interpolated a bit nicer, in
other words (though concave cases, e.g. 'N', don't work very well).
|
|
|
|
|
|
|
|
|
|
|
|
msvc (though further work may be needed because changes made by the merge
|
|
disabled for realtime displaying but enabled for rendering.
- Calculate tex space for curves before modifiers applying.
|
|
Used approach with creating DerivedMesh for curves whet they've got such modifiers.
Available modifiers are: array, edge split, mirror, solidify, subsurf.
|
|
|
|
|
|
course it handles ngons properly now.
|
|
|
|
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
|
