| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This patch adds "Less Than" and "Greater Than" evaluation types to the property sensor.
The Wiki Docs modifications http://wiki.blender.org/index.php/User:Lordloki/Doc:2.6/Manual/Game_Engine/Logic/Sensors/Property
Also, I have attached a screenshot and a blend to check.
Reviewers: dfelinto, moguri
Reviewed By: moguri
Differential Revision: https://developer.blender.org/D476
|
|
|
|
* Anisotropic BSDF now supports GGX and Beckmann distributions, Ward has been
removed because other distributions are superior.
* GGX is now the default distribution for all glossy and anisotropic nodes,
since it looks good, has low noise and is fast to evaluate.
* Ashikhmin-Shirley is now available in the Glossy BSDF.
|
|
* Ashikhmin-Shirley anisotropic BSDF was added as closure
* Anisotropic BSDF node now has two distributions
Reviewers: brecht, dingto
Differential Revision: https://developer.blender.org/D549
|
|
|
|
Suggestion by Andy Davies (metalliandy) to conform with industry standard (custom cage is something else apparently)
Note: this is the last bake related commit I plan for 2.71/rc (unless
everyone agrees that we could squeeze in D546 - custom UVs, which would
be really nice to add for 2.71 scripters)
Note 2: I'll update the wiki docs shortly
|
|
slightly outside the mesh.
Reported by Thomas Beck on irc. Issue here is that the mesh bounding box
changes as we are transforming the vertices. Solution is to collide
against the initial bounding box. Unfortunately the snapping functions
are made in a way that a lot of code needed to be tweaked here, but the
change should be straightforward and harmless (famous last words, I
know).
Ideally we might want to even increase the size of the bounding box a
little (as seen in screen space) to allow snapping even in cases where,
cursor is slightly outside the bounding box, but since this is not so
straightforward to do for all cases, at least for me, leaving this as
a TODO.
|
|
There is a new option to select whether you want to use cage or not.
When not using cage the results will be more similar with Blender
Internal, where the inwards rays (trying to hit the highpoly objects)
don't always come from smooth normals. So if the active object has sharp
edges and an EdgeSplit modifier you get bad corners.
This is useful, however, to bake to planes without the need of adding
extra loops around the edges.
When cage is "on" the user can decide on setting a cage extrusion or to
pick a Custom Cage object. The cage extrusion option works in a
duplicated copy of the active object with EdgeSplit modifiers removed to
inforce smooth normals. The custom cage option takes an object with the
same number of faces as the active object (and the same face ordering).
The custom cage now controls the direction and the origin of the
rays casted to the highpoly objects. The direction is a ray from the
point in the cage mesh to the equivalent point to the base mesh. That
means the face normals are entirely ignored when using a cage object.
For developers:
When using an object cage the ray is calculated from the cage mesh to
the base mesh. It uses the barycentric coordinate from the base mesh UV,
so we expect both meshes to have the same primitive ids (which won't be
the case if the cage gets edited in a destructive way).
That fixes T40023 (giving the expected result when 'use_cage' is false).
Thanks for Andy Davies (metalliandy) for the consulting with normal
baking workflow and extensive testing. His 'stress-test' file will be
added later to our svn tests folder. (The file itself is not public yet
since he still has to add testing notes to it).
Many thanks for the reviewers.
More on cages:
http://wiki.polycount.com/NormalMap/#Working_with_Cages
Reviewers: campbellbarton, sergey
CC: adriano, metalliandy, brecht, malkavian
Differential Revision: https://developer.blender.org/D547
|
|
|
|
settings.
|
|
|
|
Classic case of integer flag AND-ing result passed to boolean and
failing.
|
|
|
|
|
|
|
|
also allow passing NULL vertex to BKE_curve_nurb_vert_active_set
|
|
Forbid this now and do tricks in the versioning code to repair
corrupted files.
Thanks to Pablo, Caminandes and Koro for discovering this bug!
|
|
|
|
for exporters).
|
|
|
|
|
|
|
|
passing NULL to BLI_sprintfN crashed in some cases.
|
|
|
|
start out with frame=0
So! First, frame for absolute shape keys: never allow a new key to have the same pos as an
existing one (this does not make sense). This way, the two workflows are possible (create
all keys and then animate ctime, or animate ctime and then create keys where you need them).
Also, fixed UIList for shapekeys, the "absolute" test was wrong, and better to show frame
value, even though not editable, than nothing in case of absolute keys.
And finally, add getter to RNA 'frame' readonly value, so that we output real frame values,
and not dummy internal ones (which are /100) in our API.
|
|
|
|
|
|
particle texture slot
|
|
- underline faces had flipped winding by default.
- BKE_vfont_to_curve_ex disallowed 0 underline height (annoying when sliding value)
- disallow negative underline height since it flips underline direction (just change position + height)
|
|
|
|
|
|
|
|
modules.
|
|
|
|
FreestyleSettings and FreestyleModuleSettings are now defined as RNA aliases of
FreestyleConfig and FreestyleModuleConfig, respectively.
|
|
|
|
style modifiers.
|
|
|
|
|
|
|
|
|
|
cleared from the drivers
With this change, there should hopefully be less need to hit "Update Dependencies"
on drivers so often.
|
|
This patch removes the limitations on the number of action layers in the BGE.
BL_ActionManager currently uses a fixed array to keep track of the action layers. This patch replaces the fixed array with a map which allows for dynamic allocation of action layers. Layers (map items) are automatically removed on BL_ActionManager's update function. The maximum number of layers is roughly the value of a short. Backwards functionality is maintained and there are no changes to the Python API.
Task Discussion:
https://developer.blender.org/T39572
Author: Kevin Ednalino
Reviewers: moguri
Differential Revision: https://developer.blender.org/D491
|
|
Reviewed By: dingto, brecht
Differential Revision: https://developer.blender.org/D507
|
|
As reported by ZanQdo on IRC, the bend modifier's "angle" property had a range
of +/- 572.95 degrees (equivalent to 10 radians). From the looks of things, this
was simply something overlooked when doing degrees to radians conversions. Now
it has a range of +/- 180 degrees.
|
|
Makes importing armatures from matrices (FBX...) *much* easier.
|
|
|
|
|
|
Paolo Acampora.
Reviewers: brecht, kjym3, #freestyle
Reviewed By: brecht, kjym3
Differential Revision: https://developer.blender.org/D246
|
