Was a concurrent access of pointcache from both particle system and UI (time space).
Pointcache not being threadsafe is really an issue to be addressed for its next version,
for now simply locking spacetime (like we already do with 3DView), not ideal fix
but it's working and safe for release.
This code obviously should also use the cache_fields flag variable,
like the code for reading the lowres data in the same function.
This is because fluid_fields actually represents the old state before
smoke was reallocated to match cache_fields read from the file, and if
it has some fields enabled that aren't allocated any more, it crashes.
This also fixes a reverse glitch: when a file was loaded with
the current frame in the middle of a baked smoke+fire simulation,
smoke appeared immediately, but the fire didn't until the frame
was changed. The reason is the same: after file load no fields
are initially allocated and thus fluid_fields is 0.
ccgDM_drawMappedFacesMat was missig a smooth shade model restore, some other
functions were redundantly setting it since we can assume it to be the default
state already.
ifdef’ing out defines in DNA/RNA is not a good idea, was breaking alternative keymaps loading
from splash screen e.g. (reported by Sergey over IRC, thanks).
export.
This aligns the behaviour of the file selection with the other
exporters. The Alembic case would fail if the filepath did not have an
extension set.
Also set a default file name for the Alembic export operator in case the
Blender file was not saved before exporting.
This function is only really secure in a very limited amount of cases,
and can especially bite you later if you change some buffer sizes...
So not worth bothering with it, just always use BLI_strncpy instead.
Error: `origin` and `edge` args were swapped in final `FindOccludee()` call of `ViewMapBuilder::ComputeRayCastingVisibility()`
Cleanup: main for loop in `Strip::createStrip()` was really confusing (though correct),
generated a false positive in coverity scan, now should be cleaner how it loops over its vprev/v/v2
triplet of consecutive items.
When WITH_INPUT_NDOF is disabled, 3D mouse handling code is removed
from:
- GHOST (was mostly done, finished the job)
- window manager
- various editors
- RNA
- keymaps
The input tab of user prefs does not show 3D mouse settings. Key map
editor does not show NDOF mappings.
DNA does not change.
On my Mac the compiled binary is 42KB smaller after this change. It
runs fine WITH_INPUT_NDOF on or off.
If the ruler is saved, a new color was created for each ruler. With the
change, a color is created for the first instance, and it reused in the
following instances. The default color is the current default color for
GP.
It's becoming annoying to have public API dependent on build type
and everything. Let's just always have API defined and do stubs
in the function implementation instead.
Current implementation more or less indiscriminately links physics
objects to colliders and forces, ignoring precise details of layer
checks and collider groups. The new depsgraph seemed to lack some
such links at all. The relevant code in modifiers suffers from a
lot of duplication.
Different physics simulations use independent implementations of
collision and similar things, which results in a lot of variance:
* Cloth collides with objects on same or visible layer with dupli.
* Softbody collides with objects on same layer without dupli.
* Non-hair particles collide on same layer with dupli.
* Smoke uses same code as cloth, but needs different modifier.
* Dynamic paint "collides" with brushes on any layer without dupli.
Force fields with absorption also imply dependency on colliders:
* For most systems, colliders are selected from same layer as field.
* For non-hair particles, it uses the same exact set as the particles.
As a special quirk, smoke ignores smoke flow force fields; on the other
hand dependency on such field implies dependency on the smoke domain.
This introduces two utility functions each for old and new depsgraph
that are flexible enough to handle all these variations, and uses them
to handle particles, cloth, smoke, softbody and dynpaint.
One thing to watch out for is that depsgraph code shouldn't rely on
any properties that don't cause a graph rebuild when changed. This
was violated in the original code that was building force field links,
while taking zero field weights into account.
This change may cause new dependency cycles in cases where necessary
dependencies were missing, but may also remove cycles in situations
where unnecessary links were previously created. It's also now possible
to solve some cycles by switching to explicit groups, since they are
now properly taken into account for dependencies.
Differential Revision: https://developer.blender.org/D2141
For now simply reshuffle option so they keep proper dependency flow.
Benefits:
- Has an ability to hide tracks lists to work with other sliders around.
Could be really handy to quickly get rid of lenghty lists.
- From a feedback seems to be fitting workflow better.
Things to doublecheck on:
- Feels a bit misordered: first you define whether one want to have
rotation stabilized, then have tracks, then scale options.
While this follows dependency flow (which is really good and which
we should not violate) it has weird feeling on whether things are
really where they have to be.
- Autoscale controls visibility of max-scale, can we just make it
active/inactive instead?
- Autoscale replaces slider with label. Can it be disabled slider
instead to reduce visual jumping (disabled slider prevents user
input)
Hopefully we'll still want to have collapsable box after re-iterating
over this points, so we don't waste bits in DNA.
See this page for motivation and description of concepts:
https://github.com/Ichthyostega/blender/wiki
See this video for UI explanation and demonstration of usage
http://vimeo.com/blenderHack/stabilizerdemo
This proposal attempts to improve usability of Blender's image stabilization
feature for real-world footage esp. with moving and panning camera. It builds
upon the feature tracking to get a measurement of 2D image movement.
- Use a weighted average of movement contributions (instead of a median).
- Allow for rotation compensation and zoom (image scale) compensation.
- Allow to pick a different set of tracks for translation and for
rotation/zoom.
- Treat translation / rotation / zoom contributions systematically in a
similar way.
- Improve handling of partial tracking data with gaps and varying
start / end points.
- Have a user definable anchor frame and interpolate / extrapolate data to
avoid jumping back to "neutral" position when no tracking data is available.
- Support for travelling and panning shots by including an //intended//
position/rotation/zoom ("target position"). The idea is for these parameters
to be //animated// by the user, in order to supply an smooth, intended
camera movement. This way, we can keep the image content roughly in frame
even when moving completely away from the initial view.
A known shortcoming is that the pivot point for rotation compensation is set to
the translation compensated image center. This can produce spurious rotation on
travelling shots, which needs to be compensated manually (by animating the
target rotation parameter). There are several possible ways to address that
problem, yet all of them are considered beyond the scope of this improvement
proposal for now.
Own modifications:
- Restrict line length, it's really handy for split-view editing
- In motion tracking we prefer fully human-readable comments, meaning we
don't use doxygen with it's weird markup and comments are supposed to
start with capital and end with a full stop,
- Add explicit comparison of pointer to NULL.
Reviewers: sergey
Subscribers: kusi, kdawg, forest-house, mardy, Samoth, plasmasolutions, willolis, sebastian_k, hype, enetheru, sunboy, jta, leon_cheung
Maniphest Tasks: T49036
Differential Revision: https://developer.blender.org/D583
Reduces noise from --debug-gpu so we can spot serious errors.
Blender 2.7x uses OpenGL 2.1, we don't care if features are deprecated.
I'll re-enable these warnings for blender2.8 after next merge.
When running blender --debug-gpu
Display which debug facilities are available. One of these, in order of preference:
- OpenGL 4.3
- KHR_debug
- ARB_debug_output
- AMD_debug_output
All messages are logged now, not just errors. Will probably turn some of these off later.
GL_DEBUG_OUTPUT_SYNCHRONOUS lets us break on errors and backtrace to the exact trouble spot.
Callers of GPU_string_marker no longer pass in a message length, just the message itself (null terminated).
Apple provides no GL debug logging features.
