There is a chance parts of Blender call BKE_object_workob_calc_parent
with ob->parent objects that are outside the depsgraph.
This we can tackle later since these are corner cases anyways,
and this fix fixes all parenting operators in Blender.
This commit fixes a problem the Spring team were having in the shot files 01_030/050 with
the camera rig, where when you tried grabbing/translating the bones of the camera rig,
they would only keep rotating/scaling instead.
The reason for this is that with the multi-object editing support added into the transform
system, this code would now get run for all the other objects that were being included
in Pose Mode, even if no bones from those armatures were selected. Since no valid translatable
bones were found in those other armatures, the transform mode would get reset upon
encountering one of those other bones.
Scene lights are rendered when
- v3d is not available
- or shading type is other then OB_MATERIAL
- or shading type is OB_MATERIAL and use_scene_light is true
This differential fixes a bug for resetting view (shift+c).
Bug description: When 3D cursor is placed randomly somewhere, and shift+c is pressed,
the cursor is not shown to reset at world center.
Reviewers: sergey, aligorith, brita_
Reviewed By: brita_
Subscribers: brita_
Differential Revision: https://developer.blender.org/D3423
This commit contains the minimum to make clang build/work with blender, asan and ninja build support is forthcoming
Things to note:
1) Builds and runs, and is able to pass all tests (except for the freestyle_stroke_material.blend test which was broken at that time for all platforms by the looks of it)
2) It's slightly faster than msvc when using cycles. (time in seconds, on an i7-3370)
victor_cpu
msvc:3099.51
clang:2796.43
pavillon_barcelona_cpu
msvc:1872.05
clang:1827.72
koro_cpu
msvc:1097.58
clang:1006.51
fishy_cat_cpu
msvc:815.37
clang:722.2
classroom_cpu
msvc:1705.39
clang:1575.43
bmw27_cpu
msvc:552.38
clang:561.53
barbershop_interior_cpu
msvc:2134.93
clang:1922.33
3) clang on windows uses a drop in replacement for the Microsoft cl.exe (takes some of the Microsoft parameters, but not all, and takes some of the clang parameters but not all) and uses ms headers + libraries + linker, so you still need visual studio installed and will use our existing vc14 svn libs.
4) X64 only currently, X86 builds but crashes on startup.
5) Tested with llvm/clang 6.0.0
6) Requires visual studio integration, available at https://github.com/LazyDodo/llvm-vs2017-integration
7) The Microsoft compiler spawns a few copies of cl in parallel to get faster build times, clang doesn't, so the build time is 3-4x slower than with msvc.
8) No openmp support yet. Have not looked at this much, the binary distribution of clang doesn't seem to include it on windows.
9) No ASAN support yet, some of the sanitizers can be made to work, but it was decided to leave support out of this commit.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3304
This is a hacky fix so that animators can use this tool again with autokey enabled
(which they do all the time). The issue here is that the tool writes the new (0)
values to the original data, but insertkey now reads from evaluated data (so that
keying interpolated values works). However, the cleared values do not get re-evaluated
or flushed before insertkey gets to it (via auto keying), meaning that the wrong values
get keyed.
There may be better solutions for this, but for now, this is the simplest fix that
I can get working.
More MessageBus-related silliness to resolve issue with toggling visibility/mute/locking
status of F-Curves/Groups/etc., as well as other things like modifying active keyframe's
values, or changing properties of F-Modifiers.
I've now ended up just whitelisting in the region subscribers all the animation-related
structs in RNA. But still, that may not be enough to deal with potential issues later
with the property sliders (shown per channel, optionally), which can come from anywhere.
(Spring bug)
This patch adds support for IES files, a file format that is commonly used to store the directional intensity distribution of light sources.
The new IES node is supposed to be plugged into the Strength input of the Emission node of the lamp.
Since people generating IES files do not really seem to care about the standard, the parser is flexible enough to accept all test files I have tried.
Some common weirdnesses are distributing values over multiple lines that should go into one line, using commas instead of spaces as delimiters and adding various useless stuff at the end of the file.
The user interface of the node is similar to the script node, the user can either select an internal Text or load a file.
Internally, IES files are handled similar to Image textures: They are stored in slots by the LightManager and each unique IES is assigned to one slot.
The local coordinate system of the lamp is used, so that the direction of the light can be changed. For UI reasons, it's usually best to add an area light,
rotate it and then change its type, since especially the point light does not immediately show its local coordinate system in the viewport.
Reviewers: #cycles, dingto, sergey, brecht
Reviewed By: #cycles, dingto, brecht
Subscribers: OgDEV, crazyrobinhood, secundar, cardboard, pisuke, intrah, swerner, micah_denn, harvester, gottfried, disnel, campbellbarton, duarteframos, Lapineige, brecht, juicyfruit, dingto, marek, rickyblender, bliblubli, lockal, sergey
Differential Revision: https://developer.blender.org/D1543
If the object is manifold and the camera is in the shadow side, we can
use the depth fail method to fix the inverted shadow glitch.
Unfortunately this does not really work for non-manifold.
Implementation details:
We try to be as efficient as we can, we precompute camera near plane
projected into 2D shadow space so we can test for intersection with the
shadow boundbox easily.
As the intersection test is done in 2D it's pretty fast.
Unfortunately, this means the shadow bounds are all aligned to the same
space and are not the smallest bound we could extract.
This new API aim to provide simple function that can be called by the draw
engines during any phase of the draw pipeline. All calls are saved and
issued after all engines have finished rendering.
This removes the need of setuping special passes and shading groups for some
simple debug drawing.
ninja is an alternative to msbuild designed for fast rebuilds. However there is no IDE support, builds only from the command line.
Comparison between msbuild and ninja for a full build, build time in seconds.
Full Clean Build
msbuild 867.5
Ninja 801.2
Difference -66.3 (-7.6%)
Minor Change
msbuild 43.0
Ninja 14.9
Difference -28.1 (-64.4%)
No Changes
msbuild 23.0
Ninja 6.1
Difference -16.9 (-73.5%)
make.bat was starting to become hard to maintain, this refactors it into separate batch files for each stage of the process.
-Improved detection of msvc2013/2015
-Improved failure handling.
-Added check for working msbuild and C++ compiler
-Added verbose switch to ease trouble shooting.
-Added Check if svn/cmake/git are in the path before using them
-Display the build configuration before asking to download the libraries
-Offer an option to recover an interrupted checkout of the libraries.
-Automatically check out sub-modules in-case they are missing.
The problem was that the particle system modifier was reading ob->derivedDeform
during modifier stack evaluation. Due to the mesh -> DM conversion this was no
longer set leading to wrong results.
In fact we don't really need the deformed mesh, just the original mesh topology
for face/poly index remapping. So the solution is to use that instead.
This commit adds number formatting (thousands separator) to the baking panel. It also adds a new function to format memory sizes (KB/GB/etc) and applies it to the baking panel and scene stats. The new function is unit tested.
Reviewers: Severin
Tags: #user_interface
Differential Revision: https://developer.blender.org/D1248
The registry hack we were using wasn't very reliable, the recommended way to locating visual studio is using vswhere (15.2 and up), using it also allows to switch between the regular and pre-release versions.
Just as with my earlier fix for bones (0492e56fec),
here we're reading evaluated object values into the "i" versions of each transform
property, and using the original/non-evaluated data for the pointers.
XXX:
What's not clear though is what we should be doing with the "BKE_object_where_is_calc()"
calls here. They currently use ob, but that probably shouldn't happen... and ob_eval
should in theory have a more up-to-date version of what it would need to evaluate!
* Added BKE_object_get_evaluated_mesh, which can also be used outside of
Modifier context.
* BKE_modifier_get_evaluated_mesh_from_object is now a dummy wrapper
around BKE_object_get_evaluated_mesh, we do not need anything special
anymore for RENDER quality option, since this is supposed to be handled
at depsgraph level... Maybe we can get rid of it at some point, but kind
of like the idea of keeping it for now, sounds more consitent.
* Always use BKE_id_new, unless you have a very good reason to use
lower-level code!
* Prefer to pass actual ID user pointer to functions like id_us_plus & co,
rather than 'floating' ID pointer, when possible. It makes it more clear
who is the user we increase count for!
Don't store pointers to ViewLayer in the workspace, only names. Add specific
relation type since the generic mechanism makes the code hard to follow.
Integrate with pointer restore for undo and library remapping code to avoid
data going out of sync.
Also add relation automatically if there doesn't exists one yet in
BKE_workspace_view_layer_get, because in general it's really hard to ensure
it will exist when making arbitrary scene changes.
Differential Revision: https://developer.blender.org/D3432
This caused a glitch with COW, where forcing edge selection
caused the evaluated scene to enable this afterwards.
Now pass the selection mode as an argument to the draw function.
Note from revisor: Edit the error message to match the original one.
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3351
These needed to be using the COW evaluated data, instead of the raw bone
positions.
All other datatypes still need converting to work with this though.
The GPU kernel needs to use atomics for accumulation since all offsets are processed in
parallel, but on CPUs that's not the case, so we can disable them there for a considerable speedup.
This commit adds a new menu entry - "Edit Driver" - the RMB menu that
will show a popover panel displaying the settings for the driver you
activated the menu item on. This shows the popover panel defined in
yesterday's commit (GRAPH_PT_drivers_popover).
It is possible to edit the driver settings from this panel now.
However, do be warned that the functionality presented is highly
WIP still. There are some unresolved issues, such as:
- The popover disappears too easily on any mouse movements/clicks
on anything, making the panel less useful right now than it should.
- The layout still needs refining. Currently the layout that's there
is a bit of a placeholder until we can play around with it a bit
more to see/feel what feels good/right or what is too much.
- The "Open Drivers Editor" on the bottom of the panel doesn't work.
There are some tricky context tricky things that need to happen here
to make that case work, since the operator button won't have the necessary
context info.
The Math node currently has the normal atan() function, but for
actual angles this is fairly useless without additional nodes to handle the signs.
Since the node has two inputs anyways, it only makes sense to add an arctan2 option.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D3430
The implementation is pretty straightforward.
In Cycles, sampling the shapes is currently done w.r.t. area instead of solid angle.
There is a paper on solid angle sampling for disks [1], but the described algorithm is based on
simply sampling the enclosing square and rejecting samples outside of the disk, which is not exactly
great for Cycles' RNG (we'd need to setup a LCG for the repeated sampling) and for GPU divergence.
Even worse, the algorithm is only defined for disks. For ellipses, the basic idea still works, but a
way to analytically calculate the solid angle is required. This is technically possible [2], but the
calculation is extremely complex and still requires a lookup table for the Heuman Lambda function.
Therefore, I've decided to not implement that for now, we could still look into it later on.
In Eevee, the code uses the existing ltc_evaluate_disk to implement the lighting calculations.
[1]: "Solid Angle Sampling of Disk and Cylinder Lights"
[2]: "Analytical solution for the solid angle subtended at any point by an ellipse via a point source radiation vector potential"
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D3171
This fix applying the following modifiers:
* Boolean (working already)
* Array
* Mesh Deform
* Surface Deform
* Vertex Weight Proximity
This function was to return evaluated mesh. So it should get the evaluated
object at all times. So in this case it makes more sense to simply pass the
depsgraph (or in this case the ModifierEvalContext that contains both the
depsgraph and the flag.
Solution discussed with Bastien Montagne.
- Adjusted order and names for better consistency.
- Group add/edit/delete into menu sections.
- Move UV/Vertex color into 'Face Data' menu, matching 'Edge Data'.
- De-duplicate items between vertex/edge/face menu.
- Remove undo/redo menu (to be moved into 'Edit' menu).
- Remove Auto-Merge & Proportional Editing
(already available from the 3D view).
Patch from @billreynish w/ edits
Was breaking static override chaining (static override of a linked
datablock that is already a static override in it original lib file).
Dummy mistake, thanks to @dfelinto for finding the bug.
574c0fe38f caused complications
restoring the cursor.
Use WM_cursor_modal_set/restore which is intended for operator use,
calling ED_region_cursor_set after an operator runs isn't reliable.
Fixes bug with changes to properties not being flushed to the COW data.
It fixes T55144.
This is the part of rBb4b745b72064 that is required although slow.
Which was partially addressed but the rest of the commit, which in
turn broke things. So for now let's get RNA to flush slow cow, and
deal with the consequences.
affects one item
UI editing multiple selected items missed the case of PROP_POINTER
properties
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3373
Some conversion helper functions were (most likely by accident) contained
inside an ifdef for SSE2 support, so on e.g. ARM they would be undefined
and therefore cause compilation to fail.
* Add horizontal bar at bottom of all non-temp windows, similar to the Top-bar.
* Status-bar is hidden in UI-less fullscreen mode
* Current contents are preliminary and based on T54861:
** Left: Current file-path if needed. "(Modified)" note if file was changed.
** Center: Scene statistics (like in 2.7 Info Editor).
** Right: Progress-bars and reports
* Internally managed as own "STATUSBAR" editor-type (hidden in UI).
* Like with the Top-bar, Status-bar data and SDNA writing is disabled.
* Most changes in low-level screen/area code are to support layout bounds that differ from window bounds.
Design task: T54861
Main changes approved by @brecht.
This reverts commit b4b745b720.
This was causing a problem in 01_025_A.anim.blend from the Spring
production files, where selecting one of Autumn's bones would
result in character jumping back to the origin.
Note the relationship we need is from the geometry/object to the curve data,
not the curve object.
Related to T55167, though when copy-on-write is enabled, we still get a crash.
Otherwise, it's not clear where things are coming from.
FIXME: The icons for datablocks may not always be correct. It uses the
innermost struct's icon instead of the datablock's icon - e.g. Bone
vs Object/Armature. But, that may make more sense for users?
The idea is that we may be able to just take this code and put it into a
new popover panel that gets displayed when called from the UI. This should
at least work well for a first pass test of what we want this UI to look like.
In theory, this should mean that we can get rid of the "Update Dependencies"
button. In practice, there may still be cases where it's still needed
(as somehow, it did end up being needed in the past, even though the RNA
calls should in theory be doing everything needed already).
There are multiple other ways to do it. Leaving this here just made it
easy (and dangerous) to accidentally remove the driver, and was causing
other problems with other layouts.
* Remove "Show Debug Info" option. Everyone has it turned on all the time,
since it's just useful to have
* Make the "Remove Driver" button less prominent. It doesn't happen that much,
so it shouldn't take up as much room
* Make "expressions" textbox wider (i.e. taking up the whole column width)
by separating the label and textbox on separate lines.
* Rename "Add Variable" button to make it clearer to users what "variables"
may be (i.e. they serve as a way to specify Inputs, just like adding a
"Source Data" node in a nodetree)
* Regroup buttons
This is intended to help developers to know how and when to use each shader.
There are plenty of undocumented shaders, but it's a matter of filling them in.
The script I used to quickly find the related shaders for a const is: P700
Original patch: D2318
Unmultiplied the final color during compositing. Same as the revealage
buffer would do
Also use the DRW_STATE_ADDITION_FULL as it is aware of premultiplied
colors
The modifier is still quite slow; this could be due to caches being written
to a CoW datablock instead of the original one. More investigation is
needed.
Logic here was a bit broken.
1) We need to send updates even when deselecting bones, not only when we
actually end up select then.
2) Also, when bones are locked for "selectability", they should not be able
to be deselected.
To bring the UI more in line with the proposed design in T54653 for the "Add Drivers"
popup panel (NOTE: this is separate from the "Drivers Editor", in previous commit!),
this commit adds a new panel - "Driven Property" to the Drivers Editor UI.
This basically duplicates the "Active F-Curve" panel (with less options)
to make it easier to see at a glance which property the Drivers Editor is
showing you.
This commit adds an operator, "Show Drivers Editor", to the RMB menu when
clicking on properties.
As per T54653, this will open a new Graph Editor instance in a new/separate
window (much like how the User Preferences show up in a popup window now),
and will configure all the relevant panels so that you can see and edit the
driver settings immediately without doing a lot of the view configuration steps
that were previously needed.
When doing so on a property that is driven, the driver/fcurve for that property
will be made active in the editor, ready for you to start editing its settings
without having to hunt it down again first.
Allows more than one snap mode to be enabled. So different combinations are possible.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Subscribers: Christopher_Anderssarian, duarteframos
Tags: #bf_blender_2.8
Differential Revision: D3400
Only show hierarchy relationship lines when bone or its parent is selected.
This cuts down the clutter visible in general when relationship lines are
enabled (currently they can't be disabled), which should make it more useful
to keep them on (e.g. constraint lines/hints can still be drawn this way).
As was decided at today's dev kickoff, we're now moving to having
Copy-on-Write enabled by default, as 2.8 is barely functional with
it off.
To run Blender *without* COW (e.g. for testing), use:
--disable-copy-on-write
You need the whole chain of pointers... This was breaking static
overrides of any rig basically.
Note that this kills performances again (adding several hundreds of
thousands more stuff on a blendrig...), need a better way to handle RNA
override walking.
Fixes camera view locking, camera related transitions and movements with the active object as pivot point
Note there can still be problems if the active object is not selectable
Seriously... Not all edges have faces!!!!!!!!
Quick fix to make it possible to load/use customshaped bones again, not
100% sure it is correct, but... At least it does not crash anymore!
- This allows quick, consistent toolbar access
w/o conflicting w/ the keymap.
Where pressing space before a key activates that operator as a tool
instead of running immediately.
- Search can still be accessed by pressing spacebar again.
- When there is no toolbar for a space, operator search still opens.
If a mesh is known to be manifold, then it's not necessary to increment the
stencil buffer 2 times anymore. But we still need to account properly for
degenerate triangles.
In this case, only generate a quad if the tri is facing the lamp. If there
is a degenerate loop, the other edge will either cancel the increment (if
it is also facing the light) or not produce a quad (if not facing).
This will always give the correct count.
Seems that degenerate tris are somewhat widely used in modeling. So we need
to fix this. Test the edges in the geom shader since the adjacency info is
only dependant on topology, not actual vertex placement.
This fixes most of the remaining noise issues. Only a few artifacts appear
on really weird models. So if you want to get rid of the artifacts, fix
your model!
This makes the shadows ~10 times faster in the general case.
This only create extrusion geometry on the outline edges. Also we increment
or decrement the stencil buffer by 2 for each manifold edge and only by 1
for non manifold. This make the algorithm robust yet less heavy than creating
one prism for each triangles.
Operators did not suffer from this problem as they were still just using notifiers
directly. The "proper" fix is to use the new message bus system. But, we've
got enough problems dealing with COW already as it is now... moving on.
The transform code needed to use data from the "_eval" copy of the posebone
instead of the main-db version, otherwise the initial/reset value would be
wrong, causing the jumping.
Without the exception, adding new poses to pose libraries took several seconds
with only <= 4 bones selected. While we may still need this for other cases too,
since bones are such a common use case, it makes sense to provide some level
of optimisation for them.
This now works by getting the RNA Path from the given PointerRNA to go from the
ID block to the data it points to, then uses this path to find the new data
relative to the COW ID.
Note: This currently still has all the debug prints left in - As can be seen,
I was testing this against the earlier PoseBone hack/special case. We may still
need to bring such special cases back in future, since looking up RNA Paths
like this can be slow.
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
Experimental support for using popovers like menus,
use this when the user hold the mouse down
(previously this did nothing).
This means turning frequently accessed menu items into
popovers doesn't add more clicks to the existing use case.
There are still probably other massive problems to solve (i.e. which copies
of data cache/sim gets written/read from for COW eval) that need to be solved
before we can get the sims actually running though.
This adds Eevee render tests using the Cycles files. Currently it must
be enabled by setting WITH_OPENGL_RENDER_TESTS=ON. Once we have reference
images we can enable it by default.
Some of the Cycles and Eevee tests are also currently broken due to
modifier and particle changes.
Differential Revision: https://developer.blender.org/D3182
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383https://code.blender.org/2018/05/collections-and-groups/
Without this we need to have the context to get the
(space_type, mode) args for an active tool lookup.
For event handling & poll its more convenient to have direct access.
This piece of code remains annoyingly verbose, but at least now we do
not have anymore twice the same logic duplicated between single array
element handling, and non-array properties.
This patch adds support for:
- Per space-type tools (3D view and edit).
- Per mode tools (object, edit, weight-paint .. etc).
The top-bar shows the last activated tools options, this is a design
issue with using a global topbar to show per-space settings.
See D3395
We handle doversion for the scene properties, but not for the
view layer overrides.
Overrides will be implemented in a different way via dynamic overrides.
For now this data is completely lost.
For now, do not override/instantiate objects used as boneshapes.
Note that this is a rather poor/dirty hack, it seems Spring char groups
still have a lot of other (unused???) shape objects.
Ideally lib groups should be designed more cleanly for the new Static
Override system, putting only really usable objects into 'main' group,
and placing the others in sub-groups, helpers groups, or so...
*Always* use BKE_library API to handle IDs allocation and freeing,
unless you have a very, very, very good reason not to do so - and
perfectly know what you are doing.
No idea why that was working this morning, now we do not get CoW tag
anymore (which kind of makes sense since it's set *after* copying
happens...), so just resorting to using the NO_MAIN flag instead.
This is a usefull feature that can be used to do a lot of precomputation on
the GPU instead of the CPU.
Implementation is simple and only covers the most usefull case.
How to use:
- Create shader with transform feedback.
- Create a pass with DRW_STATE_TRANS_FEEDBACK.
- Create a target Gwn_VertBuf (make sure it's big enough).
- Create a shading group with DRW_shgroup_transform_feedback_create().
- Add your draw calls to the shading group.
- Render your pass normaly.
Current limitation:
- Only one output buffer.
- Cannot pause/resume tfb rendering to interleave with normal drawcalls.
- Cannot get the number of verts drawn.
Patch D3205 by Kanzaki Wataru
Only implemented in Eevee for now. Collapse a closure to RGBA so we can
do NPR stuff on the resulting color.
Use an emission shader to convert the color back to a closure.
Doing this will break PBR and will kill any SSR and SSS effects the shader
the shader rely on. That said screen space refraction and ambient occlusion
are supported due to the way they are implemented.
There are a few places where DerivedMesh is still used, most notably
when calling the (not yet ported) cloth simulation. There is also still
the use of Object.derivedDeform and Object.derivedFinal. Those places are
marked with a TODO.
Some functions in the editors module were copied to accept Mesh. Those
already had 'mesh' in the name; the copies are suffixed with '__real_mesh'
for easy renaming later when the DM-based functionality is removed.
Locked bones of proxies should not be editable, at all. But lack of
update from linked rest pose in 2.7 allows to pose and animate locked
bones (not to pose them without animation though, or you'd lose your
pose on next file save & reload).
this is used by artists to always lock all their bones in a rig, so that
proxies fully update when lib rig is modified...
For now, restore that broken behavior in 2.8 by not updating proxies
against lib armature in CoW context (makes sense anyway, we are
currently doing a lot of useless thing when copying data for depsgraph
evaluation!).
This patch adds support for clip_planes (ie ignore what is behind a face)...
The idea is to first execute a raycast to get the polygon to which the mouse cursor points.
Then a snap test is done on the vertices or edges of the polygon.
Then with the normal and location obtained in raycast a new clip_plane is created and the snap over the whole scene is processed ignoring the elements behind the clip_plane.
Here 2 gif of how the previous patch would work on blender2.79:
{F497176}
{F497177}
Reviewers: mont29, campbellbarton
Reviewed By: campbellbarton
Subscribers: bliblubli
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2527
Doing that copy is the right thing, but only if the mesh has its own
deformed_only flag set correctly. This isn't generally the case, so
keeping dm->deformedOnly = 1 is better.
This flag is copied when converting between DM and Mesh.
This flag is set to true in get_mesh(), to mimick the behaviour of
CDDM_from_mesh_ex. This is necessary for the particle system to work
correctly.
Reviewers: dfelinto (changed test from totvert to totfacesel before committing)
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3306
This ports the main modifier eval loop.
A few things haven't been ported yet: tessface and shapekey related code. As
far as I can tell, shapekey code was never entered into.
https://developer.blender.org/D3342
Non modifying version of `BKE_mesh_validate`, mirrors `DM_is_valid` more
closely. Will be used in port of `mesh_calc_modifiers`
from `DerivedMesh` to `Mesh`.
This relations is only to force geometry evaluation to happen
after scene's CoW is done. it was never meant to update geometry
when scene is being tagged.
Don't try to bend existing design, just follow it. It's not nice, but is
working. Just bring it back, then repeal and replace system as a whole,
making sure every bit is working according to a design.
Such quick patches only trying to make local sense of a system, defeating
it's design.
- Default Lamp increased strength (10x stronger)
- 3D View & Camera Lens = 50mm
- Camera film size = 36x24mm Full Frame
- Render Size Percentage = 100%
- Render Display = New Window
- Scene Units = Metric
- Color Management View = Filmic
- Workbench Object Overlap = ON
- Headers on top for all editors, except the Timeline at the bottom
- Default Properties tab = Object Properties
- Generate UV's = ON
See T47064
The outliner can redraw quicker without rebuilding the tree, for example when
just moving the mouse and highlighting different items. The way this worked is
that the outliner would be tagged to avoid rebuilding, however if another
operation that does require rebuilding happens in the meantime we could go out
of sync and crash.
Currently all are stacked together, but perhaps if we don't get any other
tools in the meantime, it would make sense to have them separate.
Notes:
* No icons for now...
* There are some 2.8 bugs with the underlying operators (notably multi object)
For fun, I tried adding some more edit armature tools to the toolbar to
check how this is all working. Icons are missing currently, but it's a
nice test.
Regression in recent undo system changes,
This caused T55048.
When each mode had its own undo stack it was important
to initialize it when entering edit-mode.
This patch does not make any difference for a user's POV. But it is a step for adding the occlusion test for snapping functions.
This new function finds the node(aabb) whose projection is closest to a screen coordinate.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D3180
With a few changes:
* Use space after if.
* Skip for loop when no selected vertices.
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3349
With changes by Dalai Felinto:
* Indentation
* Skip for loop when no vert/edge are selected
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3233
Previously, the "layers_used" value was getting updated by the drawing code.
However, when using copy on write, the drawing code gets evaluated copies of
the armature data instead of the original data, so any updates here fail to
get flushed to the original data, hence the lack of updates in the UI.
Fixed by moving the calculation to RNA when setting bone layers, as it should
have been done originally. (The one downside to this is if we set individual
layer memberships one by one - this could be slower as the recalc would have to
happen each time this changes).
With changes by Dalai Felinto:
* Move WM_operator.* outside for loop.
* Update error message to handle Mesh and Meshes.
* Skip main functionality when no vert/edge/face is selected.
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3371
* Move Shading modes out of the popover
* Move Show Overlays out of the popover
* Test moving the Mode to the topbar again
* Move submode (select vertex, edge, face) to the topbar
* Remove icon from show_manipulator toggle
With changes by Dalai Felinto (skip for loop when no vert/edgeface selected).
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3302
SSR does not work with hair strands. Basically, the rays are too much
random to ever converge properly and just result in a soup of self
inter reflections.
So forcing it to not produce any SSR. Could potentially save some bandwidth
by not rendering hair to the SSR buffers.
This is a hack to properly shade wire hairs. Use stochastic sampling and
let TAA solve the noise.
At least it's way more correct than the previous hack.
Linking/appending in edit mode currently isn't supported. For workspaces it
should probably be, but we can look into supporting this later.
For now gray out buttons in "Add Workspace" menu while in edit mode.
This avoids having to store the tool definition in the operator
properties (on redraw).
Now just set the name, note this means we can't show the keymap in the
tool-tip anymore. This will eventually be shown in the status bar.
This means only one texture to draw to and only one sprite per pixel.
The texture is twice as large and near and far planes are side by side.
The sprite choose the biggest coc to expand to and is redirected to the
area (layer) it belongs to.
The fragment shader discard every pixel that does not belong to the correct
layer.
Due to the scatter operation being done at half resolution, undersampling
is visible at bokeh shape edges (because of the hard cut).
This commit adds a smoothing function to minimize the problem.
Also optimize the bokeh shape parametrization by precomputing a lot of
constants.
This new blending allows background to fill the gaps left by forground
objects. However this has a drawback, background objects that should be
partially occluded in this case can be seen through the blurred objects.
This does not fix the problem of blurred foreground over sharp background.
Also cleanup code to be simpler and remove unused geometry shader.
The Studio lights are now loaded from disk. The location is
`datafiles/studiolights` they need to be JPG for now. JPG cannot store
HDRI color range but they are clamped inside the Workbench
engine for speed reason. I didn't select JP2K as it might not be
enabled.
Users can add upto 20 HDRI files. This limitation is inside the
RNA_space.c Currently the icons are calculated when you first open the
selection box for the HDRI's. We could add them to a background
rendering later.
I added 2 test files a sky texture rendered in Cycles and an HDRI from
cloud.blender.org.
We can not rely on edit->psys, it is not set for particle edit,
and there is some logic deeper inside which does different things
dependent on that.
We need to replace those checks with some some HAIR vs. PARTICLES
flag and always set psys pointer.
The idea is that edit mode structure is owned by original object,
and used for drawing. This is a bit confusing, especially since
path cache is also in that structure and needs evaluated object
to calculate cache.
In the future we should split edit data from visualization data,
but that's bigger refactor.
Freeing sequencer would always do usercount, which is now forbidden when
called from main ID freeing code.
Annoying in 2.7x, much more critical issue in 2.8!
Also, moved RNA sequencer API functions to proper rna_scene_api.c file.
Freeing sequencer would always do usercount, which is now forbidden when
called from main ID freeing code.
Annoying in 2.7x, much more critical issue in 2.8!
Also, moved RNA sequencer API functions to proper rna_scene_api.c file.
Two things to indicate (which als apply before the DM → M port):
- Face count in the UI is not updated and stays at 0
- When planar mode is used, the result is inverted (mirrored along X)
compared to 2.79
Reviewers: sybren
Differential Revision: https://developer.blender.org/D3303
Bone selection overlay is only available in pose mode.
and when active overrules the selection buffer.
This is currently `tricked` by switching the draw engines, but this is
an exception. Not sure how to solve this in a better way.
After this is solved we can look at how to localize the dim effect to only the objects connected to the active armatures. Currently it dims the whole screen (including background).
@campbellbarton I added you as reviewer as it you have done a lot in the DRW_draw_select_loop
Reviewers: campbellbarton, fclem
Reviewed By: fclem
Subscribers: campbellbarton
Tags: #bf_blender_2.8, #code_quest
Maniphest Tasks: T54983
Differential Revision: https://developer.blender.org/D3241
Initial add-cube tool which uses the scale cage to resize.
The 3D cursor is currently used to project the cursor onto.
We'll likely have more orientation options in the future.
NOTE: This is all still heavily WIP, and still requires some additional
layout engine magic to make it all nice.
* Moved current frame, and start/end frame buttons to the end
* Put playback controls in the center
* Remove other more obscure buttons (e.g. Frame menu, lock frame to frame range)
More to follow in next commit...
Now all Keying Set and Auto Keyframing settings can be found the in NKEY
Properties Region (right-hand-side hidden tab/drawer).
This way, we have more room to display the full names of the settings,
without clogging up the timeline header.
Bvhtrees take up a lot of memory space, reusing the common bvhtree of looptris to snap to vertices and edges is a good way to save memory.
Unfortunately we have a worsening performance in the snapping operation around 63% (addition to the original time).
But as we often do not need to build a bvhtree of loose verts and loose edges, we have an improvement in cache time :)
Since the CPU time of snapping operations (no matter how higth poly the object is) corresponds to less than 0.01% of all CPU time of a blender frame, that change is not really significant.
Snapping operations on a mesh in edit mode have not changed significantly.
Signed-off-by: Germano <germano.costa@ig.com.br>
Everything seems to be working without this, which makes since there is no
evaluation-time edit code in master. The only tricky part here would be that
this means we might want to ensure edit structure exists from inside particle
mode in draw manager.
Other point for not having this code in evaluation is that it's possible to
have same object evaluated in different contexts at the same time, and since
edit structures are supposed to be in original object we might run into
threading conflict.
Readcode always set relative paths of indirectly linked libs relative to
*current* .blend file, not to the library using it.
But BKE_library_filepath_set was then setting them relative to their
parent library, breaking checking code (and saved files even :((( ).
in Scene DNA is available in scene.display New DNA Struct DisplayData
Added RNA (scene.display).
We already have scene.display_settings which contains non viewpoert
specific color management settings. I did not merge those two.
Patch should be in line with the ideas that @brecht wrote in T55008.
As I am not in detail aware of the decisions that have been made for the override feature I want a short review if it is in line with the plans.
Reviewers: brecht, dfelinto
Reviewed By: brecht
Subscribers: brecht
Tags: #code_quest, #bf_blender_2.8
Differential Revision: https://developer.blender.org/D3290
This feature is limited (only byte PPM output, no multi-view),
only works with specific configurations.
This also causes some maintenance overhead
when testing changes to the render pipeline.
There is still an issue with the modified mesh not being updated until you
disable and re-enable the modifier. However, after that it'll now also work
while editing the deformation mesh.
The modifier performed the 'bind' operation not in the bind operator,
but delayed in the mesh evaluation. This saved the result in a CoW copy
instead of in the actual modifier data. The binding operator now follows
the same approach as Mesh Deform: it forces the modifiers to run on the
real (non-CoW) data, making it possible for the modifier to store the
binding data.
This commit also ports the usage of DerivedMesh to Mesh.
Patch description:
- Reports "Nothing selected" only when all objects has no selection
and it is in Separate type(Mode)
- Tested all types (Seperate/By Material/By loose parts)
- Instead of using
```
BKE_view_layer_array_from_objects_in_edit_mode_unique_data
```
I used
```
BKE_view_layer_array_from_bases_in_edit_mode_unique_data
```
Because it needs the "Base" not the "Object" itself.
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3267
With minor changes:
* Have BMOperator declaration close to its initialization.
* Move const use_prepare and const use_interp_simple outside the for loop.
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3222
Gets edit more from the current object and displays it as a path.
this is how both hair and particle edit modes are supposed to work.
This only covers path itself, it doesn't do anything like keys
visualization or selection. However, it's already possible to
comb and such.
Only implements particle mode. There are also some settings to
do soft body and cloth. No idea yet what that all is about.
Copy-on-write is not supported either, this is due to some
edit mode ownership problems which are to be addressed from
dependency graph side.
Shading is dead-simple: uses tangent as a color. This is where
i hope to get some help from Clément.
BLI_bvhkdop functions were not made to work with zero-leaf trees.
Perhaps a better solution would be to modify BLI_bvhkdop to work with zero leaf trees.
But this solution of returning NULL was already used for bvhtrees of looptris.
Some years-old deprecated stuff has now been removed.
Correct solution is probably to use valid defines etc. in own code, but
this is more FFMEPG maintainer task (since it also may change how old
FFMPEG we do support...).
When entering edit mode the texture coordinates is not calculated by
drawcachemesh. For now fallback to solid mode. This gives wrong
artifacts when disabling overlays when in edit mode. We should make it
possible to calculate the UVLOOP from bmesh. This will be done in a next
patch
The actual code is a bit convoluted but allows good and "pseudo efficient"
drawing. (pseudo efficient because rendering instances with that amount of
vertices is really inneficient. We should go full procedural but need to
have bufferTexture implemented first) But drawing speed is not a bottleneck
here and it's already a million time less crappy than the old (2.79) immediate
mode method.
Instead of drawing actual wires with different width we render a triangle
fan batch (containing 3 fans: bone, head, tail) which is then oriented in
screen space to the bone direction. We then interpolate a float value
accross vertices giving us a nice blend factor to blend the colors and
gives us really smooth interpolation inside the bone.
The outside edge still being geometry will be antialiased by MSAA if enabled.
Now we use vcos when provided, and fall back to mesh vertices' co
otherwise.
Deform modifiers usually do not have up-to-date coordinates in Mesh
itself, only in given vcos array!
Aside from identation, seed should change for each object. Otherwise to objects
with a copied mesh would get the exactly same "random" selection.
And we do so in a consistent way so it doesn't vary depending on
object order.
Seed bump using hash suggested by Campbell Barton and Sergey Sharybin.
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3231
This modifier still has issues that are not related to this port:
- While editing the deformation mesh, the deformed mesh doesn't update.
This update only happens after exiting edit mode, making editing
cumbersome.
- Binding doesn't work yet. It works fine when binding in master and
loading pre-bound in 2.8. This was also an issue before this port, and
will be investigated separately.
This function creates a Mesh struct with a number of vertices/edges/etc.
It allocates the minimal number of CD layers needed.
Currently not yet used, but will be soon in the upcoming
BKE_new_mesh_from_curve_displist().
With changes by me:
* Indentation (tabs)
* Removing RNA_boolean_get tests out of the for loop.
* Continue iterator if no selected vertice.
Maniphest Tasks: T54643
Differential Revision: https://developer.blender.org/D3210
Some notes here:
* Proximity with non-mesh objects (like curve, see TEST_2 scene in
weightvg testfile) are not working currently. This is known TODO of COW
depsgraph project.
* Proximity modifier is slower, due to some other TODO pending on
BVHTree creation/caching for Mesh.
This commit brings back motion path calculations working on same level
as 2.7x. Caveats:
* You cannot actually see anything, as all the drawing code for motion
paths was removed and not reimplmented in 2.8 draw engines yet
* This doesn't actually use a separate depsgraph instance for fast
background calculations yet. That's a separate topic, and will require
further investigation (probably after code quest, according to original
planning).
* The work here *does* however pave the path forwards towards fully separate
COW evaluation though. We only need to stub in a different depsgraph instance
here to get things working.
frames
caused division by zero if both dupli_frames_on and dupli_frames_off are
zero. doing this doesnt seem useful, dupliframes can be disabled in
other ways.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3132
frames
caused division by zero if both dupli_frames_on and dupli_frames_off are
zero. doing this doesnt seem useful, dupliframes can be disabled in
other ways.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3132
Note that custom normals drawing seems to be broken, and there also are
some refresh issues in some cases... But this is same with old DM-based
code, so not related to modifiers themselves probably.
Steps to recreate were:
* Go into fullscreen mode (Alt+F10)
* Open debug menu (Ctrl+Alt+D)
* Set value to 1
* Confirming should crash (at least in debug builds)
Was hidden behind debug values 1, 2 and 3.
Also cleaned up logic in region_azone_edge_initialize. It was using a variable
called is_hidden that actually should've been called is_visible.
Since modifier stack is still primarily based on DM in blender2.8, we
need to copy over 'dirty normals' flag from temp Mesh to DM after
modifier has been evaluated.
Scroll-bars are now hidden unless the cursor approaches them, in which case they
smoothly grow and become more & more visible. Note that since 0d309144020168e55,
scroll-bars are drawn on top of editor contents. There's no more jumping of
buttons when scroll-bars appear.
Technical notes:
* AZones are used to adjust scrollbars based on mouse movements
We may want to support screen level AZones if we want scrollbars to also
smoothly appear when approaching them from a different area.
I also plan to make further changes to AZones to clean up stuff a bit.
* Had to move AZone handling to a post ARegion init stage, since we need the
updated View2D data from there.
* View2D masks and scroller rectangles are now updated on every redraw. It's
cheap to do that though.
Scroll-bars used to draw in a little extra space in the editor, causing
buttons to jump a bit when they appeared/disappeared. Now they draw on
top of the buttons, just small enough to avoid bigger overlaps. Followup commits
will do further adjustments.
With this we can get rid of a hack that was calling the (often Python
defined) panel definition - the panel 'draw' callback - twice.
Note: This rely on the property having a pre-defined default.
Also, be aware that trying to multi-drag and multi-ui-edit is not working
at the moment (T54976).
With changes by Campbell Barton.
Differential Revision: https://developer.blender.org/D3207
* Ensure popover does not change direction or location.
* Open popover towards the relevant editor, like pulldown menus.
* Use a bigger maximum assumed size to deal with some corner cases.
* Do proper 3D viewport header refresh on shading mode changes.
In object mode, the axes are drawn like any other wire objects with
depth test and depth write. Thus enabling MSAA to work but not their xray
behaviour.
In edit armature/pose mode, draw smooth line without depth testing. This
produces wrong draw ordering problem but still gives the desired xray
behaviour. We do it outside of the MSAA pass since the xray behaviour is not
compatible with it. But we are drawing smoothed lines so no need for MSAA.
The lines are 2px thick and improve readability.
Now the axes are displayed correctly at the tip of the bone and with the
axes names.
I've made some modifications though:
- Axes are colored. (should not be in object mode but that's TODO)
- Axes ends are not flat arrows anymore. Replaced with a small diamond.
- Axes names are now scale by their respective axes instead of being
affected by other axes.
- Changed axes names "font" to be a bit more sexy.
This is for the 3D viewport and image editor. A remaining issue is
that pulldown menu buttons only show text, which is not visible on
all background colors, so making the header entirely transparent
does not work well at the moment.
There is no object to update anyways, and there is no valid basact when the
nified_findnearest() test fails.
How to reproduce the bug: Try to select linked (L) with selected faces but
withotu mouse hovering any mesh.
Bug introduced on: rBbfc9d426bb95 (original multi-object edit commit).
This makes a few changes:
- Remove the old "overlay" wires.
- Add constraints colors to bones.
- Specify a a new "hint" color per bone. Making selection/Active state
more obvious.
- Unify Octahedral/B-Bones/Envelope shading and colors.
- Change outline size depending on the selection/active state of the bone.
Note that thoses changes are not final and needs review.
This will enable us to do more nice stuff in future commits.
This commit is a temporary commit, it will compile but will crash if
trying to display any armature. Next commit does work.
For some we may add per object overrides, but for most we plan to keep them
strictly per viewport settings. Display settings from the mesh still need to
be moved here, only collections were done to remove that code.
While testing UI_OT_reset_default_button, discovered that using
Reset to Default Values on bone locations didn't work. Turns out
to be missing update on this property. So, this is probably
dependent on the property used.
This was the otherway around before. But since we can have a different size*
for cube texture now, we can compute the correct-ish texture size.
This will give us on average the same texture appearance when we will add
support for real cubemap shadows.
As much as I want to give freedom to the user, 1.5G of vram for a
single shadow is a big of a stability issue.
So limiting to 4096 for now, we may remove this limit in the future.
This mean we can now have different shadow resolutions for both.
However each shadow type keep the same size accross all lamps because of
future "real" Cube Shadowmaps limitation and to save texture sampler slots.
That said the cascade shadow resolution could (in the future) still be
changed to be adjustable per sun lamp.
Existing code checked pose/edit mode to check for transforming in an
objects local space.
This added many similar checks all over the code,
which leads to confusion.
Multi-edit caused a regression in UV transform since where UV's
had the object matrix applied by accident.
Now there is a boolean to use a local matrix,
this allows for any mode to have a 4x4 matrix
applied w/o adding mode specific checks everywhere.
Initial review of the shard shadows in the workbench engine.
Speed optimizations like transform feedback are not implemented yet. I first want this part to be reviewed and merged.
@fclem please check the note in drw_stencil_set it was holding back nequal == 0 as by default DST.stencil_mask was set to 0. questioin is should we remove the whole check or not.
Also I am still looking for a better name (or split the enum) for DRW_STATE_STENCIL_DEPTH_FAIL_INCR_DECR_WRAP
Reviewers: fclem
Reviewed By: fclem
Tags: #code_quest
Differential Revision: https://developer.blender.org/D3198
Those should be used in priority when you need to create either a new
datablock in Main, or a new temp one. Lower level BKE_libblock_...
should only be used when you need a very specific, uncommon behavior.
The value of epsilon was never used to create this bvhtree because whenever we activate this constraint, a bvhtree with parameter epsilon 0.0 was created and cached.
Seems to be only related on linked nature of particles.
This is caused by some conflicting optimization done for viewport, which
does not do particles re-calculation if they do not depend on time
(which is crucial for big layout scene grass fields) and particle render
setting switch which was relying on fact that render pipeline will do
particle update via time dependency.
Now we extent an old workaround for invisible objects, which now also
deals with particles in the same way as old dependency graph was dealing
with this: tag object data for update if there is particle system.
There shouldn't be any speed difference between old and new depsgraph,
since tagging was already needed and was happening.
In Blender 2.8 such things should be easier to deal with since the whole
depsgraph is to be evaluated for render engine anyway.
`MREMAP_RAYCAST_APPROXIMATE_BVHEPSILON(ray_radius)` greatly increased the radius making for example that 0.1 becoming 1.5
Now the result is much more predictable.
* Remove the "sync_mode" dropdown from timeline header, and move it into
the Playback menu instead.
* Remove the confusing "Frame Dropping" and "AV Sync" entries from the
Playback menu. These were supposed to be mutually exclusive (or else,
the "sync_mode" menu would break).
* Turn AV Sync on by default
* Commented out the Frame Dropping and Av Sync RNA Properties too.
THere doesn't seem to be any valid reason for these to exist?
Note: This still needs some copy-on-write magic to get the bone pointers
to get remapped properly (e.g. evaluated pose still refers to original
arm->bones, and arm->act_bone isn't getting remapped).
After copying animation data we need to re-map action, otherwise
our original DNA values will go out of symc, causing flickering
when tweaking values on animated node tree.
The idea is to re-use evaluated datablock from within current context.
This relies on the following factors:
- It expects scene to be fully evaluated before preview jobs starts.
- It expects datablocks to be localized.
The workaround removal was wrong, the whole id->adt of a local
copy is to be NULL.
But now instead of modifying original datablock, we tell library
manager to not copy animation data.
This was due to the background being drawn by a batch that had its VAO
generated in the windows "UI" context.
Since we use the DRW ogl context to draw the entire area, we have to
regenerate the VAO for thoses UI batches to be drawn correctly.
The actual weighting calculation is not smooth as the bone display.
The bone itself can be smooth for esthetic purpose but the distance display
should match the underlying weighting formula.
Past shader was too slow and had bad artifacts. This method is much simpler
and eficient and only exhibit some popping when the raidus of the head/tail
is changed.
We now use a more pleasant and efficient way to display enveloppe bones
and their radius.
For this we use a capsule geometry that is displaced (in the vertex shader)
to a signed distance field that represents the bone shape.
The bone distance radius are now drawn in 3D using a "pseudo-fresnel" effect.
This gives a better understanding of what is inside the radius of influence.
When capsules are not needed, we switch to default raytraced points.
The capsules are not distorded by the bone's matrix (same as their actual
influence radius) and are correctly displayed even with complex scaled
parents hierarchy.
Here is how it works:
We render a high poly disc that we orient & scale towards the camera so that
it covers the same pixel of the sphere it's supposed to represent.
Then the pixel shader raytrace the sphere (effectively starting from
the poly disc depth) and outputs the depth to gl_FragDepth.
This approach has many benefit:
- high quality obviously: per pixel accurate depth!
- compatible with MSAA: since the sphere horizon is delimited by polygons,
we get the coverage computed by the rasterizer. However we still gets
aliasing if the sphere intersect directly other meshes.
- virtually no overdraw: there is no backface to shade but we still get
overdraw because by little triangle [gpus rasterize pixel by groups of 4].
- allows early depth test: since the poly disc is set at the nearest depth
we can output, we can use GL_ARB_conservative_depth to enable early depth
test and discard pixels that are already behind geometry.
- can draw outline pretty easily without geometry shader.
This manually resolve the content of a multisample FB to a single sample FB.
It resolves color (combine the 2 framebuffers in a logical maner keeping
depth buffer occlusion etc..) instead of a plain glBlitFramebuffer copy.
Group all fetches together without interleived alu to let compiler optimize.
Also do the color samples only if needed.
Went from 3.86ms to [1.11-2.22]ms [min-max] for the 16samples resolve pass
on my nvidia card.
This shader is used instead of blitting back and forth to a single sample
buffer.
This means it resolves the color and depth samples and outputs a fragment
which can be depth tested and blended on top of an existing framebuffer.
We do static shader variation with manual loop unrolling for performance
reason. In my test I get 25% more perf with intel integrated gpu and 75%
performance gain with dedicated nvidia card compared to a single shader
with a uniform for sample count.
This fix the issue with the zfighting we were getting at bones edges.
Moreover, this enables us to render arbitrarly large outline with
varying thickness.
It's usefull in some scenario to tweak the specular intensity of a light
without modifying the diffuse contribution.
Cycles allows it via lamps material which we currently not support in Eevee.
This is a good workaround for now.
The asserts were introduced on rB5f6c45498c92 (top-bar).
Although the asserts are technically correct, they would fail even in master.
And the commit simply added the asserts without fixing the situation itself
(as you can see in the report, it is really simple to reproduce this issue).
I propose we remove the asserts and bring them back only when the situation
itself is fixed. It doesn't make sense to introduce asserts that would fail
with the current state of the code.
This was a hard to reproduce bug, but it happens often enough.
Basically the tooltip of the active tool was been invoked when
context had no valid ScrArea which would lead to a crash.
We now just return no tooltip in these cases.
There are various values which depends on context in there, for example
current driver value and original DNA value f-curve is applied for.
This partially fixes issue with not being able to tweak keyed values
when material preview is open.
The material preview is not being currently updated against non-keyed
changes since every tweak of material property does full preview scene
depsgraph evaluation.
Now they are properly converted to Linear space before interpolation.
Since the only way to get vertex color in eevee and cycles is via the
attribute node with the CD_AUTO_FROM_NAME flag, we have to know at binding
time which type of buffer will be connected to this auto input.
We store this information inside the batch cache (together with the according
uniform name) and pass it as uniform to the shader which does conversion if
needed. The same shader can then be reused to draw another mesh with
different auto layers configuration.
This introduces `BKE_mesh_to_bmesh_ex()`, which exposes all of the
`BMeshFromMeshParams` parameters to the caller. This is required to enable
the `calc_face_normal` flag, which is required for the Bevel modifier.
This also introduces `BKE_bmesh_to_mesh()`, which allocates a new `Mesh`,
converts the `BMesh` to it, and returns it. The returned mesh is owned by
the caller.
- ability to switch between Single Color, Object Color, Material Color
and Random Color
- fixed Shading and Lighting popover
- Renamed Solid -> Single Color
Note: As already commented in the code, the ideal solution would
be to pass select mode as parameter to ED_view3D_backbuf_validate.
Without that we have to resort to the hack solution of writing to
evaluation data.
Does not yet support applying those operations, only detecting
insertions and generating matching rules was already rather complicated.
Also got rid of ;ost rna_path string allocation in collection diffing
code, could help a bit with speed too.
This matches the new convention for left-handed mode selectors,
however we're still undecided on exactly how this should work.
For now test this out as a convention for all space types.
The contents of the ModifierEvalContext struct are constant while iterating
over the modifier stack. The struct thus should be only created once, outside
any loop over the modifiers.
This commit introduces `EditMeshData`. The fields in this struct are
extracted from `EditDerivedBMesh` into their own struct `EditMeshData`,
which can then also be used by the `Mesh` struct. This allows passing
deformed vertices efficiently to the draw routines.
The modifier code constructs a new Mesh instead of writing to ob->data;
even when ob->data is a CoW copy, it can still be used by different
objects and thus shouldn't be modified by a modifier.
Makes the follow changes:
- Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers.
- Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary
- Update the rest of Blender to be aware and make use of these new functions
The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed.
Reviewers: campbellbarton, sergey, mont29
Subscribers: sybren
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D3155
We use 'reference' to designate the linked ID which is being overridden
by the local one, so using 'reference' to designate the stored local ID
in apply RNA code was... not a good idea. ;)
Actions shouldn't be copying by new library management code.
Or at least should be possible to make it to not copy actions
or do unneeded user management.
This way we avoid modification of original data which could
and does cause threading conflict with copy-on-write which
could be happening for viewport.
Skip access to any evaluated data when operator is run on file load,
we don't have depsgraph evaluated yet. In this case we skip part of
sculpt session initialization, since it will be done during depsgraph
evaluation which happens after DEG_on_visible_update().
We can not skip sculpt session initialization since during normal
operation we want all the data to be initialized on mode change,
and not on initial brush stroke.
Since area lights are affected by scaling them, it only makes sense to support applying the scale to the lamp size.
Of course, applying location or rotation does not work.
If a scaling that changes the aspect ratio is applied to a square lamp, the mode is automatically changed to Rectangle.
This reduces the number of headers we need to import (and/or dependencies
on the order of them), as these depend on PBONE_VISIBLE(), which is already
in BKE_armature.h
Like the select/deselect operators, we only support doing this for the
active object for now. From the UI panels, it doesn't make sense to be
operating on bone groups which may not appear/line up with those in the panel
that we're currently dealing with.
This can be reviewed later, but for now, it's easier and makes more sense
this way.
This operator was only partially converted to multi-object editing,
as on one hand, it was using the new "objects in mode" iterator,
while on the other hand, it was also using the context iterator inside
that, making all selected bones across armatures get included.
We only want these to operate on the "active" armature only at a time
(where the "active" one is whichever the groups from the UI came from).
The fix therefore is to make it not use the context functions
(which were changed to always take bones from all selected armatures
instead).
Because:
- Less redundancy.
- Better suffixes.
Also a few modification to GPU_texture_create_* to simplify the API:
- make the format explicit to the texture creation process.
- remove the component count as it's specified in the GPUTextureFormat.
- Disable VertexPaint and WeightPaint for OB_MATERIAL and OB_RENDER. Users want to see the final result
- When in OB_SOLID, the active object should be rendered without any color. The lighting information is multiplied with the VertexPaint/WeightPaint color
- Removed the use_shading flag from VertexPaint and WeightPaint
- add method to check if render engine should draw without color (DRW_object_in_only_lighting_mode)
Reviewers: fclem
Tags: #code_quest
Maniphest Tasks: T54894
Differential Revision: https://developer.blender.org/D3191
A recent change in the UI layout code probably broke how the scale_x
for layouts was getting handled. This was leaving a large gap
(and causing layouts to pop) when trying to scrub the timeline.
This commit fixes this with a manually-found value that largely seems
to get rid of the popping problem. There's still a little jumping (1-2 px)
but it's less distracting now.
Otherwise, trying to change color/material properties of EEVEE materials
that have been keyframed doesn't work until a new keyframe has been inserted.
NOTE: There's still some wonkiness if you edit more than one keyframed value
before keyframing (i.e. the other unkeyed value temporarily gets reset). But
that's more of a general COW+animation issue.
Was causing temporal sampling artifacts when scene is set to Cycles
and viewport is set to Eevee. Visually was looking like ghosting or
motion blur when moving objects.
Was using classes to define tools, however this makes it awkward to
dynamically generate them (we can do it, but its not very "Pythonic").
Move to a named tuple.
This commit does two things:
- Adds an option to do the calculation in different color spaces (BT601
or BT709).
- Changes the default caluclation from legacy BT601 to BT709.
This affects several areas:
- UI areas (mainly scopes)
- ViewLevelsNode
- Several other nodes that use `COM_ConvertOperation.h`
Dynamically sized regions in the topbar were flickering due to only updating
their size after redraws. Now there is an optional layout() callback for
all regions in an area to do UI layout first, then refresh the region layout,
and then do the actual drawing for each region.
Task T54753
* This is just moving buttons to get a bit closer to the intended design,
better naming and layout is needed.
* Popovers currently work best when the 3D view header is at the top, with
the most important settings nearest to the mouse. Open design question is
if we should flip (part of) the buttons if header is at the bottom.
* Another question is if selecintg a shading mode enum should immediately
close the popover since those are changed often, unlike the other settings
for which it seems more convenient to keep the popover open.
This is to address things like a percentage slider with a fixed soft mininum.
For example, the render resolution ranges from 1% to 100% and it is really
strange to have the slider showing nothing filled when the ui shows 1%.
Now we always fill the slider with a vertical boundary. A bit hard to explain,
but very easy to see the difference.
I split the widget in three parts and used fragment shader discard to remove the
undesired bits. That means all the widget program is doing a bit extra
calculation.
Reviewers: fclem
Subscribers: billreynish
Differential Revision: https://developer.blender.org/D3186
U.ui_scale is the setting from the user preferences and should never be used
for drawing. UI_DPI_FAC is the final scale after DPI from the operating system
is taken into account.
Having single & multi-column checks inline were becoming unmanageable.
Use a generator to define the layout,
allows for easily adding different layouts in the future.
Not really happy with the fix, but it works. With the new window draw method
we are no longer storing the 3D viewport in 4 buffers, by having the GPU
viewport function directly as the 3rd buffer. This means we need to draw the
action zones into it, and so we need to keep the framebuffer bound a little
longer.
Note: Quad-View region overlay drawing is not working because of e01cadd657.
However I tested this patch after reverting that commit locally and this
patch's code seems fine.
Partial revert of 3d62230ed6.
The problem is that some local path is always returned by
bpy_resource_path. The function does not enforce a check for existence
of the path in the low level code.
Since client code may indeed not care about existence of the directory,
I leave bpy_resource_path alone and patch the python code to check for
existence. An extra argument that enforces the check might be a better
solution, but I will be leaving this to the UI team.
Originally it was nice to have a small list of definitions
with tools inline.
However we need to be able to define drawing functions for tools
which Python can't easily inline.
Use function for keymap definition,
support creating a function from a tuple as well
(handy for simple key-maps).
For Blender 2.8 we had to be compatible with very old OpenGL versions, and
triple buffer was designed to work without offscreen rendering, by copying
the the backbuffer to a texture right before swapping. This way we could
avoid redrawing unchanged regions by copying them from this texture on the
next redraws. Triple buffer used to suffer from poor performance and driver
bugs on specific cards, so alternative draw methods remained available.
Now that we require newer OpenGL, we can have just a single draw method
that draw each region into an offscreen buffer, and then draws those to
the screen. This has some advantages:
* Poor 3D view performance when using Region Overlap should be solved now,
since we can also cache overlapping regions in offscreen buffers.
* Page flip, anaglyph and interlace stereo drawing can be a little faster
by avoiding a copy to an intermediate texture.
* The new 3D view drawing already writes to an offscreen buffer, which we
can draw from directly instead of duplicating it to another buffer.
* Eventually we will be able to remove depth and stencil buffers from the
window and save memory, though at the moment there are still some tools
using it so it's not possible yet.
* This also fixes a bug with Eevee sampling not progressing with stereo
drawing in the 3D viewport.
Differential Revision: https://developer.blender.org/D3061
The issue was that every object tweak was doing a full copy
of original datablock onto evaluated version, and was updating
animation. This made it impossible to tweak properties which
has keyframes.
Proposed solution is to:
- Always apply animation on frame change, and when object
is explicitly tagged for animation update.
This will store original DNA value of animated property
in the f-curve.
- When applying animation in other cases, we check original
DNA value stored in f-curve with the actual original DNA
property. If they differ, it means user started to tweak
animated property, and we should skip animation.
If the value is the same, we apply animation.
This is just a first step towards proper final implementation,
but seems to be the direction we want to take.
Both the scene and workspace had an active view layer, and it was confusing
which settings were being used or displayed where. Now we always have one,
so there is no mismatch.
The "View Layers" tab in the properties editor is now "View Layer", no longer
showing a list of layers. Instead view layers can be added and removed with
the workspace view layer selector. They are also listed and selectable in the
outliner.
Single layer rendering uses the active view layer from the workspace.
This fixes bugs where the wrong active view layer was used, but more places
remain that are wrong and are now using the first view layer in the scene.
These are all marked with BKE_view_layer_context_active_PLACEHOLDER.
Use render settings and active view layer will be handled elsewhere.
Also change icon to not be confusing with render layers.
Probably we should get rid of the workspace tab entirely and do it in
the user preferences, but that's for later.
When creating an offscreen context we need wglCreatePbufferARB to create
a drawable. In non-background mode wglCreatePbufferARB would have been set
by the main window creation code. But in background mode this is not the
case so we need to create a dummy context using the screen window to init
wglew properly.
Active tool name needed to be unique from all other tools.
This caused problems since different modes have different tools with the
same name (Armature/Mesh click to extrude for eg).
Tool names now only need to be unique per mode.
Normal packing. The sign is stored in the A of the color buffer.
if the A == 1.0 the normal should be inverted. before use.
The reason is that packing has more precision for frontfaces, than for
backfaces
This allows for background rendering with EEVEE and other opengl render
engine.
I've only tested it on Linux for the moment so I can't say about other
platforms.
We do lazy init because we cannot assume we will need Ghost for rendering
before having parsed all arguments and we cannot know if a script will
trigger rendering. This is also because it currently does not work without
any display server (blender will crash).
Previously it could have happened on every request to evaluated scene
or view layer.
This commit also removes expansion of view layer and scene from iterator.
Iterator is not to be used before depsgraph is evaluated.
This isn't working well when zoomed out in the properties editor,
we should be taking into account properties editor zoom level.
This reverts commit 1ba91ae2c0.
This caused too much trouble, also it's possible users run with
'release' in their CWD causing issues.
Developers can symlink "release/" to "bin/2.79".
Technically this is the following operator:
bpy.ops.view3d.edit_mesh_extrude_move_normal
But this is a Python operator that in turns calls:
MESH_OT_extrude_region_move
Which in turns calls:
* MESH_OT_extrude_region
* TRANSFORM_OT_translate
Multi-View was never a per-viewlayer option. And now that we have viewlayer
it is better to name it in a more recognizable way:
"Stereoscopy" instad of plain "Views".
The Blender Internal removal (51b796ff15)
removed support for texture slots from Materials/Lamps/Worlds,
but didn't remove the relevant parts from the animation editor filtering
code that were responsible for adding the texture slots for those channels.
Added Object Overlap Overlay
- Added R32UI support to GPU_framebuffer
- Added R32U support to draw manager
- The overlay mode has a object data pass that will render 'needed' data to specific buffers so we can mix them together via a deferred rendering. In future will also add UV's and other data
- Overlap is implemented as an overlay so it could be used on top of the Scene lighted Solid mode (that will be rendered by Eevee.
Reviewers: fclem, brecht
Reviewed By: fclem
Subscribers: sergey
Tags: #code_quest
Maniphest Tasks: T54726
Differential Revision: https://developer.blender.org/D3174
There were two issues here actually:
* The hack to allow running Blender directly from the source directory
would just check for a 'release' directory, without actually ensuring it
is release dir from blender source tree, and not some other random
folder.
* GHOST_getSystemDir returns nothing for portable installations, now
we'll then check directly in the blender binary dir in that case.
This fix is more critical in 2.8 branch, where that system path is used
to retrieve new '3D' icons...
* Draw the frame/time number box over the scrollbar instead of above it,
to reduce the clutter/clashes with markers.
* Draw the box centered around the line instead of off to one side,
making it clearer that the frame shown is the one being affected.
* Make the box larger than the scrollbar + use white text to make it
stand out from the neighbouring frame numbers (otherwise, it's easy
to misread that it's just another one of those)
Based on discussions here in the office, this commit introduces a number of
changes to make the "Bind Camera to Markers" feature (introduced during Sintel
to facilitate camera switching, and now an integral part of the UI for doing this)
nicer to use.
Main changes:
* "Camera Markers" are now drawn using Camera icons, making it easier to
distinguish between them and other ("normal") markers
* "Camera Markers" will display the name of the bound marker, making it
easier to see what camera each marker uses. This will then also stay
in sync with the camera being used (though a manual refresh is needed
after renaming objects to make the timeline update), fixing the problem
where the marker's camera and the name get out of sync.
* Behaviour of Ctrl-B has been modified to make it easier to quickly add
these markers. Now, it will directly add a new marker on the current frame,
bound to the currently selected camera object. If there's an existing marker
on that frame, the existing marker's camera will be replaced instead of making
a new marker.
With the clear separation between data and a state we need to make sure
operators and other areas are readingstate from evaluated datablocks.
Code-wise it means that all evaluated values are to be read from dataglock
which is owned by dependency graph, using DEG_get_evaluated_id() or similar
helper.
Reviewers: brecht, mont29, campbellbarton, dfelinto
Differential Revision: https://developer.blender.org/D3036
Each parameter of the function is copied into the memory stack.
This also brought an improvement in peformance of snapping functions between 5% and 12% in my tests.
* "Scenes" now shows for each scene lists of all view layers, collections and
objects contained in it. This is the place to see all collections and objects
in the scene even if they are not used in any view layer. Objects are nested
according to parenting here.
* "Collections" now shows all collections in the view layer, and the objects
in those collections. Objects are not nested by parenting, only collections
since it would be too confusing if the children are in a different collection.
* "Groups" is unchanged.
* "View Layer" was removed, replaced by "Collections".
Part of T54790.
Works on every probe type.
The function to see is EEVEE_lightprobes_obj_visibility_cb.
Set pinfo->vis_data.cached to true makes the computation faster for multiple
views using the same group.
We could even sort the probes by group for that mater to speed things up
even more (only applies to dynamic probes like the planar reflections because
other probes are only rendered one at a time).
This add a callback function that runs after frustum culling test.
This callback returns the final visibility for this object.
Be aware that it's called for EVERY drawcalls that use this callback even
if their visibility has been cached.
Some widgets would have rounding relative to the button size, others
absolute. Now it's always absolute. Note changing Display Scale in the
user prefs is not zooming, the rounding still scales with that.
- Added UInt R support to framebuffers
- Added the overlap as an overlay so should be reusable by other engines
(Scene lighted Solid mode)
Differential Revision: https://developer.blender.org/D3175
message("Unable to detect the Visual Studio redist directory, copying of the runtime dlls will not work, try running from the visual studio developer prompt.")
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.
