Age | Commit message (Collapse) | Author |
|
|
|
Separate the creation of trees from EditMesh from the creation of trees from DerivedMesh.
This was meant to simplify the API, but didn't work out so well.
`bvhtree_from_mesh_*` actually is working as `bvhtree_from_derivedmesh_*`.
This is inconsistent with the trees created from EditMesh. Since for create them does not use the DerivedMesh.
In such cases the dm is being used only to cache the tree in the struct DerivedMesh. What is immediately released once
bvhtree is being used in functions that change(tag) the DM cleaning the cache.
- Use a filter function so users of SnapObjectContext can define how edit-mesh elements are handled.
- Remove em_evil.
- bvhtree of EditMesh is now really cached in the snap functions.
- Code becomes organized and easier to maintain.
This is an important patch for future improvements in snapping functions.
|
|
Using SSE2 intrinsics when available for this kind of conversions.
It's not totally accurate, but accurate enough for the purposes where
we're using direct colorspace conversion by-passing OCIO.
Partially based on code from Cycles, partially based on other online
articles:
https://stackoverflow.com/questions/6475373/optimizations-for-pow-with-const-non-integer-exponent
Makes projection painting on hi-res float textures smoother.
This commit also enables global SSE2 in Blender. It shouldn't
bring any regressions in supported hardware (we require SSE2 since
2.64 now), but should keep an eye on because compilers might have
some bugs with that (unlikely, but possible).
|
|
This commit:
* Adds a 'compare_ff' function for absolute 'almost equal' comparison of floats.
* Makes 'compare_vxvx' functions use that new 'compare_ff' one.
* Adds a 'compare_ff_relative' function for secured ulp-based relative comparison of floats.
* Adds matching 'compare_vxvx_relative' functions.
* Adds some basic tests for compare_ff_relative.
See https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
Note that we could replace our python/mathutils' EXPP_FloatsAreEqual() by BLI's compare_ff_relative
(using a very small absolute max_diff), but these do not have exact same behavior...
Left a comment there for now, we can do it later if/when we are sure it won't break anything!
|
|
|
|
|
|
Move powX functions from particle code into math library and use them.
|
|
bypass angle calculation to avoids (asin, sqrt, cos).
|
|
|
|
|
|
|
|
|
|
pythons modulo), and use in a few more places.
allow mesh-checker-deselect to have a negative offset.
|
|
|
|
also whitespace edit.
|
|
old issue, the formulas here were never quite right, should all work ok now
with byte and float images.
Some differences:
* Colors with zero alpha from the background will never have an influence, so
you don't get alpha fringes when painting over such areas. This does give
hard edges when looking at the RGB channels alone, but there's no way to
avoid that and fringes at the same time, same behavior as other painting apps.
* Add/Subtract/Multiply/Lighten/Darken now leave the alpha channel unchanged
and work only the RGB channels, again same behavior as many other apps.
* Erase/Add alpha now compensates for premultiplied float images to keep the
straight RGB colors the same.
Next: fix projection painting.
|
|
|
|
The problem was that vertex colors only have 8 bits of precision, and integer
division always rounds down, so after some color blending iterations everything
gets darker. Instead use integer division that behaves like round() instead of
floor() for blending operations.
|
|
|
|
|
|
* MEM_CacheLimitier - Size type to int conversion, should be safe for now (doing my best Bill Gates 640k impression)
* OpenNL CMakeLists.txt - MSVC and GCC have slightly different ways to remove definitions (DEBUG) without the compiler complaining
* BLI_math inlines - The include guard name and inline option macro name should be different. Suppressed warning about not exporting any symbols from inline math library
* BLI string / utf8 - Fixed some inconsistencies between declarations and definitions
* nodes - node_composite_util is apparently not used unless you enable the legacy compositor, so it should not be compiled in that case.
Leaving out changes to BLI_fileops for now, need to do more testing.
|
|
extra elements
|
|
- minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
|
|
|
|
function calls (we had a few of these).
|
|
|
|
|
|
|
|
else if's
|
|
also remove large, duplicate comments from sunsky.h
|
|
* correct cmake/clang warning.
* use same include guard names as everywhere else for BLI math inline.
* correct define for madd_sh_shfl
|
|
much, add to the BLI_math api.
- is_power_of_2_i
- power_of_2_min_i
- power_of_2_max_i
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
adjust to use floats.
- also UV angle stretching was using radians->deg which wasn't needed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
old code was merged chich use the angle degrees.
|
|
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
|