Age | Commit message (Collapse) | Author |
|
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.
|
|
more serious warnings, and also non-backbuffered selection sortof works now, though it still needs plenty of work.
|
|
replaced with bmesh. this is not usable by any means. for those who read through this, note the design is still fairly messy in places, and fyi BMTessMesh is the replacement for EditMesh, I need to rename it to BMEditMesh.
|
|
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
|
|
main features are:
* Modifiers can now be in any order in the modifier stack
* DerivedMesh now has a standard framework for custom element data to be passed
through the stack with mesh data (being copied and interpolated as
appropriate), so modifiers can access whatever data they need
* The modifier stack code has been refactored and a number of bugs have been
removed
* The EdgeSplit modifier has been added:
http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier
* The DerivedMesh modifier has been added:
http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier
* The UVProject modifier has been added:
http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier
For more info, see:
http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade
(currently undergoing reorganisation)
|