| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
oclusion in Blender internal renderer
|
|
|
|
Auto-scale is expected to work just fine now.
Only thing changed now is the pivot point for the scale: it is now
the same as rotation pivot, so scaling happens around weighted median
of the translation tracks. This seems to be what is actually required
for the VFX workflow.
|
|
Previously, this extension used the translation compensated image centre
as reference point for rotation measurement and compensation. During
user tests, it turned out that this setup tends to give poor results
with very simple track configurations.
This can be improved by useiing the weighted average of the location
tracks for each frame as pivot point. But there is a technical problem:
the existing public API functions do not allow to pass the pivot point
for each frame alongside with the stabilisation data. Thus this
change implements a trick to package a compensation shift into
the translation offset, so the rotation can be performed around
a fixed point (center of frame). The compensation shift will then shift
the image as if it had been rotated around the desired pivot point.
|
|
It is common in blender to use 1-based counting for
frame sequences (while 0-based is allowed). Thus
initializing to use frame 1 as reference for stabilization
is likely to produce smooth start values in most cases
|
|
Alongside with this change, we fix disabling of Autoscale,
because this feature works even when rotation/scale is disabled.
|
|
values > 1 will zoom in and values < 1 zoom out
Rationale: the changed orientation is more natural
from a user POV and doing it this way is also more
consistent with the calculation of the other
target_* parameters.
Compatibility: This will break *.blend files saved
with the previous version of this patch from the
last days (test period). It will *not* break any
old/migrated files: Previously, the DNA field "scale"
was only used to cache autoscale. Only with the
Stabilisator rework, "scale" becomes a first class
persistent DNA field. There is migration code to
init this field to 1.0
|
|
We should treat all three "target" ("expected") parameters in a similar way:
The "influence" control should only work on the measurement part of stabilisation,
i.e. it should only control the automatic part of stabilisation, while
the target parameters are deliberately set by the user and thus should
even be in effect when the automatic stabilsation is turned down.
It used to be so for location and rotation, but for the scale part,
I re-used the existing code for autoscale, which also had the scale influence
work on the autoscale factor. This was sensible in the old version,
since scale_influence was the only way to control the result. But now,
the user has always total control trough the "target_*" parameters
and thus we should prefer to treat all similar.
|
|
Really couldn't find where this was used.
|
|
harder when some cope changes...
|
|
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.
|
|
End Cap enabled.
Origindex can be invalid, code was not fully protected against it...
|
|
rBb10d0058d72da30
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.
|
|
Sorry for the noise :|
|
|
Seriuosly, guys... Please always check that kind of changes with and without affected option, and in full build case.
|
|
coverity).
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.
|
|
|
|
|
|
Recompute the normals if the normals are supposed to be varying (e.g. in
the ISchema).
|
|
transform animations into account.
|
|
account.
This resulted in animations always starting at frame 0.
|
|
Was calling the fast path for finding edge order in cases
where it should not have been called.
|
|
Now the range is between -90 to 90 degrees to give more customization
options.
|
|
|
|
|
|
|
|
This would be a real disaster if track has no markers, which we should
not masquerade and detect such weird cases as soon as possible.
|
|
Annoying i did not notice this originally, but for RNA we need to keep
things as much consistent as possible.
|
|
|
|
|
|
|
|
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.
|
