This is very bold right now - you simply can replace (or add) an action
to an override data-block. Actions themselves are not 'customizable'
through override at all currently (we may at least add
'add/remove/replace fcurves' feature in future), and nothing else in
animdata is overridable currently.
You can now override loc/rot/scale of objects and posebones.
Also added a basic operator to make an override of active linked object,
but this is very limited/wip/testing feature (you have to manually override
object and its armature, and relink to proper local overrides
yourself...). Final 'make proxy killer' will be much more automated of
course.
First real 'usable' commit, will be needed by the 'virtual data-block'
asset feature (i.e. to be able to link a mere image file as if it was a
linked datablock, and generate automatically an override of it to make
it editable).
We could do that in several different way, e.g. adding some tag during
DEG evaluation, etc. But this is not a critical process (it's main
purpose is user feedback), so current solution seems to work well enough
- and it's dead simple! ;)
This is essentially a huge refactor/extension of our existing RNA
compare & copy code, since static override needs more advanced handling here.
Note that not all new features are implemented yet, advanced things like
collections insertion/deletion are still TODO (medium priority).
This completes the ground work for overrides, remaining commits will be
about UI and some basic/testing activation of overrides for a limited
set of data-blocks & properties.
For details see https://developer.blender.org/D2417
See https://developer.blender.org/D2417 for details.
Note that since static overrides rely heavily on RNA, this commit is
essentially invisible from user PoV, more in next commits.
This function swaps the memory content of two data-blocks (of same type
obviously), while preserving most of the ID 'header' itself.
It is intended to be used to quickly and easily replace the data of an
existing ID by another one, presumably a temporary 'working' one,
without having to suffer from things like name changes,
registering/removing from Main database, etc.
This is very bold right now - you simply can replace (or add) an action
to an override data-block. Actions themselves are not 'customizable'
through override at all currently (we may at least add
'add/remove/replace fcurves' feature in future), and nothing else in
animdata is overridable currently.
You can now override loc/rot/scale of objects and posebones.
Also added a basic operator to make an override of active linked object,
but this is very limited/wip/testing feature (you have to manually override
object and its armature, and relink to proper local overrides
yourself...). Final 'make proxy killer' will be much more automated of
course.
First real 'usable' commit, will be needed by the 'virtual data-block'
asset feature (i.e. to be able to link a mere image file as if it was a
linked datablock, and generate automatically an override of it to make
it editable).
We could do that in several different way, e.g. adding some tag during
DEG evaluation, etc. But this is not a critical process (it's main
purpose is user feedback), so current solution seems to work well enough
- and it's dead simple! ;)
Do a direct update of object transform instead, without involving
manual trickery of recalc flag.
Shouldn't be functional changes as far as artists are concerned,
but will allow us to get rid of recalc flags in 2.8.
Thanks Bastien for review!
This is essentially a huge refactor/extension of our existing RNA
compare & copy code, since static override needs more advanced handling here.
Note that not all new features are implemented yet, advanced things like
collections insertion/deletion are still TODO (medium priority).
This completes the ground work for overrides, remaining commits will be
about UI and some basic/testing activation of overrides for a limited
set of data-blocks & properties.
For details see https://developer.blender.org/D2417
See https://developer.blender.org/D2417 for details.
Note that since static overrides rely heavily on RNA, this commit is
essentially invisible from user PoV, more in next commits.
This function swaps the memory content of two data-blocks (of same type
obviously), while preserving most of the ID 'header' itself.
It is intended to be used to quickly and easily replace the data of an
existing ID by another one, presumably a temporary 'working' one,
without having to suffer from things like name changes,
registering/removing from Main database, etc.
Initially there was hope at least part of this work could be used for
dynamic overrides as well... but looks like not, so better be specific
and avoid any confusion.
PS: this commit break any file saved with static overrides, should not
be an issue though.
There is no reason to have such a long function, it is really easy to break it
down into a smaller ones, and call them from where needed. Makes them smaller
and easier to follow. Also avoids use of confusing goto's.
For functions which will allocate requested data if it does not exist yet
"_ensure" is to be used instead of "_get". "_get" functions should return
NULL in cases when requested data does not exist yet.
There were following issues:
- This was used in a similar way of DEG's ID update callback. No reason to have
yet-another-way of informing editors/engines about changes. Better to keep
regular update mechanism usable and fast for those needs.
- It wasn't granular at all, and granularity in flags is something what we
need to support anyway, even for existing ID update.
- There is no reason to have it per-object. Depsgraph operates on IDs.
- It wasn't clear when and who clears the flag, and was possible to run into
conflicts.
This replaces dedicated flag which wasn't clean who sets it and who clears it,
and which was also trying to re-implement existing functionality in a way.
Flushing is not currently very efficient but there are ways to speed this up
a lot, but needs more investigation.
Adds support for defining a number of tags as part of the rna-struct
definition, which its properties can set similar to property-flags.
BPY supports setting these tags when defining custom properties too.
* To define tags for a struct (which its properties can use then), define the tags in an `EnumPropertyItem` array, and assign them to the struct using `RNA_def_struct_property_tags(...)`.
* To set tags for an RNA-property in C, use the new `RNA_def_property_tags(...)`.
* To set tags for an RNA-property in Python, use the newly added tags parameter. E.g. `bpy.props.FloatProperty(name="Some Float", tags={'SOME_TAG', 'ANOTHER_TAG'})`.
ntree_shader_relink_displacement is creating a transient node that does not have a correct original to point to.
In this case we revert to constant uniform.
This way it is more clear what is needed to be passed and what is available
in the callback itself.
Thanks Dalai for review and tips about engine type!
This commit effectively reverts fix T45702 done in 067fe2719a.
Reasoning:
- Blender Internal is being replaced with Eevee, and will be removed entirely
rather soon.
- All render engines are planned to have own depsgraph, so such threading
conflicts should no longer be an issue.
- We don't want to spend time on porting workarounds for EOL things to a new
design. Less code -- faster the work :)
- If such notifications will end up needed for some other cases, we would
need to re-implement this a more proper depsgraph tagging/flushing and make
it to work with all copy-on-write datablocks and everything.
There might be much more logic involved there, also we might not know proper
evaluated CoW pointer there yet. So we leave this to dependency graph to
decide what exactly to do here.
No need to print status for basic & reliable operations,
build systems can output operations they run if needed,
or debug output changed in the source if developers are debugging.
Nice for ninja, so any printed text hints at a problem to fix.
User count was wrong for newly created files. We increase/decrease user count
when we link/delete objects from a SceneCollection.
So we don't want to leave user count of 1 after calling BKE_libblock_alloc in
BKE_object_add_only_object().
This is fully unreadable to have lots of boolean arguments scattered across the
whole argument list. What does `false, true, true` mean in terms of behavior?
Replace those with bitfield which has advantage of having more human readable
meaning.
Pretty straightforward this time, we already have a single struct
pointer containing all needed data (or nearly).
And we gain about 10-15% speed on tracking! :)
Two more 'not really useful' cases (OMP only shows some noticeable
speedup with above 1M elements, and since this is quick operation anyway
compared to even ather basic operators, gain is in the 1% area of total
processing time in best case).
So not worth parallelizing here, we'll gain much more on tackling heavy
operations. ;)
And BMesh is free from OMP now!
Performances tests on this one are quite surprising actually...
Parallelized loop itself is at least 10 times quicker with new BLI_task
code than it was with OMP. And subdividing e.g. a heavy mesh with 3
levels of multires (whole process) takes 8 seconds with new code, while
10 seconds with OMP one. And cherry on top, BLI_task code only uses
about 50% of CPU load, while OMP one was at nearly 100%!
In fact, I suspect OMP code was not properly declaring outside vars,
generating a lot of uneeded locks.
Also, raised the minimum level of subdiv to enable parallelization,
tests here showed that we only start to get significant gain with subdiv
levels of 4, below single threaded one is quicker.
Those three ones were actually giving no significant benefits, in fact
even slowing things down in one case compared to no parallelization at
all (in `BM_mesh_elem_table_ensure()`).
Point being, once more, parallelizing *very* small tasks (like index or
flag setting, etc.) is nearly never worth it.
Also note that we could not easlily use per-item parallel looping in
those three cases, since they are heavily relying on valid
loop-generated index (or are doing non-threadable things like allocation
from a mempool)...
Previously outcome depended on order of edges,
now the longest boundary edges are rotated first,
then the faces connected edges.
This gives more predictable results, allowing regions containing
a vertex fan to be rotated onto the next vertex.
That was a nasty one, Debug build would never have any issue (even tried
with 64 threads!), but Release build would deadlock nearly immediately,
even with only 2 threads!
What happened here (I think) is that gcc optimizer would generate a
specific path endlessly looping when initial value of virtual_lock was
FLT_MAX, by-passing re-assignment from v_no[0] and the atomic cas
completely. Which would have been correct, should v_no[0] not have been
shared (and modified) by multiple threads. ;)
Idea of that (broken) for loop was to avoid completely calling the
atomic cas as long as v_no[0] was locked by some other thread, but...
Guess the avoided/missing memory barrier was the root of the issue here.
Lesson of the evening: Remember kids, do not trust your compiler to
understand all possible threading-related side effects, and be explicit
rather than elegant when using atomic ops!
Side-effect lesson: do check both release and debug builds when messing
with said atomic ops...
Using atomic cas correctly is really hairy... ;)
In this case, the returned value from cas needs to validate *two*
conditions, it must not be FLT_MAX (which is our 'locked' value and
would mean another thread has already locked it), but it also must be
equal to previously stored value...
This means we need two steps per loop here, hence using a 'for' loop
instead of a 'while' one now.
Note that collisions are (as expected) very rare, less than 1 for 10k
typically, so did not catch the issue initially (also because I was
mostly working with release build to check on performances...).
Previously the lighting of SSS material was not present in reflection probe or irradiance grid.
This does not compute the SSS correctly but at least output the corresponding irradiance power to the correct output.
While this probably isn't the final solution we'll go with, it's nicer
as current one, which was basically broken. So consider this as
temporary solution.
It also allows testing how changing workspace changes mode & active
object, but only by having the workspaces use different view-layers.
Decided to remove WorkSpace.mode for now. If we need to bring it back,
we'll have to version patch it anyway.
This option prevent from automatically blurring the albedo color applied to the SSS.
While this is great for preserving details it can bleed more light onto the nearby objects since the blurring will be done on pure "white" irradiance.
This issue is to be tackled in a separate commit.
All depsgraphs are sharing same object state for now, which means doing set
scene evaluation after main scene evaluation will override all modifications
done by the main scene.
When setting background object, it might pull new objects in and those objects
will not have proper flags unless on_visible_update() was called afterwards.
This reverts commit 90ff88646d.
Can not do this yet, if object is not part of graph yet it will not have entry
taq. Need some more generic solution here.
It is possible to have situation when we need to both update relations and do
some updates on random IDs. This was only done before for objects using their
recalc field. This means, every update tag which did not fit into there would
have been lost after updating relations.
Now we do some smarter re-scheduling of operations after relations are updated.
object.is_from_set
object.is_from_duplicator
We need them for the unittests, and users can benefit from it as well.
Note, this only makes sense when reading objects from depsgraph:
`bpy.context.depsgraph.objects`
This is an incomplete test since we cannot check for the
depsgraph selection value with the current API, nor can we
see if the relationship lines are being drawn.
Previously it was done during depsgraph iteration, which is not good at all,
since after evaluation nobody should really modify how object was evaluated.
The idea then is to avoid doing depsgraph tag for each of the object which
selection is changed (which could be tricky to do anyway due to lots of areas
of selection code where this could happen), and simply tag scene's with
selection update tag.
This will involve synchronization of flags from base to objects, which is
rather cheap anyway.
This is crucial bit since batch cache is stored in the evaluated object,
meaning we can't tag it's hatch cache dirty from the notifier system.
Not easily at least. Better to leave this job to depsgraph, it knows
all the copies of data.
This cleanup removes the need of gigantic code duplication for each closure.
This also make some preformance improvement since it removes some branches and duplicated loops.
It also fix some mismatch (between cycles and eevee) with the principled shader.
This is a hack to make the user control the SSS radius even though the profile is baked with the default radius values.
This is completly against UI principles since you cannot edit the profile radiuses while there is something plugged into the radius socket.
Better solution will be to either have a dedicated node value for RGB radiuses and a SSS scale socket only for eevee.
`BM_mesh_normals_update` was converted from OMP to new parallel iterator code,
basic test with heavily subdivided cube (24.5k faces) gives:
- old OMP code: average 10ms per run.
- new BLI_task code: average 6ms per run.
So new code seems to be easily 40% quicker, in addition to getting rid of OMP. ;)
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2930
It merely uses the new thread-safe iterators system of mempool, quite
straight forward.
Note that to avoid possible confusion with two void pointers as
parameters of the callback, a dummy opaque struct pointer is used
instead for the second parameter (pointer generated by iteration over
mempool), callback functions must explicitely convert it to expected
real type.
Also added a basic gtest for this new feature.
This will allow threaded tasks to 'consume' all mempool items in
parallel tasks, each one working on a whole chunk at once (to reduce
concurrency managing overhead).
Adapted from http://www.pixelbeat.org/programming/gcc/static_assert.html.
Note that this macro just discards error message, so error when building
is much less nice than with gcc's _Static_assert... But error log will
point to right place in code, so should still be OK.
Pixel size was not initial early enough. For first time this was not a problem
because the bevel amount starts at 0 then, and after the mouse moves the pixel
size is initialized. For the second time the bevel amount starts at a non-zero
value, and it failed then.
These and other non-RGB passes should always be stored as full float, the
precision loss is too unpredictable.
Related to T53381, but that one is about file output nodes where we don't
know the type of data being saved currently.
Reason is motsly that dealing with type conversion in calling code is
not great, makes it less readable, and can generate hidden bugs in case
original type changes and atomic primitive calls are not updated
accordingly...
Sets the 'advanced' tag for some properties of following mesh edit operators:
* Loop Cut
* Subdivide
* Mark Seam
* Smooth Vertex
* Laplacian Smooth Vertex
* Merge
This will later be used to show advanced operator properties separate from
basic (as in non-advanced) ones in the UI.
Tagging a single operator property in C should be done via
`WM_operatortype_prop_tag()`. It does additional checks for type safety
that `RNA_def_property_tags()` doesn't do.
To avoid having to tag each advanced property individually, multiple
ones can be tagged by wrapping them into
`WM_operatortype_props_advanced_bein()` and
`WM_operatortype_props_advanced_end()` calls. It's also possible to only
call `_begin()`, all properties added after this will get tagged then.
In most cases this last approach should be sufficient.
Example of Python usage:
`my_float = bpy.props.FloatProperty(name="Some Float", tags={'ADVANCED'})`
Adds support for defining a number of tags as part of the rna-struct
definition, which its properties can set similar to property-flags.
BPY supports setting these tags when defining custom properties too.
* To define tags for a struct (which its properties can use then), define the tags in an `EnumPropertyItem` array, and assign them to the struct using `RNA_def_struct_property_tags(...)`.
* To set tags for an RNA-property in C, use the new `RNA_def_property_tags(...)`.
* To set tags for an RNA-property in Python, use the newly added tags parameter. E.g. `bpy.props.FloatProperty(name="Some Float", tags={'SOME_TAG', 'ANOTHER_TAG'})`.
Actual usage of this will be added in a follow-up commit.
The RenderResult struct still has a listbase of RenderLayer, but that's ok
since this is strictly for rendering.
* Subversion bump (to 2.80.2)
* DNA low level doversion (renames) - only for .blend created since 2.80 started
Note: We can't use DNA_struct_elem_find or get file version in init_structDNA,
so we are manually iterating over the array of the SDNA elements instead.
Note 2: This doversion change with renames can be reverted in a few months. But
so far it's required for 2.8 files created between October 2016 and now.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D2927
This reverts commit d749320e3b.
It's possible the container struct is larger,
we could do sizeof checks that falls back to memmove
but rather avoid complicating things.
Crash introduced on: 3a95bdfc65
We can't decrease user count of freestyle linestyle IDs before linking.
Moving doversion for after linking.
And for the records we are simply removing the freestyle data altogether.
This is only for files created with 2.8, so it should be fine.
This patch moves all the functionality previously in SceneRenderLayer to SceneLayer.
If we want to rename some of these structs now would be a good time to do it, before they are in SceneLayer.
Everything should be working, though I will test things further tomorrow. Once this is committed depsgraph can get
rid of the workaround added in rna_Main_meshes_new_from_object and finish whatever this patch was preventing from being finished.
This patch also adds a few placeholders for the overrides (samples, ...). These are obviously not working, so some unittests that rely on 'lay', and 'zmask' will fail.
This patch does not addressed the change of moving samples to ViewRender (I have this as a separate patch and needs some separate discussion).
Following next is the individual note of the individual parts that were committed.
Note 1: It is up to Cycles to still get rid of exclude_layer internally.
Note 2: Cycles still need to handle its own doversion for the use_layer_samples cases and
(1) Remove the override as it is
(2) Add a new override (scene.cycles.samples) if scene.cycles.use_layer_samples != IGNORE
Respecting the expected behaviour when scene.cycles.use_layer_samples == BOUNDED.
Note 3: Cycles still need to implement the per-object holdout
(similar to how we do shadow catcher).
Note 4: There are parts of the old (Blender Internal) rendering pipeline that is still
using lay, e.g., in shi->lay.
Honestly it will be easier to purge the entire Blender Internal code away instead of taking things from it bit by bit.
Reviewers: sergey, campbellbarton, brecht
Differential Revision: https://developer.blender.org/D2919
There are parts of the old (Blender Internal) rendering pipeline that is still
using lay, e.g., in shi->lay.
Honestly it will be easier to purge the entire Blender Internal code away instead
of taking things from it bit by bit.
We cannot assume a render layer does not have a setting that was needed for
compositing. Even if:
```
(scene->lay & render_layer->lay) != (scene_lay) &&
(render_layer->lay | render_layer->lay_exclude) == 0))
```
Which would mean use the scene layers just as they are.
Note: Cycles still need to handle its own doversion for theses cases and
(1) Remove the override as it is
(2) Add a new override (scene.cycles.samples) if scene.cycles.use_layer_samples != IGNORE
Respecting the expected behaviour when scene.cycles.use_layer_samples == BOUNDED.
This adds the possibility to simulate things like red ears with strong backlight or material with high scattering distances.
To enable it you need to turn on the "Subsurface Translucency" option in the "Options" tab of the Material Panel (and of course to have "regular" SSS enabled in both render settings and material options).
Since the effect is adding another overhead I prefer to make it optional. But this is open to discussion.
Be aware that the effect only works for direct lights (so no indirect/world lighting) that have shadowmaps, and is affected by the "softness" of the shadowmap and resolution.
Technical notes:
This is inspired by http://www.iryoku.com/translucency/ but goes a bit beyond that.
We do not use a sum of gaussian to apply in regards to the object thickness but we precompute a 1D kernel texture.
This texture stores the light transmited to a point at the back of an infinite slab of material of variying thickness.
We make the assumption that the slab is perpendicular to the light so that no fresnel or diffusion term is taken into account.
The light is considered constant.
If the setup is similar to the one assume during the profile baking, the realtime render matches cycles reference.
Due to these assumptions the computed transmitted light is in most cases too bright for curvy objects.
Finally we jitter the shadow map sample per pixel so we can simulate dispersion inside the medium.
Radius of the dispersion is in world space and derived by from the "soft" shadowmap parameter.
Idea for this come from this presentation http://www.iryoku.com/stare-into-the-future (slide 164).
Just removing it, such cases are not bottlenecks and not worth the
complication of doing real threading with own BLI_task.
Other (remaining) usages may be relevant, need case-by-case check.
This was expected behavior for over-exposured lamps when the mode was originally
created for Tears of Steel. Turns out, there could be really bad green screen in
real production which will only have green (or rather screen) channel over
exposured.
Tweaked condition now so we use least bright channel to see if the area has
proper exposure or not.
Seems to work fine in tests, but further tweaks are possible.
This is tricky since we may want granular polling depending on the setting.
Or an option to pick whether we want the context or the scene to drive the
panels to prevent too many panels when mixing Eevee and Cycles for example.
This way we don't modify scene to get current frame from. Will also let us to
hopefully get rid of Scene stored in ModifierData.
Only did for Wave modifier for now, maybe someone is around to check on another
modifiers? :)
This was dangerous to do such calculations, and now it is solvable by making
dependency graph more granular in this case. Removing the workaround also saves
us a hassle of passing lots of extra arguments down the evaluation routines.
In theory, we can also remove EvaluationCOntext from constraints evaluation as
well now. But probably better to wait with such removal for now.
This commit effectively reverts 1130c53. Will do a proper fix in dependency
graph itself.
CUDA 9.0.176 apparently caused some slow down on high-end Pascal cards that can be mitigated by increasing the number of registers. See https://developer.blender.org/F1142667 for a detailed comparison.
Was giving difference when using sharpness of 1.0 and 0.999 even though the
result was expected to be really close to each other.
This SSS profile will probably be removed in the future in favor of more
physically bases Burley, but for the time being don't see anything wrong
fixing an existing code.
Regression from rB823bcf1689a3 (VPaint 2017 GSoC, this is not in 2.79 release).
Also cleanup, using fake-array-ification to access struct members is
generally not a great idea, but when we already have a totally confusing
broken struct layout, this is pure evil, as demonstrated here!
Found while investigating T53341.
- initialize the cube-size from the bounding box when it's not set.
- no longer wrap faces to keep in 0-1 bounds,
other projection methods don't do this and calculating the scale
prevents the UV's from being too far outside the view.
Was using cursor position from within menu,
clicking on the same position for every selected item (toggling).
Now operate on each selected outliner element, without toggling.
This commit introduces the following changes:
* Modified the poll callback on the "Update Paths" operator for bones
so that it only checks if there are bones that have motion paths
(instead of checking whether the active bone has paths).
This makes it easier to update paths without having to first select one
that has them - useful when the paths are all on hidden/hard-to-select bones.
* Add a readonly property, "has_motion_paths" to the animviz.motion_path
RNA struct, providing easier access to the internal flag used above.
This makes it possible for the UI to display the "Update" button without
having to check various bones for motion paths.
Notes:
* The flag being used in these changes already existed, and was only really
intended for internal use. However, since it was already used in many places
for determining if auto-update of all bone paths was needed (e.g. after certain
editing ops), it should be safe to use here too.
* The update_paths operator currently bakes all paths when activated, so there's
currently no loss of functionality with changing to not checking if the active
bone has any paths (e.g. we couldn't only update the active bone only either).
That is still listed as a todo in the code.
There were 2 issues here (first was the one reported):
1) Curve shape changes if multiple consecutive pairs of keyframes
are selected. The problem is that after the first pair is handled,
subsequent pairs get sampled on the basis of the modified curve.
2) With multiple separate "islands" selected, unselected points in between
would get ignored, causing the entire curve to get sampled.
Previously, Mikktspace just bucketed the vertices based on one spatial coordinate and then ran full pairwise comparisons inside each bucket.
However, since models are three-dimensional, the bucketing has a massive false-positive rate, and since pairwise comparison is O(n^2), the merging process is very slow.
But, since we only care about exactly identical vertices, there is a much more efficient approach - we can just hash all values belonging to each vertex and form buckets based on the hash.
Since the hash has 32 bits and considers all values, false-positives are very unlikely - and since both hashing and the radixsort that's used for bucketing are O(n), both asymptotical and
real-world performance (as well as code complexity) are significantly improved.
No color pass because it's hard to define what to use as color in a volume.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D2903
UV project mixed up global/local space,
3D cursor offset didn't take object scale into account.
Minor improvements:
- Match Cube Project 'center' behavior w/ sphere & cylinder.
- Add active-element center.
- Wrap UV's in Cube Project based on center instead of first vertex.
This seems to be a correct implementation of the same diffusion profile as Cycles uses by default.
There are a few bias though:
- We consider _A_ the albedo to be 1 when evaluating _s_.
- We use a factor of 0.6 when computing _d_ to match more or less cycles results.
Note that doing per pixel jittering does bias the result even further (loss of energy).
local and reference are awfully confusing names here, since destination
is a copy of reference that will become local override once applied, and
source is .blend-file-written version of local override...
random_id() crashes when there is no current dupli object.
We could also throw a Python error when doing it via RNA, but as far as
Cycles is concerned we need to check if instanced.
The loc one (shift-alt-G) was same as 'remove selected from active group'
action... Clear delta transform is not a common operation, so we can
live without a default shortcut for it.
Note that using same key (G) in same space for two completely different
kind of operations is probably a rather bad thing, nice topic for future
keymap work. ;)
Probably nice to have in 2.79a.
Main reason here is to make comparison/override_diff/override_store/override_apply
customizable per RNA property if needed.
This should allow us especially to get advanced behavior on case-by-case
basis, when dealing with Pointer and Collection properties mostly.
Note that IDProps remain fuzzy area for now, a big part of the code
tries to take them into account, but it's most likely still missing some
bits, and definitively not tested at all yet!
This was caused by 93936b8643
From GL spec :
GL_INVALID_OPERATION is generated if mask contains GL_DEPTH_BUFFER_BIT or GL_STENCIL_BUFFER_BIT and the source and destination depth and stencil formats do not match.
So blitting framebuffer with depth or stencil require the SAME FORMAT.
The issue was caused by SpinLock implementation in old pthreads we ar eusing on
Windows. Using newer one (2.10-rc) demonstrates same exact behavior. But likely
using own atomics and memory barrier based implementation solves the issue.
A bit annoying that we need to change such a core part of Blender just to make
specific CPU happy, but it's better to have artists happy on all computers.
There is no expected downsides of this change, but it is so called "works for
me" category. Let's see how it all goes.
Samples : pretty self explanatory.
Jitter Threshold : Reduce cache misses and improve performance (greatly) by lowering this value. This settings let user decide how many samples should be jittered (rotated) to reduce banding artifacts.
How to use:
- Enable subsurface scattering in the render options.
- Add Subsurface BSDF to your shader.
- Check "Screen Space Subsurface Scattering" in the material panel options.
This initial implementation has a few limitations:
- only supports gaussian SSS.
- Does not support principled shader.
- The radius parameters is baked down to a number of samples and then put into an UBO. This means the radius input socket cannot be used. You need to tweak the default vector directly.
- The "texture blur" is considered as always set to 1
Add the 3D view ruler as a tool,
the modal operator remains for now
however it may be removed if we use the tool-system for 2.8.
Note that this does copy code from the operator,
its different enough not to attempt to de-duplicate.
Not sure why that piece of code stopped working, but now this operation
is pretty much never evaluated... Will have to either dig deeper in DEG
or ask Sergey about it, but not a crucial issue for now.
Animation is by definition another kind of (dynamic) override of properties,
which supersedes static override.
Note that this could be debated in some corner cases ('differential'
animation, like dloc/drot/dscale), but think we can ignore that for now,
and expect user to handle those manually when needed.
This is not the commit you are looking for ...
This is not to be used lightly. But sometimes we change the name of the collections,
the initial value they have, ... and this helps to quickly update the tests.
Faces that have the last two indices equal are considered triangles, and not those that the last index is 0
Improvement of 7% in performance of the `polygonize` function
We now created nested collections for the original Collection 1, 2 ...
collections for the "hide" and "hide_render" objects.
Also, remove logic for rename single-collection files, it's now kept as
it was originally (Collection 1, Collection 5, ...).
Thanks Sergey Sharybin and Pablo Vazquez for patch review and suggestions.
There was some changes about namespaces, which causes ambiguities.
Replaces using namespace with an explicit symbols we need. Is good idea to NOT
pull in the whole namespace anyway!
Previously we picked one of the RGB channels with equal probability, but this
works poorly in a dense volume after many bounces. Now we take into account
the throughput and single scattering albedo.
This makes it a little more practical to do brute force SSS with volumes, but
is still very inefficient because we do direct light sampling at every volume
bounce even when inside an opaque mesh. In theory there could be a light inside
the mesh so we can't automatically disable direct lighting.
In fact this was an existing issue when exceeding the number of available
closure, but it's more common now that we set the number to 0 for shadows
and emission
Checked in really old revisions, seems like this was never used. So
doesn't matter for compatibility either (tested opening files saved with
this in 2.49).
Before this patch, the XBlur/YBlur compositor nodes would crash for me when run in a MSVC 2015 debug build (test scene: BMW27_cpu). I added the compiler instructions to explicitly align the local variables that the SSE instructions are accessing.
The only remaining part is the particle stuff, which needs a pointer to exact
particle system which does not exist yet. Leaving it for later a bit for until
it's more clear what do we do with particles.
Unless i'm mistaken, we've got all proper CoW pointers bound now.
This is a final step of having proper ownership. Now selecting different
layers in the "top bar" will actually do what this is expected to do.
Surely, there are still things to be done under the hood, that will happen
in a less intrusive way.
This was wrong since it's concenption in 28ee0f9218.
The if statement was returning true when pinid was NULL, and false otherwise.
However when scene is pinned we also want to run this code.
Code snippet by Brecht Van Lommel.
Goal is to reduce OpenCL kernel recompilations.
Currently viewport renders are still set to use 64 closures as this seems to
be faster and we don't want to cause a performance regression there. Needs
to be investigated.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2775
While getting rid of Scene->base we got the following fixes:
* Fix "Convert To" operator
* Fix "NLA allowing to selected objects that are not selectable
* Fix scene.objects (readonly, no option to link/unlink)
Note: Collada needs to use the context SceneLayer for adding objects
however I added a placeholder, so Collada maintainers can fix this
properly.
The idea is to allow iterating over ID nodes in exact order of their
construction, and in order which will not change dependent on memory
pointers or anything.
Depsgraph itself is still created fer the whole scene rather than for a
single layer, this is to be addressed next.
The storage for those dependency graphs is in scene, but now it is a hash
indexed by layer. In the future we can extend hash key to include extra
information (workspace? window?).
This fixes the issue for the Draw Manager, but for Cycles this is still not
working. The iterator bpy.context.depsgraph.duplis seems to be correct though.
* Fix saving a multiview render from the image editor giving invalid files.
* Fix failure to load multiview images with a single view per part.
* Fix loss of multiview metadata when saving/loading a single view.
* Fix Z-Buffer writing option for single layer EXR not being respected.
Multiview EXRs are now always handled as multilayer internally, significantly
reducing the amount of code.
Reviewed By: dfelinto
Differential Revision: https://developer.blender.org/D2887
The algorithm averages normals from nearby surfaces. It uses the same
sampling strategy as BSSRDFs, casting rays along the normal and two
orthogonal axes, and combining the samples with MIS.
The main concern here is that we are introducing raytracing inside
shader evaluation, which could be quite bad for GPU performance and
stack memory usage. In practice it doesn't seem so bad though.
Note that using this feature can easily slow down renders 20%, and
that if you care about performance then it's better to use a bevel
modifier. Mainly this is useful for baking, and for cases where the
mesh topology makes it difficult for the bevel modifier to work well.
Differential Revision: https://developer.blender.org/D2803
This causes some difference in the classroom scene, where ray visibility
tricks are used and break the MIS balance. Otherwise there doesn't seem
to be much effect, but better to use the right formulas. Problem originally
identified by Lukas.
We now initialize iter.valid as true as part of the main iterator (and manually
when using via Python). And we don't even bother setting iter->current to NULL
if it's invalid. Let's stick to using iter->valid only.
To help diagnose issues like T53259, it is useful to know the module causing the issue (is it us, or some opengl icd, or python module?) and while we cannot do stackdumps on release builds on windows, it is possible to display the faulting module. This commit changes the exception handler to output the following information:
Error : EXCEPTION_ACCESS_VIOLATION (Type of exception , this we had before)
Address : 0x0000000140193726 (Address of the exception, new)
Module : k:\BlenderGit\build_windows_Full_noge_x64_vc15_Release\bin\Release\blender.exe (module of the exception, new)
Means that from now on, we work based on blender2.8, no more master!
Conflicts:
source/blender/blenloader/intern/readfile.c
source/blender/blenloader/intern/writefile.c
source/blender/depsgraph/intern/builder/deg_builder_nodes.cc
source/blender/editors/interface/interface_ops.c
source/blender/makesdna/DNA_ID.h
source/blender/makesrna/intern/rna_ID.c
This was leading to crashes on Cycles as well as misleading
len(bpy.context.depsgraph.objects)
I can even move the iter->skip as part of DEGObjectsIteratorData instead of
BLI_Iterator, but if I do it will be a separate commit.
Thanks Sergey Sharibyn for the well done sample file and patch suggestion.
This was originally done as a fix for T37713, but now this workaround becomes
tricky since we don't know which layers to update scene for. Even more, render
engine is supposed to have own dependency graphs amd those ones do not exist
yet at the file open time.
Keep an eye on T37713, since that's where the original workaround is coming
from.
Need to ensure Render has proper dependency graph.
While this is a subject of re-design (render pipeline should manage all
dependency graphs it needs, and not demand external users to provide
depsgraph), this is good to have something working, so we can run regression
tests and such.
Although this works by itself, it should actually happen after:
"Reshuffle collections base flags evaluation, make it so object is gathering
its base flags from collections."
Meanwhile we have one single hacky function (deg_flush_base_flags_and_settings)
to be removed once the task above is tackled.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D2899
This gets rid of the bottleneck of allocation / free of thousands of elements every frame.
Cache time (Eevee) (test scene is default file with cube duplicated 3241 times)
pre-patch: 23ms
post-patch: 14ms
This makes code closer to id_override/assent-engine ones, which
introduce a new type of linked data, and hence reserve
ID_IS_LINKED_DATABLOCK to real linked datablocks.
Inner DAG code would not check against NULL pointer, and in case of an
active linked scene, scene pointer will be NULL here, so we have to
check it ourself. ;)
New access is C.scene.render_layers.active.depsgraph. This will give depsgraph
for a given layer. In the future there will need to be some extra context to be
passed.
With a Titan Xp, reduces path trace local memory from 1092MB to 840MB.
Benchmark performance was within 1% with both RX 480 and Titan Xp.
Original patch was implemented by Sergey.
Differential Revision: https://developer.blender.org/D2249
This is a prequisite for getting host memory allocation to work. There appears
to be no support for 3D textures using host memory. The original version of
this code was written by Stefan Werner for D2056.
This is a lots of changes, but they are boiling down to a simple API
changes where we are no longer relying on implicit usage of scene's
depsgraph and pass depsgraph explicitly.
There should be no user measurable difference, render_layer* tests
are also passing.
Some drivers may report very large allocation sizes, which could cause
unnecessary memory usage. This is now limited to 2gb which should
still be enough to get the needed performance benefits without waste.
The legacy algorithm only considers two adjacent points when computing
the bezier handles, which cannot produce satisfactory results. Animators
are often forced to manually adjust all curves.
The new approach instead solves a system of equations to trace a cubic spline
with continuous second derivative through the whole segment of auto points,
delimited at ends by keyframes with handles set by other requirements.
This algorithm also adjusts Vector handles that face ordinary bezier keyframes
to achieve zero acceleration at the Vector keyframe, instead of simply pointing
it at the adjacent point.
Original idea and implementation by Benoit Bolsee <benoit.bolsee@online.be>;
code mostly rewritten to improve code clarity and extensibility.
Reviewers: aligorith
Differential Revision: https://developer.blender.org/D2884
This fix enables the usage of bbones easing parameters for edit and pose mode seperately. This allows animators to take advantage of the functionality and may eliminate confusion as the parameters now behave similar to other bbone parameters.
Note that splitting the parameters between the modes effectively creates a new parameter set. Blend files of previous versions do not contain this information and will have the values set to 0 on load. As it broke backwards compatibility for pose mode values anyway, I also took the liberty to rename the easing parameters in some places for consistency (which breaks edit mode values).
Reviewers: aligorith
Subscribers: aligorith
Tags: #animation
Differential Revision: https://developer.blender.org/D2796
This also:
- make sure to only compile the shader needed by the active effects.
- same thing for the shading groups.
- disable TAA if motion blur is active (avoid infinite refresh).
The idea is to make it possible to report extra meta data from
render engine to the file writing. This way we can provide
additional information such as number of samples rendered by
resumable Cycles rendering so we can easily combine files back.
Currently only report number of samples from Cycles when rendering
a single render-layer scene. This is something what was required
here at the studio. We can easily extend that further.
Ideally we would also need to support non-string metadata, but
that's for later.
Reviewers: mont29, campbellbarton
Reviewed By: mont29, campbellbarton
Subscribers: sybren, candreacchio
Differential Revision: https://developer.blender.org/D2502
If an object is in any visible collection, the object will be visible.
This behaviour has changed in 9ad2c0b615.
If it will change again, it will be for:
https://developer.blender.org/D2878
Bug introduced on 1c4c288727 (well technically in b48694639a).
We should not remove the renderlayer from the context, but instead the one that
is active from scene.
That said, the UI should make a distinction between the scene active render layer
and the one that is active in the UI (and that should be the one used when
removing it).
But for now this is at least more consistent for the users.
cmake's link_directories will supply forward slashes for the search paths, the msvc linker has some issues with that, while it will search for the needed libs just fine, the incremental linker gets fed forward slashes for some libs, while the previous binary has backward slashes in it's metadata, the linker assumes obj files got added and performs a full link instead of an incremental link. This change brings down the link time with newer msvc versions for a trivial edit down from a few minutes to a few seconds.
- Only basis balls are exported, as they represent the resulting mesh.
As a result the mesh is written to Alembic using the name of the basis
ball.
- MetaBalls are converted to a mesh on every frame, then an
AbcMeshWriter is used to write that mesh to Alembic.
When the mesh changed topology but kept the vertex count the same, it would
result in a corrupt mesh. By checking the face & loop counts too, this has
become less likely.
I've checked IPolyMeshSchema::isConstant(), but it returns true even when
we see that the mesh changed topology.
Recent addition of 'reinsert' didn't match logic for ghash API.
Rename to BLI_heap_node_value_update,
also add BLI_heap_insert_or_update since it's a common operation.
The single byte version of hash_data was casting from unsigned char
instead of signed.
This didn't cause any errors since the result of each aren't compared.
Even so, better keep them matching.
It should behave like cycles.
Even if not efficient at all, we still do the same create - draw - free process that was done in the old viewport to save vram (maybe not really the case now) and not care about simulation's GPU texture state sync.
This is quite basic as it only support boundbing boxes.
But the material can refine the volume shape in anyway the user like.
To overcome this limitation, a voxelisation should be done on the mesh (generating a SDF maybe?) and tested against every volumetric cell.
The system now uses several 3D textures in order to decouple every steps of the volumetric rendering.
See https://www.ea.com/frostbite/news/physically-based-unified-volumetric-rendering-in-frostbite for more details.
On the technical side, instead of using a compute shader to populate the 3D textures we use layered rendering with a geometry shader to render 1 fullscreen triangle per 3D texture slice.
Basically reverts rB65c4149f203610 and fixes the issue in a better way.
Keymaps using the removed operator will be affected. Switching header
from top to bottom now has the shortcut F5, just like switching other
regions.
This moves background images out of the 3D viewport,
to be used only as camera reference images.
For 3D viewport references,
background images can be used, see: D2827
Some work is still needed
(background option isn't working at the moment).
Tool for creating polygons, exact usage may change based on feedback.
LMB to add faces at boundaries (tris from edges, quads from verts).
- Ctrl splits edges
- Alt to dissolve edges/verts.
Works well with vertex snap & auto-merge.
This uses selection hover but isn't intended to introduce more widely
pre-selection highlighting, at least it will be restricted to this tool.
We are already using the AO distance, so might as well offer this extra
control over the intensity. Useful when an interior scene is supposed to
be significantly darker than the background shader.
This would break if using preview in VSE. We now use the scene engine
not the workspace engine.
That said we could have the preview engine defined as part of the sequence strip
as we had for draw modes in the past. But this is a separated topic for a
separated patch.
This issue in particular was introduced in e4f2b2be26.
Note: VSE preview is still broken in two cases:
* If you have Eevee as the engine in the Scene of the Scene strip.
* If you use Clay, save the file, and re-open.
Objects from set scene gets flattened out to the active scene depsgraph, so it
is a big question why do we need to build dependency graph for set scenes.
Make it a tag for relations update function instead, since we will not be able
to easily rebuild relations, and we wouldn't be able to iterate all scenes.
This is a part of mowing depsgraph to be per-workspace/layer in 2.8 branch.
This replaces usage of generic PLACEHOLDEWR with string lookup with more
explicit opcode. This should make it faster to build dependency graph by
avoiding string comparisons when it's not needed.
There should be no user measurable different.
Was never actually used and implementation seems to be slow: we shouldn't be
doing per-node evaluation hash lookups, adds too much overhead. We can instead
store statistics in the node itself, and maybe even group them somehow.
Ideally such a statistics should be user-friendly so riggers and animators
can see exactly what's happening.
Steps to reproduce were:
* Open Blender, create a new scene
* Go back to initial scene, transform object
* Switch back to newly created scene, change operator settings there
* Should cause a crash (at least with asan)
Should behave like 2.7 now, that is, switch scene back to where
operator was executed.
We wouldn't know which dependency graphs needs/safe for reconstruction,
so rather use API which tells that relations are out of date. This way
graph evaluation will take care of the rest.
Committing to 2.8 only since it's where we can't reliably know the graph
and is probably not that safe to apply this in master.
This needs to be re-implemented in a new fashion, without touching global list
of bases and become compatible with the new dependency graph.
The idea to go here would be to create new dependency graph for motion path
evaluation, bring a single object in there (which will pull all dependencies
at a construction) and use that.
Needs working copy-on-write first tho.
Was never actually used and implementation seems to be slow: we shouldn't be
doing per-node evaluation hash lookups, adds too much overhead. We can instead
store statistics in the node itself, and maybe even group them somehow.
Ideally such a statistics should be user-friendly so riggers and animators
can see exactly what's happening.
It will not be possible to do that after depsgraph becomes more context
oriented. Which means, all code will need to explicitly tell which graph
to free,
This is a first step towards an updated API where we pass explicit graph rather
than a scene. This is because we can no longer deduct which graph to use since
it will depend on a context.
Will happen in several steps, so bisecting will not be such a pain.
This is a corner-case, but one that is too easy to reproduce:
* Unlink all the collections of active view layer.
* Link a group without "Instancing" it.
The test will leak CPU devices, but is all passing other than that.
Leak will be fixed shortly.
P.S. Committing code refactor without running regression tests, tsk ;)
* Remove tex_* and pixels_* functions, replace by mem_*.
* Add MEM_TEXTURE and MEM_PIXELS as memory types recognized by devices.
* No longer create device_memory and call mem_* directly, always go
through device_only_memory, device_vector and device_pixels.
Was actually possible to invoke this assert failure in two ways:
* Transforming in newly created 3D View (like described in the report).
* Transforming in newly appended workspace from default workspaces.blend. Issue was that default workspaces.blend was saved in 2.8.1, but in a branch state that didn't include the transform-orientation changes. So versioning code wouldn't run when needed.
Note that files saved with this bug will still cause the assert to
fail. Can be ignored then.
This is not related to manipulators (as suggested in the report).
rna_scene.c was getting way too big with data that was related to
DNA_layer_types.h.
I tried doing it earlier, but failed. But now with the new changes I think it's
better to do this sooner than later.
Was using an edge hash for triangle -> edge lookups,
updating triangle indices for each edge-rotation.
Replace this with half-edge which can rotate edges much more simply,
writing triangles back once the solution has been calculated.
Gives ~33% speedup in own tests.
Progressive refine undoes memory saving from save buffers, so enabling
both does not make much sense. Previously enabling progressive refine
would disable denoising, but it should be the other way around since
denoise actually affects the render result.
Includes some code refactor for progressive refine render buffers, and
avoids recomputing tiles for each progressive sample.
CPU rendering will be restricted to a BVH2, which is not ideal for raytracing
performance but can be shared with the GPU. Decoupled volume shading will be
disabled to match GPU volume sampling.
The number of CPU rendering threads is reduced to leave one core dedicated to
each GPU. Viewport rendering will also only use GPU rendering still. So along
with the BVH2 usage, perfect scaling should not be expected.
Go to User Preferences > System to enable the CPU to render alongside the GPU.
Differential Revision: https://developer.blender.org/D2873
The tool-system it's self is primitive and may be changed.
Adding to 2.8 to develop operators and manipulators as tools.
Currently this is exposed in the toolbar, collapsed by default.
Work-flow remains unchanged if you don't change the active tool.
Placing the 3D cursor is now a Click instead of a Press event,
this allows tweak events to be mapped to tools such as border select,
keeping click for 3D cursor placement when selection tools are set.
This way evaluation routines will know which exact depsgraph evaluation
is happening for.
Mainly needed to get evaluation flags associated with ID nodes.
The idea is following: we do need to have multiple dependency graphs to denote
different scene layers (depsgraph should only contain objects from a specific
scene layer), and we also want to support same scene layer to be evaluated to
a different state in different windows. In order to achieve that we do need to
have a list or hash (for faster lookup presumably) somewhere. To keep things
easier for now, it will be a scene which owns that hash. This seems to make
sense anyway, since dependency graph only points to data which is owned by
scene.
This commit only introduces some basic API and hash itself stored in DNA, there
is no changes in behavior. See this as a first step towards getting rid of
scene-global dependency graph.
While such drivers will generally get evaluated too late to be of much
use during animations, it can still be useful to allow using drivers to
control a whole bunch of NLA strip properties (i.e. syncing NLA strip
timings via a single property/control).
Keyframe insertion however is still not allowed on these properties
(and an error message will now be displayed when trying to do so,
instead of silently failing), as it is useless.
This was never correctly implemented. It now works as expected (ala 2.79 behaviour).
The proxy object is added to all the collections of the original empty.
Before not only this wasn't the case, but it would crash Blender.
Loading blender with an unknown name would interpret it as a blend file.
This meant passing `--arg` arguments would end up creating new
blend files which could be confusing if you made a typo on a command
line argument.
Now check the string has a blend file extension,
exiting if it doesn't.
This only applies when LIB_ID_CREATE_NO_ALLOCATE flag is used and guarantees
that non-memset-zero memory can be used (or, that same memory chunk might be
used over and over again without need to clean it from the calleer).
OUr beloved root nodetrees... Had to check again the code to undersand
why we copy them with bmain even though they are not in bmain, so this
is worth a comment. ;)
Changes from D2876 by @meta-androcto /w own edits
Move 3x undo items into Undo menu,
these are such common operations they're typically accessed by keys.
Also add to menus which didn't have undo
(seemed random which modes had undo, undo history in their menus).
Changes from D2876 by @meta-androcto /w own edits
- Move view axis & camera selection into "Viewpoint" menu.
- Move render border and clipping into border menu.
- Move Camera operators into own menu.
- View Selected was located in two menus,
Only expose the "use_all_regions" version when quad-view is used.
This solves issue with user counter on materials, objects and such,
additionally avoids having too much overhead of temporary lock and
datablock allocation.
Still need to do similar thing for scene copy, and look into nested
ID datablocks somehow.
Before it was a compile time option which was not very easy to use or test. Now
the project is getting more mature, so very soon we will be able to call for a
public tests of limited features.
The copy-on-write (which includes animation, modifiers) is enabled using
--enable-copy-on-write command line argument.
This is fully unpredictable for artists when one damaged object makes the whole
scene to render incorrectly. This involves two main changes:
- It is not enough to check triangle bounds to be valid when building BVH.
This is because triangle might have some finite vertices and some non-finite.
- We shouldn't add non-finite triangle area to the overall area for MIS.
Cyclic extrapolation is implemented as an f-curve modifier, so this
technically violates abstraction separation and is something of a hack.
However without such behavior achieving smooth looping with cyclic
extrapolation is extremely cumbersome.
The new behavior is applied when the first modifier is Cyclic
extrapolation in Repeat or Repeat with Offset mode without
using influence, repeat count or range restrictions.
This change in behavior means that curve handles have to be updated
when the modifier is added, removed or its options change. Due to the
way code is structured, it seems it requires a helper link to the
containing curve from the modifier object.
Reviewers: aligorith
Differential Revision: https://developer.blender.org/D2783
It seems that `typestr` does not always define the final size of the element. And it varies by operating system.
Then use the `typestr` only to know the itemtype is `float` type or not.
Engine is not stored in WorkSpaces. That defines the "context" engine, which
is used for the entire UI.
The engine used for the poll of nodes (add node menu, new nodes when "Use Nodes")
is obtained from context.
Introduce a ViewRender struct for viewport settings that are defined for
workspaces and scene. This struct will be populated with the hand-picked
settings that can be defined per workspace as per the 2.8 design.
* use_scene_settings
* properties editor: workshop + organize context path
Use Scene Settings
==================
For viewport drawing, Workspaces have an option to use the Scene render
settings (F12) instead of the viewport settings.
This way users can quickly preview the final render settings, engine and
View Layer. This will affect all the editors in that workspace, and it will be
clearly indicated in the top-bar.
Properties Editor: Add Workspace and organize context path
==========================================================
We now have the properties of:
Scene, Scene > Layer, Scene > World, Workspace
[Scene | Workspace] > Render Layer > Object
[Scene | Workspace] > Render Layer > Object > Data
(...)
Reviewers: Campbell Barton, Julian Eisel
Differential Revision: https://developer.blender.org/D2842
NODE_NEWER_SHADING was introduced in e868b459bb however it should have been
added as a bitflag.
BKE_scene_uses_blender_eevee() was used in gpu_shader_output() as a workaround
for compatibility being poorly used.
Anyways this fixes this situation. This is necessary for an upcoming patch, even
though this is considered temporary - since the other NODE_*_SHADING values are
legacy from Blender Internal drawing.
Border and circle select wait for input by default.
This commit uses bool properties on the operators instead of
magic number (called "gesture_mode").
Keymaps that define 'deselect' for border/circle select
begin immediately, exiting when on button release.
There was noise correlation between the rotation random number and the radius random number used in the contact shadow algo.
Hacking a new distribution from the old distribution (may not be ideal because it's discrepency may be high)
Also distribute samples evenly on the shadow disc. (add sqrt)
Fix the "bias floating shadows", was cause by the discarding of backfacing geom which makes no sense in this case.
User count of scenes was inconsistant, screens only have 'user_one' kind
of owning over scenes, which means they shall never increment or
decrement their real user count. And usually, scenes have no real user
at all.
Would happen during panel's refresh drawing, if drawing code had to adjust
final panel position compared to the initial one computed based on the
mouse coordinates, and user had dragged the floating panel around.
Issue fixed by adjusting stored mouse coordinates once final panel
position is known, such that they would directly generate those
coordinates. that way, the basic offset applied to those stored mouse
coordinates during panel dragging is valid, and recreating panel based
on those won't make it jump in screen.
Note that panel will still jump in case user dragged it partially out of
view - we could prevent that, but imho it's better to keep that
behavior, since redraw can generate a popup of different size, which
could end up with a totally out-of-view one...
Hopefully this fix does not break anything else!
This adds a custom depth test that have the benefits to glitch less and be more visually pleasing.
Downside is that it let the grid pass trough the objects a little.
This effect is done in NDC space so that it counteract the logarithmic depth distribution imprecision (read as it's less visible near the camera but more present far away).
This patch also includes some cleanups.
Was a mistake in optimization commit which was disconnecting closures and nodes
which does not make sense for volume output.
OSL script we can't ignore and can't currently know in advance if it's a proper
volume shader or not. So we never disconnect OSL nodes from volume output.
This is a good candidate for corrective release.
This patch goes away form using C++ RNA during tangent space calculation which
avoids quite a bit of overhead. Now all calculation is done using data which
already exists in ccl::Mesh. This means, tangent space is now calculated from
triangles, which doesn't seem to be any different (at least as far as regression
tests are concerned).
One of the positive sides is that this change makes it possible to move tangent
space calculation from blender/ to render/ so we will have Cycles standalone
supporting tangent space.
Reviewers: brecht, lukasstockner97, campbellbarton
Differential Revision: https://developer.blender.org/D2810
Everything was fine if one batch is always used with instancing. But problem arise if the next drawcall for this batch is not using instancing as the attrib divisor stays set to 1 in th VAO.
As instancing is less used than normal drawing I prefer to reset the divisor after drawing as it is reset before drawing instances.
This was caused by small float precision being insuficient. The blue component of R11F_G11F_B10F has lower precision than the other 2 components. This resulted in colors drifting towards a yellowish tone.
Using RGBA16F for the concerned buffer. This double the memory usage of the framebuffers and add subsequent bandwidth usage.
This bug (explained here https://github.com/dfelinto/opengl-sandbox/blob/downsample/README.md) is breaking eevee beyond the point it's workable.
This patch workaround the issue by making sure every fbo have mipmaps that are strictly greater than 16px. This break the bloom visuals a bit but only for this setup.
This change affects CUDA GPUs not connected to a display or connected to a
display but supporting compute preemption so that the display does not
freeze. I couldn't find an official list, but compute preemption seems to be
only supported with GTX 1070+ and Linux (not GTX 1060- or Windows).
This helps improve small tile rendering performance further if there are
sufficient samples x number of pixels in a single tile to keep the GPU busy.
Best guess is that cuInit() somehow interferes with the AMD graphics driver
on Windows, and switching the initialization order to do OpenCL first seems
to solve the issue.
* Use common TextureInfo struct for all devices, except CUDA fermi.
* Move image sampling code to kernels/*/kernel_*_image.h files.
* Use arrays for data textures on Fermi too, so device_vector<Struct> works.
Instead of trying to be clever with swaps and lazy updating the weight
data, simply recalculate one single array. To improve performance, use
threading for that.
This was introduced on 9ad2c0b615.
Although this still doesn't fix the issue, it updates the preview
system to use COLLECTION_DISABLED as intended.
What is missing now is for the flushing to work effectively.
This add the possibility to add screen space raytraced shadows to fix light leaking cause by shadows maps.
Theses inherit of the same artifacts as other screenspace methods.
Two issues here:
- Checking table size to be non-zero is not a proper way to go here. This is
because we first resize the table and then fill it in. So it was possible that
non-initialized table was used.
Trickery with using temporary memory and then doing table.swap() might work,
but we can not guarantee that table size will be set after the data pointer.
- Mutex guard was useless, because every thread was using own mutex. Need to
make mutex guard static so all threads are using same mutex.
Tried 101 but it gives colisions.
I think 257 is enough now that we dont have thousands of uniforms.
This gives some noticeable performance improvement.
Could be refined further.
The issue was caused by light sample being evaluated to nan at some point.
This is root of the cause which is to be fixed, but is very hard to trace down
especially via ssh (the issue only happens on AVX2 release build). Will give it
a closer look when back to my AVX2 machine.
For until then this is a good check to have anyway, it corresponds to what's
happening in regular radiance sum.
This changes quite a few things:
- Drops the allocation of inputs as a chunk.
- Merge the linked list system into the Gwn_ShaderInput.
- Put name buffer into another memory block, easily resizable.
- Use offset instead of char* to direct to input name.
- Add only requested uniforms dynamicaly to the Shader Interface.
This drops some minor optimisation and use a bit more memory for small shaders (which are fixed count).
But this saves a lot of memory when using UBOs because the names and the Gwn_ShaderInput were alloc'ed for every UBO variable.
This also reduce the Shader Interface initial generation.
The lookup time is left unchanged.
Camera clipping was left to default values, which won't work well for
very large (or small) objects. Now recompute valid clipping start/end
based on boundingbox of rendered data, and final location of camera.
This makes brush influence into a tube instead of a sphere.
It can be used along the outline of a mesh to adjust it's silhouette.
Note that all this takes advantage of changes from vertex paint,
from testing this seems useful so exposing from the brush options.
This is an internal structure, and we don't put it to a list for anything else
that hash collision resolution. No need to have dedicated entry here, saves us
from extra allocation and pointer dereference.
This way we reduce number of loops from look-over-all-inputs to
loop-over-collision, which is expected to be much less CPU ticks.
There is still possible optimization: use memory pool of some sort
to manage memory needed for hash entries, but that will only speedup
shader interface construction / deconstruction time.
There are also some trickery happening to speed up process even more
in the case there is no hash collisions detected when constructing
shader interface.
This behavior makes more sense for sculpt, less so for painting.
Restores non PBVH behavior, adding `BKE_pbvh_find_nearest_to_ray` -
similar to ray-cast except it finds the closest point on the surface.
There are cases where we'll want to also override the reference pointer
(when we actually switch that datablock itself), but in some specific
situations, like when creating a new override, we need to keep org
pointer here!
The work size is still very conservative, and this doesn't help for progressive
refine. For that we will need to render multiple tiles at the same time. But this
should already help for denoising renders that require too much memory with big
tiles, and just generally soften the performance dropoff with small tiles.
Differential Revision: https://developer.blender.org/D2856
This was originally done with the first sample in the kernel for better
performance, but it doesn't work anymore with atomics. Any benefit was
very minor anyway, too small to measure it seems.
- Separate the Post Processes settings into sub panel.
- Rename "Viewport Anti-Aliasing" to sampling & super-sampling as it also reduce the noise of other effects.
- Remove Temporal Anti-Aliasing toggle and make it always active unless the number of samples is 1.
Restoring weights is problematic when the stroke overlaps its mirror.
It's better to simply compute the new weight based on the saved data
rather than restoring things, and check that the change is monotonic.
This way is also closer to how things worked before the merge.
This secondary accumulation option accumulated brush falloff.
The same option in image painting accumulates color
as vertex paiht 'Spray' does.
Giving this option different behavior for vertex paint seems strange.
Also this is basically increasing falloff over time.
Remove the new code, expose existing 'Spray' as 'Accumulate'
to match other paint modes.
Notes:
- Changes in paint_vertex.c were simple to merge, mainly related on passing
evaluation context.
- Conflicts in EditDM and drawmesh.c are solved using code from blender2.8
branch. Those areas are deprecated and not to be used in final release.
However, it's possible that some reference code from master is lost, so
keep attention when adding alpha support for vertex painting.
The issue here is that we can not read scale from socket when determining
dependent area of interest. This area will depend on current pixel. Now fall
back to more stupid but reliable thing: if scale size input is connected to some
nodes, we use the whole frame as area of interest.
This makes vertex paint match image painting more closely.
- Add falloff shape option sphere/circle
where sphere uses a 3D radius around the cursor and
circle uses a 2D radius (projected), like previous releases.
- Add normal angle option so you can control the falloff.
- Add Cull option, to paint onto faces pointing away.
Disabling normals, culling and using circle falloff
allows you to paint through the mesh.
When painting with spray disabled - we need to re-apply
on top of the original each time.
Applying the soc-2016-pbvh-painting branch removed this.
While I'd added back a simple previous weight array,
this won't work when multiple groups are painted at once.
This is most pronounced in Auto-Normalize + Multi-Paint. Unlike
vertex paint, the weights being painted on in weight paint mode
don't necessarily correspond to the weight actually stored in
any one vertex group, and may instead be a computed aggregate.
This restores original code behavior lost in rB4f616c93f7cb.
This required some small changes to the data display shaders so that they match the way the object mode renders them.
Strangely enough, I had to remove the normal attribute from the display code because it was being not bound as soon as I created another rendering call in object mode. The problem may be deeper but I did not have time for this so I derive the normal from the sphere pos.
Note that this tool seems like it might need to be rewritten
since results are quite strange.
Projecting on the view vector gives a small improvement though.
paint_vertex.c was getting too big, move all code unrelated to
mode switching and modal painting into their own files.
Also replace vertex-color operators region redraw tag /w notifiers.
GSOC 2017 by Darshan Kadu, see: D2859.
This is a partial merge of some of the features from
the soc-2017-vertex_paint branch.
- Alpha painting & drawing.
- 10 new color blending modes.
- Support for vertex select in vertex paint mode.
This removes a bunch of code that is no longer needed, and running
"make update" will now automatically download the new libraries.
Differential Revision: https://developer.blender.org/D2861
This is done by storing only a subset of PathRadiance, and by storing
direct light immediately in the main PathRadiance. Saves about 10% of
CUDA stack memory, and simplifies subsurface indirect ray code.
This is really convenient for development. Either for profiling the
generated shaders or to check if the generated code is correct.
It writes the shaders to the temporary blender session folder.
2016 GSOC project by @nathanvollmer, see D2150
- Mirrored painting and radial symmetry, like in sculpt mode.
- Volume based splash prevention,
which avoids painting vertices far away from the 3D brush location.
- Normal based splash prevention,
which avoids painting vertices with normals opposite the normal
at the 3D brush location.
- Blur mode now uses a nearest neighbor average.
- Average mode, which averages the color/weight
of the vertices within the brush
- Smudge mode, which pulls the colors/weights
along the direction of the brush
- RGB^2 color blending, which gives a more accurate
blend between two colors
- multithreading support. (PBVH leaves are painted in parallel.)
- Foreground/background color picker in vertex paint
by the transform constraint lines
Ported over e7395c75d5 from the
greasepencil-object branch. I should've fixed this ages ago, but
couldn't figure out why at the time.
This adds TAA to eevee. The only thing important to note is that we need to keep the unjittered depth buffer so that the other engines are composited correctly.
The problem was that orthographic views can have hit position that are negative. Thus we cannot encode the hit in the sign of the Z component.
The workaround is to store the hit position in screenspace. But since we are using floating point render target, we are loosing quite a bit of precision.
TODO: use RGBA16 instead of RGBA16F. But that means encoding the pdf value somehow.
You can change the amount of samples in the user preferences. You do not need to restart blender to see the effect in the new viewport.
This adds another Multisample Framebuffer and textures (so even more memory required).
It works by blitting the default_fb to the multisample_fb each time the renderer need to render one or more "wire" pass.
It it then blit back to the default_fb so that the rest of pipeline is working as expected.
We COULD lower the GPU memory / bandwidth usage to render everything to the same multisample fbo and change the logic depending on if MSAA is enabled or not, but I think it's a bit too much work for now.
One crucial thing here: OpenVDB shoudl be compiled WITHOUT
OPENVDB_ENABLE_3_ABI_COMPATIBLE flag. This is how OpenVDB's Makefile is
configured and it's not really possible to detect this for a compiled library.
If we ever want to support that option, we need to add extra CMake argument and
use old version 3 API everywhere.
Even if pointer assignment may be atomic, it does not prevent reordering
and other nifty compiler tricks, we need a memory barrier to ensure not
only that transferring pointer from wip array to final one is atomic,
but also that all previous writing to memory are “flushed” to
(visible by) all CPUs...
Thanks @sergey for finding the potential (though quite unlikely) issue.
Now uses "Text Selected" theme color of "Menu Back" widget colors. Also
repositioned text slightly to have same margin on top and right (measured
by eye ;) ).
Tested with all bundled themes (contrib and no-contrib) and worked fine.
Considering that different splashes may need different colors for
overlaid text, using theme color may not be the best solution. I would
like to try how this works before adding an ugly way to force a certain
text color though.
Also tried different approaches, but this one I find the least ugly :S
As far as longer term plans go, we wanted to get a redesigned multi-page
splash screen anyway. At this point we can rethink how splash colors work
in general (i.e. auto-contrast, own splash theme colors, etc).
It has been deprecated since at least macOS 10.9 and fully removed in 10.12.
I am unsure if we should remove it only in 2.8. But you cannot build blender with it supported when using a modern xcode version anyway so I would tend towards just removing it also for 2.79 if that ever happens.
Reviewers: mont29, dfelinto, juicyfruit, brecht
Reviewed By: mont29, brecht
Subscribers: Blendify, brecht
Maniphest Tasks: T52807
Differential Revision: https://developer.blender.org/D2333
Adds a FXAA for smoothing out the extracted outlines.
The Post Process Anti Aliasing is only done on the Alpha channel of the outlines.
Because of that we need to add bleed the outline color out of the silouhette so the AA'd alpha can blend the right color and not pick black when the alpha is smoothed out of the silhouette.
Also because of the AA needs to have clear contrast to work with, I decided to ditch the "bluring" or the occluded outlines.
The FXAA adds an overhead of 0.17ms but we gain back 0.22ms * 4 = 0.88ms by removing the blur.
The FXAA Implementation is from Corey Richardson (cmr) (D2717). I had to modify it a bit to only filter the alpha channel.
This introduce some little artifacts on the border of edges because some pixel with very low opacity does not get discarded and then occlude the face rendered behind if it has not been drawn yet.
To fix this. I added an offset in the geometry shader for the edge fixup. This make the artifact only visible on the border of the object if there is a very dense wire region. It's only visible in edge select mode since vertex and face center also hides the artifacts.
We can enable this only if AA is enabled but for now it's always enabled.
Introducing a new header using the Blender socket logo,
commit of the source file will follow soon.
Splash committee: Ton Roosendaal, Dalai Felinto, Pablo Vazquez.
Artwork is a screenshot of 'Wanderer', an Eevee sample file
by Daniel Bystedt, available on blender.org (license: CC-BY-SA)
Textures were bound once. But since it was not unbound it's bind_num would not change and considered still bound next time a shader needed it.
Fix T52866
Fix T52855
Partial revert of 9068c0743e.
This commit tried to do two things:
(1) Fix UBO binding logic [good]
(2) "Improve" texture binding logic [bad]
Don't ever mix different fixes and refactors in the same commit.
Iterate over invisible objects too, so lamps can still lit the scene.
Also, now you can use a collection to set an object to invisible, not
only to visible.
For example:
Scene > Master collection > bedroom > furniture
Scene > View Layer > bedroom (visible)
> furniture (invisible)
The View Layer has two linked collections, bedroom and furniture.
This setup will make the furniture collection invisible.
Note: Unlike what was suggested on D2849, this does not make collection
visibility influence camera visibility. I will keep this as a separate
patch.
Reviewers: sergey
Subscribers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D2849
-No more hardcoded python35/36 tokens in the scripts
-disabled python module for boost, was not used
-Updated patches for python to support building with msvc2013
For the first bounce we now give each BSDF or BSSRDF a minimum sample weight,
which helps reduce noise for a typical case where you have a glossy BSDF with
a small weight due to Fresnel, but not necessarily small contribution relative
to a diffuse or transmission BSDF below.
We can probably find a better heuristic that also enables this on further
bounces, for example when looking through a perfect mirror, but I wasn't able
to find a robust one so far.
Similar to what we did for area lights previously, this should help
preserve stratification when using multiple BSDFs in theory. Improvements
are not easily noticeable in practice though, because the number of BSDFs
is usually low. Still nice to eliminate one sampling dimension.
Previously the Sobol pattern suffered from some correlation issues that
made the outline of objects like a smoke domain visible. This helps
simplify the code and also makes some other optimizations possible.
Right now this is exposed in the outliner, though all this
(visible/selectable/enable) should be moved to a new panel soon.
This removes objects from the depsgraph when the collection is disabled.
It allows you to "hide" lamps but still having them lighting the scene.
Same for light probes and other support objects.
Pending tasks:
* Have depsgraph to include invisible objects in the DEG_OBJECTS_ITER, and
then have Eevee and other engines to make a distinction between an
invisible and a visible object.
(for example, we probably want invisible objects to not show in the
viewport, but cast shadows and show up in light probes).
* Change how we evaluate collection settings so that an invisible
collection can force an object to be invisible.
Reviewers: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D2848
Now we replace O(N^2) computational complexity with O(N) extra memory penalty.
Memory is much cheaper than CPU time. Keep in mind, memory penalty is like
4 megabytes per 1M vertices.
Tentative fix, since I cannot reproduce thenissue for some reason here
on linux.
Core of the problem is pretty clear though, thanks to Germano Cavalcante
(@mano-wii): another thread could try to use looptris data after worker
one had allocated it, but before it had actually computed looptris.
So now, we use a temp 'wip' pointer to store looptris being computed
(since this is protected by a mutex, other threads will have to wait on
it, no possibility for them to double-compute the looptris here).
This should probably be backported to 2.79a if done.
The issue was caused by threading conflict around looptris: it was possible
that DM will return non-NULL but non-initialized array of looptris.
Thanks Campbell for second pair of eyes!
Use triple buffer by default now on all platforms, remaing ones where:
* Mesa: seems to have been working well for a long time now, and not using
it gives issues with the latest Mesa 17.2.0.
* Windows software OpenGL: no longer supported since OpenGL 2.1 requirement
was introduced.
* OS X with thousands of colors: this option was removed in OS X 10.6, and
that's our minimum requirement.
Ubo needs to be rebound every times the shader changes.
This simplify the logic a bit.
Also modify texture binding logic to potentially reuse more already bound textures.
When 2x loops have different number of vertices,
the distribution for vertices fan-fill depended on the loop order
and was often lop-sided.
This caused noticeable inconstancies depending on the input
since edge-loops are flipped to match each others winding order.
This fix the crappy binding logic.
Note the current method is doing a lot of useless binding. We should somewhat order the texture so that reused textures are already bound most of the time.
Use more watertight and robust intersection test.
It uses now ray to triangle intersection, but it's all fine because segment was
covering the whole bounding box anyway.
Mainly when object origin is not at the geometry bounding box center.
Seems to be straightforward to fix, hopefully it doesn't break some obscure case
where this was a desired behavior.
The issue here was that removing datablock from main database will poke editors
update, which includes buttons context to free users of texture. Since Cycles
will free datablocks from job thread, it might crash Blender since main thread
might be in the middle of drawing.
Solved by exposing extra arguments to bpy.data.foo.remove() which indicates
whether we want to perform ID user count and interface updates. While scripts
shouldn't be using those normally, this is the only way to allow Cycles to skip
interface update when removing datablock.
Reviewers: mont29
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D2840
The issue was caused by render result identifier only consist of scene name,
which could indeed cause conflicts.
On the one hand, there are quite some areas in Blender where we need identifier
to be unique to properly address things. Usually this is required for sub-data
of IDs, like bones. On another hand, it's not that hard to support this
particular case and avoid possible frustration.
The idea is, we add library name to render identifier for linked scenes. We use
library name and not pointer so we preserve render results through undo stack.
Reviewers: campbellbarton, mont29, brecht
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D2836
Add sanitizer. I wanted to stay away from this because I think we should fix what causes NaNs in the first place. But there can be too much different factor causing NaNs and it can be because of user inputs.
Was caused by numeric overflow when calculating preview dimensions.
Now we try to avoid really insance preview resolutions by fitting
aspect into square.
The branching introduced by the uniform caused problems on mesa + AMD in the resolve stage.
This patch create one shader per sample count without branching.
This improves performance of a single ray per pixel case (3.0ms against 3.6ms in my testing)
The issue was caused by operator redo which frees all object's evaluated data,
including bounding box. This bounding box can not be reconstructed properly
without full curve evaluation (need to at least convert font to nurbs, which is
not cheap already).
There is absolute no reason to have such an indentation level, it only causes
readability and maintainability issues. It is really simple to make code more
"streamlined".
This was cause by a fairly funky unitialize buffer (last frame) that was causing NANs during the SSR resolve stage.
They were then propagated to the whole image during the next swap.
Bypassing the SSR completly if no valid history exists fixes the problem. Also disabling SSR data output in this case so we can have correct reflection in the 1st history buffer.
Rather than treating all ray types equally, we now always render 1 glossy
bounce and unlimited transmission bounces. This makes it possible to get
good looking results with low AO bounces settings, making it useful to
speed up interior renders for example.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2818
You can now use a transparent shader as a completly transparent bsdf. And use whatever alpha mask in a mix shader between a transparent bsdf and another bsdf.
In fact, any type of baking might have caused holes in mesh.
The issue was caused by zspan_scanconvert() attempting to get order of traversal
'a-priori', which might have failed if check happens at the "tip" of span where
`zspan->span1[sn1] == zspan->span2[sn1]`.
Didn't see anything bad on making it a check when iterating over scanlines and
pick minimal span based on current scanline. It's slower, but unlikely to cause
measurable difference. Quality should stay the same unless i'm missing something.
Reviewers: brecht, dfelinto
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2837
Previously we used a 1D sequence to select a light, and another 2D sequence
to sample a point on the light. For multiple lights this meant each light
would get a random subset of a 2D stratified sequence, which is not
guaranteed to be stratified anymore.
Now we use only a 2D sequence, split into segments along the X axis, one for
each light. The samples that fall within a segment then each are a stratified
sequence, at least in the limit. So for example for two lights, we split up
the unit square into two segments [0,0.5[ x [0,1[ and [0.5,1[ x [0,1[.
This doesn't make much difference in most scenes, mainly helps if you have a
few large area lights or some types of HDR backgrounds.
This causes render differences in some scenes, for example fishy_cat
and pabellon scenes render brighter in a few spots. This is an old
bug, not due to recent RR changes.
This is in order to use the same texture on multiple sampler.
Also texture counter is reset after each shading group. This mimics the previous behaviour.
Just using same code for distribution for face/volume as the one
changed/used for vertices since some months.
Note that this change is breacking compatibility, in that distribution
of particles over faces/volume may not be exactly the same as
previously.
Previously only the active object was used.
Use coroutines to support baking frames for multiple objects at once,
without having to playback the animation multiple times.
- Replace poisson by concentric samples: Less variance. They are sorted by radius then by angle.
- Separate filtering into 2 blur. First blur is 3x3 box blur. Second is user dependant.
- Group fetches by group of 4.
This brings some data structure changes.
Shared shadow data are stored in ShadowData (in glsl) (aka EEVEE_Shadow in C).
This structure contains the array indices of the first shadow element of this shadow "object".
It also contains how many shadow to evaluate (to be used for Multiple shadow maps).
The filtering is noisy and needs improvement.
- Use only one 2d texture array to store all shadowmaps.
- Allow to change shadow maps resolution.
- Do not output radial distance when rendering shadowmaps. This will allow fast rendering of shadowmaps when we will drop the use of geometry shaders.
- Use indices instead of character args.
- Use numbered macros instead of variadic args.
Parsing using rtags used over 11gb of memory. While this should be
resolved upstream (report as #1053), the extra complexity didn't give
any real advantage.
Disabled forceinline for those architectures, which seems to be compiling
successfully more often.
There might be ~3% slowdown based on quick tests, but better be rendering
something rather than failing to compile kernels again and again.
Those architectures will be doomed for abandon once we'll switch to toolkit 9.
Empty BVH nodes are set to NaN which must be preserved all the way to the
tnear <= tfar test which can then give false for empty nodes. This needs
strict semantices and careful argument ordering for min() and max(), so
the second argument is used if either of the arguments is NaN.
Fixes T52635: crash in BVH traversal with SSE4.1.
Differential Revision: https://developer.blender.org/D2828
There was some invalid state in the screen here, some areas had
sa->full set even though no screen was maximized, which then caused
a restore from the wrong (empty) area, which then led to spacedata
being empty and a crash.
This fix properly clears the sa->full after restore, and also fixes
existing .blend files in such an invalid state.
Only the camera from View3D.localvd is used,
other pointers may be invalid.
Longer term we should probably clear these to ensure no accidents.
For now just follow the rest of Blender's code and don't access.
Baking rigid body cache was broken if some cached frames already
existed.
This is just a band aid for release, the logic need to be looked into
further.
Since the change to prevent shader recompilation at every update, we got
a regression when clearcoat was used.
Basically at the shader build time we would determine if the shader
needed clear coat, and if it didin't, it would build a different GLSL
program.
However if later the user updated the clearcoat value so that it would
then require the full clearcoat shader, the user wouldn't get it until
manually forcing the shader to recompile, or reopening the file.
We now handle the optimization in the GLSL code. That adds a minimum
overhead due to branching. But the overall performance seems unchanged
(tested on linux in AMD and NVidia).
Reviewers: pascal, brecht, fclem
Differential Revision: https://developer.blender.org/D2822
Operators and their properties are two different types
Previously both operators and their properties are added
causing C operators to access the properties, Python the classes.
Favor consistency in this case so only Python classes are added.
A single diagonal axis was used for sorting coordinates,
the algorithm relied on users not having vertices axis aligned.
Use BLI_kdtree to remove doubles instead.
Overall speed varies, it's more predictable than the previous method.
Some typical tests gave speedup of ~1.4x - 1.7x.
For example, if you have two keyframes:
k1 = 1px, k2 = 10px
it was doing:
1px, 9px, 8px, ..., 3px, 2px, 10px
instead of:
1px, 2px, 3px, ..., 8px, 9px, 10px
This reverts commit 134e927965.
Writing into const event is very bad,
but this change broke compositor manipulators.
Will look into better solution eventually.
For some specific pipelines (e.g., holographic rendering) you can easily
need over a million frames (1k * 1k view angles).
It seems a corner case, but there is no real reason not to allow users
doing that.
That said we do loose subframe precision in the highest frame range. Which can
affect motionblur. The current maximum sub-frame precision we have is 16.
While the previous limit of 500k frames has a precision of 32.
Thanks to Campbell Barton for the help here.
To be backported to 2.79
Own error in recent type checks, in many cases the 'idname'
is used for the struct identifier, not the 'identifier'
which is the Python class name in this context.
Mostly internal changes, keeping both manipulators
could have worked but there was no point long term.
There are still some glitches to resolve, will work on those next.
Basically since g_data was malloc'ed (instead of calloc'ed)
g_data->minzbuffer was never initialized.
So when running DRW_framebuffer_init after EEVEE_effects_init, the test
to *g_data->minzbuffer would lead to unpredictable results.
This was caught by valgrind, reported by Sergey Sharybin.
Previous version was trying to do a quick and simple process in the case
we were only considering smooth/flat status of faces.
Thing is, even then, the algorithm was not actually working in all
possible situations, e.g. two smooth faces having a single vertex in
common, but no common edges, would not have split that vertex, leading
to incorrect shading etc.
So now, tweaked slightly our split normals code to be able to generate
lnor spaces even when autosmooth is disabled, and we always go that way
when splitting faces.
Using smooth fans from clnor spaces is not only the only way to get 100%
correct results, it also makes face split code simpler.
One problem is that it was always using __mm_blendv_ps emulation even if the
instruction was supported. The other that the emulation function was wrong.
Thanks a lot to Ray Molenkamp for tracking this one down.
Apparently with Maya in a certain configuration, it's possible to have an
Alembic object without schema in the Alembic file. This is now handled
properly, instead of crashing on a null pointer.
This affects the curve display color setting, but is really intended
for future per-curve options.
The id_data reference in the created rna pointers refers to the object
even if the curve is actually owned by its action, which is somewhat
inconsistent, but the same problem can be found in existing code.
Fixing it requires changes in animdata filter API.
The is following: split copy on write update for node trees, and if we are only
tagging for uniform buffer update we skip whole datablock copy and only invoke
copy default_values form original nodetree to a copied one.
Thing which i'm not sure is: whether we need to use different branches in graph
itself to control such a conditional behavior, or whether we need to store tag
somewhere in the dependency graph. There are obviously cons and pros in both
approaches, and need to think about this. Maybe with more examples it becomes
more obvious which way is better.
This only fixes manual tweaks for now, animation support is coming.
Adding alongside the existing one for now,
but it should eventually replace it.
Uses a matrix instead of (position + scale),
written so rotation can be done more easily.
Currently has a primitive handle for rotation, supports corner scaling.
There were two issues here:
1. material_update did not do anything, because DEG_id_tag_update was storing
update tags in original IDs, which had nothing evaluated. Even more, material
update should have been called with evaluated version of material, Solved
this by copying update tag from original ID to a copied one.
However, perhaps DEG_id_tag_update should tag both original and copied ID,
so updates are never gets lots if some depsgraph is not visible.
2. Tagging material for update should ensure it's copied version of node tree is
up to date, otherwise material will still use old node tree.
This solves missing material updates when changing topology. Tweaking values is
still broken, because of GPUMaterial using pointer to original node's socket
value, which gets broken after copy-on-write of the node tree (pointers of nodes
are changing).
Previously it was returning short, which was really easy to (a) compare against
non-ID type value (b) forget to handle some specific value in switch statement.
Both issues happened in the nearest past, so it's time to tighten some nuts
here.
Most of the change related on silencing strict compiler warning now, but there
is also one tricky aspect: ID_NLA is not in the IDType enum. So there is still
cast to short to handle that switch. If someone has better ideas how to deal
with this please go ahead :)
A single manipulator could only assign a single operator to each part.
Now each part can have it's own.
Also modify 2D selection callback, 2D started at 1, 3D at 0.
Now use -1 for unset value, start both at 0.
- Vertex only meshes never restored their selection history.
- Select history was cleared on the source instead of the target.
Simple Optimizations:
- Avoid O(n^2) linked list looping that checked the entire list before
adding elements (NULL values in the source array to prevent dupes).
- Re-use vert & edge lookup tables instead of allocating new ones.
Issue was nasty hidden one, the dual status (mix of local and linked)
of proxies striking again.
Here, remapping process was considering obdata pointer of proxies as
indirect usage, hence clearing the 'LIB_TAG_EXTERN' of obdata pointer.
That would make savetoblend code not store any 'lib placeholder' for
obdata data-block, which was hence lost on next file read.
Another (probably better) solution here would be to actually consider
obdata of proxies are fully indirect usage, and simply reassign proxies
from their linked object's obdata on file read...
However, that change shall be safer for now, probably good for 2.79 too.
This reverts commit 3888227a7b.
This "Fix" was made while ORCO was broken. Now that orco itself is fixed
this is no longer required, otherwise Tangent node produces different
results in Cycles and Eevee.
Don't use quick sort for small arrays, bubble sort works way faster for small
arrays due to cache coherency. This is what qsort() from libc is doing actually.
We can also experiment unrolling some extra small arrays, for example 3 and 4
element arrays.
This reduces tangent space calculation for dragon from 3.1sec to 2.9sec.
Brings tangent space calculation from 4.6sec to 3.1sec for dragon model in BI.
Cycles is also somewhat faster, but it has other bottlenecks.
Funny thing, using simple `static inline` already gives a lot of speedup here.
That's just answering question whether it's OK to leave decision on what to
inline up to a compiler..
Would be nice to be able to catch this with assert as well, will see what would
be the best way to do this/.\
Need to verify with Mai that this solves crash for her and maybe consider
porting this to 2.79.
Orco should behave the same if it comes from unconnected vec inputs, or
from the Texture Coordinate -> Generated node output.
Fixup for 11e7e0769a.
This is related to T52528. The coordinates are still different between
Eevee and Cycles, but at least it behaves consistent within itself.
In fact the shader should now be correct, but the orco attributes we are
passing the shader seems to be where the problem is. But it's to be
tackled separately.
scripts being "Artwork" which is your sole property and free to license.
I've removed the reference to scripts in this text.
This was from 2002! With our Python scripts becoming part of how Blender runs,
such scripts now are officially required to be compliant with GNU GPL.
For more information; check the FAQ or consult foundation@blender.orghttps://www.blender.org/support/faq/
Some manipulators are used like on-screen buttons,
in this case it doesn't make sense to keep track of their state,
so zero the offset when its unused.
Needed for lamp-target manipulator.
We have a hardcored limit of 1000 images to be baked.
However anything anove 100 would be leading to overflow in the code.
Caught by warning from builder bot (my compiler doesn't even complain
about this, but it should).
Re-use operator return flags for manipulator modal & invoke,
this means manipulators can allow navigation or other events to be
handled as they run - see T52499
Fishy cat benchmark was rendering with wrong shadows. Cause is unclear,
adding printf or rearranging code seems to avoid this issue, possibly a
compiler bug. This reverts the fix and solves the OSL bug elsewhere.
This was needed when we accessed OSL closure memory after shader evaluation,
which could get overwritten by another shader evaluation. But all closures
are immediatley converted to ShaderClosure now, so no longer needed.
While unlikely to have had any serious effects because of limited use, the
previous implementation was not actually atomic due to a data race and
incorrectly coded CAS loop. We also had duplicates of this code in a few
places, it's now been moved to a single location with all other atomic
operations.
We need to make sure we can store all volume closures for all objects in volume
stack. This is a bit tricky to detect what would be the "nestness" level of
volumes so for now use maximum possible stack depth. Might cause some slowdown,
but better to give reliable render output than to fail quickly.
Should be safe for 2.79 after extra eyes.
We were showing "search for unknown menutype WM_MT_button_context" messages in terminal which were not helpful for users, so now they are disabled.
To be backported to 2.79
It is possible to have same image used multiple times at different frames,
which means we can not free it's buffers without any guard. From quick tests
this seems to be doing what it is supposed to.
Need more testing and port this to 2.79.
Although the problem was exposed in 9457715d9a, the problem was in the
original code that was copied over. To have:
```
} else { /* EXPECTED_VALUE */
```
Without an BLI_assert(value == EXPECTED_VALUE); is asking for troubles.
Yet another reason to favour switch statements with:
```
default:
BLI_assert(!"value not implemented or supported");
```
Instead of chained if/else if/else /* expected_value */.
- NOCHECK -> ALL
- ALL -> MAYBE_ALL
Where 'MAYBE_ALL' checks to see if the mesh has changed.
This is clearer that `BKE_MESH_BATCH_DIRTY_ALL` is dirty and
going to be updated without any guess-work.
This was meant to be generic but introduced possible type errors
and unnecessary complication.
Replace with typed PyC_Tuple_PackArray_* functions.
Also add PyC_Tuple_Pack_* macro which replaces some uses of
Py_BuildValue, with the advantage of not having to parse a string.
- WM_manipulatorgrouptype_remove- > free
- WM_manipulator_group -> WM_manipulator_group_type
Naming here is still a bit confusing,
now at least free/remove are differentiated.
This means we have less overall noise for rendered image.
SSR, AO, and Refraction are affected by this change.
SSR still exhibit artifacts because the reconstruction pattern needs to change every frame (TODO).
Regression from rBfed853ea78221, calling this inside thread worker was
not really good idea anyway, and we already have all the code we need in
pre-threading init function, was just disabled for vertex particles
before.
To be backported to 2.79.
This exposes 2 methods for manipulators:
- new_custom_shape
- draw_custom_shape
This can be used for script authors to create and re-use shapes
without dealing with lower level API's.
Python's C-API doesn't provide functions to get
int's at specific integer sizes.
Leaving the caller to check for overflow,
which ended up being ignored in practice.
Add API functions that convert int/uint 8/16/32/64, also bool.
Raising overflow exception for unsupported ranges.
The thing that most often still goes wrong for new users building blender on windows is checking out the libraries, some skip over the wiki, some check out to the wrong folder, in an effort to reduce the time i spend on this, I added detection of svn and misisng libs to make.bat .
When the user has svn installed, and the libdir is missing he'll be asked if he wants to download them
if svn is not installed, or the user chooses 'no' the current error message is shown.
Reviewers: Blendify, sergey, juicyfruit
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D2782
We should only early out with any hit in BVH traversal if the only visibility
bits used are opaque shadow. Not when opaque shadow is one of multiple bits.
Also pass by value and don't write back now that it is just a hash for seeding
and no longer an LCG state. Together this makes CUDA a tiny bit faster in my
tests, but mainly simplifies code.
This implements Arvo's "Stratified sampling of spherical triangles". Similar to how we sample rectangular area lights, this is sampling triangles over their solid angle. It does significantly improve sampling close to the triangle, but doesn't do much for more distant triangles. So I added a simple heuristic to switch between the two methods. Unfortunately, I expect this to add render time in any case, even when it does not make any difference whatsoever. It'll take some benchmarking with various scenes and hardware to estimate how severe the impact is and if it is worth the change.
Reviewers: #cycles, brecht
Reviewed By: #cycles, brecht
Subscribers: Vega-core, brecht, SteffenD
Tags: #cycles
Differential Revision: https://developer.blender.org/D2730
No real reason we keep this only to copying, creating ID outside of
database is handy as well!
Also, add helpers to add/remove an ID from Main, and to set/clear its
'user refcounting' status. Those will be useful in future complex ID
manipulation cases (like static override...).
Not much happy, have to include BKE_curve in BLI_freetypefont to copy
nurbs... Not sure why fonts are in BLI tbh. We are already replicating
quite a bit of nurbs logic there. :(
Those are not actually copying the ID, only its internal subdata (and
other ID-specific handling). Generic processing common to all ID copying
is done by `BKE_id_copy_ex()`!
Makes things much simpler, and more consistent.
Also fix issue with new copying and bloody nodetrees, using same hack as
in original ntree copying code to detect 'root' ntrees that shall never
be put into bmain :(((((((
Note that those are an nightmare to handle correctly, current code is
like a plate of noodle, so... most likeley not fully working, think I'll
have to nuke localize code as well :(
(continuation of previous WIP commit, sorry about that one :/ ).
This commits changes quite a few things, distributing new copying flags
into sub-data copying code (mostly concerns ID refcounting or not).
It also removes ID refcounting handling from Modifiers' copy callback
(this was ugly from the start, proved to be problematic in current
master, and generally bad practice). This is now done by calling code.
Also, it brings back ID refcounting handling to main BKE_library's copy
code, which means in generic ID copying lower-level IDType-specific copy
code should not use it at all. Support at lower-level remains needed
though, unfortunately, to cope with partial copying tools etc.
It tried to assert that
addons/io_blend_utils/blender_bam-unpacked.whl/__init__.py was loaded when
the io_blend_utils module was imported. However, this happens only on
demand, and not directly when importing the add-on.
*Sigh* One more example of why we should keep ID management handling in
as few places as possible! It's impossible to keep more than a few
places in sync regarding which ID pointer is refcounted etc.
Children where always getting at least one segment of fixed length...
Now fully hidden ones (zero length) get no segment at all.
Note that even very short ones keep getting one 'unit' length segment - would
rather avoid changing that at this point, given how complex children
particles 'length' can get with all kind of modifiers... Think we can
live with that for now anyway.
The crash did not happen yet because we always had proper vmemh defined in
the parent scope.
Patch by Ivan Ivanov (aka obiwanus), thanks!
Differential Revision: https://developer.blender.org/D2715
Idea is the same, looks like it will be a tad simpler than with copy
though, since we should not need to change each ID type freeing func, as
ID usercount handling is done in main BKE_library code (would like to do
that for copy as well, but it's not that simple).
Namely, those allowing to link an object to an armature.
Thing is, we cannnot and absolutely do not want to use same trick as
armature proxies regarding deforming their related geometries.
So instead, we'll automatically make override of objects using
overridden armature as deformer, ultimately. This also allows for
several overrides of a same linked data.
Not sure how much good/bad this is, will have to ask artists once it's
ready for testing (cannot think of any non-ugly way to do that 'magic
trick' tbh).
Nothing functionnal for now, just made it possible for override to have
NULL reference ID.
Those overrides would be used as templates (created in original file of
the ID, they define some kind of default overriding settings). They
should also allow to forcefully lock some properties (forbid users of
that library ID to override some properties).
On second thought, modifying real data-block to store diff in it is...
just bad. Because it affects actual data, because it involves complicated
and heavy processes like remapping, and because it stores useless values
in .blend file (i.e. values that would give garbage results if e.g.
opening .blend file with older version of Blender, etc.).
So instead, decided to save an extra data-block in .blend file each time
we have some differential overrides.
Note that for now, we do full copy of datablock into its extra 'storage'
sibbling for .blend file. This is bad (think about double copy of heavy
mesh...) and will have to be fixed. Whole copy process will need serious
work anyway, for that kind of features we need to be able to copy
without increase usercount of IDs etc.
In fact, here, maybe we even need a smarter version of copy that would
only duplicate sub-data as needed by diff-overriden properties...
That way we don't have to add the same stupid few lines to *all*
datatypes writers! Obvious gain on efficiency and security from coding PoV.
Conflicts:
source/blender/blenloader/intern/writefile.c
Instead of calling a function looping over whole list of a given ID
type, make whole loop over Main in parent function, and call functions
writing a single datablock at a time.
This design is more in line with all other places in Blender where we
handle whole content of Main (including readfile.c), and much more easy
to extend and add e.g. some generic processing of IDs before/after
writing, etc.
From user point, there should be no change at all, only difference is
that data-block types won't be saved in same order as before (.blend
file specs enforces no order here, so this is not an issue, but it could
bug some third party users using other, simplified .blend file reader
maybe).
Reviewers: sergey
Differential Revision: https://developer.blender.org/D2510
Typical case: bones having constraints targetting other bones from same
armature. ID swap needs remapping here.
Really have to find something better than regular ID copy + swap + relinking
for override operations, this is horribly inneficient, complicated
and... most likely a nest of bugs and worms.
(pretty sure e.g. we still can generate same pointers during writefile
with current code :( ).
Seems CUDA failed to de-duplicate the array across multiple inlined
versions of the shadow_blocked(). Helped it a bit with that now.
Gives about 100MB memory improvement on a scenes after previous
commit and brings up memory "regression" to only 100MB comparing to
the master branch now.
This commit enables record-all behavior of transparent shadows
rays.
Render times difference goes as following:
GTX 1080 render time
BMW -0.5%
Fishy Cat -0.0%
Pabellon Barcelona -11.6%
Classroom +1.2%
Koro -58.6%
Kernel will now use some extra VRAM memory to store the intersection
array (200MB on my configuration). This we can optimize out with some
further commits.
The idea is to record all possible transparent intersections when
shooting transparent ray on GPU (similar to what we were doing on
CPU already).
This avoids need of doing whole ray-to-scene intersections queries
for each intersection and speeds up a lot cases like transparent
hair in the cost of extra memory.
This commit is a base ground for now and this feature is kept
disabled for until some further tweaks.
Now we break the traversal cycle and then perform volume attenuation
and check with zero throughput. Not sure it makes any measurable sense
at this moment, but in the future it might help de-duplicating some
extra logic here.
Removed unnecessary call to DM_update_tessface_data(). This call is
already performed by DM_ensure_tessface(dm). The call being performed
twice caused a failing BLI_assert().
Reviewed by: Kévin Dietrich
With the new names the arguments (yup, zup) are in the same order as
they appear in the function name. The old names used copy_src_dst(dst,
src), which I found very confusing. Furthermore, now it is clear from
where to where the copy is made.
This makes the function names a little bit longer, though. If that is
a real issue, we can just name them zup_from_yup(zup, yup).
Reviewed by: Kévin Dietrich
I.e. support override of loc/rot/scale of posechannels.
Also implied to add some minimal support of collections in 'diff
generating' RNA code.
Still much to be done of course.
So, now 'proportional' RNA properties (here, Object's scale) is stored
as 'multiply' override op.
Once again, this is mostly testing for now, there are a lot of potential
issues and traps in current code that'll need more background work to
address later if we keep working in this direction.
Main remaining TODO to complete the proof of concept now is sketching
out a bit of UI/UX control over override!
This commit mainly extend/refactor RNA prop copy and equals functions
into more advanced override utils (since equals is a subset of
aurooverride operations generation, and copy is a subset of override
operations application).
And some other work needed on the road...
Still called from pre-depsgraph eval step, does an RNA comparison and
generate overriding rules for changed props...
Note: we most certainly do not want to run this on all depsgraph eval.
Own current idea would be to just tag IDs e.g. in depsgraph callback,
and run actual auto-generation e.g. in a low-priority job, maybe? not
sure... :|
Also, fix stupid mistake in RNA applying of override (used when reading
file to apply static override), and add object's loc/rot/scale as
overridable properties.
Add a 'NOOP' override ruul to prevent any kind of override on a given
RNA path, and an ID flag 'AUTOOVERRIDE' to allow automatic definition of
override rules based on changed data.
Again, just defines, do not do anything yet.
Note that this is dummy empty placeholder for now!
Idea here is that depsgraph is best place to generate our override rules
based on data changes. That way all tools in Blender keep working as
usual, on local data, and overrides are generated when needed just
before IDs get actually evaluated.
Depsgraph has key advantage of only running over *changed* data-blocks
already.
Not sure this is actually valid idea, but for tests will do the work.
If we want to keep it, we'll have to find a way to prevent this running
too often though, especially not during most animation-triggered
evaluations.
Mostly code using override data to selectively update a copy of linked one
with local data.
As said, still totally hackish and experimental, but it works - you can
create overrides of linked Objects, and override their position, yeha! :P
Mostly nasty testing code, only overriding location of object for now.
And of course, we are still missing bits in read/write code to actually
do the override.
Also, add some minimal exposure of override in RNA, here again, most to
be done still.
Could very easily get into infinite loop when comparing Pointer
properties... And in any case, comparing ID pointer should be enough, no
need to dive into all ID properties!
COMMAND${CMAKE_COMMAND}-Ecopy"${PYTHON_OUTPUTDIR}/python35${PYTHON_POSTFIX}.lib"${BUILD_DIR}/python/src/external_python/run/libs/python35.lib#missing postfix on purpose, distutils is not expecting it
COMMAND${CMAKE_COMMAND}-Ecopy"${PYTHON_OUTPUTDIR}/python35${PYTHON_POSTFIX}.lib"${BUILD_DIR}/python/src/external_python/run/libs/python35${PYTHON_POSTFIX}.lib#other things like numpy still want it though.
COMMAND${CMAKE_COMMAND}-Ecopy"${PYTHON_OUTPUTDIR}/python${PYTHON_SHORT_VERSION_NO_DOTS}${PYTHON_POSTFIX}.lib"${BUILD_DIR}/python/src/external_python/run/libs/python${PYTHON_SHORT_VERSION_NO_DOTS}.lib#missing postfix on purpose, distutils is not expecting it
COMMAND${CMAKE_COMMAND}-Ecopy"${PYTHON_OUTPUTDIR}/python${PYTHON_SHORT_VERSION_NO_DOTS}${PYTHON_POSTFIX}.lib"${BUILD_DIR}/python/src/external_python/run/libs/python${PYTHON_SHORT_VERSION_NO_DOTS}${PYTHON_POSTFIX}.lib#other things like numpy still want it though.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
