If the "UV" texture coordinate option is selected while no UV layers exist,
the UV layer name in the modifier is blank. This is not a problem while no UV
layers exist, but if a UV layer is added the modifier code attempts to use
UV coordinates without handling the missing layer name correctly, leading to a
segfault. This only occurs when the modifier stack is recalculated before a
modifier UI redraw, as the UI redraw updates the layer name.
This fix handles a missing UV layer name by setting it to the active UV layer.
This commit fixes displace modifier to propery support arbitrary uv
layers. This seemed like a fairly big usability bug,
as displace modifiers would use the active UV layer (and thus could change when
you changed the active layer). The modifier UI code now uses a menu for browsing
the uv layers, however only the uv layer name is actually stored, so that
adding/deleting layers won't mess up displace modifiers.
Whenever a displace modifier has an invalid UV name (for whatever reason) the
UV name is set to the active layer. This is checked both in the UI code and
in the modifier exec code, so all bases are covered. For deleting a layer, this
required upgrading the layer delete code in the UI to properly preserve the
active layer, to prevent unwanted behaviour. I hope this is an ok solution.
Brecht, Ben you might want to look over and make sure I didn't break anything. I don't
think I did, I tested as thouroughly as I could.
These can be created and deleted in the Mesh panel in the same place as
before. There is always one active UV and vertex color layer, that is
edited and displayed.
Important things to do:
- Render engine, material support
- Multires and NMesh now lose non active layers
Also CustomData changes to support muliple layers of the same type, and
changes to layer allocation, updated documentation is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
This commit upgrades the modifier stack to only calculate the data which is
needed, either by modifiers further down the stack or by other functions at
the end of the stack (e.g. drawing functions).
This speeds up modifier stack recalculation, especially where vertex
groups and UV coordinates are concerned. For example, a mesh with an Armature
modifier followed by a Subsurf modifier would previously have required the
Subsurf modifier to interpolate all the vertex groups in the mesh, slowing
down modifier calculations considerably. With this update, vertex group data
is not propagated beyond the Armature modifier, so calculations are faster.
Note that this depends on the order of modifiers in the stack. If the Armature
and Subsurf modifiers were swapped in the above example, the Subsurf modifier
would have to interpolate vertex groups, as they are needed by the Armature
modifier.
This bug was caused by broken's recent patch to make the Curve modifier
determine its axis from the modifier panel, rather than the object's track
axis. In the case where a Curve modifier is applied by parenting the object
to the curve, the curve axis needs to be copied from the object's track axis
in modifiers_getVirtualModifierList(). This commit adds the necessary copy.
Array Modifier type "path length" didn't force a path calculation on load.
Note that this is still improper handling in Blender... an exception that
has to move to the depsgraph.
- New perspective projection capability. If a camera is used as the
projection object, the modifier detects whether to do perspective or
orthographic projection based on the camera type. If any other object
type is used as the projection object, orthographic projection is used.
- Orthographic projection actually works properly now.
- The projected UVs are scaled and offset so that the image is centred in
the projecting camera's view.
- AspX and AspY inputs have been added to control the aspect ratio of the
projected UVs.
Also:
- I have added the Mat4MulVec3Project() function to BLI_arithb.h; this
function converts a 3-dimensional vector to homogeneous coordinates
(4-dimensional, with the 4th dimension set to 1), multiplies it with the
given matrix, then projects it back to 3 dimensions by dividing through
with the 4th dimension. This is useful when using projection matrices.
that vertices will be individually displaced in the X, Y and Z directions
by the RGB components of the texture (R affects X, G affects Y, B affects Z).
This can be used along with e.g. the colour Clouds texture for a jitter effect.
Wave Modifier
This patch allows the option to use an object to determine the wave modifier's
start X & Y, it also allows for animated objects giving a moving wave
start X & Y.
Thanks to Michael Fox for the patch!
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.
Displace modifier crashed when used on Curve, the fix removed the flag
that accepts curve objects, but apparently then a flag to accept meshes
has to be added. (eModifierTypeFlag_AcceptsMesh).
Thanks Michael Crawford for notifying this fix.
duplicate code. Also removed redundant files from the bsp module,
that where replaced by boolop last year, no sense in updating them
for these changes. On the user level things should still work the
same, this is only preparation work.
Not counting the removed files, -1501 lines of code, not too bad :)
settings, rather than using the object's TrackX/Y/Z/etc buttons.
This is good for two reasons: a) having the settings over in the object buttons
before was terribly unintuitive and hidden, now it's more visible how to
control the deformation, and b) now if you have more than one curve modifier,
they can have their own settings, instead of being forced to use the object
level data.
Armature and Hook modifiers, and the flag field for the Mirror modifier. These
modifiers should all be copied correctly now.
This fix also means that converting modifiers to mesh with Alt-C now works
correctly (the convertmenu function copies the modifers before applying them,
so it wasn't always giving correct results for the above modifiers before).
The convertmenu function has also been changed to use DM_to_mesh instead of
converting to DispListMesh and using displistmesh_to_mesh, which means that
extra mesh data such as dverts is preserved.
structured and more maintainable. The old algorithm could leave the mesh in an
inconsistent state during recursive calls, making it quite fragile. The new
algorithm keeps the mesh in a consistent state, and should be more robust.
This commit fixes the issues EdgeSplit was having with non-manifold meshes
(bug #4946, also reported by several other people). EdgeSplit now works
correctly with all the test files I have.
This commit also fixes the BLI_ghash_remove function to correctly decrement
gh->nentries (the number of entries in the hashtable) on a successful removal.
Curve Length" or "Fixed Count" and the base mesh was scaled to 0 in edit mode
(could also happen while entering a numerical scale value like 0.25).
The problem was that the dist value could be almost 0, leading to a
ridiculously large duplicate count which would then cause memory allocation
to fail and the array modifier to get stuck in an almost infinite loop trying
to calculate the offset of the final copy. This commit fixes the problem
by checking that dist is greater than FLT_EPSILON before continuing.
modifier.
The bug was caused by an endless loop in the Array modifier's calc_mapping
function. The loop worked under the assumption that there could not be sets
of vertices such that (for example) vertex A merges with vertex B and vertex
B merges with vertex A. As it turns out, this situation is possible, so the
loop got stuck going from A to B to A to B ad infinitum.
This commit fixes the problem by limiting the number of loop iterations with
the copy number for which the mapping is being calculated. This should also
give more correct results in general.
RGB values if they are returned by the texture function. This fixes an issue
reported by several people where Image textures gave no displacement unless
CalcAlpha was turned on.
a vertex group which will modulate the influence of all bones in the armature.
This commit also tidies up the height of the modifier panels; they should all
have the same size margin now.
Bone renaming goes over a complex series of checks, which includes
checking all objects that have relations to the armature. the call
modifiers_usesArmature() didn't check properly for existing pointer...
Wave Modifier defaulted to Y waves, even when both X and Y buttons were
disabled. That case isn't very useful, nevertheless... if buttons allows it
then it should just work!
Boolean modifier allowed to be added after subsurf, but it doesn't support
that. Added "eModifierTypeFlag_RequiresOriginalData" flag to prevent this
from happening in UI.
previously would only work if the armature was the first in the meshes modifier list,
in that case the armature would be name flipped but the mesh would not)
This modifier allows to make arrays of meshes, with multiple offset types:
- constant offset
- offset relative to object width
- offset with scale and rotation based on another object
The number of duplicates can be computed based on a fixed count, fixed length
or length of a curve. Duplicate vertices can be automatically merged.
Nice docs and example files available in the wiki:
http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
This fixes most of the UV distortion issues with subsurf. Near seams
however there might still be some distortion, but this should at least
not be worse than before. Subsurf UV is enabled by default on new meshes,
and can be enabled in the modifier panel for existing ones.
Before and after:
http://users.pandora.be/blendix/notsmooth.pnghttp://users.pandora.be/blendix/smooth.png
When Modifiers are used in Edit Mode to show the deformed result for
editing, all actual coordinates Blender works with are still the ones from
the original Cage. You can notice that with the Transform Widget or
helper lines while transforming.
Even worse, the actual transformations still happened on the original Cage
as well, making it very hard to edit. That caused the feature to be named
"CrazySpace" (baptized by Andy, afaik?).
This commit calculates the deformation transformation per vertex, and
inverse corrects it, so it's more intuitive editing this way.
Unfortunately all the deformation features of Blender don't use matrices
for defining deform, so the existing code cannot be re-used to retrieve
the correct deformation matrix per vertex. The solution I found is based
on calculating per face the transformation based on its first 3 vertices,
and store this transformation averaged in the face's vertices.
The solution can also only work on entire faces, because the full deform
can only be retrieved using 3 vertices. (using 2 vertices will miss edge-
aligned rotation, using 1 vertex can only retrieve translation).
By deriving the deformations per face, small errors will still happen,
especially on very low-poly Meshes with extreme deformations.
The only alternative I know now, is providing each vertex in
a mesh with 2 extreme small tangent vectors, which get deformed using the
existing code as well. That will mess up the existing deformation code too
much though, this solution has the benefit it works with each deform we can
up with later too.
Last note about CrazySpace: it can only be used to tweak Meshes. Do not
even try to add vertices, extrude, or duplicate. Probably we should disable
this... but preventing user errors isn't always power-user-friendly, eh. :)
to finetune deform further as well.
Note that curve deform requires object buttons 'track' and 'up' axes set
properly. Curve deform can twist/flip a lot, making Vertex Group based
deform hard to set up.
The "Use VGroup" or "Use Envelope" options now are in Modifier Panel
for Armature deform.
If Modifiers are in use, they override the Armature settings for it.
(Cannot get rid of the Armature panel options yet, since Blender still
allows parenting to be deforming too, which is displayed as a Virtual
modifier now)
This now allows to - for example - make a Envelope deform on a Lattice,
and have same Armature use vertexgroups on Mesh.
Next; vertexgroup option for Lattice & Curve deform
Hooks now support vertex groups. With weight painting it looks very
interesting. Almost z-painting! :) Try a sphere with all vertices in a
group, hook it, and scale empty in object mode a bit.
http://www.blender.org/bf/rt3.jpg
(Which gives the idea to make a Displace Modifier working with normals and
vertexgroups..)
Works as follows now; in Mesh editmode, when no vertices are selected, it
tries to assign on CTRL+H command the active Vertex Group. (Menu is getting
to long now... need to think over). Only works when vertices are assigned
to a Vertex Group, this to calculate the Hook center.
