In compositor, not always all scenes rendered... this was why:
When disabling 'save buffers', but keeping the 'full sample' option, the
*other* scenes in a composite didn't render.
Removing the stub I added for a binreloc function. Here for some reason it's needed (somehow binreloc is not being included ?) or the player won't link, but for others (at least on 64 bit systems) the opposite happens.
Thanks Chris Want for the feedback to the commit where I tested this.
* Ctrl-I now swaps the selection status of keyframes/channels depending on where the mouse cursor is located. Ctrl-Shift-I does so for markers.
* (De)selecting channels now clears the 'active' flags too, so there will be no more 'selected' items lingering around even after pressing AKEY
* Transform Constraint UI drew 'VG:' field incorrectly, resulting in bad layout
* StretchTo constraint's UI has been tidied up a bit
* (TODO: MinMax's UI needs URGENT attention)
This bug-report brought to light some problems with the transform constraint's handling of degrees+radians. Now, the input-range scaling is done in degrees (as the clamping factors ranges are in degrees) instead of having that done after this stage. The problems should now be fixed (and gears now seem to work ok), but I hope no other rigs have been broken.
compositor node, another in render_realtime_texture. Note that multilayer images
in the image compositor node do not respect the premul flag (though I did write
commented out code for it).
As far as I can tell, the premul option never worked for multilayer images in the
image node, so I'm a little nervous about making it work properly there.
ton, any comments?
commit. I still think this is a good idea, but needs more discussion.
Basically, the way the premul option worked before is it actually
changed the image data to be premul (for each pixel it multipled r,g,b by a) when
loading an image. So if a user wanted his image to be key, yet
still work in the renderer (which expects premul) he'd be stuck.
Also, it was kindof confusing how if you painted something in the image,
then saved it with premul on, when next you loaded the image it'd have
changed (especially since the image editor painting seems to paint in
key, not premul).
basically flagged the image so that on next load/reload, the image
data would be converted to premul. This was very confusing to the
user, as it meant premul wouldn't take effect will the image was
reloaded, and it would also change the image data, which the user
might've been painting.
To fix this, I've removed this behaviour and instead made the premul
option apply at render time. During render while evaluating an image
texture, if the image has the premul flag set then the premul operation
is done on the texture result data, thus not touching the image data
at all.
Also, I've made premul be turned on by default.
The menu listing the scripts available for use was not working correctly for newly created PyConstraints. This was caused by a missing initialisation for the 'active' index.
Now it is possible to define a custom colour set per bone group. This allows rigs to look consistent across different computers with different themes. As such, the bone-groups buttons have been reshuffled to present the settings in a better way.
Colour sets are now selected from a menu with descriptive names, instead of using a slider. Choose the 'Custom Set' entry to use a custom set of colours for the active group. The sets of theme colours have been retained, and can be used directly, or as the basis for a new custom colour set (when any one of the colour controls is touched).
For bone-groups that haven't had any custom colour set used yet, a default 'test' set is used. This uses bright versions of the RGB colours.
Fixing mistake in Blender_ShowHelp() function: argument to Blender_Run() should be passed directly as a string, not encapsulated in a tuple (aka "s", not "(s)").
I also added a button to control enabling/disabling SSS for render.
- Fix for potential halo sorting crash.
- Add a newline at the end of a file to remove gcc warning.
I had this assigned to Alfredo for a while, but he hasn't replied to the tracker at all, so I suspect he's not around. I'll commit this now to prevent crashes.
Some of the code in the glare node assumed that all buffers will be 4 channel RGBA, when in fact it was possible to give it a VEC3, such as a spec pass with no alpha, which would crash it. This fix just duplicates the input to a new temporary RGBA buffer to work on, if it's not already RGBA.
It's already supported within transform, was previously known as 'tweak mode' and for some odd reason was a compile time option. This brings it to a user preference (in 'Edit Methods' section).
Basically it means that you don't need the extra click at the end to confirm a drag-move transform, if you're already dragged, you can just let go of the mouse rather than needing to click again. It's a lot more comfortable when you're used to using other applications as well as blender, and much more sensible for tablets.
This started life as patch #7144 by Ed Britton, but this implementation has been changed considerably.
This adds a few settings to control global render quality, for faster
renders when tweaking lighting etc. The implementation is not so great,
and this should really be part of a proper render profile and preset
system. So for now it's a hidden Peach feature, enabled by setting rt
to 1. Before the next release, I'll either remove or improve it.
Settings are:
- Maximum subsurf level
- Child particles percentage
- Maximum shadow map samples
- AO and SSS quality factor
"Insert Key" menu in Action Editor (IKEY) now has a new option: "In Active Group". This only inserts keyframes in the active action group (if available).
This is messy because the files can be left there when blender quits, however saveBuffers and sessions alredy do :/ Some cleanup function needs to Blender that deals with this!
- Material buttons code didn't set particles update flag
- Small change to how particle emit time is interpreted from textures, now the "time" texture output can actually be used for something
- Hair didn't update the visibility flag of each particle
- Changing the disp value gave a too strong update call to particles
- Changed disp value behavior for dynamic particles a bit, now all particles are always calculated for uncached frames so that every particle gets it's data cached. Now the disp value actually does what it's supposed to do, it alters the amount of particles DISPlayed in viewport, but doesn't change the simulations. (With old particles it was possible to only calculate the disp amount of particles too as everything was always recalculated from scratch anyways, but now that particles are more complicated and cached etc. it's not an option anymore.)
-softbody BodyPoint indexes were created with a lag of one leading to use of wrong softbody points for particles when creating path cache
-interpolation points for softbody hair weren't chosen optimally when not yet at the end of a hair
