Partially revert efe1af3d11
The offending commit over-zealously removed the datablocks viewer case
as well, when only the condition needed to be modified.
This was caused by dupli's ObjectEngineData that were not free.
This allocates the data using the instance data manager (no alloc/free between frames). Though the data should be treated as not persistent in this case.
Made shape keys to work for meshes. Also added missing code for curves.
Curves and lattices will not have shape keys visible, since modifiers support
is still to be done for them.
This brings separate initialization for libcuda and libnvrtc, which
fixes Cycles nvrtc compilation not working on build machines without
CUDA hardware available.
Differential Revision: https://developer.blender.org/D3045
It is possible to have non-NULL scene in graph which was never built yet,
this happens when ID is tagged for update for non-built graph.
Was causing crash opening deg_anim_pose_bones.
Reported by Mai in IRC, thanks!
This made vertex/weight/sculpt crash.
Add BKE_workspace_update_object_mode which sets the object mode from the
workspace.
We may want to re-visit exactly when this is set, for now call within
wm_event_do_refresh_wm_and_depsgraph.
This fixes an issue where old cache data was used after an object has been moved.
Particles were coming from very wrong positions. Reproduction case is to move an
object while animation is running and then let the animation loop back and
play again.
Differential Revision: https://developer.blender.org/D3044
Suggested by Pablo Vazquez (venomgfx).
The idea here is that it should be easy to work in the outliner by picking a
bunch of objects and adding them to a new collection.
Where is the new collection? In the same level as the "outliner active" object.
Note, since the outliner has no pure concept of an active object, I'm using
the highlight tag for this. Hopefully it works fine.
It should work in "Collections", "View Layer", and "Groups".
Only when collections are not filtered out.
The reason it appeared working was due to left-over debug code to force
time dependency.
Real fix seems to include force tagging objects used by duplication,
similar to what we do for some other modifiers already.
When destination IDProp did not exist, new code (related ot static
overrides) would not do nothing...
IDProps and RNA are really not easy to tame, thinking more and more we
should totally bypass RNA and directly use (add) IDP code to handle
comparison and diff creation/application of IDProps.
But for now, this bandage should to the trick.
Add a enum headers to DNA, to be included in other headers
so function signatures can use enums for better type safety.
Add DNA_*_enums.h matching DNA_*.types.h as needed.
The check to see if `use_advanced_hair` was enabled was actually in two places
(render panel `draw` function and physics panel `poll` function). As these
properties are only in one place now the check in `draw` isn't needed anymore.
Related: T53513, a6c69ca57f
As a follow-up to the commit rB354f92a49458795c69f857de927c5b1531cd3618
for fixing Freestyle crash when using Cycles (thanks Brecht for the fix), this revision
applies a related bugfix addressed partly in D3040 (item #2 in the description).
We should actually be using CL_DEVICE_MEM_BASE_ADDR_ALIGN for sub buffers,
previous change in this code was incorrect. Renamed the function now to
make the specific purpose of this alignment clear, it's not required for
data types in general.
Cycles old behaviour is to hide the duplicator on rendering at all times.
We have since a few months an option in 2.8 to control the duplicator
visibility on its own. However when the duplicator is also duplicated, things
were not working properly.
What we do now is, in addition to the duplicator visibility control, is to not
have the source collection of the duplicator object to ever influence its
visibility when the object is been duplicated.
So if the user wants to reproduce Cycles old behaviour all that is required is
to have different collections, one for the original to-be duplicated objects
that you hide in for the view layer used in the final render. And another
collection with only the first duplicator (which in turn duplicates other
duplicators).
I know this all may sound confusing, so please just give it a try, it's simpler
than it sounds.
T53783.
Before, profile=1 ("square outside") only worked well in a few cases
(some "pipes", cube corners). This makes it work well pretty much
everywhere.
This leads to a huge improvement of AntiAliasing quality.
There is no other distribution now and there is not settings displayed to the user. That's for another commit.
This patch changes the huge list of projects in visual studio into a nice tree matching the source folder structure. see D2823 for details.
Differential Revision: http://developer.blender.org/D2823
nvcc is very picky regarding compiler versions, severely limiting the compiler we can use, this commit adds a nvrtc based compiler that'll allow us to build the cubins even if the host compiler is unsupported. for details see D2913.
Differential Revision: http://developer.blender.org/D2913
This adds midlevel and object/world space for displacement, and a
vector displacement node with tangent/object/world space, midlevel
and scale.
Note that tangent space vector displacement still is not exactly
compatible with maps created by other software, this will require
changes to the tangent computation.
Differential Revision: https://developer.blender.org/D1734
When duplicating a layer collection directly linked to the view layer we copy
the collection and link it.
For all the not directly linked layer collectionns, we try to sync the layer
collection flags, overrides, ...
Also we make sure the new collection is right after the original collection.
We also expose this in RNA, via collection.duplicate().
Was happening when viewport visibility on the particle system is disabled.
This became an issue after c45afcf, but the actual issue goes a bit deeper
and the following aspects were involved:
- Relations builder for particle system was ignoring particle system if
it's visibility is not enabled for viewport. This is something what
shouldn't have been done -- depsgraph relations are supposed to be the
same no matter if it's viewport or render.
- Relation builder was only dealing with duplication set to object, but
was ignoring group duplication.
This is technically a regression in 2.79a-RC as well, so would need to
backport this fix to the branch after extra testing is done here in the
studio.
This is rather a workaround to avoid main thread freeing all glyph caches
at the same time as sequencer uses fonts to draw text sequences.
Ideally we need to either make cache more local, or user-counted or to make
somewhat more global locks. All this ends up in a bigger refactor which is
better for 2.8. For the meantime let's make Blender more stable with a tiny
workaround.
Downside is that keeping zooming things up and down in interface during render
will increase memory usage by unused glyph caches. It's not too bad though,
all unused caches will be freed first time at area zoom after render.
Thanks Bastien for review!
Behavior is expected to be simillar to 'make proxy' on linked groups, it
basically allows you to select which object in the group will be to
'root' override (usually, the armature), checks which other objects
needs to be overridden as well, overrides the group itself too, and
instantiates the group and the root overridden object.
It seems to be working, though handling of armature deformation is kind
of totally broken in blender2.8 currently (modifiers...). ;)
At some point, we could probably think about removing IRIS file format
support, don't think there are much of those around anymore. But for
now, let's add a translation context to wipe effect. :)
Reported in T43295 by @blend-it, thanks.
I was calling the ntree syncing function too late. So the index of the layer
was -1 since it was no longer in the ListBase, making all RenderLayer nodes
to decrease their respective `custom1` (even going to negative sometimes).
Since 30a966a726 when I removed the recursion, the code was still relying
on stack data. This would crash in release often, and it should crash always.
Big thanks to Sergey Sharybin for spotting the issue.
The issue was introduced by eb016eb as a fix for T41258, which added depsgraph
tagging with zero flag. The comment was saying that it's to make derived caches
to be updated, however bot sure how that could possibly work: tagging ID for
update with 0 flag only sets updated tags in bmain in old dependency graph.
In the new depsgraph, where object data is a part of depsgraph, doing such a
tag forces object to be updated, which re-triggers viewport rendering, which
is causing such an infinite viewport render rest.
Can not reproduce any crashes here, so maybe it's fine to move on with this
change.
This was leading to so much recursion that it was failing here.
How to test it: Open wanderer.blend and try to render (F12).
Note: This won't fix F12 rendering for wanderer with Eevee. Something else is
going wrong there.
For simplicity we choose to execute the rendering of Opengl engines in the main thread and block the interface.
This might be addressed in the future at least for video rendering.
A drawmanager wrapper (DRW_render_to_image) is called by the render pipeline to set up the Opengl state and then call the specific draw_engine->render_to_image function.
General idea of the fix: skip the whole draw manager callback madness which
was used to tag object's engine specific data as dirty. Use generic recalc
flag in ObjectEngineData structure instead. This gives us the following
benefits;
- Sovles mentioned bug report.
- Avoids whole interface lookup for opened viewports for EVERY changed ID.
- Fixes missing updates when viewport is temporarily invisible.
Reviewers: dfelinto, fclem
Differential Revision: https://developer.blender.org/D3028
Main idea is to make specific engine types be a subclass of generic
ObjectEngineData structure.
This required following changes:
- Have extra size argument to engine data allocation function.
Not sure whether there is less error-prone way of doing this.
- Add init() callback to engine data allocation function.
Additionally, added some extra checks to Eevee's engine data getters, so we do
not silently cast lamp data to lightprobe data.
Reviewers: dfelinto, fclem
Differential Revision: https://developer.blender.org/D3027
This was disabled to avoid updating the geometry every time when the
material includes displacement, because there was no way to distinguish
between surface shader and displacement updates.
As a solution, we now compute an MD5 hash of the nodes linked to the
displacement socket, and only update the mesh if that changes.
Differential Revision: https://developer.blender.org/D3018
This code was disable a while back and got re-enabled by some previous debug
process. Having relation names in dot file helps understanding what's going
on in one cases, but makes things spread too far away in others.
This does not affect current blender2.8, but is mandatory for asset
engine branch.
Bottom line being, we also need to 'survey' changes in actual
SpaceFileBrowser struct, not only its FileSelectParams sub-struct.
Generic ED_area_do_msg_notify_tag_refresh callback only tags area for
refresh, not redraw. This was not updating view e.g. when changing
ordering options in top region, until you'd mouse-over main filelisting
region...
So now, always tag area for redraw in filbrowser's refresh callback.
When pressing on a button to zoom for eg,
using zoom-to-mouse-position doesn't make any sense.
There is also zoom speed scaling which increases the closer the cursor
is to the top-edge of the screen, which was noticable since the
navigation widget is currently at the top of the screen.
The new depsgraph was only considering the active action
when attaching relations from the AnimData component/operation
to the properties that are affected by the animation data.
As a result, only properties animated by the active action
were working, while those animated by NLA strips did not change
when playing back/scrubbing the timeline.
This commit fixes this introducing a recursive method to properly
visit all NLA strips, and calling DepsRelBuilder::build_animdata_curves_targets()
on each of those strips.
- Rename eViewOpsOrbit to eViewOpsFlag
since VIEWOPS_ORBIT_DEPTH isn't just used for orbiting.
- Move use_ensure_persp & use_mouse_init into the flag.
- Remove viewops_data_create_ex.
Technically this was not a bug, as this functionality was not meant to
work. (Drivers were already handled though, as they are part of the rig)
It was assumed that there was little value in having this functionality
available, as in most pipelines, animation production only begins after
the rig has been locked down (see bug report comments for more details).
On reflection, in most common situations, there's probably no harm in
doing these rna path fixups. This commit takes advantage of some similar
code I recently put in place in the Grease Pencil branch (for joining GP
objects and their layers).
Important Note for Animators/Riggers/TD's:
Please be aware that after joining armatures, some of the animation may
still need to be redone (due to changes in the transform hierarchies/
transform spaces that the animation is applied in). We do not attempt
to correct for these problems, and it is unlikely that we will in future.
The "Apply Pose as Rest Pose" operator now affects Bendy Bone settings
too, making it possible to use interactive posing tools (e.g. Pose Sculpting
brushes) to get the desired shape for the rest-pose shape of Bendy Bones.
When such posing tools are available, this change makes it easier to get
the desired Bendy Bone shapes, as you are no longer restricted to using
buttons to get the desired effects.
USER_ZBUF_ORBIT -> USER_DEPTH_NAVIGATE
The name didn't make sense since it's used for all view navigation.
Also rename USER_ZBUF_CURSOR -> USER_DEPTH_CURSOR since zbuf
is an internal detail.
- Group initial/previous/current members
Was using terms old/prev/last/orig in confusing way.
- Replace x,y variables with vectors.
- Remove unused members.
When accessing view-port operators from widgets
we need the ability not to use auto-depth or zoom-to-mouse.
Trackball rotation still needs to be supported.
The old algorithm depended on vertex order.
The new one uses a global least squares solution on chains
and cycles of edges where loop slide induces a dependency.
See https://wiki.blender.org/index.php/Dev:Source/Modeling/Bevel
in the "Consistent Widths for Even Bevels" for derivation of
the new algorithm.
There was a check for volume bounces at every surface intersection. That could lead to a volume scattered path being terminated
when passing through a transparent surface. This check was superfluous, as the volume shader evaluation already checks the
number of volume bounces and once it passes the max, volume shaders will not return scatter events any more.
Reviewers: #cycles, brecht
Reviewed By: #cycles, brecht
Subscribers: brecht, #cycles
Tags: #cycles
Maniphest Tasks: T53914
Differential Revision: https://developer.blender.org/D3024
In my tests the previous loop was running in 200 ms. With this change it now runs in 17 ms.
The difference in the end is still not great because the `draw_uvs_lineloop_bmface` function is called for each face and has an ImmBegin and ImmEnd in the function itself
Previously we stored each color channel in a single closure, which was
convenient for sampling a closure and channel together. But this doesn't
work so well for algorithms where we want to render multiple color
channels together.
FFMPEG uses int for the numerator, while Blender uses a short. So in
cases people gave weird exotic framerate values and we cannot reduce
enough the numerator, we'd get totally weird values (even negative frame
rates sometimes!)
Now we add checks for short overflow and approximate as best as possible
in that case (error should not matter unless you have shots of at least
several hundreds of hours ;) ).
In the future we may have siblings to collections (like overrides) that are not
collections. This change make sure tooltips will keep working.
Note: This was originally wrongly committed together with a Collada fix,
re-committing separately now. See bd7060a87f.
I really would prefer if we were to use the dropbox API for this.
That said, we now have some tooltips that work.
I'm using the new draw callback draw API for outliner tooltips.
Reviewers: mont29
Subscribers: venomgfx, mano-wii, Severin
Differential Revision: https://developer.blender.org/D3020
This reverts commit dc2617130b, which disabled
writing of previews for undo. While this uses some memory, re-rendering all
previews is very expensive, especially if for example you have lots of materials
using high-res image textures.
As done by c42fc19a8a - this was needed originally because notifiers were
not working so I had to force tagging.
And for the records, I should have used DEG_TAG_BASE_FLAGS_UPDATE instead of 0.
This is not the issue actually mentioned there. However it is the most serious
one.
Now if the object being dragged was not in a collection linked in the viewlayer
or invisible, we add it to the active collection (or create one if necessary).
This is related to T50967, which is now fully fixed.
We can't have more than one NOTE_SUBTYPE in the same notifier.
This is a partial revert of: cd4d5dcb46. In particular to the part concerning
"Also fixed a missing notifier of the object instancing operator".
Not only this was mixed with the original reason for the commit for no reason,
but it actually introduced a bug. Bad, bad developers ;)
Note: Although this commit is not needed for master, blender2.8 requires it for
the forementioned bug report.
Only do special handling of ob->data pointer in case we are remapping to
a valid (non-NULL) other obdata. Otherwise, handle it as any other
'remapping to NULL' case.
Hopefully not breaking anything else...
Move timer and tip out of button code,
now the only requests a tooltip,
passing a creation callback to run.
Needed for manipulators in 2.8,
also helps de-duplicate logic - since we never want
multiple tool-tips showing at once.
The issue was caused by Cycles allocating ID property in a temporary object
which gets overwritten and thrown away every so often.
Now dependency graph will try to reliably check whether ID properties from
a temp object are to be freed.
The issue here is that we can not duplicate the whole datablock since we
use view layer pointers in depsgraph callbacks.
Maybe this whole chunk of code belongs to somewhere else, or maybe we
can find a smart solution to avoid need of CoW pointers passed to the
evaluation functions.
This fixes lack of viewport update when toggling collection enabled flag.
This is similar to idproperty_reset() defined in layer.c, but it does not
re-alloc property itself.
We should replace idproperty_reset() with IDP_Reset() now.
Make sure scene and view_layer set for depsgraph before running editors
update. This is required since tagging might happen before we created depsgraph.
The issue was caused by some incompatibility of new API which expects ID block
to be specified explicitly, while old code is tagging object's data using
object's ID with OB_RECALC_DATA flag.
We need to switch all areas to give proper ID and everything, but for until
then we'd better stop crashing.
Compared to usual cddm one, ccgdm one was not applying the
ob->derivedDeform deformation to the pbvh generated from the
original mesh geometry, when possible.
We can only support painting from subsurf DM in a limited subset of
cases, others (like multiple subsurf, or topology-modyfying ones,
break mapping to original geometry).
This is not the most ideal fix (ideally, we should always be able to get
a mapping to original geometry from any point in modifiers stack...).
We do not always have that one available, and even without the
isDisabled callback this func is helpful.
Note that this is a bot stupid, only modifier actually needing a valid
Scene pointer here is subsurf... :|
It is possible to have animation (or driver) to modify nested datablock, such
as shape key value for example (where animation is on Mesh level, but shape key
is it's own datablock). To deal with such cases we need to create relation
from nested datablock CoW to animaiton/driver operation.
`gpu_texture_try_alloc` invalidates zero-sized textures.
The message in the console is not correct in this case (because it is not due to lack of memory).
Note this comes from the greasepencil-object branch, and are merged to help
preventing future merge conflicts.
Also, I renamed the icons for consistency sake. So when this is merged in 2.8
other areas of the code will need to change.
Icons by Matias Mendiola
This reverts commits:
* f0ef360386 Grease-Pencil: Icons from the grease pencil branch
* 13bf4b3804 Grease-Pencil: Fixup for icons
* fb8c382fa1 Grease Pencil dat files fix
Previously only scalar displacement along the normal was supported,
now displacement can go in any direction. For backwards compatibility,
a Displacement node will be automatically inserted in existing files.
This will make it possible to support vector displacement maps in the
future. It's already possible to use them to some extent, but requires
a manual shader node setup. For tangent space maps the right tangent
may also not be available yet, depends on the map.
Differential Revision: https://developer.blender.org/D3015
This converts object space height to world space displacement, to be
linked to the new vector displacement material output.
Differential Revision: https://developer.blender.org/D3015
The ones I previously commited were done with Inkspace 0.92.2
But apparently this renders some parts of the icons transparent.
For example, the tip of the new grease pencil pencil icon.
This was we can introduce other types of BVH, for example, wider ones, without
causing too much mess around boolean flags.
Thoughs:
- Ideally device info should probably return bitflag of what BVH types it
supports.
It is possible to implement based on simple logic in device/ and mesh.cpp,
rest of the changes will stay the same.
- Not happy with workarounds in util_debug and duplicated enum in kernel.
Maybe enbum should be stores in kernel, but then it's kind of weird to include
kernel types from utils. Soudns some cyclkic dependency.
Reviewers: brecht, maxim_d33
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3011
This was originally a good idea. However we will need to pay special attention
to this when doing the dynamic overrides anyways. The placeholders won't be
enough to spare us that job.
That said I left the ones on layer.c because we are actually calling these
BKE_override_*_add() functions from doversion, yet they don't do anything.
This was fixed in master with commit 9d873fc3de. However, this fix never made it to 2.8.
(The following merge (a96008f3aa) did not import the fixes.)
Note: This fix is ment to fix the alignment problem.
I don't know if other parts of the code not merged are interesting or not.
But if they are, they should be tackled separately.
Reviewers: dfelinto
Subscribers: venomgfx, dfelinto, raa, Severin
Differential Revision: https://developer.blender.org/D3014
This optimisation only works if no material in the scene require the AO pass.
For this either set the AO distance to 0 or both Cavity and Edges factors to 0.
This double the performance of scenes with very high triangle count.
This is an optimization / cleanup commit.
The use of a global ubo remove lots of uniform lookups and only transfert data when needed.
Lots of renaming for more consistent codestyle.
This would lead to sock.default_value pointing to the wrong data type,
possibly causing crashes. Unfortunately, this bug will still exist for
older Blender versions that try to load newer files, which makes
changing the type of a node socket problematic.
This was introduced to the outliner when we had no User Preference
window back in 2.5x. Right now it makes no sense to keep this around.
But how about addon user preferences:
* They belong in the user preference window under the addon.
How about the user preferences themselves:
* You find them in the user preference window.
And templates?
* Why are they here in the first place?
After talking to Pablo Vazquez (who in turn poked Sergey Sharybin) we found
it reasonable to get rid of this. If it turns out that we were wrong we
revert this.
As for leaving this exposed as a debug option (as suggested on IRC) I would say
no, please. This end up polluting the code and never cleaned up in the end.
(this was specific talking about templates).
Technical note: I left the functions in outliner still hanging around.
While I used UNUSED_FUNCTION for one of them, for the other one I had to use:
`#if 0` because the function was calling itself, which would fail to build if
I used UNUSED_FUNCTION.
Debug flags are to be controlling render behavior, nothing to do with low level
system utilities.
it was simple to hack, but logically is wrong. Lets do things where they are
supposed to be done!
We have different ways of explore the scene objects, namely View Layer and
Collections. This change let us focus on compositing elements only such as:
* View Layers
** Collections
** Render Passes
* Freestyle
* Grease Pencil?
Not included in this commit is an option to handle filtering of
collections passes, ... Not sure if we would like, though.
Since they are all properly nested under a "Collections" / "Passes"
parent.
User notes:
The outliner so far was a great system to handle the object oriented workflow
we had in Blender prior to 2.8. However with the introduction of collections
the bloated ammount of data we were exposed at a given time was eventually
getting on the way of fully utilizing the outliner to manage collections and
their objects.
We hope that with this filtering system the user can put together the outliner
with whichever options he or she seem fit for a given task.
Features:
* Collection filter: In case users are only focused on objects.
* Object filter: Allow users to focus on collections only.
* (Object) content filter: Modifiers, mesh, contrainst, materials, ...
* (Object) children filter: Hide object children [1].
* Object State (visible, active, selected).
* Compact header: hide search options under a search toggle.
* Preserve scrolling position before/after filtering [2].
[1] - Note we still need to be able to tell if a children of an object is in a
collection, or if the parent object is the only one in the collection.
This in fact was one of the first motivations for this patch. But it is to
be addressed separately now that we can at least hide children away.
[2] - We look at the top-most collection in the outliner, and try to find it again
after the filtering and make sure it is in the same position as before.
This works nice now. But to work REALLY, REALLY nice we need to also store
the previous filter options to be sure the element we try to keep on top
was valid for both old and new filters. I would rather do this later though
since this smell a lot like feature creeping ;)
Remove no longer needed display options:
* Current Scene (replaced by View Layer/Collections)
* Visible (replaced by filter)
* Selected (same)
* Active (same)
* Same Type (same-ish)
How about All Scenes? I have a patch that will come next to replace the current
behaviour and focus only on compositing. So basically stop showing the objects
and show only view layers, their passes and collections, besides freestyle.
Also, while at this I'm also reorganizing the menu to keep View Layer and
Collections on top.
Developer notes:
* Unlike the per-object filtering, for collections we need to filter at tree
creation time, to prevent duplication of objects in the outliner.
Acknowledgements:
Thanks Pablo Vazquez for helping testing, thinking some design questions
together and pushing this to its final polished state as you see here.
Thanks Sergey Sharybin and Julian Eisel for code review. Julian couldn't do a
final review pass after I addressed his concerns. So blame is on me for any
issue I may be introducing here. Sergey was the author of the "preserve
scrolling position" idea. I'm happy with how it is working, thank you.
Reviewers: sergey, Severin, venomgfx
Subscribers: lichtwerk, duarteframos
Differential Revision: https://developer.blender.org/D2992
Both object level and camera datablock properties animation did not work with
copy on write enabled.
The root of the issue is going to the fact, that all interface elements are
referencing original datablock. For example, View3D has pointer to camera it's
using, and all areas which does access v3d->camera should in fact query for
the evaluated version of that camera, within the current context.
Annoying part of this change is that we now need to pass depsgraph in lots
of places. Which is rather annoying.
Alternative would be to cache evaluated camera in viewport itself, but then
it makes it annoying to keep things in sync.
Not sure if there is nicer solution here.
Reviewers: dfelinto, campbellbarton, mont29
Subscribers: dragoneex
Differential Revision: https://developer.blender.org/D3007
The displacement shared was running before particle data was copied to the
device causing bad memory access when the particle info node was used. Fix
is simply to move particle update before mesh update so the data is
available to displacement shaders.
(Altho this fixes the crash the particle info node is still mostly useless
with displacement for now...)
Drawing hair weights read before the hair array start.
This code could be improved since it currently copy-pastes,
from do_particle_interpolation, but this would need larger changes.
For now just correct existing logic.
Sun is treated as a unit distant disk like in cycles.
Opti: Since computing the diffuse contribution via LTC is the same as not using the Linear Transformation, we can bypass most of the LTC code.
This replaces the sphere analytical diffuse computation as it gives a more pleasing result very close to cycles' AND cheaper.
Lights power have been retweaked to be coherent with cycles (except sun lamp with large radius where cycles has a non-uniform light distribution).
This is an improvement on the old spining quad method that was giving artifacts when the reflection ray was nearly aligned with the sphere center.
This might be a bit heavier but it's worth it.
This operator not only links a collection, but it creates a new one and then it
links it. Although the preferrable method for users to handle their collections
is when viewing the "Collections", let's explore this workflow for now.
Suggested by Pablo Vazquez, thank you.
Headers should not have operators as much as possible. The exception here is
for datablocks mode when you want to see the active keyset.
Edit menus on the other hand should be clearly distinct from the RMB context
menus. Edit menu options should be only the ones that apply to the entire
outliner, regardless of the selected element.
Context (rmb) menus should be related to the element you RMB on to invoke the
menu. I'm also taking this opportunity to start bringing the context menus
to Python. There is little reason not to, and it helps editing them (In this
case I'm doing it only for the Scene Collection one).
Solves these security issues from T52924:
CVE-2017-12102
CVE-2017-12103
CVE-2017-12104
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
Solves these security issues from T52924:
CVE-2017-12081
CVE-2017-12082
CVE-2017-12086
CVE-2017-12099
CVE-2017-12100
CVE-2017-12101
CVE-2017-12105
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
One thing i'm not fully happy with is all this is_same_* functions. Need to
get rid of this by probably adding explicit entry/init/whatever nodes and
maybe making node criteria aware of whether key will be used as "from" or
as "to" node.
This leads to a ~3ms improvement of CPU time during drawing.
This prevent the rendering from being stalled waiting for the texture data to be transfered.
This is because certain part of the engine may require a blank framebuffer to bind textures to.
This is the case when using only array textures, unsupported by DRW_framebuffer_init().
By adding the ANIMFILTER_NODUPLIS flag to the filter it'll only be
processing each F-Curve once, which means we can remove while iterating.
This also solves a potential issue when a datablock has a driver and is
shared among multiple objects.
The issue was happening because dependency graph did not inform particle
settings as modified. This is a regression caused by tagging and flushing
mechanism refactor.
The real fix would be to make particle settings to use ID level recalc flags
rather than own flags, which will also simplify relations around particle system,
and particle settings evaluation.
Reported by Mai in IRC.
Now hashed alpha materials are stable when moving the camera/not using TAA.
It also converge to a noise free image when using TAA. No more numerical imprecision.
There still can be situations with multiple overlapping transparent surfaces that can lead to residual noise.
Using GL_RG16I texture for the hit coordinates increase tremendously the precision of the hit.
The sign of the integer is used to 2 flags (has_hit and is_planar).
We do not store the depth and retrieve it from the depth buffer (increasing bandwith by +8bit/px).
The PDF is stored into another GL_R16F texture.
We remove the raycount for simplicity and to reduce compilation time (less branching in refraction shader).
Instead of creating non temp textures only at framebuffer creation, we create them and bind them if their pointer is NULL.
This should simplify the framebuffers creation code.
Now when you make an override of a linked armature, code will
automatically also override objects using that armature (deformed by, or
children of), trying to replicate make_proxy results.
Also some initial code to replicate 'make_proxy' in case of instantiated
linked groups, but that is not working yet (and will also require some
work in RNA part of group's objects collection anyway).
This simplifies remapping task, since you don't have to ensure your
overrides are created in the correct dependency order.
Uses famous LIB_TAG_DOIT to mark IDs to be overridden.
An index stored in Alembic wasn't used. Often this index is a no-op
(i.e. index[n] = n), in which case the result was fine. However, when it
isn't, it caused issues.
Before we were re-using newid pointer inside of ID structure where we were
storing pointer to an original datablock.
It seems there is no way we can avoid requirement of having pointer to an
original datablock, so let's stop obusing system which was only designed to
be a runtime only thingie. Will be more safe this way, without need to worry
about using any API which modifies newid.
There was a fake cyclic dependency happening when node of node tree is driving
another node of the same tree.
This is related to T53794, but more fixes is needed here.
Collection A [disabled]
-> Collection B
-> Collection C
-> object
Object should be invisible, but it is not. Reported by Antonio Vazquez.
Bug introduced on: 1f5106de61
How to reproduce it:
* Change Outliner from Active View Layer to Collections
* Create a new collection under Master Collection (Collection 2)
* Move all three objects from Collection 1 to Collection 2
* Move all three objects from Collection 2 to Collection 1
Bug introduced on fb4cd136a7 (multi-object drag-and-drop).
How to reproduce the bug:
* Create a new collection
* Move the Cube to the new collection
* Move the Camera to the new collection (Cube disappears)
* Move the Lamp to the new collection (Camera disappears)
Explanation of the bug:
The moved object was still selected, so we were trying to add the object to the
collection were the object was already inserted (which would fail silently) and
then remove it.
The reason for the crash is still a bit confusing, but on Windows with Intel HD Graphics 4000 it always happens when you enable `Use Nodes` or when you try to connect the Pricipled Shader node to the output without the `Subsurface Scattering` and `Subsurface Translucency` options enabled.
This patch fixes a 32-bit overflow that occurs on 64-bit systems due to a numeric literal being treated as 32-bit.
This patch allows for the generation of images that occupy more than 4GB of RAM, which previously caused a crash.
Reviewers: sergey
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D2975
Brushes themselves are still affected by the mask, but the viewport is not
showing the mask. This way it's easier to see details while sculpting.
Studio request by Julien Kaspar
Adds the code to get screen size of a point in world space, which is
used for subdividing geometry to the correct level. The approximate
method of treating the point as if it were directly in front of the
camera is used, as panoramic projections can become very distorted
near the edges of an image. This should be fine for most uses.
There is also no support yet for offscreen dicing scale, though
panorama cameras are often used for rendering 360° renders anyway.
Fixes T49254.
Differential Revision: https://developer.blender.org/D2468
There is even a chance the compilers handles this itself, but we should try to
use the internal storage as much as possible (and save 0.000001s in the process)
For experimental options, outside the scope of typical preferences.
While templates are developed we might want to make changes
to behavior which aren't fully compatible with typical work-flows.
Instead of mixing these options in with current preferences
expose separately (we could even force disable them when templates
aren't int use)
This can be enabled in the Film panel, with an option to control the
transmisison roughness below which glass becomes transparent.
Differential Revision: https://developer.blender.org/D2904
The offscreen dicing scale helps to significantly reduce memory usage,
by reducing the dicing rate for objects the further they are outside of
the camera view.
The dicing camera can be specified now, to keep the geometry fixed and
avoid crawling artifacts in animation. It is also useful for debugging,
to see the tesselation from a different camera location.
Differential Revision: https://developer.blender.org/D2891
The code for vertical line was assuming that we necessarily neeeded vertical
lines for all the elements. Which is not true since we are not drawing
vertical and horizontal lines for collections.
Patch made in contribution with Philippe Schmid (@Quetzal).
Use the libraries if they exist in ../lib/linux_x86_64 or similar, so
that you can run "make deps && make full" to get a full static build.
Note that install_deps.sh is still the only officially supported way to
build Blender dependencies on Linux, but this may be useful to some.
Differential Revision: https://developer.blender.org/D2980
Was due to the fact that the instances don't have a "static" obmat that can be referenced to use as a uniform.
Solution : precompute the full matrix for each bone and pass it as instance data. (theses are copied into a buffer and can be discarded right away)
Note: this could be optimized further and make only one drawcall (shgroup) to draw all bone instance of one type (vs. one call per armature).
Remove the critical OMP sections used to protect mem allocation.
First one can be done in a separate loop before main, parallelized one.
Second one only affect 'private' data, so we only need to ensure
guardedalloc thread safety is enabled.
This is committed as separated step to ease troubleshooting in case
bisecting becomes necesary.
Tests on my system with ~1200 objects with 128 shadow casting lamps (current max) show a significant perf improvment (cache timing : 22ms -> 9ms)
With a baseline with no shadow casting light at 6ms this give a reduction of the overhead from 16ms to 3ms.
This remove pretty much all allocations during the cache phase. Leading to a big improvement for scene with a large number of lights & shadowcasters.
The lamps storage has been replace by a union to remove the need to free/allocate everyframe (also reducing memory fragmentation).
We replaced the linked list system used to track shadow casters by a huge bitflag.
We gather the lights shadows bounds as well as the shadow casters AABB during the cache populate phase and put them in big arrays cache friendly.
Then in the cache finish phase, it's easier to iterate over the lamps shadow SphereBounds and test for intersection.
We use a double buffer system for the shadow casters arrays to detect deleted shadow casters.
Unfortunatly, it seems that deleting an object trigger an update for all other objects (thus tagging most shadow casting lamps to update), defeating the purpose of this tracking.
This needs further investigation.
Gives about 40% speedup of object which has simple-ish deformation applied
on top of subdivided mesh.
This might easily happen with single character animation.
Helps in cases of not very complex scenes and lots of system threads available.
A bit hard to measure change on it's own, it works best with the upcoming
changes and gives measurable improvements.
Mutex is now local to particular CCGDM, and guarding edge hash which is only
used by a single function only. There is no need to acquire read lock after
edge hash was created.
Unfortunately, we cannot perform set/unset checks on 'resolved'
properties (i.e. from actual IDProperties pointers, and not virtual RNA
placeholders)... IDProps in RNA are rather challenging topic. :|
This should fully fix T53715: 2.8: Removing keymap items no longer works
With factory settings, steps to reproduce were:
* Select "Collection 1" (in "RenderLayer")
* Delete
It might crash at this point, although maybe this crash is ASAN only.
However, this was also doing some weird things that I've corrected now. It
called outliner_build_tree in an operator callback. This should only be
called in the main redraw function or so, not in regular handlers.
Instead, we manually cleanup the tree to keep it valid.
This is quite common to have 64GB memory now, and even 128. There is no reason
to add any artificial caps on the cache and undo memory here. We can not protect
against using too much memory in one cases and allow use of full computer
potential in others.
Now 32 bit will use 2GB max (as it used to be), but 64bit will use whatever
number of megabytes fits into integer.
Reviewers: campbellbarton, mont29
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D2972
This reverts change to BKE_brush_add,
callers now remove the extra user.
Note this isn't very convenient for callers but
is consistent with other ID types.
In the future we will probably remove this and have new
ID's created with zero users.
When using a tablet, detecting absolute motion only worked
when activating a tool with the tablet.
Pressing Enter to run a tool for e.g. would use relative motion.
Now store is_motion_absolute in the event,
set for new events based on the most recent motion events.
The idea is to support following: allow doing parallel for on a small range,
each iteration of which takes lots of compute power, but limit such range to
a subset of threads.
For example, on a machine with 44 threads we can occupy 4 threads to handle
range of 64 elements, 16 elements per thread, where each block of 16 elements
is very complex to compute.
The idea should be to use this setting instead of global use_threading flag,
which is only based on size of array. Proper use of the new flag will improve
threadability.
This commit only contains internal task scheduler changes, this setting is not
used yet by any areas.
Now all the fine-tuning is happening using parallel range settings structure,
which avoid passing long lists of arguments, allows extend fine-tuning further,
avoid having lots of various functions which basically does the same thing.
Still not fully working, more work TODO (IDProps are rather tedious to
handle in RNA... :/ ).
Partial fix of T53715: 2.8: Removing keymap items no longer works.
Some shortcuts can now be edited/deleted again, but some remain
mysteriously frozen!
This modify the selection code quite a bit but it's for the better.
When using selection we use the same batching / instancing process but we draw each element at a time using a an offset to the first element we want to draw and by drawing only one element.
This result much less memory allocation and better draw time.
This is a special memory manager that keeps memory blocks ready to send as vbo data.
Since we loose which memory block was used each DRWShadingGroup we need to redistribute them in the same order/size to avoid to realloc each frame.
This is why DRWInstanceDatas are sorted in a list for each different data size.
This a small cleanup of something which I think is just a typo anyway.
With all the recent talks of harrassment and groping, I think we better avoid
that within our source code! :)
Reviewers: sergey
Reviewed By: sergey
Tags: #motion_tracking
Differential Revision: https://developer.blender.org/D2979
We now can drag multiple objects at once in the outliner. You we restricted to
working within a single outliner. Be sure to drag from the objects name, not
from its icon (otherwise it will try to parent it).
We don't use the same drag'n'drop system as IDs here. Which although I dislike
allowed for this solution to be local, and not dependent on the entire
drag'n'drop system of Blender.
This is a feature Andy Goralczyk has requested a long time ago.
Kudos for him for his request.
This technically reverts 176698b2eb.
Drag and drop for scene collections requires id for its poll function. However
we were passing the collection as id pointer for outliner_add_element
(which is ok since the function doesn't require a real ID).
I couldn't reproduce the original issue tackled by the forementioned commit so
I'm going ahead and bringing drag and drop back for scene collections.
Note: We already pass the ID for view layer collections as well since we brought
collections into groups.
This is a partial revert of 1f5106de61.
First and firemost, for groups I was checking the wrong flag
(soops->flag & SO_GROUPS) instead of (soops->outlinevis == SO_GROUPS).
Second, the columns were entirely broken for things like Orphan Data.
Third, I tried to have different columns for different `outlinevis`, but we have
bones with only visible and select, modifiers with visible and render, render
passes with enable and another value ... I would rather stay away from this mess
at the moment, and stick to the more obvious bug fix.
Finally, there is a bug (not addressed here) where the whole line is selected,
regardless of the restriction column area. It should be fixed separately.
Result is less noisy ogl renders.
What this patch does:
- the draw loops gets accumulated into the output buffer.
- disable TXAA persmat jittering in ogl render since ogl render already does that.
- make noise texture update correct accross all draw loops. Previously it was reset between each FSAA samples.
- Hashed Alpha materials were outputing their alpha values even if the final pixel has no blending and thus no transparency.
- Opacity was not clamped when using "add closure" nodes.
We need to remove all transform to display during rendering for this to work. The float rect is then color managed when displayed.
This makes all interface colors wrongly displayed because they should be color managed when rendering.
This fixes any function that relied on these iterators such as:
* Outliner Same Type
* Metaballs
* scene.objects
We were not considering the collections when there was collections nested
to the collections nested to the master collection.
It includes a unittest.
Adding new context modes requires adding a string in CTX_data_mode_string,
but there is no error when omitting this other than panels using
incorrect contexts. The static assert should help detect simple
missing strings at least to avoid confusing errors.
In that case it can now fall back to CPU memory, at the cost of reduced
performance. For scenes that fit in GPU memory, this commit should not
cause any noticeable slowdowns.
We don't use all physical system RAM, since that can cause OS instability.
We leave at least half of system RAM or 4GB to other software, whichever
is smaller.
For image textures in host memory, performance was maybe 20-30% slower
in our tests (although this is highly hardware and scene dependent). Once
other type of data doesn't fit on the GPU, performance can be e.g. 10x
slower, and at that point it's probably better to just render on the CPU.
Differential Revision: https://developer.blender.org/D2056
This is part of T53495.
This makes sure the master collection is always expanded and you don't even get
the expand/collapse icons for it.
This is only for the Collecions (currently Master Collection Tree) option, not
for active view layer.
This is part of T53495.
This operator is actually using existing code. The only new thing about it is
that it has a shortcut.
It will be exposed in the UI soon together with the nested collection operator.
This is part of T53495.
This operator is intended for the outliner when viewing Collections (at the moment, Master Collection Tree).
It has a shortcut "C", and will be added to a menu shortly.
Technically this was introduced in 01b547f993 when
exposing size and randomness for particles.
This "fixes" makes sure particle size and size randomness is always in the
Render panel when it affects the particle system (i.e., always unless using
advanced hair or hair that is not rendering groups/objects).
Fix T52977: Parent bone name disappeared in the UI in pose mode.
Regression caused by own rBc57636f060018. So instead of changing widget
type, just flag it as disabled.
Note that core of the issue is elsewhere though - there is absolutely no
reasons to have a search widget for pointers we cannot change nor
search! But fixing this is not really top priority, one of the many
glitches of our UI code, so think we can live with current code.
To be backported to 2.79a.
This allows users to have "Support", "Rig", "Characters" collections nested to
different collections without having to resort to "House.Rig", "House.Characters"
or "Rig.001", "Characters.003" :/
This is part of T53495.
This fixes renaming the view layer via Python.
This bug was introduced originally in 3a95bdfc65. Although I suspect it was
around for longer, since this commit didn't touch this part of the code.
But basically we need the id of the RNA property to be the one that owns
the data (view layer).
This fixes renaming via the interface.
This bug was introduced originally in 9515737b55. We need the id of the RNA
property to be the one that owns the data (view layer).
So it can't be the window's id, but the scene one instead.
We were bumping user count when duplicating viewlayer and its freestyleconfig
depending on the flag, however when freeing we were always decreasing user
count.
This fixes this and get rid of the assert when running:
`--factory-startup --enable-copy-on-write`
And closing Blender.
SVM nodes need to read all data to get the right offset for the following node.
This is quite weak, a more generic solution would be good in the future.
The mental model is that a scene collection is a small wrap on top of the master
collection, so all objects are in the master collection at all times.
When we remove a collection there is no reason to remove an object. So if the
object was not linked to any other collection, we add link it to the master one.
We tried to do as much as possible in a single threaded callback, which
lead to using some nasty tricks like fake atomic-based spinlocks to
perform some operations (like float addition, which has no atomic
intrinsics).
While OK with 'standard' low number of working threads (8-16), because
collision were rather rare and implied memory barrier not *that* much
overhead, this performed poorly with more powerful systems reaching the
100 of threads and beyond (like workstations or render farm hardware).
There, both memory barrier overhead and more frequent collisions would
have significant impact on performances.
This was addressed by splitting further the process, we now have three
loops, one over polys, loops and vertices, and we added an intermediate
storage for weighted loop normals. This allows to avoid completely any
atomic operation in body of threaded loops, which should fix scalability
issues. This costs us slightly higher temp memory usage (something like
50Mb per million of polygons on average), but looks like acceptable
tradeoff.
Further more, tests showed that we could gain an additional ~7% of speed
in computing normals of heavy meshes, by also parallelizing the last two
loops (might be 1 or 2% on overall mesh update at best...).
Note that further tweaking in this code should be possible once Sergey
adds the 'minimum batch size' option to threaded foreach API, since very
light loops like the one on loops (mere v3 addition) require much bigger
batches than heavier code (like the one on polys) to keep optimal
performances.
So they are:
House
-> House 1
-> House 2
-> ...
The exception is when the parent collection is the master collection. In this case we get:
Master Collection
-> Collection 1
-> Collection 2
-> ...
This is part of "T53495: View layer and collection editing - Design Task"
This is a bit annoying to have per-DM locking, but it's way better (as in, up to
4 times better) for playback speed when having lots of subsurf objects,
The idea is to avoid any threading overhead when we start pushing tasks in a
loop. Similarly to how we do it from the new dependency graph. Gives couple of
percent of speedup here, but also improves scalability.
I could done a subversion bump, but I found a safe way to avoid it.
It leads a bit of an ugly code, but once we bump the subversion
next time we can clean it up easily.
This allows a duplicator (as known as dupli parent) to be in a visible
collection so its duplicated objects are visible, however while being
invisible for the final render.
An object that is a particle emitter is also considered a duplicator.
Many thanks for the reviewers for the extense feedback.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2966
This statistics is only collected when debug_value is different from 0.
Stored in depsgraph node itself, so we can always have access to average data
and other stats which requires persistent storage. This way we also don't waste
time trying to find stats from a separately stored hash map.
I had to make Eevee draw its scene in the scene pass (before it was doing it
in the background pass). This is not ideal since reference images require
a separation between scene and background.
But it's the best way to solve it now. Clay is working fine.
This is something deliver form node type, there is no reason to try cache it
anywhere, especially since it's not used in any performance critical code.
Lighter weight dependency graph is what we want.
Since in Alembic the loop order seems to be reversed when exporting and
importing, and this was the only place where it was not, I was thinking
to match this to the convention of reversing the loop order as well.
Reviewers: sybren, kevindietrich
Tags: #alembic
Differential Revision: https://developer.blender.org/D2968
Notifier is getting through, yet tree wasn't rebuilding until
we force redraw by resizing the outliner.
Thanks to Danrae Pray (@spockTheGray) for looking at this issue.
Annoyingly, need to convert vfont to nurbs, do minmax and toss nurbs away.
This is likely to be fine, since this function is not intended to be used
a lot, and this is the only way to get more meaningful result.
However, it's not very clear what to do with font on curve.
This fixes rendering of font object with auto texture space in Cycles
introduced in c34f3c7.
It is probably possible to introduce new mode to vfont_to_curve which
will do boundbox without extra allocations, but that's more like an
optimization.
Reviewers: campbellbarton, mano-wii
Reviewed By: campbellbarton
Subscribers: zeauro
Differential Revision: https://developer.blender.org/D2971
We can not store pointers to elements of collection property in the
case we modify that collection. This is like storing pointers to
elements of array before calling realloc().
There is still a crash that you get because the draw manager needs to
handle duplis differently.
But the initial assert caused by this particular file is now fixed.
The goal is: have id->recalc flags set to components which got changed.
To make it possible for render engines to check on a more granular basis
what changed in the object. For example, is it a transform which changed
or is it just some ID property changed which has nothing to do with rendering.
The tricky part is: we don't want duplicated logic in tagging and flushing.
In order to avoid this duplication, we store ID recalc flag in the component
node type information. That type information could easily be accessed by both
tagging and flushing routines.
Remaining part of the changes are related on changing the way how tagging
works. The new idea here is to have utility function which maps update tag to
a component. This way we can easily set ID recalc flags right away. Without
any duplication of ID recalc flags set in multiple flag handler functions.
With all this being said, there should be no user measurable difference for
now, it's a gigantic basement for some upcoming work and fixes.
The issue actually goes a bit deeper, converting curve to mesh will
change texture space just because font and bezier curves are using CV
to calculate texture space.
So now when those objects are converted to mesh, we disable auto
texture space and copy evaluated space over.
Original fix was assuming that particle init operation is updated on every
frame, which is wrong behavior and that was fixed in previous commit to the
original bugfix.
- Highlight's were too intense/distracting
use more subtle alpha (consistent with the rest of our UI).
- Don't fill center cube (only draw edges).
- Draw widget while interacting since this is helpful in some cases.
Thanks to @jbakker for suggestions.
Also change axis hotspots so the nearest is always selected
for quicker axis picking (relies on dragging any axis to orbit).
Makes the 3D view navigation widget easier to use: dragging anywhere
in the rotation region now rotates without having to avoid the XYZ axis
hotspots which only activate on a single click.
Logic for drag detection is complicated by manipulators reliance
on keeping the modal operator running.
Currently this is wrapped in an ifdef,
we may want to implement it differently later.
A comparison should have not just have been against an epsilon,
but relative to the edge length involved.
Thanks to mano-wii for patch on which this is based.
The idea is to de-duplicate logic in DEG_id_tag_update() and flushing where we
need to translate depsgraph tag or component type to ID level recalc flag.
Currently unused, but is required for Blender 2.8.
Not only this helps merges form master to the branch, but also:
- Allows us to production-check changes as soon as possible.
- Avoids some unnecessary editors update about ID changes.
- Adds small optimization on queue size by always keeping one of the pointers
outside of the queue.
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.
Now we stick to a single button, when data is directly linked, clicking
on it will make a local copy, while shift-clicking on it will make a
static override.
When data is a static override, icon is the DATA_OVERRIDE one, and clicking
on the button will make it a fully borring local data-block.
This is just the 'linked' icon with top-down arrow instead of left-right
one, if any graphist feels more inspired... ;)
Note that this is 'new inkscape' version of the svg file, hope
everything is alright (it does change all icons whe re-exporting :/ ).
Code also handling auto-generation of static overrides.
Aside from some naming consistency cleanup, this commit:
* Is the first step addressing the 'operator' issue with static
overrides, by implementing a first version of the 'restore from
reference' behavior.
* Fixes several issues that were discovered on the way in enhanced
RNA comparision code, like the 'zero-length dynamic array' case, or some
infinite looping caused by some non-ID pointers (that for some
mysterious reasons did not show up previously...).
* Factorizes a bit said RNA comparison code (auto-static override
generation and comparison/check were essentially doing the same thing).
This flag means that the pointer does not 'own' the data it references.
This is the case of nearly all ID RNA pointers (NodeTrees will probably
again be some nasty exception here :( ), but also several other cases.
That kind of information is mandatory for complex processing over whole
data-blocks done in RNA, like some static override tasks (advanced
comparison...).
We need to tag groups before and after rendering, so the group collections
viewport and render visibility are taken into account.
Note: This is a workaround, that will be removed once the render engine have
its own depsgraph, instead of re-using the viewport depsgraph.
Users can change the group collection visibility in the outliner
when looking at groups.
Regular collections on the other hand don't have any special visibility control,
if you need a collection to be invisible during render, either don't link it
into the view layer used for F12, or disable it.
This includes:
* Updated unittests - update your lib/tests/layers folder.
* Subversion bump - branches be aware of that.
Note:
Although we are using eval_ctx to determine the visibility of a group collection
when rendering, the depsgraph is still using the same depsgraph for the viewport
and the render engine, so at the moment the render visibility is ignored.
Following next is a workaround for this separately to tag the groups before and
after rendering to tackle that.
Currently this is a no-visible-changes change, but the idea is to use this
dedicated flag to tell which exact components of ID changed, make it more
granular than just OBJECT and OBJECT_DATA. Allow setting this field based
on what components new dependency graph flushed on evaluation.
Currently unused, but this is where LIB_TAG_ID_RECALC* flags will go.
Also modified other DNA to make pointer property being followed by pointer.
Makes it easier to keep track of alignment and extend nested structures without
ruining anything.
The possible issue with just listing arguments is that it might not be clear
what particular value is used for. For example, is it a scene itself, or is
it a parent scene?
Not as if it's not very clear now, but better be explicit for the future,
and me reading code in 10 years.
Outliner was using the old selection flag to show selected objects.
So if you selected an object in the outliner it would keep "selected"
(drawn in yellow) even after you selected another object.
New dependency graph is supposed to have relation from animation node to
the node which corresponds to a property which is modified by that curve.
This means it is up to dependency graph to flush recalc flags, and no
manual control is needed in the animation code.
This is a part of ongoing work in Blender 2.8, where we need to replace
`object->id.tag & LIB_TAG_ID_RECALC_DATA`
with
`object->data->id.tag & LIB_TAG_ID_RECALC`
Should be no user measurable difference.
We now select the LayerCollection at index 0 for the active ViewLayer after a
collection deletion operation.
Added some functions to query outliner tree data & get LayerCollection
by index using a similar approach as we do for SceneCollection indexing.
With warning and style cleanups by Dalai Felinto.
Reviewers: dfelinto
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2942
This is something what we would need to ensure anyway, so doesn't seem
to make sense to NOT allocate depsgraph and then worry about this externally.
Steps to reproduce: add cube, change it's size in redo panel.
Found by Campbell during code review session.
Remove unused func from public API.
Make parameters & variables naming more consistent accross the code.
Move RNAproperty validation/'conversion' (for IDProps case) to upper
level in code, this will avoid some useless re-processing.
Previously, hitting Shift-LMB will first invoke selection operator, which
then later on is transformed to mouse tweak used for reroute operator.
This was causing problems extending selection with Shift-LMB when clicking
fast or from a tablet.
When one creates a new local static override from another linked
data-block already overriding a third one etc., walk the whole
inheritance chain up to the original ancestor to try to find an
overriding template, instead of only checking the immediate reference...
Avoid creating new Python instances
every time a scene, object, mesh .. etc are accessed.
Also resolves crashes T28724, T53530
although it's only valid for ID types, not modifiers vertices etc.
Back-ported from blender2.8 branch.
WorkSpaceLayout->screen will be made public soon, but meanwhile this makes it
clear why we are not passing layout->screen to CALLBACK_INVOKE in this case.
We can not store pointer to an object ion temporary variable here, since then
pointer will not be updated in the base itself.
This fixes missing modifiers on objects coming from dupli-group.
Bug introduced on rB9f5bf197a0c3.
The offset for selection of vertices (`bm_vertoffs`) starts where the offset o edges ends (`bm_wireoffs`).
However, the `bm_wireoffs` depends on the offset of face selection (`bm_solidoffs`).
Before the commit that introduced the bug, the drawn of edges (in backbuff) was always computed along with the `bm_wireoffs`:
```
bm_wireoffs = bm_solidoffs + em->bm->totedge;
```
Now that the edges are not always drawn in backbuff, `bm_wireoffs` has to start from `bm_solidoffs`.
It is still based on generic collection evaluation, but the idea is to avoid
having view_layer pointer passed from group to it's evaluation function.
This is essential for copy-on-write, where we need to pass view_layer pointer
from a copied datablock, but that copy is not yet available at construction
time. Also, this is NOT the case where we want to expand datablock at a
construction time, just to keep our life easier.
View Layer was not duplicated between destination and source.
This would lead to a crash if you duplicated the group and assigned
the new group to any object.
Our own implementation was behaving different comparing to OSL and GPU,
namely on the border pixels OSL and CUDA was doing interpolation with
black, but we were clamping coordinate.
This partially fixes issue reported in T53452.
Similar change should also be done for 3D interpolation perhaps, but this
is to be investigated separately.
This only applies to ID being copied outside of bmain. Handy for cases when it
is important to check if the copy corresponds to a data block coming from
library.
Example of that is proxy evaluation with copy on write.
Thanks Bastien for review!
This should solve crash on files having proxies, but there will still be
assert failure because proxy_from is expected to come from library, which
is no longer truth for objects which got copied.
Before that it was up to lots of other places to keep track on whether
something is to be dependent on time or not. Was annoying, and unreliable,
and fragile.
This commit avoids hacks in object builder. Other areas will be adopted
soon.
This is something what should be supported by the new dependency graph.
Fixed by making it so, build_animation() adds relation between Animation
component and whatever-is-being-animated. In fact, for now, only relations to
ID properties are added. Rest of the relations are kind of hacked in all over
the code and needs to be removed and verified with specific .blend files.
We can't use a single component here, sine it might consist of multiple
operations. So, for example, having driver operation will confuse targets
of another driver.
Fill-selection would only go upward in list of items to find an already
selected one and fill-select all items in-between. Now, in case upward
search fails, it will also intent to go downward, effectiviely allowing
to 'fill-select' from bottom to top.
Note that top-to-bottom keeps priority (i.e. if a top-to-bottom
fill-selection is possible, it will always happen, even if a
bottom-to-top one is also possible).
* For the T48988 fix (i.e. separate Ease In/Out properties for Bendy Bones
in Edit vs Pose modes), old animation data needed to be patched to use
the new property names. This is needed to partially fix some of the
issues in T53356 (though the Rigify code itself still needs to be patched).
* For the T52009 fix, old files needed to have the frame_start and frame_end
properties on the FModifier (base-class) updated to match that of the
FMod_Stepped type-specific class. This wasn't done in the earlier commit
since it wasn't worth going through all animation data just for the sake
of updating these relatively-rare settings, but since we're doing it anyway
now, it makes sense to include this here.
Patch from Richard Erhardt, with some additions & modifications.
Changes bevel profile shape parameter so that can get arbitrarily
near square profile as parameter -> 1.
Adds code to make profile=0 case work, at least for cube corners,
so changed hard min of profile parameter to 0 from 0.15.
Currently shouldn't make any difference, but this is something what needs to be
done to sanitize drivers relations )with the idea to re-use some generic code
to get operations for driver variables.
Those are unused, and not clear whether we will ever support this.
Seems to be better having more like "component" tags, would be less magic
involved to guess what exactly is to be tagged.
One or two are OK, but more make it rather unreadable, and future work
is likely to require more toggle specific behavior here. So switched to
bitflags, switching from short to int and using 16 upper bits for
'internal' ones defined in BLO_readfile.h, combined with 'public' ones
from user interaction, defined in DNA_space_types.h
Updated collection_delete_exec() so we don't try to delete elements as we search
the outliner tree anymore.
Now we search the whole tree first for the selected nodes that need to be
deleted and delete them afterward.
Reviewers: dfelinto
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2936
Differential Revision: https://developer.blender.org/D2940
Use dynamically generated message publish/subscribe
so buttons and manipulators update properly.
This resolves common glitches where manipulators weren't updating
as well as the UI when add-ons exposed properties which
hard coded listeners weren't checking for.
Python can also publish/scribe changes via `bpy.msgbus`.
See D2917
This augment the existing irradiance grid with a new visibility precomputation.
We store a small shadowmap for each grid sample so that light does not leak through walls and such.
The visibility parameter are similar to the one used by the Variance Shadow Map for point lights.
Technical details:
We store the visibility in the same texture (array) as the irradiance itself (in order to reduce the number of sampler).
But the irradiance and the visibility are not the same data so we must encode them in order to use the same texture format.
We use RGBA8 normalized texture and encode irradiance as RGBE (shared exponent).
Using RGBE encoding instead of R11_G11_B10 may lead to some lighting changes, but quality seems to be nearly the same in my test cases.
Using full RGBA16/32F maybe a future option but that will require much more memory and reduce the perf significantly.
Visibility moments (VSM) are encoded as 16bits fixed point precision using a special range. This seems to retain enough precision for the needs.
Also interpolation does not seems to be big problem (even though it's incorrect).
Before this patch, if one of the grid was updated (moved) only the subsequents evaluated grids had their level reset and had all their bounces recomputed.
Tests were broken since e8c15e0ed1.
We now get view_layer from window, not workspace, since the same workspace can
have a different view_layer depending on the window scene.
We do not assume subversion bump until we actually change the subversion.
For example, a branch may have bumped its subversion to 3, yet still require
the new doversion code introduced on 108c4bd502.
This way we can inform editors about all edits at once. Currently this is not
used, but in the next commits we will inform editors about what exactly has
changed.
We are using NC_SCENE | ND_LAYER_CONTENT for the shader, however this does not work for groups
unless we manually handle the notifiers.
Otherwise the group id is passed, and the listener never gets the notification since a scene id
is expected, or no id at all.
Allow users to edit either the object group active collection or view layer one
We can't support users selecting the group collections from the outliner group
because that would be imply having an active group for the scene or workspace.
But the way it is now allows to see and edit the collection values after the
group is instanced.
You could still create groups as before, with Ctl + G. This will create a group
with a single visible collection.
However you can also create a group from an existing collection. Just go to
the menu you get in the outliner when clicking in a collection and pick
"Create Group".
Remember to instance the group afterwards, or link it into a new scene or file.
The group and the collection are not kept in sync afterwards. You need to manually
edit the group for further changes.
Since we are ditching layers from Blender (2.8) we need a replacement to
control groups visibility. This commit introduces collections as the building
blocks for groups, allowing users to control visibility as well as overrides
for groups.
Features
========
* Groups now have collections
This way you can change the visibility of a collection inside a group, and add
overrides which are part of the group and are prioritized over other overrides.
* Outliner
Groups can inspect their collections, change visibility, and add/remove members.
To change an override of a group collection, you need to select an instance of
the group, and then you can choose "group" in the collection properties editor
to edit this group active collection instead of the view layer one.
* Dupli groups overrides
We can now have multiple instances of the same group with an original "override"
and different overrides depending on the collection the instanced object is part
of.
Technical
=========
* Layers
We use the same api for groups and scene as much as possible.
Reviewers: sergey (depsgraph), mont29 (read/write and user count)
Differential Revision: https://developer.blender.org/D2892
Instead of storing a single active view-layer in the workspace, one is
stored for each scene the workspace showed before.
With this, some things become possible:
* Multiple windows in the same workspace but showing different scenes.
* Toggling back and forth scene keeps same active view-layer for each scene.
* Activating workspace which didn't show current scene before, the current view-layer is kept.
A necessary evil for this is that accessing view-layer and object mode
from .py can't be done via workspace directly anymore. It has to be done
through the window, so RNA can use the correct scene.
So instead of `workspace.view_layer`, it's `window.view_layer` now (same
with mode) even though it's still workspace data.
Fixes T53432.
It makes more sense to stick to DEG_iterator_object order in name, since we can
have functions to iterate over different entities and we want all of them to
have common prefix.
The idea of this flag was to prevent snapping onto an object which depends on
currently modifying ones. Using single flag makes more sense here, and also
makes it possible to replace some ob->recalc based magic with depsgraph query
to set those flags.
It looks stupid to first force some flag being set and then have workaround
to ignore that flag in snapping code. Let's just not set the flag in the first
place.
The only useful situation where such snapping was usable is to move roots of
disconnected hair, which still works just fine. However, there might be some
other hidden corner case where this workaround was needed.
We should keep base_flags after CoW object datablock was updated. Not entirely
happy with current solution, but it fixes crash and allows us to run tests
again.
More proper solution would be to make CoW operation a per-component thingie,
which will only update corresponding parts.
Previously, the NLM kernels would be launched once per offset with one thread per pixel.
However, with the smaller tile sizes that are now feasible, there wasn't enough work to fully occupy GPUs which results in a significant slowdown.
Therefore, the kernels are now launched in a single call that handles all offsets at once.
This has two downsides: Memory accesses to accumulating buffers are now atomic, and more importantly, the temporary memory now has to be allocated for every shift at once, increasing the required memory.
On the other hand, of course, the smaller tiles significantly reduce the size of the memory.
The main bottleneck right now is the construction of the transformation - there is nothing to be parallelized there, one thread per pixel is the maximum.
I tried to parallelize the SVD implementation by storing the matrix in shared memory and launching one block per pixel, but that wasn't really going anywhere.
To make the new code somewhat readable, the handling of rectangular regions was cleaned up a bit and commented, it should be easier to understand what's going on now.
Also, some variables have been renamed to make the difference between buffer width and stride more apparent, in addition to some general style cleanup.
For some blend modes there would be no effect with factor 1.0, even if factor
0.999 would give a very different image. Now the result should have no
discontinuity.
Differential Revision: https://developer.blender.org/D2925
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.
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!
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).
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.
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.
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)
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.
2017-10-07 12:45:21 +03:00
1753 changed files with 98238 additions and 60617 deletions
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.
