screen.
Apparently the screen on the given file did not have a scene attached.
Not sure how this is possible exactly, but for now just guard against it
at load time by assigning default scene in that case.
New Lock Z velocity parameter was added. This parameter avoid the micro-jumping.
By default it is actived except when you load an old file that it is deactived to keep former behaviour.
Additionally it was solved another issue related with the acceleration: That is the acceleration value was not taked into account and we had always the maximum linear velocity from the beginning of movement. Now the acceleration is taken into account until we reach the maximum velocity.
When you load an old file, the acceleration value is set to the maximum range (1000.f). This way we simulate a maximum velocity constant from the beginning of movement (former behaviour).
{F142195}
Reviewers: moguri, dfelinto, campbellbarton
Reviewed By: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D1074
This reverts the change made in 8872cba7e9
which was contributing to actions being lost in some cases [1], even when
they were assigned to those actuaters, which needed them to be able to
function. Now there's one less case where users are needed but were missing :)
Note that this still doesn't solve the core issue where nothing is responsible
for associating actions created for a particular datablock (and not currently
being used in its active action slot, or in the NLA stack) with that datablock.
That issue is the cause of most action disappearances as well as for other problems
(such as renaming bones being unable to fix unreferenced/unused actions) where there
are diifferences between users' mental models and the data model. Proper fixes are
coming soon (restoring fake users here isn't a proper fix, as it only masks the
fundamental mismatch/problem here).
[1] http://blenderartists.org/forum/showthread.php?357021-BGE-loses-actions
Originally the files are coming from ancient early-2.4x epoch, but in
theory such setups might have been re-saved multiple times already with
more recent blender versions.
So the verisoning code is applied on all the files, including very
recent ones.
Bumped subversion, because this check si not really cheap.
This commit introduces a few ready made effects for the 3D viewport
and OpenGL rendering.
Included effects are Depth of Field, accessible from camera view
and screen space ambient occlusion. Those effects can be turned on and
tweaked from the shading panel in the 3D viewport.
Off screen rendering will use the settings of the current camera.
WIP documentation can be found here:
http://wiki.blender.org/index.php/User:Psy-Fi/Framebuffer_Post-processing
structs to paint struct (might be useful for vertex paint too in the
future)
Cavity masking now has a curve control. The control will set the amount
of masking for positive cavity ("pointness") or negative cavity
("cavity") with x axis being the amount of cavity and 0.0 = full cavity,
1.0 = full pointness, 0.5 = no cavity and the y axis being the amount of
alpha.
Bookmarks are now editable (i.e. you can rename them, and reorder them).
They are also listed in regular UILists, so you can filter/sort them as usual too.
Also, FileBrowser 'T' side area is changed to something similar to 3DView one,
in this case because we need op panel to remain at the bottom, and later because
we'll more than likely need tabs here!
Thanks to Campbell and Sergey for reviews.
Differential Revision: https://developer.blender.org/D1093
Using different scenes with 2+ windows broke entirely using undo.
Now keep track of the current windows scene in each undo-file,
and ensure the undo-scene is on a visible window when undo is executed,
switching the scene only when its not in a visible window.
This is the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
Quite striaghtforward change, and in theory we can even try supporting motion
blur for the corner pin node (which is tricky because coordinates actually
coming from sockets, but with some black magic should be doable).
- Add falloff types & curves (matching warp-modifier)
- Add uniform scale option,
important when adding hooks to non-uniform scaled objects,
especially for use with lattice objects which can't avoid uneven scaling.
This uses relative transformation set when the hook is assigned,
when measuring the distances.
This way it doesn't have to be stored as DNA runtime pointers or passed
down as a function argument. Currently there is now no property or
button to enable debugging, this will be added again later.
This adds another level of clumping on child hairs. When enabled, child
hairs chose a secondary clumping target using a Voronoi pattern. This
adds visual detail on a smaller scale, which is useful particularly when
the number of parents is relatively small.
Natural fibres behave in a similar way when they become sticky and
intertwined. Hairs close to each other form a first twisted strand, then
combine into larger strands. Similar features can be found in ropes:
http://en.wikipedia.org/wiki/Hair_twistshttp://en.wikipedia.org/wiki/Rope
Conflicts:
source/blender/blenloader/intern/versioning_270.c
This is an alternative method to the current fixed function with a
clump factor and "shape" parameter. This function is quite limited and
does not give the desired result in many cases (e.g. long, parallel
rasta strands are problematic). So rather than trying to add more
parameters there is now a fully user-defined optional curve for setting
the tapering shape.
This helps to create some variation in a hair system, which can
otherwise become very uniform and boring. It's yet another confusing
setting in a system that should have been nodified, but only option for
now (broken windows ...)
Conflicts:
source/blender/blenkernel/intern/particle_system.c
source/blender/physics/intern/BPH_mass_spring.cpp
shape instead of a brush tool.
The brush cutting tool for hair, while useful, is not very accurate and
often requires rotating the model constantly to get the right trimming
on every side. This makes adjustments to a hair shape a very tedious
process.
On the other hand, making proxy meshes for hair shapes is a common
workflow. The new operator allows using such rough meshes as boundaries
for hair. All hairs that are outside the shape mesh are removed, while
those cutting it at some length are shortened accordingly.
The operator can be accessed in the particle edit mode toolbar via the
"Shape Cut" button. The "Shape Object" must be set first and stays
selected as a tool setting for repeatedly applying the shape.
This returns a general status (success/no-convergence/other) along with
basic statistics (min/max/average) for the error value and the number
of iterations. It allows some general estimation of the simulation
quality and detection of critical settings that could become a problem.
Better visualization and extended feedback can follow later.
This will allow us to implement moving reference frames for hair and
make "fictitious" forces optional, aiding in creating stable and
controllable hair systems.
Adding data in this place is a nasty hack, but it's too difficult to
encode as a DM data layer and the whole cloth modifier/DM intermediate
data copying for hair should be removed anyway.
This implements a penalty force as well as a repulsion force to avoid
further penetration, as suggested in
"Simulating Complex Hair with Robust Collision Handling"
(http://graphics.snu.ac.kr/publications/2005-choe-HairSim/Choe_2005_SCA.pdf)
Friction forces are still missing. More problematic is handling of
moving colliders, when face swap places with the hair vertex and a
collision is missed, putting the vertex inside the mesh volume. Larger
margins might help, but ultimately using Bullet collision detection is
probably more reliable and failsafe.
as forces, velocities, contact points etc.
This uses a hash table to store debug elements (dots, lines, vectors at
this point). The hash table allows continuous display of elements that
are generated only in certain time steps, e.g. contact points, while
avoiding massive memory allocation. In any case, this system is really
a development feature, but very helpful in finding issues with the
internal solver data.
This reverts commit fbc2909cef.
The reason for revert is that the commit made it so bpy.data is not set to any
of the new main (on both file open and file link/append) which basically totally
broke versioning code.
Needs some smarter solution there.
This way addons and render engines which needs to do versioning code on files will properly
do it when something is being linked or appended to the scene. Previously that callback was
only called for the local main only, making it impossible to do tweaks on linking.
