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.
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
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.
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 commit includes a few things:
* It moves the Rake and Random flags from the brush to the MTex.
* The first change allows mask textures to have independent rake
support.
* Random rotation now has an angle value that controls the width of the
effect from the rake or default angle
* Rake and Random are now supported together.
This commit contains:
- Subversion bump to 2.73
- Release cycle is set to "rc"
- Submodules are pointed to appropriate tag now
(addons contrib just points to the latest contrib repo)
- New shiny splash screen!
It turns out that several important modelling addons depend on the assumption
that Grease Pencil data gets created on the active object instead of on scene
level. This commit adds a toggle for setting whether new Grease Pencil data
is created on scene or object level.
These work as follows:
* "Scene" = The behaviour originally introduced as part of the GPencil_EditStrokes
changes. New strokes are added to the scene instead of the active object, making
it easier to manage things when working with Grease Pencil in general.
* "Object" = The previous behaviour (from 2.50 to 2.72), where new strokes are added
to the active object. This is now being reintroduced to soften the transition
for addons out there which have been doing this in a lazy/lax way so far.
Now, what may be slightly confusing are the "fallback" measures in place:
* "Scene" - To ensure that loading old files goes ok without needing a version patch,
if the active object has GPencil data, that will be used in place of the scene's
own GPencil data.
* "Object" - If there was no active object at the time of creating strokes
(for instance, if you delete the active object immediately before drawing),
GPencil data gets attached to the current scene instead.
Since some tweaks may still be needed here, I've decided to bump the subversion
number so that we have a reference point when doing version patches.
Make pie menu item placement touch the radius from the internal side of
the buttons rather than placing on the center on the cirtcle. This
allows us to get rid of the separate visual angle property, also allows
for tighter placement of pies with a smaller radius without easily
overlapping.
Also pie menu title now always appears above the threshold indicator.
This commit merges the code in the pie-menu branch.
As per decisions taken the last few days, there are no pie menus
included and there will be an official add-on including overrides of
some keys with pie menus. However, people will now be able to use the
new code in python.
Full Documentation is in http://wiki.blender.org/index.php/Dev:Ref/
Thanks:
Campbell Barton, Dalai Felinto and Ton Roosendaal for the code review
and design comments
Jonathan Williamson, Pawel Lyczkowski, Pablo Vazquez among others for
suggestions during the development.
Special Thanks to Sean Olson, for his support, suggestions, testing and
merciless bugging so that I would finish the pie menu code. Without him
we wouldn't be here. Also to the rest of the developers of the original
python add-on, Patrick Moore and Dan Eicher and finally to Matt Ebb, who
did the research and first implementation and whose code I used to get
started.
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
This is related to Task T34861 to increase up & track axis options for TrackTo actuator. I've just added it to differential to facilitate an easier review.
With the patch applied you can select X, Y and Z axis for the Up axis, and X, Y, Z, -X, -Y and -Z for the track axis.
Related to the implementation I have used the algorithm from Trackto constrain placed in constrain.c but adapted to be used with MOTO library.
The wiki docs are here (http://wiki.blender.org/index.php/User:Lordloki/Doc:2.6/Manual/Game_Engine/Logic/Actuators/Edit_Object#Trackto_Actuator).
Test file is here: {F97623}
I have also uploaded 2 screenshots showing the UI modifications to the TrackTo actuator:
{F91992} {F91990}
Reviewers: moguri, dfelinto
Reviewed By: moguri
CC: Genome36
Differential Revision: https://developer.blender.org/D565
New properties 'line_color' and 'line_priority' are added to Material ID data blocks.
The 'line_color' property allows users to specify a per-material line color that can be
used as a Freestyle line color through Material color modifiers of line style settings.
The new line color property is intended to provide a solution for line color
stylization when a proper Freestyle support for Cycles is implemented (likely
as part of the upcoming Blender 2.72 release; see Patch D632). Materials in
Cycles are usually set up using shader nodes, and Freestyle won't be capable
of retrieving colors and other properties from node-based materials any soon.
The new line color property of materials addresses this foreseen limitation by
providing artists with an intuitive alternative mean to specify line colors on a
per-material basis independently from node trees.
The 'line_priority' property gives users a way to control line colors at material
boundaries. When a line is drawn along a feature edge at material boundaries,
one of the two materials on both sides of the edge has to be picked up to
determine the line color. So far there was no way to control this selection
(which was in effect at random). Now the material with a higher line color
priority will be selected.
The new per-material line settings are shown in the new Freestyle Line tab in
the Material context of the Properties window (only when Freestyle is enabled).
So that users opening a .blend saved in 2.70.5 and above in an older version
get warning the file might not be 100% compatible (should have been done
already for 2.70, actually).
As suggested by Campbell, bump subversion and reset all ui_previews data (so that any file that could
have been corrupted in past two weeks because of this bug is fixed and valid again).
Line styles now have a set of new options for rearranging the stacking order of lines.
This gives artists more control to determine which lines should be drawn on top of others.
Two available sort keys are the distance from camera and curvilinear 2D length.
Since the distance of a line from camera may vary over vertices, another option called
integration type is used to compute the sort key for a line from the values computed at
individual vertices. Available integration types are MEAN, MIN, MAX, FIRST and LAST
(see the tool tips for more detail).
* Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf).
EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit.
* Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it
(tessellation, rna access, etc.).
* Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable
split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding
this option is now incoherent, will be addressed in a separate commit.
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D365
There is no good solution here, since RNA props can only have one type/unit.
Tried to find the less worse one - have different RNA props for same DNA value
(a bit like the angle/length for camera lens).
Also fixed two other issues with Transform conctraint:
* Angle were still in degrees (yes, another backward-compatibility breacking).
* Scale was absolute, unlike loc/rot.
Also cleaned up a bit the code, replaced some magic numbers by proper enums, ...
For initial discussion see T38371
This commit organized panels for image editor to new tab categories dependent
on the image editor mode:
View Mode:
Tools - contains UV tools (currently only transform and UV Sculpting)
Scopes - contains scopes
Grease Pencil - contains Grease Pencil operators
Paint Mode:
Tools - contains brush options
Scopes - as above
Grease Pencil - as above
Mask Mode
Mask - contains mask tools
Scopes - as above
Grease Pencil - as above
Grease Pencil panel/tab now includes operators, not view options which have been
moved to the UI region on the right.
To make this work better, image editor toolbar now is of type TOOLS instead
of PREVIEW as was the case previously. A nice version patch makes sure all
works predictably, but opening newer files with older blender executables
could backfire.
This commit does not address which UV Tools will be included in the
Tools tab for the view mode, but does include some basic tools (transform)
and provides a class to inherit from to avoid conflicts with UV Sculpting.
Reviewers: brecht, dingto, sergey
Differential Revision: https://developer.blender.org/D315
patch D234 from Jonathan Williamson with edits
- de-duplicate rna_def_userdef_theme_space_gradient and rna_def_userdef_theme_space_generic
- ui_theme_init_new_do now always sets theme settings (no need to test),
used by bpy.ops.ui.reset_default_theme()
EditFont's use of Curve.len was very confusing, in editmode it
represented the number of characters, in object mode the number of
bytes. add Curve.len_wchar and keep track of both.
Also don't convert the editmode text into utf8 on every keystroke.
Now this is done on exiting editmode or save - to match most other
object types.
This also fixes curves 'body_format' being reported with an invalid size.
* Move symmetry options to the paint struct (where all paint systems can
make use of it)
* Rename draw_pressure to stroke_active. This is what is really checked
on those occasions that this is used. Also move turning on/off of this
option to the stroke level and avoid doing it on every stroke system.
* Rename BRUSH_RESTORE_MESH to BRUSH_DRAG_DOT. In image painting this
won't restore any mesh, so better have a name that is directly linked to
what the flag actually does.
moved the hide preview logic to a method on bNodeTreeType. This way the node.c keeps clean, but logic could still be shared.
Implementing this per node, can lead to future errors.
This patch changes most of the reamining degrees usage in internal code into radians.
I let a few which I know off asside, for reasons explained below - and I'm not sure to have found out all of them.
WARNING: this introduces forward incompatibility, which means files saved from this version won't open 100% correctly
in previous versions (a few angle properties would use radians values as degrees...).
Details:
- Data:
-- Lamp.spotsize: Game engine exposed this setting in degrees, to not break the API here I kept it as such
(using getter/setter functions), still using radians internally.
-- Mesh.smoothresh: Didn't touch to this one, as we will hopefully replace it completely by loop normals currently in dev.
- Modifiers:
-- EdgeSplitModifierData.split_angle, BevelModifierData.bevel_angle: Done.
- Postprocessing:
-- WipeVars.angle (sequencer's effect), NodeBokehImage.angle, NodeBoxMask.rotation, NodeEllipseMask.rotation: Done.
- BGE:
-- bConstraintActuator: Orientation type done (the minloc[0] & maxloc[0] cases). Did not touch to 'limit location' type,
it can also limit rotation, but it exposes through RNA the same limit_min/limit_max, which hence
can be either distance or angle values, depending on the mode. Will leave this to BGE team.
-- bSoundActuator.cone_outer_angle_3d, bSoundActuator.cone_inner_angle_3d: Done (note I kept degrees in BGE itself,
as it seems this is the expected value here...).
-- bRadarSensor.angle: Done.
Reviewers: brecht, campbellbarton, sergey, gaiaclary, dfelinto, moguri, jbakker, lukastoenne, howardt
Reviewed By: brecht, campbellbarton, sergey, gaiaclary, moguri, jbakker, lukastoenne, howardt
Thanks to all!
Differential Revision: http://developer.blender.org/D59
This allows you to choose between subdivide edges, collapse and both. Being able to
only collapse edges can be useful to simplify meshes with accidentally introducing
more detail.
Reviewed By: psy-fi, carter2422
Differential Revision: http://developer.blender.org/D15
mimics the previous behavior when settings were shared by both modes (but not equivalent).
NOTE: Due to the use of additional sRGB conversion in the LGG mode the result is not entirely accurate, this should perhaps be fixed.
Settings for each mode are kept in their own color values nevertheless, this avoids potential problems with float precision.
* Remove the compatible falloff SSS implementation. We shouldn't support two implementations in the long term, and 2.7x is a good release number do break some compatibility as well.
* Version patch added, so Files with Compatible falloff will automatically use Cubic now.
It was already mentioned in the manual, that Compatible is deprecated.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#BSSRDF
