* Particle collision with size was broken since raytrace optimizations by jaguarandi, now the collision code falls back to old slower method when the collision ray has a radius.
* Single goal/avoid object now works for boids.
* Some tiny improvements on collision avoidance for boids.
Basically two simple changes, changes, I pulled in the faster
ghash in bmesh (which uses mempools for allocation, providing
a substanstial speedup in some cases, and also I inlined some
of the functions), and I changed __inline to __forceinline for inlining
of math functions.
I also removed the timer in the view3d zoom op (ctrl-middlemouse)
that was making it nonfunctional. Why was that there?
* inline some more functions, from math_base and math_vector
* also made some changes to the way inline is done so it can
work for more than one file
* reflect_v3_v3v3 requires input vectors to be normalized now.
* added rgb_to_grayscale
* added zero_v4, copy_v4_v4, swap_v4_v4, is_one_v3
* added box_clip_bounds_m4 to clip a bounding box against a
projection matrix
to wait for an item to be put in the queue and then pop immediately without,
this makes it possible to avoid sleep() while waiting for the results of a
thread.
replaces another so it can do updates (e.g. dopesheet editor can
sync channel selection).
Also coded a simple optimization for allocating small objects,
based on mempools. It's #ifdef'd out, you can enabled it by
defining OPTIMIZE_SMALL_BLOCKS (e.g. adding -DDOPTIMIZE_SMALL_BLOCKS to
your compiler flags).
We suffer from a great deal of performance loss from the system allocator
(vgroups, ghash, edgehash, the singly-linked list implementation in blenlib,
editmesh, and likely a great many areas I'm forgetting), and this is the
common solution for handling the many-small-objects problem. It's not
really production-ready yet (it's long-term memory consequencers need to
be profiled first, and the implementation tweaked as necassary), but for
people on systems with slow system allocators it's worth trying.
Note that since this creates a guardedalloc<->blenlib link, the build systems
need to be updated accordingly (I've already done this for scons, though I'm
not sure if the player builds).
similar to sequence editor.
--> http://mke3.net/blender/devel/2.5/color_balance_node.jpg
Also added 0 key (zero key) shortcut when mouse is over a button, to reset it to its default value.
Same as the RMB menu ->Reset to Default, except for color wheels, it only resets the hue/sat/value
components that that widget affects.
Peter/Xavier: The existing color balance code can generate NaNs (fractional power of a negative),
which causes havoc along the image pipeline. I added a check in the node code to prevent this.
Still plenty of potential for lots of better colour correction tools in the compositor, just needs time...
A solid color backdrop is now drawn behind the mute/protect toggles and sliders, reducing the visual clutter with long names still appearing behind the UI widgets.
/* given an array with some invalid values this function interpolates valid values
* replacing the invalid ones */
int interp_sparse_array(float *array, int list_size, float skipval)
* utility function BLI_findstring to avoid listbase lookup loops everywhere.
eg:
ListBase *lb= objects= &CTX_data_main(C)->object;
Object *ob= BLI_findstring(lb, name, offsetof(ID, name) + 2);
* made some more math functions use const's, (fix warnings I made in previous commits)
Useful if you have 2 different characters with the same base mesh (matching indicies), and want to copy a facial expression for eg, from one to another.
Durian request to re-use shapes between characters.
* Copies the active shape to other selected objects
* Different methods to apply the shape
* * OFFSET, simple translation offset
* * RELATIVE (EDGE/FACE), Use Barycentric transformation to copy the shape. This means the target mesh can be a different orientation and scale and the shape should still apply since the surrounding geometry is used as a basis for the offset.
bug: barycentric transform's depth was inverted.
Note:
* This isnt added into a menu yet,
* This cant be redone since adding a shape key messes up the redo stack. needs fixing for other scripts too.
From 2 triangles and 1 point, the relative position between the point and the first triangle is applied to the second triangle to find the target point.
the barycentric weights are calculated in 2D space with a signed area so values outside the triangle bounds are supported.
wrapped by python:
pt_to = Geometry.BarycentricTransform(pt_from, t1a, t1b, t1c, t2a, t1b, t1c)
NOTE:
- moved some barycentric weight functions out of projection painting into the math lib.
- ended up making some of the math functions use const args.
TODO:
- support exceptional cases. zero area tries and similar.
* Increase epsilon for intersection a bit more, ortho view + small
faces are problematic.
* Fix a redraw issue with one partial redraw too much at the end of
the stroke.
* added renamed files in revision 25337
* renamed BLI_util.h -> BLI_path_util.h for consistency
* cleanup of #includes: removed BLI_blenlib.h in favour of direct includes of the needed headerfiles in a few places.
* removed debug print in sequencer.c
* added missing include in blenkernel/blender.c -> bad dependency, needs to be fixed still
* Temporary workaround for sculpt not working well with small polygons,
still seems to be some issues, but can at least paint now.
* Small optimization avoiding local function variable aliasing.
* Added detection if VBO extension is supported.
* Redraw other 3d views after sculpting.
* Fix brush sometimes punching through mesh with very small polygons,
added an extra epsilon to the ray-triangle intersection.
* Don't allow adding/removing multires levels in editmode.
* Customdata code for swapping mdisps restored.
* Fix inflate brush crashing with multires.
* Smooth and layer brush don't work yet with multires, but at
least avoids crashing now.
* Fix threading issue with flatten brush.
After testing and feedback, I've decided to slightly modify the way color
management works internally. While the previous method worked well for
rendering, was a smaller transition and had some advantages over this
new method, it was a bit more ambiguous, and was making things difficult
for other areas such as compositing.
This implementation now considers all color data (with only a couple of
exceptions such as brush colors) to be stored in linear RGB color space,
rather than sRGB as previously. This brings it in line with Nuke, which also
operates this way, quite successfully. Color swatches, pickers, color ramp
display are now gamma corrected to display gamma so you can see what
you're doing, but the numbers themselves are considered linear. This
makes understanding blending modes more clear (a 0.5 value on overlay
will not change the result now) as well as making color swatches act more
predictably in the compositor, however bringing over color values from
applications like photoshop or gimp, that operate in a gamma space,
will give identical results.
This commit will convert over existing files saved by earlier 2.5 versions to
work generally the same, though there may be some slight differences with
things like textures. Now that we're set on changing other areas of shading,
this won't be too disruptive overall.
I've made a diagram explaining the pipeline here:
http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png
and some docs here:
http://www.blender.org/development/release-logs/blender-250/color-management/
