Python types defined in C can now start their docstring with a
`.. class:: TypeName(args)` line, to document their constructor.
In that case the documentation writer is responsible for indenting the
remainder of the docstring by 3 spaces, matching the generated
documentation.
Added conversion to and from exponential map representation. This
representation is useful for interpolation of > 2 quaternions, or in
PD controllers.
Implementation in C functions quat_to_expmap,
quat_normalized_to_expmap, and expmap_to_quat with Python API, unit
tests and documentation.
Added Quaternion.to_exponential_map() and Quaternion(3-vector) to
Python API.
Reviewers: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1049
The original comment seems to suggest that only the rotation vector
is normalized, leaving the rotation angle alone. This is not what happens,
though. The new comment matches the actual implementation, and the
implementation matches what is commonly understood as quaternion
normalization.
Work towards T42418
For now got rid of linked list holding key,value pairs for metadata in favour of ID properties.
Reviewers: campbellbarton, sergey
Reviewed By: sergey
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D872
The issue was caused bu the optimization in surface attributes for cases when
there's only a volume shader used. Some attributes doesn't make sense in that
case and were skipped from calculation.
However, it is possible that kernel would still try to access them (because of
the shader setup etc). Prevented an infinite loop in the kernel now, which
should not have much affect on regular renders.
It is possible that ray distance will be zero which would make intersection
refinement return NaN as the refined position which would later lead to all
sort of mathematical issues.
Don't think there are ways to improve intersection accuracy for such rays
so just return original intersection coordinate.
This should fix T43475.
TODO: Need to look into possible issues in Ashikhmin BSDF which might return
zero-length reflected/transmitted ray?
This way we save 3 bytes per BVH node while building BVH, which overall
gives 100Mb memory save when preparing Frank for render.
It's not really much comparing to overall memory usage (which is 11Gb
during scene preparation here) but still doesn't harm to have solved.
Precision of the fast functions seems to be enough in there and
since the code was heavily using inverse trigonometric functions
this change gives few percent speedup on Victor's hair.
From the tests files from ctests storage doesn't have any meaningful
difference, hair on Victor is all below 4% absolute error and only
few pixels are exceeding 1% absolute difference.
In any case, let it be as it is currently so it allows us to have
fast math file in sources for it's further evaluation and possible
usage in other areas as well.
If user cancels, there's an issue with leftover files.
Instead use a hash to record files that have akready been registered for
generation and skip them if so.
That should guarantee things will go smoothly and when a file exists it
is assumed to be valid.
* Enable operator for proxies now becomes set operator for selected and
can unset-set all options.
* Properties become read-only labels, only use operator to set proxies.
BSDF sampler function shouldn't give labels it's not intended to do.
That said reflection shouldn't give transmission ray and transmission
give reflection ray.
Added an assert in the transmission sampling but reflection still
needs some investigation because even after recent fixes the check
for projection onto the reflected ray could give both positive and
negative values.
It shouldn't have any affect on renders just makes internal logic
consistent and unleashes an issue to be investigate further.
Hair BSDF did not have proper behavior because of non-normalized
tangent direction (which it expected to be normalized).This lead
to wrong labels being returned by the hair BSDF samplers.
Height of bitmap may be negative, which indicates a 'top to bottom' line storage.
Also, fixed header handling, bitmaps using other header than 'BM' would most likely
have lead to errors/crashes too...
Divide only the length of the edge by the homogenous coordinate, not the
final coordinate. Also fix the swapping (though it's still a bit
doubtfull if it's really needed)
For now, did most of the changes in menu entries (i.e. py space UI scripts).
Note we do not get 100% same results as previously, but current situation is
globally better than previous one, though the whole system to retrieve shortcuts
remains a bit weak...
Issue is double here:
* Quite a handfull of menu entries actually diverge slightly from their shortcut
counterpart (often one has a prop explicitely set to its default value,
when the other keep it unset).
* Current code was actually basically sending 'is_strict' option into canal,
by doing a second check in `wm_keymap_item_find` setting unset op props
to their default value!
Now, is_strict mostly says one thing: "never consider an unset property as
equal to a set one". Even if set property matches default value. Default values
are not always the same things as unset ones, as demonstrated by this report.
So we are being much stricter now, and also have to check shortcuts and
menu entries definitions actually matches, added some code (triggered by
--debug-wm option) that prints when it finds some (potential) issue.
There is one exception though - Macros. Those have their whole prop set defined
in menu entries currently, this shall probably not be the case, but is another issue,
so for now for macro operators we always do non-strict comparison (pretty much
the same as previously, in this case).
Also 'enum' operators are still tricky. Currently, shortcut extraction relies on
`ot->prop` being set, so even if this is not aboslutely needed anymore (when defining
UI you can specify an arbitrary enum property by name), `ot->prop` shall be set.
Note fix commit for mismatches between menu entries and shortcuts is needed next.
Please discuss changes to core mathutils functions first.
Changes like this should be considered and applied to all areas of the API (or not at all).
Missed quaternion, matrix normalize for eg.
Yet another color space issue, we multiplied texture color with srgb
brush color and retrasnformed it to srgb. Now use the linear brush color
for the multiplication.
