working in blender render rather than blender game mode. Tweaked the flags a
bit to make it compatible more, but for full configuration you need to be in
blender game mode still.
* Removed the struct_type identifier from sockets completely. Any specialization of socket types can be done by using separate collections in RNA and customized socket draw callbacks in node type. Sockets themselves are pure data inputs/outputs now. Possibly the sock->storage data could also be removed, but this will change anyway with id properties in custom nodes.
* Replaced the direct socket button draw calls by extra callbacks in node types. This allows nodes to draw sockets in specialized ways without referring to the additional struct_type identifier. Default is simply drawing the socket default_value button, only file output node overrides this atm.
* File output node slots now use a separate file sub-path in their storage data, instead of using the socket name. That way the path is an actual PROP_FILEPATH property and it works better with the UI list template (name property is local to the data struct).
* Node draw contexts for options on the node itself and detail buttons in the sidebar now have an extra context pointer "node" (uiLayoutSetContextPointer). This can be used to bind operator buttons to a specific node, instead of having to rely on the active/selected node(s) or making weak links via node name. Compare to modifiers and logic bricks, they use the same feature.
* Added another operator for reordering custom input slots in the file output node.
This commit refactors the way that the Motion Paths GUI works. The key problems
this tries to address are:
1) Mode error - Confusion about whether we're dealing with the Object or Pose
level Motion Paths panel
2) Display settings vs Baking Settings
In line with the original design intentions for the 2.5/6 Properties Editor,
I've now split out the actual baking-related settings away from the Properties
Editor:
* Now, when clicking "Calculate Paths" from the toolbar, you'll be prompted with
a dialog to select the start/end frames (and for bones, whether to bake from
heads or tails). This is less confusing than relying on firstly setting the
range via the display range settings (and baking using that), since many people
apparently only used the "around current" mode, and were confused why things
weren't working
* Added a display of the frame ranges of the current baked Motion Path on the
active Object/Bone. This makes it clearer/easier to debug if the path suddenly
starts disappearing after a certain frame.
* Replaced Calculate/Clear Paths in the panels with a single "Update" button if
there's already a baked Motion Path.
Hopefully these changes (in combination with some of the other bugfixes) will
make it more obvious how everything works.
* Shadow color now usable in the BGE
* Simplified the shadow panel while "Blender Game" renderer is active
* Added variance shadow maps for the BGE
* Buffered shadows on sun lamps in the BGE (orthographic)
* Light textures in the BGE
- Displays dopesheet information for selected tracks, and currently does not
support any kind of editing.
- Changed regions to use the whole main region for such views as curves and dopesheet.
This allows to have own panels with tools/properties in this area.
- Active clip is getting synchronized between different clip editor editors in the
same screen, so updating of curve/dopesheet views happens automatically when one
changes current clip in one of this editors.
- Panels in toolbox and properties panels are now separated to rely on current view
mode, but some operators and poll functions still need to be updated.
- Added new screen called "Movie Tracking" where layout is configured to
display timeline, main clip window, curves and dopesheet.
Most of the changes are related to adding support for motion data throughout
the code. There's some code for actual camera/object motion blur raytracing
but it's unfinished (it badly slows down the raytracing kernel even when the
option is turned off), so that code it disabled still.
Motion vector export from Blender tries to avoid computing derived meshes
when the mesh does not have a deforming modifier, and it also won't store
motion vectors for every vertex if only the object or camera is moving.
Patch from Jaggz H, thanks!
[#31096] Weight-painting: Brush-specific weights
http://projects.blender.org/tracker/?func=detail&atid=127&aid=31096&group_id=9
Each brush's weight can now be set individually, can also enable
unified setting (same as size and strength have.)
Added readfile code to the patch: subversion bumped to 1, brushes get
default weight of 0.5, unified weight enabled by default and value
from old vgroup_weight field.
Sponsored by the Blender Development Fund.
http://www.blender.org/blenderorg/blender-foundation/development-fund/
Remarks:
The original code was not designed to support moving obstacles so I had to introduce some velocity constraints into the code to prevent smoke from exploding. If this causes problems with "fire" emulation, please let me know.
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks)
- Make functions which are used by mball.c only static and remove their prototypes
from public header file.
Further cleanup is coming.
Expose option into interface to use modal solver which currently
supports only tripod motion.
This solver requires two tracks at least to reconstruct motion.
Using more tracks aren't improving solution in general, just adds
instability into solution and slows down things a lot.
Refirement of camera intrinsics was disabled due to it's not only
refines camera intrinsics but also adjusts camera position which
isn't necessary here
To use this solver just activate "Tripod Motion" checkbox in
solver panel.
Merged from tomato: svn merge ^/branches/soc-2011-tomato -r45622:45624 -r46036:46037
P.S. Quite experimental yet, requires more checking and probably
tweaks to prevent camera jumps when tracks apperars/disappears
from the screen.
=== BVH build time optimizations ===
* BVH building was multithreaded. Not all building is multithreaded, packing
and the initial bounding/splitting is still single threaded, but recursive
splitting is, which was the main bottleneck.
* Object splitting now uses binning rather than sorting of all elements, using
code from the Embree raytracer from Intel.
http://software.intel.com/en-us/articles/embree-photo-realistic-ray-tracing-kernels/
* Other small changes to avoid allocations, pack memory more tightly, avoid
some unnecessary operations, ...
These optimizations do not work yet when Spatial Splits are enabled, for that
more work is needed. There's also other optimizations still needed, in
particular for the case of many low poly objects, the packing step and node
memory allocation.
BVH raytracing time should remain about the same, but BVH build time should be
significantly reduced, test here show speedup of about 5x to 10x on a dual core
and 5x to 25x on an 8-core machine, depending on the scene.
=== Threads ===
Centralized task scheduler for multithreading, which is basically the
CPU device threading code wrapped into something reusable.
Basic idea is that there is a single TaskScheduler that keeps a pool of threads,
one for each core. Other places in the code can then create a TaskPool that they
can drop Tasks in to be executed by the scheduler, and wait for them to complete
or cancel them early.
=== Normal ====
Added a Normal output to the texture coordinate node. This currently
gives the object space normal, which is the same under object animation.
In the future this might become a "generated" normal so it's also stable for
deforming objects, but for now it's already useful for non-deforming objects.
=== Render Layers ===
Per render layer Samples control, leaving it to 0 will use the common scene
setting.
Environment pass will now render environment even if film is set to transparent.
Exclude Layers" added. Scene layers (all object that influence the render,
directly or indirectly) are shared between all render layers. However sometimes
it's useful to leave out some object influence for a particular render layer.
That's what this option allows you to do.
=== Filter Glossy ===
When using a value higher than 0.0, this will blur glossy reflections after
blurry bounces, to reduce noise at the cost of accuracy. 1.0 is a good
starting value to tweak.
Some light paths have a low probability of being found while contributing much
light to the pixel. As a result these light paths will be found in some pixels
and not in others, causing fireflies. An example of such a difficult path might
be a small light that is causing a small specular highlight on a sharp glossy
material, which we are seeing through a rough glossy material. With path tracing
it is difficult to find the specular highlight, but if we increase the roughness
on the material the highlight gets bigger and softer, and so easier to find.
Often this blurring will be hardly noticeable, because we are seeing it through
a blurry material anyway, but there are also cases where this will lead to a
loss of detail in lighting.
* Remove RNA, Operator and UI for Texture and Sequence plugins.
Since 2.5x no effort has been done to bring that back, so there is simply no reason in keeping that code and the UI for that ;-)
* Low Level code still exists and is unchanged.
* Replaced the hard coded viscosity presets with Python ones.
* Added version check, so older files load fine.
Loading new files into 2.62 also works fine.
