This patch updates the timeline editor. Ordinarily, it draws the
yellow keyframe lines at 100% of the available height. This becomes an
issue when there are keyframes for every frame, which can happen when
importing motion capture data or recording animations from the BGE. In
such cases, the green "current frame" indicator becomes very hard to
see.
This patch restricts the drawing to the bottom 60% of the available
space, thereby making the "current frame" indicator more visible.
Reviewers: aligorith
Reviewed By: aligorith
Subscribers: Severin
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1033
The function was checking the psys flag for this, but since for
disconnect/connect the same psys is used as source and target, the flag
must be passed explicitly.
The logic used for determining whether certain keyframing settings (i.e. visual,
only needed, xyz -> rgb) got applied was wonky. The original intention here was
that the Keying Set settings would override the global settings, and the path
settings would override what was used for the Keying Set. However, that was not
happening in all cases previously, as it was only possible to add flags and not
to turn them off.
This commit fixes that by introducing separate toggles to control whether the
Keying Set/Path's settings override the settings inherited from its parent
(i.e. the Keying Set for the Path, and the User Prefs for the Keying Set).
The icons used for these toggles could get revised a bit (we need something
which communicates "override this"; the current one is the closest I could find)
WARNING: If you have old keying sets, this may cause some breakage!
Since 1c3f2354f83b3e79dee31d837ca4d7c08d2c3f26 the keyframing settings on
Keying Sets have been incorrectly displayed as a clump of toggle buttons,
which are usually only used when only one of the options apply.
Reverting this back to how it was, while leaving bl_options in place still for
the one case where it makes sense to do it that way (i.e. for KeyingSetInfo)
Campbell once told me such checks can cause warnings on some compilers, so
let's try to avoid them.
From the theoretical view, this check works quite different than the old
one, but in this case everything should work just like previousely.
Steps to reproduce:
1) Create an object, animated with shape keys
2) Copy it with Alt-D
3) Push action down to nla track
4) Select that track and delete it
In attached file 1-3 steps are completed.
{F138559}
Alexander (Blend4Web Team)
Reviewers: aligorith
Subscribers: yurikovelenov, Evgeny_Rodygin, valentin_b4w, AlexKowel
Differential Revision: https://developer.blender.org/D1015
Finally! At long last, I've gotten this working! This ended up being far trickier
to get right than anticipated; the normal remapping API's cannot be used as-is
as they will just clobber over subtleties whenever datablock changes are involved.
So, for now, we have to duplicate the logic a bit.
Now, RNA Paths and driver targets get corrected, but at the expense of this
always happening (i.e. even for those affecting drivers which existed before).
Root of the issue goes to the fact that since the very beginning Cycles was
using ZYX euler rotation for mapping shader node but blender was always
using XYZ euler rotation.
This commit switches Cycles to use XYZ euler order and adds versioning code
to preserve backward compatibility.
There was no really nice solution here because either we're ending up with
versioning code or we'll need to deal with all sort of exceptions from blender
side in order to support ZYX order for the mapping node. The latest one is
also creepy from the other render engines points of view -- that might break
compatibility with existing bindings or introduce some extra headache for them
in the future.
This could also become a PITA for us with need of supporting all sort of weird
and wonderful exceptions in the refactored viewport project.
NOTE: This commit breaks forward compatibility, meaning opening new files in
older blender might not give proper result if Mapping node was used.
Also, libraries are to be re-saved separately from the scene file, otherwise
versioning code for them wouldn't run if scene file was re-saved with new
version of blender.
Reviewers: brecht, juicyfruit, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D973
This way it is possible to probe shading compatibility of a given node from
python, making things like versioning code much easier to perform.
it's only valid for shading nodes, for other nodes the property also exists
but reads as an empty enum.
To access this compatibilities:
node.shading_compatibility
This function allows the user to run specific code for each of the
rendered stereoscopic eyes in the Game Engine.
The initial use case is to set the camera projection matrix in
a scene.pre_draw callback function for each eye, to be used in VR
(Virtual Reality) installations.
Reviewed by Mitchell Stokes and Campbell Barton, thank you guys.
Sample Test Python Script:
"""
import bge
import bgl
import blf
def init():
"""init function - runs once"""
scene = bge.logic.getCurrentScene()
scene.post_draw.append(write)
def write():
"""write on screen - depending on the eye"""
width = bge.render.getWindowWidth()
height = bge.render.getWindowHeight()
# OpenGL setup
bgl.glMatrixMode(bgl.GL_PROJECTION)
bgl.glLoadIdentity()
bgl.gluOrtho2D(0, width, 0, height)
bgl.glMatrixMode(bgl.GL_MODELVIEW)
bgl.glLoadIdentity()
eye = bge.render.getStereoEye()
if eye == bge.render.LEFT_EYE:
blf.position(0, (width * 0.2), (height * 0.3), 0)
blf.size(0, 40, 72)
blf.draw(0, "Left")
else: # bge.render.RIGHT_EYE:
blf.position(0, (width * 0.7), (height * 0.3), 0)
blf.size(0, 40, 72)
blf.draw(0, "Right")
"""
This way Cycles finally becomes feature-full on image projections
compared to Blender Internal and Gooseberry Project Team could
finally finish the movie.
Refactored some code to be easier to read. Semantically the code is
identical.
- Some conditions were negated to be able to return/continue early,
rather than having the majority of the code inside an if-body.
- Conditions were simplified (!(a == b)) turned into (a != b);
repeated conditions calculated only once.
- Unnecessary variables and one unnecessary condition were
eliminated.
Reviewers: campbellbarton, lordloki
Reviewed By: lordloki
Projects: #game_physics
Differential Revision: https://developer.blender.org/D954
Currently, when joining two armatures, the drivers of the armatures being merged
in are lost. This commit introduces a new AnimData API function for merging
animation data into another AnimData block.
NOTE:
* For now, this only copies the drivers over. As a result, manual effort will
still be needed to go through and fix the drivers.
I am working on automating that process, but it's more important that the
drivers don't have to be created from scratch for now (since this is needed
for the Goosberry rigging work).
A development addon can be used now to enable the debug drawing, without
the need to add UI code for this in the release files.
The SimDebug feature should also get an overall build flag and use
function stubs unless enabled. That way any possibility of overhead in
releases is eliminated.
These were used as UI buttons during development. If such parameters are
needed again later they should instead be added in the (now global)
SimDebugData and made accessible with a dev addon or so.
Name each icon group from its define in Blender.
Simplifies searching for a given icon (in one way or the other), and could also be
useful one day in some scripting.
Also, removed/fixed more empty and stray groups...
Finally, found that we have several svg icons not linked to any defines, and one define
with no icon (dyntopo), would be nice to sort this one way or the other too.
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.
Previously, if the active object was a child, "Show Active" only showed the
parent object. Now it also opens the tree to take children into account.
Patch D974 by @lichtwerk with some minor edits, reviewed by me.
Code in ccgdm_draw_attrib_vertex() was entirely the same as the top
portion of the code in cddm_draw_attrib_vertex(). Moved this code to a
new function, DM_draw_attrib_vertex().
ccgdm_draw_attrib_vertex() was removed in favor of calling
DM_draw_attrib_vertex(). cddm_draw_attrib_vertex() still does a couple
extra things, so it still exists but calls DM_draw_attrib_vertex().
In the interest of easy code review, no changes made to the code in
DM_draw_attrib_vertex() other than the new name and an added comment.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1010
The paths for parents and children are generated using the same function
with a rather obscure test to distinguish them. Modifiers (clump, kink,
roughness) should not be applied to parents though.
Different interpolation methods in compositor could lead to 0.5 pixel offset in
final renders. This is because of some inconsistency in integer coordinates
which might mean pixel corner or pixel center.
Should be all fine now.
mode.
This was caused by variation of the number of keys on child hairs due
to shortening of hair curves based on euclidian distances. The other
kink modes also shorten hairs, but use the parametric distance instead,
which does not vary with deformation of hairs.
By default this now copies from one object's local space to another
object's local space (instead of the previous world space). This is
more useful when transferring particles between objects, because it
doesn't require moving objects on top of each other, as long as they
have similar shapes.
another, including edit data (grooming).
This uses basically the same method as the existing connect/disconnect
feature. The main difference is that it allows working with multiple
objects and transferring the //particle/hair data// instead of the
//mesh// data (which is what connect/disconnect expects). This is a much
more realistic workflow when rigging, topology etc. changes and
groomed hair has to be transferred to the changed model.
This is BAD code, but the particle kinking does not make it easy to
write a non-local modifier that requires neighboring positions,
curvature, etc. The feature is needed for Gooseberry.
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
Scope update is very slow for high resolutions, and currently blocks
the UI thread(!). This is especially terrible in paint modes, where
each stroke causes a scope update and unacceptable freezing.
The scopes update method tries to avoid this somewhat by skipping if the
toolbar is disabled, but this doesn't help when painting where brush
tools etc. are frequently needed. It's also a bad-level poll, with the
core system accessing a UI element.
Eventually scope updates should become a low-priority background job,
as well as becoming threaded. Until then this polling provides a usable
workaround to the most outrageous cases.
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 contains a few pieces of code for a future "modifier" system that
would allow more flexible combination of effects. Eventually a node
system is the way to go, but the current code makes that impossible.
to prevent double-freeing/invalid mem access.
This can happen with the "virtual parents" feature, which generates both
parent and child paths. Each task free function also freed the shared
context, leading to double freeing.
Cloth data is used both for hair and actual cloth, which makes things
really difficult. The face number was used for distinguishing the two
types (no faces == hair mesh), but the extra hair data necessary for
hair sim is generated by particles and not available for edge-only cloth
meshes. This really needs to be sanitized ...
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
approach does not work very well.
Using a cross section estimate still causes large oscillations due to
varying hair force based on angles. It also requires a sensible hair
thickness value (particle radius) which is difficult to control and
visualize at this point.
The new model is based purely on per-vertex forces, which seems to be
much more stable. It's also somewhat justified by the fact that each
hair vertex represents a certain mass.
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
The previous calculation was modulated with the angle between the wind
direction and the segments, which leads to very oscillating behavior.
Now the formula includes an estimate for the geometric cross section
of a hair segment based on the incident angle and the hair thickness
(currently just the particle size). This gives a more stable behavior
and more realistic response to wind.
Conflicts:
source/blender/blenkernel/intern/particle_system.c
source/blender/physics/intern/BPH_mass_spring.cpp
This module will contain mirrored functions for calculating and applying
weights for points on a mesh. This includes barycentric and UV weighting
and possibly more advanced global weighting such as harmonic weights.
The naming should follow this scheme:
<type>_{2d,3d}_{calc,apply}
e.g.
poly_2d_calc
poly_2d_apply
uv_3d_calc
...
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D939
A stupid hack is needed here, changing the way the factor is applied to
angular bending springs. In cloth sim the bending factor of individual
springs is applied as a mix value between the bending stiffness and a
max value, but this max value isn't even used in hair sim so that
approach becomes useless.
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
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
framing method instead of the Frenet frame.
The Frenet frame is very succeptible to sudden twists along straight
sections of a curve where the second derivative (curvature) becomes 0.
to support multiple hash identifiers.
Using explicit hashing functions for every sim debug call defeats the
purpose of having a quick feedback system. Now this can be done simply
by passing an arbitrary number of hash inputs (integers) at the end of
the function calls, which are then combined by a system of variadic
macros (based on the ELEM feature). Up to 8 identifiers are supported
currently, but more could be added easily if needed.
Conflicts:
source/blender/blenkernel/intern/particle_system.c
source/blender/physics/intern/BPH_mass_spring.cpp
solver input and output.
This uses the central difference method (instead of combined forward/
backward difference), which makes it easier to correctly account for
grid borders.
samples.
This is just an intermediate method to make sure the density is valid.
Eventually the closest-point method should be used, but for testing
the poisson solver this is easier to debug.
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
This allows setting a target density which the fluid simulation will
take into account as an additional term in the pressure Poisson
equation. Based on two papers
"Detail Preserving Continuum Simulation of Straight Hair" (McAdams et al. 2009)
and
"Two-way Coupled SPH and Particle Level Set Fluid Simulation" (Losasso et al. 2008)
Currently the target pressure is specified directly, but it will be
a lot more convenient to define this in terms of a geometric value such
as "number of hairs per area" (combined with hair "thickness").
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
on the grid.
This uses the Eigen conjugate-gradient solver to solve the implicit
Poisson equation for the pressure Laplacian:
div(grad(p)) = div(v)
As described in "Detail Preserving Continuum Simulation of Straight Hair"
(McAdams, Selle, 2009).
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
This is a bit more awkward for artists to use, but necessary for
a stable solution of the hair continuum calculation. The grid size is
defined by the user, the extent of the grid is then calculated based on
the hair geometry. A hard upper limit prevents bad memory allocation
in case too small values are entered.
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
This is an artifact of earlier attempts to implement velocity smoothing,
but doesn't work anyway.
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
This is a leftover from previous approach of hair collisions (with
insufficient results). The hair volumetrics actually implements
"collision" with solid objects as well, but uses a Neumann boundary
condition on the main grid for this purpose.
This is based on the paper
"Detail Preserving Continuum Simulation of Straight Hair"
(McAdams, Selle, Ward, 2009)
The main difference is that hair line segments are used rather than only
rasterizing velocity at the vertices. This gives a much better coverage
of the hair volume grid, otherwise gaps can be produced at smaller grid
cell sizes and the distribution is uneven along the hair curve.
The algorithm for rasterizing is a variation of Bresenham's algorithm
extended onto 3D grids.
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
solver step.
Calculating forces and jacobians from linearly interpolated grid values
is problematic due to discontinuities at the grid boundaries. The new
approach of modifying velocities after the backward euler solver step
was suggested in a newer paper
"Detail Preserving Continuum Simulation of Straight Hair"
(McAdams, Selle 2009)
Conflicts:
source/blender/physics/intern/BPH_mass_spring.cpp
easier.
This code is badly broken and needs to be replaced, but at least having
a workable code structure might help with quick hacks to fix the worst
cases.
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.
one solver anyway), and split some particle cloth functions for clarity.
Conflicts:
source/blender/blenkernel/BKE_particle.h
source/blender/blenkernel/intern/particle_system.c
source/blender/blenloader/intern/versioning_270.c
source/blender/makesdna/DNA_particle_types.h
source/blender/makesrna/intern/rna_particle.c
distribution and path caching for child particles.
This gives a significant improvement of viewport playback performance
with higher child particle counts. Particles previously used their own
threads and had a rather high limit for threading. Also threading
apparently was disabled because only 1 thread was being used ...
This is not necessary: the implicit solver data can keep track instead
of how many off-diagonal matrix blocks are in use (provided the
allocation limit is calculated correctly). Every time a spring is
created it then simply increments this counter and uses the block index
locally - no need to store this persistently.
Without this the particle system only shows the actual non-simulated
hairs ("guide hairs") during edit mode. These hairs are used for goals
as well, so showing them in the regular viewport is pretty important.
Also the usual hair curves are interpolated along the entire length,
which makes it very difficult to see exact vertex positions, unless
using exact powers of 2 for the segment number and match the display
steps.
Conflicts:
source/blender/blenkernel/intern/particle.c
The curl radius for children in interpolated mode was calculated using
the total offset from the parent particle. This leads to very large
radii when the distance is large due to sparse parents. Such behavior is
also very unrealistic because the curl radius is mostly constant and
defined by the material properties.
All the child hairs are roughly parallel by default. To simulate the
agglomeration of children into hair wisps the "flatness" parameter is
now used to clump them together.
With the default 5 substeps the simulation can otherwise still become
unstable. This is just a preliminary measure anyway until the length
variance can be fixed properly.
This is more involved than using simple straight bending targets
constructed from the neighboring segments, but necessary for restoring
groomed rest shapes.
The targets are defined by parallel-transporting a coordinate frame
along the hair, which smoothly rotates to avoid sudden twisting (Frenet
frame problem). The rest positions of hair vertices defines the target
vectors relative to the frame. In the deformed motion state the frame
is then recalculated and the targets constructed in world/root space.
derivatives for stabilization.
The bending forces are based on a simplified torsion model where each
neighboring point of a vertex creates a force toward a local goal. This
can be extended later by defining the goals in a local curve frame, so
that natural hair shapes other than perfectly straight hair are
supported.
Calculating the jacobians for the bending forces analytically proved
quite difficult and doesn't work yet, so the fallback method for now
is a straightforward finite difference method. This works very well and
is not too costly. Even the original paper ("Artistic Simulation of
Curly Hair") suggests this approach.
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 makes the bending a truely local effect. Eventually target
directions should be based in a local coordinate frame that gets
parallel transported along the curve. This will allow non-straight
rest shapes for hairs as well as supporting twist forces. However,
calculating locally transformed spring forces is more complicated.
These are much better suited for creating stiff hair. The previous
bending springs are based on "push" type spring along the hypothenuse
of 3 hair vertices. This sort of spring requires a very large force
in the direction of the spring for any angular effect, and is still
unstable in the equilibrium.
The new bending spring model is based on "target" vectors defined in a
local hair frame, which generates a force perpendicular to the hair
segment. For further details see
"Artistic Simulation of Curly Hair" (Pixar technical memo #12-03a)
or
"A Mass Spring Model for Hair Simulation" (Selle, Lentine, Fedkiw 2008)
Currently the implementation uses a single root frame that is not yet
propagated along the hair, so the resulting rest shape is not very
natural. Also damping and derivatives are still missing.
single transform matrix.
Dynamic properties of the transformation are only needed during the
setup phase when they should be read from external data (hair system
roots) and generate fictitious forces on each point.
This is part of the original method from "Volumetric Methods for
Simulation and Rendering of Hair". The current filter is a simple box
filter. Other energy-preserving filters such as gaussian filtering
can be implemented later.
The filter size is currently given as a cell count. This is not ideal,
rather it should use a geometrical length value, but this is too
abstract for proper artistical use. Eventually defining the whole grid
in terms of spatial size might work better (possibly using an external
object).
at a the margin distance ("outer" softbody margin).
This has to be clamped arbitrarily unfortunately, otherwise the
repulsion force can add too much energy into the system. A factor of
4 * restitution impulse seems to give good results for now, this can
be refined later on if necessary.
This is now also decoupled from the internal solver data. The grid is
created as an opaque structure, filled with vertex or collider data
(todo), and then forces can be calculated by interpolating the grid at
random locations. These forces and derivatives are then fed into the
solver.
The hair solver needs sane input to converge within reasonable time
steps. In particular the spring lengths must not be too difference
(factor 0.01..100 or so max, this is comparable to rigid body simulation
of vastly different masses, which is also unstable).
The basic hair system generate strands with equally spaced points, which
is good solver material. However, the hair edit operators, specifically
the cutting tool, can move points along the strands, creating tightly
packed hair points. This puts the solver under enormous stress and
causes the "explosions" observed already during the Sintel project.
The simple solution for now is to exclude very short hairs from the
simulation. Later the cutting tool should be modified such that it
keeps the segments roughly at the same length and throws away vertices
when the hair gets too short (same goes for the extension tool).
The hair system should have a general mechanism for making sure that
situations such as this don't occur. This will have to be a design
consideration for replacements in any future hair system.
moving hair root reference frames.
This calculates Euler, Coriolis and Centrifugal forces which result
from describing hair in a moving reference frame.
http://en.wikipedia.org/wiki/Fictitious_force
frames.
These forces don't have to be calculated for each individual
contribution. Rather they can be split off and be calculated on top of
the basic force vector rotation (todo).
