This was more of a general nvidia driver bug. Was caused by a
drawcall that had 0 vertex count. This worked in normal drawcalls
but not in indirect drawcalls.
If fade_time is used, particles would be flagged PEK_HIDE (depending on
time settings), but since this is not respected in drawing in 2.8 yet
the user would have no indication of them keys being hidden.
Also doing this for hair doesnt make much sense anyways...
Reviewers: jacqueslucke
Maniphest Tasks: T70259
Differential Revision: https://developer.blender.org/D5901
Even though hidden/faded keys are not supported in drawing in 2.8 yet,
the selection tools should not be able to select non-visible keys.
Spotted while looking into T70259
Reviewers: JacquesLucke
Differential Revision: https://developer.blender.org/D5902
There was a mix of old and new constants. Now have one list of WM_CURSOR_*
cursor types, using GHOST standard cursors when available and otherwise falling
back to our custom cursors.
Ref D5197
* Add more standard cursor types, that platforms can optionally support.
* Remove a few unused cursor types that were not properly supported and
would show the wrong cursor when used.
* Add native cursor files for Windows. These scale well with DPI and have
anti-aliasing. Designed by Duarte Farrajota Ramos.
Ref D5197
Deformation of subdivision surface modifier was using wrong coordinates
for the coarse mesh: as the modifier flow goes the coordinates are to be
taken from the input array of coordinates.
Simplify it a bit, hopefully make it clearer, better var names, use
proper types for arrays of vectors, etc.
No behavioral change expected (except for corner-case of vertices being
used by more than 255 edges, which were sort of 'clamped' to those 255
first edges for the smoothed position computation previously, now we use
proper integer, which fixes that bug).
Previously the cache for the modifier would not be invalidated if
modifier settings were changed with drivers or keyframes.
Now we compare the current setting with the ones used to generate the
cache and invalidate the cache if they differ.
Reviewed By: Sybren
Differential Revision: http://developer.blender.org/D5694
When move very fast the pen using a tablet, the end of the strokes was very ugly if the sampling was enabled. The reason for that is the last point and the previous one was interpolated in distance, but not in pressure and strength.
This commit uses several processes to get better endings:
a) If the pressure at the end of the stroke is very low, this part of the stroke is removed. This is a common issue with some tablet that send events with very low pressure when the pen is raised from drawing surface.
b) The interpolated points created by sampling are interpolated in strength and pressure to get a smooth transition.
c) Active smooth also uses the strength. Before only pressure was used.
The config.h file is autogenerated during compile by a 3rd party library
quadriflow uses. Now we put this file in the build directory to avoid
adding this to the git repository in the future.
Was caused by some drawcall not being done if the volumetric resolve pass
was drawn (using dual source blending seems to be the cause).
Not sure why this is needed since it is still reset before the next
drawcall.
When calling make.bat multiple times to rebuild blender
make.bat failed to rebuild if a custom build dir was set.
reported and fixed on chat by @dgsantana
The `pose_bone_do_paste()` function is documented to only return a
non-NULL pointer on a successful paste, and the one caller that checks
the return value is expecting this behaviour. However, before this
commit, when a valid pose channel was found, 'Selected Only' was
enabled, and the bone was not selected, the function would still return
non-NULL. This resulted in auto-keying pose channels that were not
pasted.
Reviewed by: angavrilov
Differential Revision: https://developer.blender.org/D5891
This change makes it so motion paths are using minimal possible
dependency graph which is sufficient to evaluate required motion
path targets.
Disclaimer: granularity is done on ID level, but it is possible
to go more granular if really needed.
Brings time down to 0.5 sec when updating motion path for the
Rain animation file used for benchmarks in the previous commits.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5874
The title explains it all actually: this commit introduces special
dependency graph builder API which builds graph which is sufficient
to evaluate given set of IDs.
The idea is to only update parts of motion paths which lies between
keyframes around changed frame.
The changed frames are considered to be from second previous to
second next one to work correctly with bezier handles interpolation.
Brings updates in the Rain test animation file from around 11 sec
down to 1 sec.
For now, do not allow to add custom props to overriding IDs (this should
be possible in the future, by getting basic correct behavior here is
already fairly hard, no reason to complicate things even more).
Also, properly disallow editing of existing custom props in overriding IDs.
Do not see any reason not to copy over the flag of the old, existing
IDProp to the new one when assigning (e.g. `C.object['prop'] = 0.5`
would nuke that IDProp flag).
The triple possible status of an PropertyRNA (actual C-defined prop,
py-defined IDprop behaving similar ot RNA one, or actual 'pure' custom
prop) is really confusing... Not to mention the _RNA_UI ugly thingy on
top of that. :/
Cycles casts a pointer from ShaderDataTinyStorage to ShaderData, these structs by default had different alignments however (the former was 1-byte aligned, the latter 16-byte). This caused undefined behavior on at least the CUDA platform. Forcing both structs to use the same alignment fixes this.
CUDA toolkits newer than 10.1 run into this because of a compiler optimization.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5883
Don't just rely on a comment next top the code, do an assert as well.
Also, don't use `default` since that silences compiler warnings when
new enumerators are added and related code is to be verified.
More switch statements might need an adjustment, but this is something
what is easier to go over by Pablo.
This change is two-fold:
- Ensure the result of the F-Curve evaluation is stored on the FCurve
object. This was done in 2.79 but lost when we moved to more granular
per-curve evaluation from the depsgraph.
- Flush this result from the CoW copy back to the original.
Reviewed by: sergey
Differential Revision: https://developer.blender.org/D5888
The tricky part here is to support a hidden parent and a "visible" child
collection. In this case the object should obviously be invisible. It is
all working now.
