Age | Commit message (Collapse) | Author |
|
|
|
We do have an history of those pieces of evil in our code, would be nice
to get fully rid of it, but at the very least let's not add more of them
in new code. :)
|
|
# Conflicts:
# source/blender/makesrna/intern/rna_render.c
|
|
This patch adds "Pixel Size" to the performance options, which allows to render
in a smaller resolution, which is especially useful for displays with high DPI.
Reviewers: Severin, dingto, sergey, brecht
Reviewed By: brecht
Subscribers: Severin, venomgfx, eyecandy, brecht
Differential Revision: https://developer.blender.org/D1619
|
|
|
|
Rendered settings.
'OpenGL Preview' checkbox was redundant now, just use seq_prev_type
value only.
Might be OK for 2.79, but should be double-checked first...
|
|
|
|
from Selected Channels
The tweakmode flag and the selected-channels flag accidentally
used the same value, due to confusion over where these flags were
supposed to be set. The selected-channels flag has now been moved
to use a different value, so that there shouldn't be any further
conflicts.
To be ported to 2.79.
|
|
This creates a dependency of the hair groups on the validity of the pattern,
so care has to be taken to always update the groups when the pattern changes.
|
|
|
|
|
|
Adds thin/default/thick modes to add -1/0/1 to the auto detected line width,
while leaving the overall UI scale unchanged.
Also tweaks the default line width threshold, so thicker lines start from
slightly high UI scales.
Differential Revision: https://developer.blender.org/D2778
|
|
This enables to fake a second refraction event. This is great to simulate thin planar objects such as glass panels.
|
|
Theses Materials are rendered after the SSR pass.
The only difference with previous method is that they have a depth prepass (less overdraw) and are not sorted.
|
|
For the moment the only way to enable this is to:
- enable Screen Space REFLECTIONS.
- enable Screen Space Refraction in the SSR parameters.
- enable Screen Space Refraction in the material tab.
|
|
|
|
Stupid git handles merges terribly when there are conflicts and branch
is modified buring merge process... :((((
|
|
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
|
|
rendering.
Each group affects a subset of the hair follicles, so that multiple effects can be combined
without overlapping sample sets.
|
|
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
|
|
|
|
|
|
This stores basic hair follicle data, rather than full fiber caches
(which should only be generated for render data).
Note that deformation by strands will just be one possible way to generate
hair fibers, so strands should be kept separate from the hair follicle data somewhat.
|
|
Subdivision works on the parent strands for efficiency. The fibers lengths
are based on the final subdivided length of parents, so no changes to the
shader are required.
This would be nicer with a tesselation shader, but this feature is not
available in Blender 2.8.
|
|
Hair drawing requires fairly large vertex buffers. Vertices also need to be interpolated
and displaced according to the control (parent) hairs and hair-style features like curling
and clumping.
Instead of doing this in advance on the CPU and uploading a large vertex buffer every frame,
this work can be done on the GPU for realtime display, because interpolation and displacement
are highly parallelizable. The vertex buffers then only need to be uploaded once (as long
as strand lengths remain the same). The vertex format can also be very lightweight, requiring
only a curve parameter and index (half the size needed for full positions).
For interpolating a buffer texture is used in the shader, which contains all information
about the control curves (parents) from which to interpolate final vertex positions.
|
|
|
|
|
|
|
|
The names aren't meaningful but means it wont
accidentally use valid names.
Also remove textured-font setting
|
|
|
|
Also adds cursor-lock flag, to be used in next commit.
|
|
This means once an ID is created,
it will keep using the same PyObject instance.
This has some advantages:
- Avoids unnecessary re-creation of instances on UI poll / redraw.
- Accessing free'd ID's gives an exception instead of crashing.
(long standing annoyance!, though this only applies to ID's
and not yet other data that uses the ID's - vertices for eg).
- Allows using instance comparison (a little faster).
Note that the instances won't be kept between undo.
|
|
For use by manipulators since they don't have their own persistent data
in the blend file.
|
|
An id is given to each glossy node in order to determine which specular lobe is using ssr.
|
|
|
|
|
|
|
|
This is a first step towards proper depsgraph "ownership", where
we would allow scene to be in multiple states dependent on active
workspace or scene layer.
This commit introduces a basic API to get proper dependency graph
for a given scene layer. It also renames scene->depsgraph to
depsgraph_legacy, so it's easier to search0-n-replace in the future.
|
|
Support using full material shading in sculpt & paint modes mode.
Access 'Full Shading' from the display panel when in paint modes.
|
|
|
|
|
|
|
|
Hashed Alpha transparency offers a noisy output but has the benefit of being correctly ordered. Noise can be attenuated with Multisampling / AntiAliasing.
|
|
Conflicts:
source/blender/makesdna/DNA_particle_types.h
|
|
Particles were ignoring the lattice modifier visibility, and
"influence" property.
|
|
|
|
< Dependency graph Copy-on-Write >
--------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
This is an initial commit of Copy-on-write support added to dependency graph.
Main priority for now: get playback (Alt-A) and all operators (selection,
transform etc) to work with the new concept of clear separation between
evaluated data coming from dependency graph and original data coming from
.blend file (and stored in bmain).
= How does this work? =
The idea is to support Copy-on-Write on the ID level. This means, we duplicate
the whole ID before we cann it's evaluaiton function. This is currently done
in the following way:
- At the depsgraph construction time we create "shallow" copy of the ID
datablock, just so we know it's pointer in memory and can use for function
bindings.
- At the evaluaiton time, the copy of ID get's "expanded" (needs a better
name internally, so it does not conflict with expanding datablocks during
library linking), which means the content of the datablock is being
copied over and all IDs are getting remapped to the copied ones.
Currently we do the whole copy, in the future we will support some tricks
here to prevent duplicating geometry arrays (verts, edges, loops, faces
and polys) when we don't need that.
- Evaluation functions are operating on copied datablocks and never touching
original datablock.
- There are some cases when we need to know non-ID pointers for function
bindings. This mainly applies to scene collections and armatures. The
idea of dealing with this is to "expand" copy-on-write datablock at
the dependency graph build time. This might introduce some slowdown to the
dependency graph construction time, but allows us to have minimal changes
in the code and avoid any hash look-up from evaluation function (one of
the ideas to avoid using pointers as function bindings is to pass name
of layer or a bone to the evaluation function and look up actual data based
on that name).
Currently there is a special function in depsgraph which does such a
synchronization, in the future we might want to make it more generic.
At some point we need to synchronize copy-on-write version of datablock with
the original version. This happens, i.e., when we change active object or
change selection. We don't want any actual evaluation of update flush happening
for such thins, so now we have a special update tag:
DEG_id_tag_update((id, DEG_TAG_COPY_ON_WRITE)
- For the render engines we now have special call for the dependency graph to
give evaluated datablock for the given original one. This isn't fully ideal
but allows to have Cycles viewport render.
This is definitely a subject for further investigation / improvement.
This call will tag copy-on-write component tagged for update without causing
updates to be flushed to any other objects, causing chain reaction of updates.
This tag is handy when selection in the scene changes.
This basically summarizes ideas underneath this commit. The code should be
reasonably documented.
Here is a demo of dependency graph with all copy-on-write stuff in it:
https://developer.blender.org/F635468
= What to expect to (not) work? =
- Only meshes are properly-ish aware of copy-on-write currently, Non-mesh
geometry will probably crash or will not work at all.
- Armatures will need similar depsgraph built-time expansion of the copied
datablock.
- There are some extra tags / relations added, to keep things demo-able but
which are slowing things down for evaluation.
- Edit mode works for until click selection is used (due to the selection
code using EditDerivedMesh created ad-hoc).
- Lots of tools will lack tagging synchronization of copied datablock for
sync with original ID.
= How to move forward? =
There is some tedious work related on going over all the tools, checking
whether they need to work with original or final evaluated object and make
the required changes.
Additionally, there need synchronization tag done in fair amount of tools
and operators as well. For example, currently it's not possible to change
render engine without re-opening the file or forcing dependency graph for
re-build via python console.
There is also now some thoughts required about copying evaluated properties
between objects or from collection to a new object. Perhaps easiest way
would be to move base flag flush to Object ID node and tag new objects for
update instead of doing manual copy.
here is some WIP patch which moves such evaluaiton / flush:
https://developer.blender.org/F635479
Lots of TODOs in the code, with possible optimization.
= How to test? =
This is a feature under heavy development, so obviously it is disabled by
default. The only reason it goes to 2.8 branch is to avoid possible merge
hell.
In order to enable this feature use WITH_DEPSGRAPH_COPY_ON_WRITE CMake
configuration option.
|
|
|
|
|
|
While this is work-in-progress from custom-manipulators branch
its stable so adding into 2.8 so we don't get too much out of sync.
- ManipulatorGroupType's are moved out of the manipulator-map and are now
global (like operators, panels etc) and added into spaces as needed.
Without this all operators that might ever use a manipulator in the 3D
view would be polling the viewport.
- Add optional get/set callbacks for non-RNA properties
Needed so re-usable manipulators can control values that
don't correspond to a single properly or need conversion.
- Fix divide by zero bug in arrow manipulator (when moving zero pixels).
|