Age | Commit message (Collapse) | Author |
|
|
|
The issue was in fact caused by both preview and viewport renderers affecting
on the default material, conflicting with each other.
Preview render doesn't really need default material, so we can safely skip it's
initialization in the render pipeline for preview rendering.
|
|
Setting the material was resetting the link bit, this is OK from the UI,
confusing for scripts.
|
|
This commit mainly:
* Exposes PreviewImage struct in RNA, including ways for user to set images data.
* Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image.
* Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system.
* Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons.
Note that loading image from files' thumbnails is done when needed (deferred loading), not
when defining the custom preview/icon.
WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level.
We do not want our UI to explode under hundreds of different flashy icons!
For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons)
and the example/templates featured with Blender.
Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29).
Differential Revision: https://developer.blender.org/D1255
|
|
|
|
|
|
|
|
|
|
Support UV Map nodes for determining active UV layer. Now when an image
node is enocuntered, the system will recursively search the node's input
sockets for any UV Map nodes. Obviously this won't fetch any coordinate
transforms into painting, and it will only choose the first UV Map node
encountered if more than one UV Map nodes are combined.
However it should allow custom UV setups per materials and tweaking of
the UV Map node's UV layer from the Slots panel.
|
|
Makes usage of those funcs much more clear, we even had mixed '!strcmp(foo, bar)'
and 'strcmp(foo, bar) == 0' in several places...
|
|
paths in new copies.
Propper fix reverting most of rB60e70c0c6014e5, which was only partial specific fix.
This code uses generic `BKE_id_lib_local_paths()` func to handle all possible paths.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D977
|
|
Caused by own fix for another display case.
Shoud be safe for 2.73 final.
|
|
|
|
This is added in the spirit of the general cycles GLSL system
which is pretty much WIP still.
This will only work on cycles at the moment but generating for blender
internal is possible too of course though it will be done in a separate
commit.
This hasn't been tested with all and every node in cycles, but
environment and regular textures with texture coordinates work.
There is some difference between the way cycles treats some coordinates,
which is in world space and the way GLSL treats them, which is in view
space.
We might want to explore and improve this further in the future.
...also </drumroll>
|
|
|
|
Typo in material localization code.
|
|
|
|
|
|
Include explicit control for texturing:
This commit introduces a painting mode option, available in
the slots panel. The default value "Material" will create slots from the
blender material, same as just merged from the paint branch.
The new option "Image", will use an explicit image field that artists can use
to select the image to paint on. This will should allow painting regardless
of the renderer used or for use in modifiers.
|
|
* Add ability to choose blend type and enable/disable toggle for each
slot for blender internal.
|
|
Also avoid looping over all objects for texture paint checks when a
material changes, only check active object.
|
|
internal.
This should eliminate some confusion when people use external render
engines.
|
|
|
|
|
|
Add ability to select UV layer from the layer panel.
|
|
* paint slots from cycles only include texture image types
* tweaking with select mouse no longer confirms on release
|
|
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 way it's not needed to include BLI_threads.h from the
BKE_main.h which helps avoiding adding PThreads includes to
each library which uses Main on Windows.
From the API point of view it's now MainLock* and to lock or
unlock the main you're to use BKE_main_(un)lock().
This solves compilation error on Windows with SCons.
|
|
Added a lock to the Main which is getting acquired and released
when modifying it's lists.
Should not be any functional changes now, it just means Main is
now considered safe without worrying about locks in the callee.
|
|
bNodeTree blocks.
This was broken by rB6e99fb0 (own commit). I expected the `do_action`
argument to be of no importance in this case due to node trees using
material animation, but this is not the case.
Anyway, this patch adds back a do_action to the BKE_libblock_copy_nolib
function as well to restore the previous behavior.
|
|
The formula was not consistent across Blender and behaved strangely, now it is
a simple linear blend between color1 and min(color1, color2).
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D489
|
|
|
|
|
|
and buffer shadows.
Also refactor:
- Material property UI related to shadows
- Preparation of OR-ed mode flags (ma->mode_l) of render materials
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D313
|
|
|
|
depsgraph updates.
Material datablocks were localized by first making a regular datablock
copy, which always gets inserted into the bmain list, and then removing
it again from bmain.
Problem is that this localization happens in preview threads, which can
run while the depsgraph is also updating GPU materials. In case the
copying of materials takes any amount of time, this can cause the
depsgraph call to material_changed to use an invalid, localized material
and access invalid GPUMaterial lists which have already been freed for
the actual material.
Solution is to not add localized datablocks to the bmain lists in the
first place. bmain should be totally immutable during preview or render
threads.
|
|
|
|
The "Cast Shadows" worked as expected, but it can cause problem in some cases.
For example, when using strand render, we need disabling only buffer shadows,
but the previous changes made that impossible. "Cast Shadows" should be added
as a newly created option.
|
|
ray shadows also, and rename it to "Cast Shadows".
This allows us to make materials that don't cast ray shadows.
Turning off this property can reduce the rendering time slightly.
Note: RNA path is changed to "use_cast_shadows" as well. The older
path "use_cast_buffer_shadows" still can be used as its alias, but
it will be removed after updating some addons.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D272
|
|
|
|
|
|
|
|
Previously this only worked for some datablocks relevant to rendering, now it
can be used to detect if any type of datablock was added or removed (but not
yet to detect if it was modified, we need many more depsgraph tags for that).
Most of the changes are some function parameter changes, the important parts
are the DAG_id_type_tag calls.
Reviewed By: sergey, brecht
Differential Revision: https://developer.blender.org/D195
|
|
Levels of detail can be added and modified in the object panel. The object
panel also contains new tools for generating levels of detail, setting up
levels of detail based on object names (useful for importing), and
clearing an object's level of detail settings. This is meant as a game
engine feature, though the level of details settings can be previewed in
the viewport.
Reviewed By: moguri, nexyon, brecht
Differential Revision: http://developer.blender.org/D109
|
|
|
|
was used for conversion from older 2.5x files. The do_version() code is still there and functioning though.
|
|
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
|
|
from the original
|
|
|