We were calling BLI_remlink and then BLI_insertlinkbefore/after quite often. BLI_listbase_link_move simplifies code a bit and makes it easier to follow. It also returns if link position has changed which can be used to avoid unnecessary updates.
Added it to a number of list reorder operators for now and made use of return value. Behavior shouldn't be changed.
Also some minor cleanup.
Those 'never null' ID pointers are really a PITA to handle... luckily we don't have much of those around!
Found by Sybren, thanks.
Should be backported to 2.78.
Uses similar way of storing temp data as object copy paste, just
uses different read entrypoint which does not modify current bmain.
This gives ability to easily copy-paste poses from one blender to
another one.
Hopefully doesn't introduce user-measurable differences.
Request from Peer here in the studio.
Reviewers: mont29
Reviewed By: mont29
Subscribers: hjalti, fsiddi
Differential Revision: https://developer.blender.org/D2229
I) Filename was not put in temp Main generated to save selected data only,
this was breaking readcode when trying to open partial file, leading to missing
filename in final loaded Main data.
II) Read code would confuse partial .blend files with Undo ones, when they had no screen in them
(which happens to 99.999% of partial .blend files I guess).
Reported by @sybren, thanks.
Should be safe enough for 2.78 release.
Root of the issue is that active render index became wrong. This is the actual
thing to be fixed, but as usual this is quite tricky to reproduce. Since such
bad situation might have happened more and fix isn't really difficult or
intruisive let's avoid crash for now.
Can be revisited once we figure out root of the issue.
Nice for 2.78 release.
Own fault in new ID management work, thought rebuild the DAG itself was
enough to actually update whole scene, but we actually need to tag datablocks
for update as well, when we change (or remove) one of their ID pointers...
This is really hack-fix actually, not sure why `get_pointcache_keys_for_time()` seems to assume
it will always find key for given part index at least for current frame, and whether this assumption
is wrong or whether bug happens elsewhere...
Anyway, this is to be wiped out in 2.8, so no point loosing too much time on it, for now merely
returning unchanged (i.e. zero'ed) ParticleKeys in case index2 is invalid. Won't hurt anyway,
even if this did not crash in release builds, would be returning giberish values.
See commit's comments for details, but this boils down to: do not try to use
purely runtime cache data as a 'real' ID pointer in readcode, it's likely
doomed to fail in some cases, and is bad practice in any case!
Thix fix implies dupliweight's object will be invalid until first scene update
(i.e. first particles evaluation).
Was incorrect indexing done in the array. Caused by 5abae51.
Not sure why it needed to be changed here, but array here is supposed to be
a loop data, so bringing back loop index as it originally was. The shading was
wrong in edit mode with BI active as well (so it's not like it's needed for
BI only).
Patch in collaboration with Alexander Gavrilov (angavrilov), thanks!
Should be double-checked and ported to 2.78.
Another great example of inconsistency in usercount handling - dupli_group was considered
as refcounted by readfile.c code (and hence by library_query.c one, which is based on it),
but not by editor/BKE_object code, which never increased group's usercount when creating
an instance of it etc.
To be backported to 2.78.
Includes:
- Version bump to 2.78
- Doxy file update
- New splash screen
- Wrapped some do_versions with version check
- Updated template to use proper font
After poking around a lot it seems Droid Sans was used during 2.7x series.
(or at least difference between using this font and comparing to previous
splash screens gives none visible difference).
When using metadata stamping, it's often handy to have "Camera" in
front of the camera name, "Marker" in front of the marker text, etc.,
but sometimes those get in the way. This patch allows an artist to
turn those labels on/off.
Reviewed by: sergey, mont29, venomgfx
Our usercount handling was really... infuriating :|
Here, localization (i.e. 'shalow' copy that should not touch to usercounts) was incrementing
usercounts of the sole Textures IDs of lamps and worlds (on the weak and fallacious pretext
that related BKE_free... functions would decrement those counts)... Seriously...
So now, localize funcs do not increment any usercount anymore (since matching BKE_free... ones do
not decrement any either), and we do not call anymore that stupid unlink when freeing temp
localized copies of lamps/materials at end of preview generation.
Note that we probably still have a lot to do to cleanup that copy/localize code, pretty sure
we can dedpulicate a lot more.
Curves and meshes (when no modifier application required) would increase their material usercount twice.
Not sure how/why it worked in previous code, but with new, stricter ID handling we need more
careful check of ID 'ownership' handling.
Reported by Sergey over IRC, thanks.
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
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.
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.
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.
