Fixed bug #6153, Blender Crash during rendering (internal) with object selected in edit mode.
* Added a render parameter to several of multires's functions. If render==true, multires won't push data onto the undo stack, and regular Mesh data is always used (as opposed to EditMesh data.)
* Auto-create compbufs for first socket of alphaover and set alpha nodes.
This allows you to eg. plug something into the second socket of an
alphaover node, and choose a solid colour in the first empty socket for
the image to be superimposed over.
Previously I had to create a bunch of extra nodes to (for example) mix
100% black over my render, just to get a black compbuf of the right size
that I could plug in. Not nice.
The Mix node already works this way, and these two should have, but
didn't.
* Allow the 'Fac' value to be used on RGB curves when there is no input
image. This lets you easily fade the changes in and out to check it
against the original, or to tone down the effect of the colour correction.
Baked textures not updating in the 3D view. This bug was a side
effect of the image not being marked as loaded after changing
parameters (uv test grid, size) of a generated type image.
Sculpt Multires render: the Orco table should be made based on 'render'
level, not on '3d view' level. Now, how this could have worked even...
Nick, could you check?
When rotating bones around the 3d-cursor in posemode with a rotated
armature, rotation was around strange points other than the cursor.
This bug has been around for quite a few releases now. Somehow, the
maths used to convert the world/global space locations to local locations
only worked on things in editmode, but not bones.
buffer if it was an RGBA type. This caused buffer corruption in the original buffer
which would be colorspace converted again (for each render). Corrected by duplicating
buffer.
This tweaks the dependency rules for Scenes/Objects a bit. Here is the
rule:
- Each Scene has own dependency graph, and only solves dependencies for
objects in the scene
- However, when using multiple linked Scene-sets, the *current* scene is
allowed to have dependencies to objects in a 'set'.
This works by first calculating the sets, then the current scene.
Example: the current scene can have lights with a track/location
constraint to a character in a set.
* Added an "Override Image" button to the UVProject modifier; this overrides
faces' currently assigned image with the one given in the modifier panel.
This provides some of the functionality previously provided by the "Add UVs"
button - you still need to add a UV layer manually, but you only need to
change the image in one place.
* Note that the "Override Image" option uses the bit position previously used
by the "Add UVs" option, so old files which had "Add UVs" enabled will now
have "Override Image" enabled.
* Removed the "Add UVs" option from the UVProject modifier
* Added a UV layer menu to the UVProject modifier
* Refactored the Displace modifier UV layer menu code to allow the UVProject
modifier to share it
* Added two CustomData functions to facilitate getting layers by name
Fixes bug #5858 (Render to dv skips frames. OSX and Linux PPC).
Caused by stupid ffmpeg dv multiplexer. PAL-fix is easy, NTSC needs varying
buffer sizes...
When weights in Meshes are extremely small (< 0.01) normalizing them
can give overflows, thanks to float precision limit.
This is still unsolved, but for now the limit had to be set smaller...
(reason is that Plumiferos uses mixed lattice and vertex-group deform)
Also: running Blender in debug (-d) will print subversion now.
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.
Composite: some cases gave memory errors (not freed mem).
The code that tried to be smart in finding nodes to skip, caused that
stack buffers were not freed propertly.
from translate node. Once again courtesy of joeedh (Joe Eagar). Should be
noted that there are other nodes which seem not to respect these offsets
as well. Will investigate further.
Fixed bug #5799, Multires mesh modifications get reset by rendering
This bug can cause some nasty data loss (was introduces with my commit for using orco with multires.) Fixed by making sure to do multires_update_levels before applying modifiers.
have been in this particular case anyway), the blur radius will automatically
be limited to half the width or height of the image.
Nothing to do with this bug, but also now skips image region outside
borders when border rendering is enabled.
Crash entering faceselect mode in shaded mode.
The cause here is the new system that only preserves data through the
modifier stack as needed. The DerivedMesh and shaded colors could get
freed while still being used elsewhere.
