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.
This is actually rather slow process, commeting it out gives us another
10% speedup... On a non-animated char! Don't even want to know how much
this would have costed on a rig with hundreds of fcurves!
And checking this is not really critical for us anyway, once animated
you do not really care whether props are also statically overridden or
not.
- 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
Applied similar fix to T54233 to get the "Record with NLA" feature working with
active action blending + influence settings. Extrapolation is explicitly ignored
though, as it shouldn't be used with this feature (i.e. it is already disabled
with the new strips and also on the animdata by default)
While window manager is supposed to exist after file was fully read
and do-versioned, we can not rely on window manager to exist while
reading file and setting up an environment.
* Fixes crashes in versioning code for the removed editor types (see d8c719d8d8)
* Removes 'Game Logic' workspace.
It still only contains workspaces converted from old screen-layouts, proper
defaults are on the TODO.
Timelines and Logic Editors are gone. So far they were simply replaced by broken
Info Editors, now they are replaced by Dopesheets in the new Timeline mode.
We reuse ScrArea.butspacetype to temporarily store the space-type identifier of
the deprecated editor (see 9db492de6d). That way we can identify it in
versioning code and replace it nicely.
Action editor creation needs a scene to set the scrolling based on frame range.
Active screen-layouts use the active scene of the window they are displayed in.
Inactive screens simply use the first scene in the main data base.
Note that inactive editors don't need version patching, readfile.c converts them
to SPACE_EMPTY already, so users can't activate them.
Files saved since the editors were removed will still be broken.
Workspace config files saved before this will also crash (will update default
one in followup commit).
The only real reason we need `butspacetype` is while switching areas, where we
need to delay the actual switch to the RNA _update callback since only there we
can access context.
So instead of trying to sync it with `spacetype`, only set while needed and
unset it afterwards (as in set to `SPACE_EMPTY`).
This should also allow us to re-use `butspacetype` in versioning code when
trying to read removed editors. It'll store the space type value of the removed
editor which we can then use on versioning.
For backwards compatibility, we store `butspacetype` with the value of
`spacetype`.
This makes easier to distinguish between different editors
(as oppose to an editor and its regions).
Note action zones look a bit strange with this. I recommend we do next:
* Make sure all 4 corners can be used as action zones.
* Remove their drawing code (or show them only on mouse hover).
- UILayout.popover(.. panel_type ..)
A single panel
- UILayout.popover_group(.. panel categories ..)
Expands all panels matching args.
Currently used in the topbar for redo and paint options.
Requiring context means we can't easily create new editors to replace deprecated
ones in versioning code.
Think it's reasonable to give editors access to scene and area data for their
initial setup though. They mostly need it for setting "the view", as in,
scrolling values.
Also did minor cleanup in top-bar creation function.
Steps to recreate were:
* Create custom transform orientation.
* Change properties editor into 3D View.
* Trigger refresh of 3D view header by mouse hovering it.
Mistake in rB7d055da327b9555f.
Dithering the output color for 8bit precision framebuffer with bayer matrix.
On my tests the bayer matrux patterns are not noticeable at all.
Note that it also does that in opengl rendered mode which can be in a much
higher bitdepth. We can fix that if that's a problem in the future but I
doubt it will.
* Make bottom half of topbar a bit higher
* Make tabs higher and put them closer together
* Remove screen layouts dropdown, we'll have one layout per window
* Hide action zones from topbar
* Don't change topbar background color when activating
This will never get run, because direct_link_area() already flags/resets
every space type isn't registered, meaning that we don't have any opportunity
to apply our patching.
This commit removes all references to the old timeline editor.
Unfortuantely, the removal of the Timeline spacetype defining
functions has ended up breaking the version patching code I'd
been working on earlier (as now, the editor gets marked as
"unknown/info" before we get a chance to patch it!)
After a lot of failed attempts and head banging working trying to find a way to reuse
the standard editor-switching/creation code, I've just hacked in a temporary solution
here so that users can load old files and see the old timeline instances replaced
with Dopesheet-Timelines.
Note: This is not nice code, and copies a lot of the standard initialisation code,
but it works well enough for now. We can revisit this later when the other mode changes
come along.
These were getting set in the init() callback instead of the new(). As a result,
the settings would get reset everytime you resized the window/area - not quite
something you'd really want happening everything the size changes!
instead of using "black" curtains
With most editors now showing the start/end range by default, we need a way of
easily distinguishing when preview range is now enabled. By using a different color
(the exact color used is something we can change/adjust later), there is a more distinct
visual difference between them, making it easier to see what's happening.
This uses the global scene range, with styling matching the sequencer's start/end
frame drawing.
(The graph editor's "drivers" mode is exempt, as that doesn't really display time
in a linear way, so the start/end frames don't apply)
Eventually the idea is that they'll get remapped to some more global/generic hotkey
that can get used across all animation editors (see T54728). However, to facilitate
the removal of the timeline editor, it's better we do this now.
These were runtime only data, used in pre 2.8 Blender to make use of GL vertex arrays
to draw these more efficiently. Maybe we might restore these sometime as an optimisation
step, but for now, they're not needing and were confusing.
These now live in the action editor/dopesheet related files.
Apart from these, the timeline didn't actually have other settings
of its own that were of any interest to anyone.
For many years, animators have been requesting the ability to edit keyframes in the
timeline. However, implementing such tools in the timeline quickly becomes a slippery
slope, where we'll eventually end up having to duplicate all the functionality from the
dopesheet editor.
Discussing with William and Pablo this morning, we realised that perhaps it might be possible
to just make the Timeline a mode of the Dopesheet Editor (and kill off the old standalone
Timeline), meaning that we essentially get all the Dopesheet Editor goodness for free!
Also, with some proposed UI updates (i.e. allowing "submodes" of editors to be part of the
the main editors selector), it might not even matter that there isn't an "actual" timeline
editor anymore.
This commit implements the following changes (which are actually sufficient for supporting
most basic workflows):
* Timeline mode in Dopesheet Editor
* Tweaks to UI code to make the Timeline header/menus show up in Dopesheet editor
TODO:
* Hide channels list when switching to timeline mode
* Port over cache-file indicators
* Add missing timeline-only settings that need a new home in the dopesheet
* Go through fixing all timeline editor operators (e.g. Bind to camera)
* Port over start/end frame shading (and adjust preview range rendering to make the
distinction between these clear)
* Remove old timeline editor, and transfer over any leftover code
This "improve" the viewport experience by reducing the noise from random
sampling effects (SSAO, Contact Shadows, SSR) when moving the viewport or
during playback.
This does not do Anti Aliasing because this would conflict with the outline
pass. We could enable AA jittering in "only render" mode though.
There are many things to improve but this is a solid basis to build upon.
This pass create a velocity buffer which is basically a 2D motion vector
texture. This is not yet used for rendering but will be usefull for motion
blur and temporal reprojection.
== Main Features/Changes for Users
* Add horizontal bar at top of all non-temp windows, consisting out of two horizontal sub-bars.
* Upper sub-bar contains global menus (File, Render, etc.), tabs for workspaces and scene selector.
* Lower sub-bar contains object mode selector, screen-layout and render-layer selector. Later operator and/or tool settings will be placed here.
* Individual sections of the topbar are individually scrollable.
* Workspace tabs can be double- or ctrl-clicked for renaming and contain 'x' icon for deleting.
* Top-bar should scale nicely with DPI.
* The lower half of the top-bar can be hided by dragging the lower top-bar edge up. Better hiding options are planned (e.g. hide in fullscreen modes).
* Info editors at the top of the window and using the full window width with be replaced by the top-bar.
* In fullscreen modes, no more info editor is added on top, the top-bar replaces it.
== Technical Features/Changes
* Adds initial support for global areas
A global area is part of the window, not part of the regular screen-layout.
I've added a macro iterator to iterate over both, global and screen-layout level areas. When iterating over areas, from now on developers should always consider if they have to include global areas.
* Adds a TOPBAR editor type
The editor type is hidden in the UI editor type menu.
* Adds a variation of the ID template to display IDs as tab buttons (template_ID_tabs in BPY)
* Does various changes to RNA button creation code to improve their appearance in the horizontal top-bar.
* Adds support for dynamically sized regions. That is, regions that scale automatically to the layout bounds.
The code for this is currently a big hack (it's based on drawing the UI multiple times). This should definitely be improved.
* Adds a template for displaying operator properties optimized for the top-bar. This will probably change a lot still and is in fact disabled in code.
Since the final top-bar design depends a lot on other 2.8 designs (mainly tool-system and workspaces), we decided to not show the operator or tool settings in the top-bar for now. That means most of the lower sub-bar is empty for the time being.
NOTE: Top-bar or global area data is not written to files or SDNA. They are simply added to the window when opening Blender or reading a file. This allows us doing changes to the top-bar without having to care for compatibility.
== ToDo's
It's a bit hard to predict all the ToDo's here are the known main ones:
* Add options for the new active-tool system and for operator redo to the topbar.
* Automatically hide the top-bar in fullscreen modes.
* General visual polish.
* Top-bar drag & drop support (WIP in temp-tab_drag_drop).
* Improve dynamic regions (should also fix some layout glitches).
* Make internal terminology consistent.
* Enable topbar file writing once design is more advanced.
* Address TODO's and XXX's in code :)
Thanks @brecht for the review! And @sergey for the complaining ;)
Differential Revision: D2758
- need a draw mode in workbench engine.
- reorganized render engine retrieval in 3d view. There are 2 places
where this happenes 1. 3d view draw code and 2. draw manager.
the draw manager code is not used for external engines, currently added
an exception in for cycles. will need to have a better solution in
place.
issue was the factoring of the workspace engine that was removed. the logic implied that the clay could not be rendered as clay will be a draw mode we placed it already there so it is accessible in any engine. Should eventually fix the clay engine by migrating it to the workbench engine.
- Removed the depth pass as it will reuse the depth pass of the render
engine
- Used gl_FrontFacing to determine the facing
- Blender the result with the render engine result
use stack instead of always allocating memory for RNA paths of checked
properties! From average 167ms to 118ms here with Autumn rig... Still a
lot to improve, but that's already much better.
Implemented the face orientation overlay for testing.
Overlay mode is only drawn when there are overlays to be rendered.
The overlay mode is rendered before the object mode.
While the feature is interesting, it's not much from what we can tell.
Retargeting is an important feature but needs
to fit in better with typical animation work-flows.
See: T52809
This is rather uncommon when operator will operate on a non-active view layer,
so there is no need to do full scene update.
This change solves lag first time using Extrude operator in edit mode.
@campbellbarton: This operator works (as intended) on an object level, wich means that it won't remove doubles for vertices that are close to each other but contained in different objects - is that really helpful?
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
Will be part of the collection manager where per collection the
ob->col can be set. This currently depends on DepsGraph +
CollectionManager.
I removed it for now so the code won't influence development
Was caused by ec0756af6c, once again, we can't pass view layer,
need to pass index.
The sad part is that currently we don't have quick way to look up
view layer by index. Can do similar thing as we do for bones and
bases.
- added `object_color_type` where the user can set if the collection
determines the color, or the object will be used for the color.
Implemented it as an enum as later this can have a random color option.
- moved OB_LIGHTING_* to DNA_view3d_types and renamed it.
- Fixed some DRY in workbench_materials.c. Can remove more DRY's but
will need to discuss the responsibility of the workbench engine as it
might become part of the eevee renderer.
ViewRender was removed, which means we can't get the render engine for files
saved in 2.8. We assume that any files saved in 2.8 were intended to use Eevee
and set the engine to that.
A fix included with this is that .blend thumbails now draw with Clay mode,
and never Eevee or Cycles. These were drawn with solid mode in 2.7, and should
be very fast and not e.g. load heavy image textures.
Differential Revision: https://developer.blender.org/D3156
Assume files saved in 2.8 were intended for Eevee and set them to material
viewport shading. In Eevee this is equal to rendered draw mode, in Cycles
this will draw with Eevee. This way Eevee demo files still show something
interesting when opened.
Similar materials will reuse the same shadergroup. Currently using
a custom hash function that might select too similar colors into the
same material.
Reintroduced the workbench_materials.c this file will be responsible for
material lookup/creation and shader compilation
Fixed a GPUShader mem leak
I.E. only enable auto-override for 'active' selected object when making
an override of a linked group. This will ease on auto-override creation,
and you typically do not want to auto-override most objects in the group
anyway (in proxy system, you could only proxyfy one object of the group
anyaway!).
This is by default. We can still enable the thicker outlines for high dpi
screens or personnal preference but it's not used atm. This also improve
the performance removing 1/3 of the outline cost.
In more complex models the object color uniform data is freed before rendered.
We should copy it to local data. but for now we redirected it to a
constant.
Currently uses static lighting. Will become HDRI lighting.
Added do_versions to set default drawtype_solid and drawtype_texture to
OB_LIGHTING_STUDIO. When View3D space is created drawtype_solid and
drawtype_texture are also set to OB_LIGHTING_STUDIO.
Current studio lighting uses a dot product to simulate static lighting.
Will need to be changed in the future with different lighting models.
- added the drawtype_solid, drawtype_wireframe, drawtype_texture to
View3D
- enabled workbench panels for important render engines
- merged workbench_materials to solid_flat_mode. All draw modes will get
its own fast implementation in the workbench
Folders removed entirely:
* //extern/recastnavigation
* //intern/decklink
* //intern/moto
* //source/blender/editors/space_logic
* //source/blenderplayer
* //source/gameengine
This includes DNA data and any reference to the BGE code in Blender itself.
We are bumping the subversion.
Pending tasks:
* Tile/clamp code in image editor draw code.
* Viewport drawing code (so much of this will go away because of BI removal
that we can wait until then to remove this.
This is a way to deal with animated properties in evaluated version
off datablock. Previously, running blender with copy-on-write enabled
will show original values. Now we can see proper properties, while
typing values in still goes to the original datablock.
Thanks Brecht for the review!
Was caused by two things from the past:
- Tagging would set id->recalc to COW update flag.
This one is to be ignored.
- Particle tagging will use psys recalc flags on id->recalc,
but we only need to use flags from particles. Otherwise
it will be some collisions in bit masks.
This is just to have hair rendering and editing mostly working as in
master. A better fix is probably needed, there seems to be some
missing depsgraph relations for particle edit settings, and particle
edit code doesn't rebuild caches after applying edits. But at least
you can see and interact with hair now until those things can be
sorted out.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
This changes quite a few things.
- Outline is now per object.
- No more outline at object intersection (fix hairs problem).
- Simplify the code quite a bit.
We use a R16UI buffer to save one id per object outline. We convert this id
to color when detecting the outline.
Added textureGatherOffsets to the code but could not test on current hardware
so leaving it commented for now.
This uniforms can be used to have a unique id for each drawcall of a shgrp.
This only works for standard shgroups and is an exception for the outline
drawing.
This adds initial multi-object editing support.
- Selected objects are used when entering edit & pose modes.
- Selection & tools work on all objects however many tools need porting
See: T54641 for remaining tasks.
Indentation will be done separately.
See patch: D3101
Blender allows this.
The Cube in the file in the report would always disappear with the non camera view.
The clip_end was too small.
The correction here is only on the assert.
Note: tried with a complex production file characters, this is currently
totally non-functionnal (crashing even in a infinite recursion loop),
IDProps and override need some love :(
Although somewhat less micro efficient, I decided to separate the `viewinv` matrix to calculate the world position separately.
This makes it easier to understand the code.
While 3d cursor is mainly an UI thing and isn't needed for scene evaluation,
it is stored in scene DNA. This means, operator is inform depsgraph that data
has changed, so all copies of that scene can copy new values.
Fixes lack of visual feedback when changing cursor location in viewport
with copy-on-write enabled.
This gets rid of the need of a geom shader and instancing.
Both are pretty slow compared to the new method.
The only moment the old method could be better is when scene is filled
with lots of objects and most of the objects in the shadow map appear
on every layer.
But even then, we could optimize the culling and minimize the overhead.
E.g. the vertices created for each of the defines would require a
certain offset. If you don't know what to look for, finding out about
this is pretty difficult. Make them easily searchable instead.
There is quite some mess going on in that most of the old triangle
drawing code is still there, but does almost nothing effectively.
Instead values are hardcoded in the shader, however it doesn't support
the drawing options the triangle functions expose.
E.g. the 'where' variable to set triangle direction doesn't work.
For correct results these must have been set already when the depsgraph was
created and evaluated, so all dependencies have appropriate resolutions too.
For particle we no longer backup and restore the viewport particles to avoid
overwriting them during render, as copy-on-write solves this for us. Even
without COW particles seem to work ok.
This also removes the particle simplification options based on camera. This
was never used much and only available in Blender Internal.
Differential Revision: https://developer.blender.org/D3148
This was only used for viewport rendering, where we can just pass the engine
type directly. There is no technical reason why we can't draw the same depsgrpah
with different render engines.
It also led to some weird things like requiring a render engine for snapping
and raycast API functions.
Differential Revision: https://developer.blender.org/D3145
Scene, view layer and mode are now set in the constructor and never changed.
Time is updated on frame changes to indicate which frame is being or has been
evaluated last.
This is a step towards making EvaluationContext obsolete.
Differential Revision: https://developer.blender.org/D3144
Cycles is no longer using this. There are still addons using it but for
correct results with the new depsgraph this API should not be used.
Differential Revision: https://developer.blender.org/D3143
We now only look into dupli groups to find point caches to edit. This
feature is a leftover from the old proxy system, and evaluating the
full dupli list and all transforms was overkill. With static overrides
we may want to get rid of using duplis entirely, and just let users
select the objects directly.
I can see how it's slowing things down: glFinish make sure that every query
are finished but the first query may have been finished a long time ago.
This might create bubbles because of the PIL_sleep_ms.
Unless there is an external action from an user, there should not
be need in re-copying original datablock to a copied one.
This brings performance up from 5fps to 11fps with Spring runcycle
(performance in master is 14fps).
Quite straightforward implementation, allows us to remove all the cherry-picking
update of specified scene/view layer/collection fields. Makes it possible to use
generic function to update scene.
The tricky part is that we need to know view layer pointer before the whole
evaluation starts. So we actually expand scene at initialization of evaluation.
context. This is still a bit of an exceptional case, but at least we still avoid
dangerous cherry-picking update.
For the performance we convert object bases list to an array
during view layer evaluation. This makes it possible to have
very cheap index-based base lookup.
The goal of this change is to get rid of base used for function
binding, and avoid scene datablock expansion at the depsgraph
construction time.
Use single function to evaluate all the collections for the given view layer.
This way we avoid need to get scene ID sub-data. Similar to pchan index, this
allows us to avoid build-time scene expansion, which also simplifies update of
the scene datablock.
Well, sort of. There is still work to be done to get rid of build-time scene
datablock expansion, which includes:
- Need to pass view layer by index.
Annoying part would be to get actual view layer for that index. In practice
doing list lookup might not be such a bad idea, since such lookup will not
happen very often, and it is unlikely to have more than handful of view
layer anyway.
Other idea could be to use view layer from evaluation context.
Or maybe from depsgraph, which is supposed to be in the context. Can have
some assert statements to make sure everything is good.
- Need to get id of base binding for flags flush.
We can replace that with index-based lookup from an array created by view
layer evaluation.
Reviewers: dfelinto
Differential Revision: https://developer.blender.org/D3141
Got lost in big undo refactor.
Note that this is probably (maybe) not how we want to have it in the
end, things like EditMode undo should probably not trigger this check?
Only recreate ogl context if we cannot reuse the one of the previous thread.
Adding lots of shaders were recreating as many ogl context which was very
slow.
This happened when creating a window with the cursor over the timeline area.
I still don't know exactly what happened but for a reason batches were not
reset in this case.
This means fewer indices to store. That being said, it seems to be a little
slower because of the restart index. But that's in the case we would be
vertex bound, which is mostly never going to happen.
Some of the code is simpler because we use Blender's triangulation directly
instead of dealing with quads. Also some progress printing code was removed
because the depsgraph can not tell us the number of objects ahead of time.
Differential Revision: https://developer.blender.org/D3127
- Disable scissor test for fast clear. This could lead to some issues but
I cannot think of one and could not find one either.
- Manually wait for queries to be available instead of making the driver
wait and issue warnings.
Previous code was assuming that the glyph texture would remain bound to
GL_TEXTURE0 until the cache would be drawn. This is not always the case,
so better save the texture and rebind it before drawing.
This port the Blurring of blf fonts to the final drawing shader.
We add a bit of extra padding to each glyph so that jittering the texture
coord does not sample the neighbor glyphs.
Overall 10% more performance on general UI drawing time.
This commit can introduce ordering problem on some elements.
In this case you need to flush the widget cache to ensure the element that
is going to be drawn is drawn on top of any widget base.
To flush the cache use UI_widgetbase_draw_cache_flush.
This is already done for BLF and Icons.
Replace the 12 iterations of UI_draw_roundbox_4fv with only one batch.
This mean less overdraw and less drawcalls.
I had to hack the opacity falloff curve manually to get approximatly the
same result as previous technique. I'm sure with a bit more brain power
somebody could find the perfect function.
Use the new GPU_SHADER_2D_NODELINK and GPU_SHADER_2D_NODELINK_INST to
accelerate nodelink drawing.
This commit does not include the batching functionnality. So this should
not make a lot of difference.
Now use a list of preset batches with a function to add new ones to this
list.
This removes the need of new functions all over the place to reset/exit.
Special shader to draw nodelinks for the node editor.
We only pass bezier points to the GPU and vertex position is handled inside
the vertex shader.
The arrow is also part of the batch to avoid separate drawcalls for it.
We still draw 2 pass one for shadow and one for the link color on top.
One variation to draw instances of theses links so that we only do one
drawcall.
The issue was caused by component tag forcing CoW component to be run,
without actually flushing changes down the road from the CoW operation.
In a way, this is what we want: we do want CoW to run on changes, but
we don't want tiny change forcing full datablock update.
This commit makes it so order of updates is all correct, but the bigger
issue is still open: what parts of datablock CoW should be updating?
Now it's possible to open spring file and play around.
The issue was mainly visible when copy-on-write was enabled. This was forcing
lots of meshes to be freed from multiple thread, causing all sorts of race
conditions in Gawain's VAO code.
OpenGL resources seems already to be doing deferred deletion, need to do the
same for CPU side arrays.
The problem was that textures were assigned to different slots on different draw
calls, which caused shader specialization/patching by the driver. So the shader
would be compiled over and over until all possible assignments were used.
This is really minor but anyways, now it will only leak if you cancel the menu.
And that only if htis is the last time you called this operator before closing
Blender.
- Undo that changes modes currently asserts,
since undo is now screen data.
Most likely we will change how object mode and workspaces work
since it's not practical/maintainable at the moment.
- Removed view_layer from particle settings
(wasn't needed and complicated undo).
For this we use a new shader that gets it's data from a uniform array.
Vertex shader position the vertices using these data.
Using glUniform is way faster than using imm for that matter.
Like BLF rendering, UI icons are always (as far as I know) non occluded and
displayed above everything else. They also does not overlap with texts so
they can be batched at the same time.
This adds less than a megabyte of mem usage.
FT_Get_Kerning was the 2nd hotspot when profilling. This commit completly
remove this cost.
One concern though: I don't know if the kerning data is constant for every
sizes but it seems to be the case. I tested different fonts at different
dpi scalling and saw no differences.
I left a flag to quickly debug if something is wrong.
But now that everything uses shader, it seems to be alright since a shader
is always set active before drawing.
I've made a separate version of the geom shader that works with full
3D modelviewmat.
This commit also includes some fixup inside blf_batching_start().
You can now use BLF_batching_start and BLF_batching_end to batch every
drawcall to BLF together minimizing the overhead introduced by BLF and the
opengl driver.
These calls cannot be nested (for now).
If the modelview matrix changes, previously batched calls are issued and a
the process resume with the new matrix.
However the projection matrix MUST not change and gl scissors as well.
This is not a perfect win just yet. It's now calling glBufferSubData for
every call (instead of using glMapBufferRange which is almost faster), but
with this system we will be able to batch drawcalls together.
See next commit.
This allows us to specify a the number of vertices to upload to the gpu.
This is to keep the same allocation on the System Memory but send the least
amount of data to the GPU/Driver.
Selecting not only the objetcs directly linked to the selected collection.
So we also do it for the objetcs in the nested collections, just as we can
do from the outliner.
Use Shift+G > Collection. If there is only one collection, it just selects it,
if there are multiple ones user get to pick which one to select.
This is the same behaviour we have for groups. Note, we only select objects
directly in the collection, not the ones in any nested collection.
Feature suggested by Pablo Vazquez (venomgfx)
This means smaller imm buffer usage.
This does not reduce the number of drawcalls.
This uses geometry shader which is slow for the GPU but given we are really
CPU bound on this case, it should not matter.
A perfect implementation would:
- Set the glyph coord in a bufferTexture and just send the glyph ID to the
GPU to read the bufferTexture.
- Use GWN_draw_primitive and draw 2*strllen triangle and just retrieve the
glyph ID and color based on gl_VertexID / 6.
- Stream fixed size buffer that the Driver can discard quickly but this is
the same as improving IMM directly.
Fix for T54437: Sequencer preview uses last updated scene
The fix started in master, moving EvaluationContext initialization
before we leave `deg_evaluate_on_refresh()`.
Upon merging master we can fix the actual issue which was to set
the EvaluationContext depsgraph even if the depsgraph was already updated.
Introduce a UI batch cache. For the moment it's only used by widgetbase so
leaving it interface_widgets.c. If it grows, it can have its own file.
Like all preset batches (batches used by UI context), vaos must be refreshed
each time a new window context is binded.
This still does 3 GWN_batch_draw in the worst cases but at least it does
not use the IMM api.
I will continue and batch the 3 calls together since we are really CPU
bound, so shader complexity does not really matters.
I cannot spot any difference on all the widgets I could test. I did not use
any unit tests so I cannot tell if there is really any defects.
This is not a complete rewrite but it adresses the top bottleneck found
after a profilling session.
Use more generic id->recalc flag.
Also sanitize flag flush from settings to particle system.
Need to do such flush before triggering point cache reset, since
point cache reset will do some logic based on what flags are set.
This will solve crash caused by threaded update which will set
some bitflags while point cache reset is in progress.
The way how particle state is to be accessed or used did not change
in Blender 2.8, so the drawing code should follow old design.
This code is somewhat duplicated from drawobject.c, but old draw
code is on the way to be removed anyway.
This fixes issue with disappearing particles when tweaking number
of particles.
Tagging based on components might not be granular enough.
For example, for particles we would want to know what part
of particles was changed exactly. For the flushing we wouldn't
worry too much, because we will want less granular updates
there anyway.
How to use: Select a few objects, and press "M" in the viewport.
If you hold ctrl the objects will be added to the selected collection.
Otherwise they are removed from all their original collections and moved
to the selected one instead.
Development Notes
=================
The ideal solution would be to implement an elegant generic multi-level
menu system similar to toolbox_generic() in 2.49.
Instead I used `uiItemMenuF` to acchieve the required nesting of the menus.
The downside is that `uiItemMenuF` requires the data its callback uses to be
always valid until the menu is discarded. But since there is no callback we
can call when the menu is discarded for operators that exited with
`OPERATOR_INTERFACE`.
That means we are using static allocated data, that is only freed next time
the operator is called. Which also means there will always be some
memory leakage.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D3117
Drawcall per window redraw on default layout:
- 4100+ without patch
- 1270 with patch
Theses drawcalls meant a lot of driver overhead since they each correspond
to one glMapBuffer which is slow.
Remain convinced that it should not be possible for undo code to run in
parallel with DEG eval... But for now, this whould prevent static
override code to dive into this collection.
This refactor modernise the use of framebuffers.
It also touches a lot of files so breaking down changes we have:
- GPUTexture: Allow textures to be attached to more than one GPUFrameBuffer.
This allows to create and configure more FBO without the need to attach
and detach texture at drawing time.
- GPUFrameBuffer: The wrapper starts to mimic opengl a bit closer. This
allows to configure the framebuffer inside a context other than the one
that will be rendering the framebuffer. We do the actual configuration
when binding the FBO. We also Keep track of config validity and save
drawbuffers state in the FBO. We remove the different bind/unbind
functions. These make little sense now that we have separate contexts.
- DRWFrameBuffer: We replace DRW_framebuffer functions by GPU_framebuffer
ones to avoid another layer of abstraction. We move the DRW convenience
functions to GPUFramebuffer instead and even add new ones. The MACRO
GPU_framebuffer_ensure_config is pretty much all you need to create and
config a GPUFramebuffer.
- DRWTexture: Due to the removal of DRWFrameBuffer, we needed to create
functions to create textures for thoses framebuffers. Pool textures are
now using default texture parameters for the texture type asked.
- DRWManager: Make sure no framebuffer object is bound when doing cache
filling.
- GPUViewport: Add new color_only_fb and depth_only_fb along with FB API
usage update. This let draw engines render to color/depth only target
and without the need to attach/detach textures.
- WM_window: Assert when a framebuffer is bound when changing context.
This balance the fact we are not track ogl context inside GPUFramebuffer.
- Eevee, Clay, Mode engines: Update to new API. This comes with a lot of
code simplification.
This also come with some cleanups in some engine codes.
This is a bit useless because gpu lamps are only used by the game engine
and it is planned to be "remove" in some way.
Doing this to clean gpu_framebuffer.c.
This includes a few modification:
- The biggest one is call glActiveTexture before doing any call to
glBindTexture for rendering purpose (uniform value depends on it).
This is also better to know what's going on when rendering UI. So if
there is missing UI elements because of this commit look for this first.
This allows us to have "less calls" to glActiveTexture (I did not
measure the final count) and less checks inside GPU_texture.
- Remove use of GL_TEXTURE0 as a uniform value in a few places.
- Be more strict and use BLI_assert for bad usage of GPU_texture functions.
- Disable filtering for integer and stencil textures (not supported by
OGL specs).
- Replace bools inside GPUTexture by a bitflag supporting more options to
identify texture types.
This commit essentially introduces a new RNA property flag, which when
set prevents affected property from being processed at all in comparison
code (also used to automatically generate static override rules).
The idea is to use it on very low-level data in RNA, like e.g. mesh's
geometry or psys' particles collections.
For now only applied to psys' particle collections, on the main mesh of
Agent327 pigeon, it goes from 100ms to 0.5ms on a full
auto-override-generating comparison...
Also added some new RNA property helper funcs to check on comparable and
overridable status.
This module has no use now with the new DrawManager and DrawEngines and it
is using deprecated paths.
Moving gpu_shader_fullscreen_vert.glsl
to draw/modes/shaders/common_fullscreen_vert.glsl
Steps to reproduce were:
* Append a workspace (via '+' icon) - make sure its from the default workspaces.blend
* Activate it
* Should crash
Was accessing data from view-layer which wasn't updated yet (and thus could be
NULL). Crash occured after rB8153f89518b4a.
@campbellbarton, you may want to check if all object-mode stuff still works as
expected, not sure what's the state of it.
It is possible that datablock will not be re-used for the new
dependency graph building. Freeing function was freeing all
the nested pointers of databnlock, but not datablock memory
itself.
With the API recently added to gawain, it is now possible to update the vbos linked to the batch.
So the batch does not have to be destroyed.
The optimization is more sensitive when sculpt is made on low poly meshs
We revert to the malloc/realloc and manually manage the upload.
There seems to be a performance penalty from using glMapBuffer on some
hardware, prefering way is glBufferData(NULL) with glBufferSubData.
- Upload the data to the GPU directly when creating the element buffer in
GWN_indexbuf_build_in_place().
- Convert data in place when squeezing the indices and removing the need
for another allocation.
- GWN_indexbuf_build_in_place() can be used with already used element
buffers and reupload their data without changing vbo id (keeping vaos
up to date).
We now alloc a vbo id on creation and let OpenGL manage its memory directly.
We use glMapBuffer to get this memory location.
This enables us to reuse and modify any vertex buffer directly without
destroying it with its associated Batches.
This commit does not really improve performance but will let us implement
more optimizations in the future.
We can also resize the buffer even if this can be slow if we need to keep
the existing data.
The addition of the usage hint makes dynamic buffers not a special case
anymore, simplifying things a bit.
When a name property is defined for collection's struct, but no name is
actually set, we want to also fallback to index case. We cannot handle
empty names to address items of a collection!
Previous approach was not clear enough and caused problems.
UBOs were taking slots and not release them after a shading group even
if this UBO was only for this Shading Group (notably the nodetree ubo,
since we now share the same GPUShader for identical trees).
So I choose to have a better defined approach:
- Standard texture and ubo calls are assured to be valid for the shgrp
they are called from.
- (new) Persistent texture and ubo calls are assured to be valid accross
shgrps unless the shader changes.
The standards calls are still valids for the next shgrp but are not assured
to be so if this new shgrp binds a new texture.
This enables some optimisations by not adding redundant texture and ubo
binds.
Basically, don't do full in-place copy of node tree datablock if it's
already expanded. Current way how node tree is evaluated is fully
built around the idea that evaluation copies values from original
to copied datablocks.
Changing links is handled on another level.
Old solution was to create a new vbo and copy it to the location of
the old vbo hoping for the batches to update their vaos before drawing.
The issue is that the new VAO caching is not updating the VAOs at all
unless the shader interface changes.
So unless we expand gawain to support updating of vertex buffers (in a
better way than the current "dynamic" buffer) we need to delete every batch
linked to the vbo we want to recreate.
This solution might have performance implications.
Even if they are for safety they are not free to use !
On my system (Mesa + AMD Vega GPU) calling:
glBindVertexArray(1);
glDrawArrays(GL_TRIANGLES, 0, 3);
glBindVertexArray(0);
in a loop, shows the same overhead as a full vao switching (which is more
or less 10 times slower than just calling glDrawArrays)
Moreover, now that we use OpenGL 3.3 binding a VAO is REQUIRED to issue a
drawcall so it is garanted to be overwritten before the next drawcall.
Problem can only happen if someone draws directly with opengl commands.
This allows to draw multiple primitive of the type
GWN_PRIM_LINE_STRIP
GWN_PRIM_LINE_LOOP
GWN_PRIM_TRI_STRIP
GWN_PRIM_TRI_FAN
GWN_PRIM_LINE_STRIP_ADJ
with only one drawcall. This should speed up some areas that are really
sensitive to drawcall counts : UV drawing, Hair drawing...
The issue was only visible with copy-on-write enabled, and related to the
fact, that dependency graph builder binds original FCurves.
For now use smallest patch possible to make things to work and to make
draguu happy.
Need to think of a smarter way to deal with drivers, bones and view layers.
I tried to use real multisampling but the main problem is the outline detection that needs to have matching depth samples.
So adding FXAA instead. Always on for now, may add a parameter for it later.
One thing to note is that we need to copy the final output once again to the main color buffer because we cannot swap the dtxl textures (they can be referenced elsewhere like GPUOffscreen).
We could improve upon this and add TAA on top if viewport is still.
This means that rendering clay with AO only needs 1 geometry pass.
Thus greatly improving performance of poly heavy scene.
This also fix a self shadow issue in the AO, making low sample count
way better.
We also do not need to blit the depth anymore since we
are doing a fullscreen shading pass.
The constant cost of running the a deferred shading pass is negligeable.
This include quite a bit of code cleanup inside clay_engine.c.
The deferred pipeline is only enabled if at least one material needs it.
Multisampling is not supported yet.
Small hacks when doing deferred:
- We invert the normal before encoding it for precision.
- We put the facing direction into the sign of the mat_id.
- We dither the normal to fight the low bitdepth artifacts of the normal
buffer (which is 8bits per channel to reduce bandwidth usage).
Sequencer rendering can use multisample render targets. Be sure to sync
thoses after rendering.
Also disable the sample loop when not needed.
Do note that currently the color correction is broken with the sequencer.
Looks like someone changed the signature of some RNA update callback,
and for some reason that 'change skey' update function was not updated
(or later got merged from master)...
We'll need RNA to check for its func signatures, some day...
Calling the rendering operator seems to kill any other WM_job running, leaving
uncompiled materials into a GPU_MAT_QUEUED state. This then made the probe update
looping indefinitely (all_materials_updated remaining to false).
To fix this, we resume compilation for materials that are in this state.
Cancelling Render before all material compilation could make certain material
remain uncompiled. Fortunately, this is not allowed as of now.
This is mostly to avoid re-compilation when using undo/redo operators.
This also has the benefit to reuse the same GPUShader for multiple materials using the same nodetree configuration.
The cache stores GPUPasses that already contains the shader code and a hash to test for matches.
We use refcounts to know when a GPUPass is not used anymore.
I had to move the GPUInput list from GPUPass to GPUMaterial because it's containing references to the material nodetree and cannot be reused.
A garbage collection is hardcoded to run every 60 seconds to free every unused GPUPass.
This leads to less lookups to the GWNShaderInterface and less uniform upload.
We still keep a legacy path so that Builtin uniforms can still work. We might restrict this path to Builtin shader only in the future.
You can now cancel your renders that are too long. This will still output the current status of the render. For example if you cancel at 50% rendering progress, you will have a render result with only half the render samples.
This also fix a bug with the probe debug display when there was more than 2 probes. ped->probe_id was equal to 0 for all planar probes until the next frame. Resulting in all planar data debug to show probe 0.
- put render iterator in own scope
(would shadow it's own variable if used multiple times).
- enforce semicolon at end of iterator macros.
- no need to typedef one-off macro structs.
Reverts rBb9ae517794765d6a1660 and fixes the issue properly. Old fix could cause
NULL to be passed to functions that expect all arguments to be non-NULL.
The idea is to separate the most common case from symmetrical frustum. And to make a simple but efficient calculation.
The new radius is usually 98% the size of the radius size of the asymmetric solution.
Thanks to @fclem for reviewing the patch on IRC
Also get rid of the static var and initialization.
This enables the user to see the progress on the info header.
Closing blender or reading a file also kill the job which is good.
Unfortunatly, this job cannot be interrupt by users directly. We could make it interruptible but we need a way to resume the compilation.
In the gpus like `AMD Radeon HD 7570M` and `Intel(R) HD Graphics 4000` this solution improves performance a hundreds or even thousands of times depending on the resolution.
Reviewed By: @brecht and @fclem
Differential Revision: https://developer.blender.org/D3095
I keep reading that texture painting is not working yet. However it is fully
working. We even have a "Full Shading" option in the viewport display panel.
Clay/EEVEE still need their UI figured out. But the context itself is doing
its part after this patch, and at least for Cycles it's working like 2.79.
Instead of creating a new instancing shading group without attrib, we now have instancing calls. The benefits is that they can be culled.
They can be used in conjuction with the standard and generate calls but shader must support it (which is generally not the case).
We store a pointer to the actual count so that the number can be tweaked between redraw.
This will makes multi layer rendering more efficient.
It was too tricky to know ahead of time if an object would still
be visible in the new window/workspace/scene/layer combination,
especially since other windows may share some of these data-blocks.
So store the context, make the change, then check if the object is
still visible, freeing mode data of it's not.
Note that this code will likely be generalized,
currently each new case is a little different though
so it's too early to move them into general functions.
This (now removed code) calls gl_Vertex deprecated draws. It was doing
background drawing (color gradient, flat background) which is not used
by any engine.
Selection code relies on being able to set the depth functions
however passes have their own depth settings.
Add DRW_state_lock to ignore passes settings for particular flags.
This fixes occlusion queries cycling through objects under the cursor.
By default select wasn't picking the nearest object,
this could have been fixed by not clearing the depth buffer,
but calling GPU_select_(begin/end) without the binded frame-buffer
caused issues for depth-picking. So move GPU_select begin/end to a
callback.
This also has the advantage that only needs to populate the engines once
to draw two passes.
Note that cycling through objects fails with occlusion queries still,
will fix shortly.
This is very efficient and add a pretty low overhead (0.1ms of drawing time for 10K objects passing through all tests, on my i3-4100M).
The like the rest of the DRWCallState, test is "cached" until the view matrices changes.
In some cases it doesn't make sense for add-ons to be listed for hiding.
Especially for import/export which use minimal UI space.
This adds `bl_info["use_owner"]` to add-ons,
currently defaulting to True for all non Import-Export add-ons.
Now the only missing bit seems to be in Cycles to pass depsgraph to
builtin_image_float_pixels().
Ideally we could get evaluation context instead of using depsgraph + settings.
But for the other rna EvaluationContext functions this is how we are doing.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D3087
Allows for each workspace to have it's own add-ons on display.
Filtering for: Panels, Menus, Keymaps & Manipulators.
Automatically applies to add-ons at the moment.
Access from workspace, toggled off by default
once enabled, add-ons can be white-listed.
See D3076
When changing the mode of an object, apply this to all other
workspaces that share the same active object.
Also use copy the object-mode when duplicating workspaces.
Refactor include:
- Removal of DRWInterface. (was useless)
- Split DRWCallHeader into a new struct DRWCallState that will be reused in the future.
- Use BLI_link_utils for APPEND/PREPEND.
- Creation of the new DRWManager struct type. This will enable us to create more than one manager in the future.
- Removal of some dead code.
This still does not make point density to work in Cycles, but at least it pass
the depsgraph down the line.
Note this was working fine before the depsgraph/render refactor to pass
evaluated depsgraph to the engines.
User notes
----------
Compositing, rendering of multi-layers in Eevee should be fully working now.
Development notes
-----------------
Up until now we were still using the same depsgraph for rendering and viewport
evaluation. And we had to go out of our ways to be sure the depsgraphs were
updated.
Now we iterate over the (to be rendered) view layers and create a depsgraph to
each one, fully evaluated and call the render engines (Cycles, Eevee, ...) with
this viewlayer/depsgraph/evaluation context.
At this time we are not handling data persistency, Depsgraph is created from
scratch prior to rendering each frame. So I got rid of most of the partial
update calls we had during the render pipeline.
Cycles: Brecht Van Lommel did a patch to tackle some of the required Cycles
changes but this commit mark these changes as TODOs. Basically Cycles needs to
render one layer at a time.
Reviewers: sergey, brecht
Differential Revision: https://developer.blender.org/D3073
-Make the view and object dependant matrices calculation isolated and separated, avoiding non-needed calculation.
-Adding a per drawcall matrix cache so that we can precompute these in advance in the future.
-Replaced integer uniform location of only view dependant builtins by DRWUniforms that are only updated once per shgroup.
Now that Eevee has support for offline rendering (F12) we can use it for
the Material previews.
Note: This makes the duplicated UI issue one panel worse. That happens when
Cycles if your scene engine, and Eevee is your workspace engine.
Depth picking needs to read the depth buffer after drawing
since GPU_select_end runs in a different OpenGL context
reading the depth buffer wasn't working.
This caused the last object to be unelectable.
This patch adds F12 offline Freestyle rendering support to Eevee.
Most functionalities are identical with those found in Cycles.
The only major difference is that the per-view layer "use Freestyle" toggle
option is currently placed in the "Passes" panel of the "View Layers"
properties window instead of a "Layer" panel as in Cycles. Since Freestyle
is a post-processed overlay and not a pass, the present option location is
a compromise. To describe this fact, the per-layer "use Freestyle" option
is in a subsection labeled as "Layer".
Reviewers: fclem, brecht, campbellbarton
Reviewed By: fclem, brecht
Subscribers: dfelinto
Differential Revision: https://developer.blender.org/D3084
This separate context allows two things:
- It allows viewports in multi-windows configuration.
- F12 render can use this context in a separate thread and do a non-blocking render.
The downside is that the context cannot be used while rendering so a request to refresh a viewport will lock the UI. This is something that will be adressed in the future.
Under the hood what does that mean:
- Not adding more mess with VAOs management in gawain.
- Doing depth only draw for operators / selection needs to be done in an offscreen buffer.
- The 3D cursor "autodis" operator is still reading the backbuffer so we need to copy the result to it.
- All FBOs needed by the drawmanager must to be created/destroyed with its context active.
- We cannot use batches created for UI in the DRW context and vice-versa. There is a clear separation of resources that enables the use of safe multi-threading.
Offscreen contexts are not attached to a window and can only be used for rendering to frambuffer objects.
CGL implementation : Brecht Van Lommel (brecht)
GLX implementation : Clément Foucault (fclem)
WGL implementation : Germano Cavalcante (mano-wii)
Other implementation are just place holder for now.
Turns out to be the call that was destroying performance.
I get 18ms->6ms improvement of drawing time with 10 000 unique objects.
And we can still improve upon this!
This replaces the blackbody to RGB code with the simpler and faster one from
Cycles. It's a little different but the other placing using this is the legacy
volume drawing, so no need to stay compatible with that.
Technically the original issue is that xof/yof in render result is calculated
for drawing border render. So a simpler patch could be:
```
- rr->xof = re->disprect.xmin;
+ rr->xof = re->disprect.xmin + BLI_rcti_cent_x(&re->disprect) - (re->winx / 2);
```
However everywhere in the code we are getting border directly from re->disprect
which we may as well do here too.
Besides I'm taking this as a chance to get rid of RenderResult in the internal
loop of eevee, to help prepare the code to the upcoming rendering pipeline
changes.
This is not an ideal solution but blender freeing system is already well tangled.
So tracking and clearing vao caches when destroying contexts does prevent bad behaviour.
Was temporarily removed when moving object mode to workspace.
Note: there is an issue where eval_ctx->view_layer is NULL on load,
for now pass a view layer argument, we might wan't to set the value
instead.
This reverts commit 87c72a7d27.
Caused T54121 which breaks blend file saving.
For now crash on exit is preferable.
Possible solution is to free screen-manipulator batches in a separate
loop.
A major bottleneck of current implementation is the call to create_bindings() for basically every drawcalls.
This is due to the VAO being tagged dirty when assigning a new shader to the Batch, defeating the purpose of the Batch (reuse it for drawing).
Since managing hundreds of batches in DrawManager and DrawCache seems not fun enough to me, I prefered rewritting the batches itself.
--- Batch changes ---
For this to happen I needed to change the Instancing to be part of the Batch rather than being another batch supplied at drawtime.
The Gwn_VertBuffers are copied from the batch to be instanciated and a new Gwn_VertBuffer is supplied for instancing attribs.
This mean a VAO can be generated and cached for this instancing case.
A Batch can be rendered with instancing, without instancing attribs and without the need for a new VAO using the GWN_batch_draw_range_ex with the force_instance parameter set to true.
--- Draw manager changes ---
The downside with this approach is that we must track the validity of the instanced batch (the original one). For this the only way (I could think of) is to set a callback for when the batch is getting free.
This means a bit of refactor in the DrawManager with the separation of batching and instancing Batches.
--- VAO cache ---
Each VAO is generated for a given ShaderInterface. This means we can keep it alive as long as the shader interface lives.
If a ShaderInterface is discarded, it needs to destroy every VAO associated to it. Otherwise, a new ShaderInterface with the same adress could be generated and reuse the same VAO with incorrect bindings.
The VAO cache itself is using a mix between a static array of VAO and a dynamic array if the is not enough space in the static.
Using this hybrid approach is a bit more performant than the dynamic array alone.
The array will not resize down but empty entries will be filled up again. It's unlikely we get a buffer overflow from this. Resizing could be done on next allocation if needed.
--- Results ---
Using Cached VAOs means that we are not querying each vertex attrib for each vbo for each drawcall, every redraw!
In a CPU limited test scene (10000 cubes in Clay engine) I get a reduction of CPU drawing time from ~20ms to 13ms.
The only area that is not caching VAOs is the instancing from particles (see comment DRW_shgroup_instance_batch).
This allows allocation of VAOs from different opengl contexts and thread as long as the drawing happens in the same context.
Allocation is thread safe as long as we abide by the "one opengl context per thread" rule.
We can still free from any thread and actual freeing will occur at new vao allocation or next context binding.
We need to move the render result logic outside the render engine code.
It makes no sense for Eevee/Clay/... to have to re-implement the render resilt
creation logic. Beside the original implementation really got it wrong, by
ignoring the different render layers needed for the final render.
Finally, there is no need to re-create the logic for views. So this was also
fixed.
Note 1: This will break still if the depsgraph of the needed view layers is not
updated / created. We need to address this separately. For now if users want
to test this, just show each view layer in the viewport at least once.
Note 2: We are still getting depsgraph from scene and creating if needed.
`BKE_scene_get_depsgraph(scene, view_layer, true);` according to Sergey we need
to move the render depsgraph for the Render struct instead. I will do it
separately as well.
view_layer is NULL when the render engine is created, this gets passed
around and ends up in this code causing a crash. This should be reverted
after the render engine api is updated to set view_layer.
The conditionals in particle code are... some sort of madness... I'm not
even sure what the correct behavior should be from looking at it.
In this case the path cache generation was being skipped in edit mode.
Due to changes in draw code particles from old files that may have had a
default draw size of 0 will not be visible. Old draw code would check
for this and adjust the size, however the unit for draw size has changed
from pixels to BU, and it no longer makes sense to have such checks.
This patch is to ensure particles from such files remain visible.
This removes the need of custom attribs for instancing.
Instancing works fully with dynamic batches & Gwn_VertFormat now.
This is in prevision of the VAO manager patch.
This manager allows to distribute existing batches for instancing
attributes. This reduce the number of batches creation.
Querying a batch is done with a vertex format. This format should
be static so that it's pointer never changes (because we are using
this pointer as identifier [we don't want to check the full format
that would be too slow]).
This might make the original Instance Data manager useless but it's currently used by DRW_object_engine_data_ensure().
Theses batches keeps their memory chuck allocated after transfer to be reused and updated very often.
NOTE: This commit break instancing in DRW. (it's fixed in the next commit)
Now that the new 3D viewport draws to a multisample offscreen buffer, there is
no good reason anymore to create an entire multisample window and pay the
performance/memory cost for other regions that don't need it.
GL_MULTISAMPLE now only gets enabled for offscreen buffers, so we don't need
to check for it throughout the UI code anymore.
Differential Revision: https://developer.blender.org/D3062
Instead of cloning the window to create dummyHWNDs and dummyHDCs to avoid calling the SetPixelFormat more than once in the same window, use the original window and HDC and do not call the SetPixelFormat again.
In addition to avoiding a lot of unnecessary calls, it simplifies the code and makes it match the others OS
Cycles already uses 1.5 as default. BI original 1.0 filter doesn't look good for
Eevee. The ideal scenario would be for both Cycles AND Eevee to use the same DNA
setting.
But for now it is nice to at least have Eevee renders to look better by default.
Note: This handles doversion for 2.7x files only. Files previously created in
2.8 need to be manually corrected.
We were not passing a scene collection parent to the BKE_collection_add
function, which in turn made syncing not work.
Right now we:
* Explicitly pass the master collection in this case
* Fallback to the master collection in other cases
With unittest.
- Read-only access can often use EvaluationContext.object_mode
- Write access to go to WorkSpace.object_mode.
- Some TODO's remain (marked as "TODO/OBMODE")
- Add-ons will need updating
(context.active_object.mode -> context.workspace.object_mode)
- There will be small/medium issues that still need resolving
this does work on a basic level though.
See D3037
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.
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.
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.
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).
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.
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.
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().
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...). ;)
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.
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 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.
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
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
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.
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.
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
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 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 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.
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
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).
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().
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.
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.
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.
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)
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).
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).
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.
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.
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.
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.
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.
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.
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.
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"
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
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.
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.
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.
- 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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
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().
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.
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
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).
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.
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.
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.
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.
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.
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).
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.
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.
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.
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
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 was introduced on 9ad2c0b615.
Although this still doesn't fix the issue, it updates the preview
system to use COLLECTION_DISABLED as intended.
What is missing now is for the flushing to work effectively.
This add the possibility to add screen space raytraced shadows to fix light leaking cause by shadows maps.
Theses inherit of the same artifacts as other screenspace methods.
Tried 101 but it gives colisions.
I think 257 is enough now that we dont have thousands of uniforms.
This gives some noticeable performance improvement.
Could be refined further.
This changes quite a few things:
- Drops the allocation of inputs as a chunk.
- Merge the linked list system into the Gwn_ShaderInput.
- Put name buffer into another memory block, easily resizable.
- Use offset instead of char* to direct to input name.
- Add only requested uniforms dynamicaly to the Shader Interface.
This drops some minor optimisation and use a bit more memory for small shaders (which are fixed count).
But this saves a lot of memory when using UBOs because the names and the Gwn_ShaderInput were alloc'ed for every UBO variable.
This also reduce the Shader Interface initial generation.
The lookup time is left unchanged.
This is an internal structure, and we don't put it to a list for anything else
that hash collision resolution. No need to have dedicated entry here, saves us
from extra allocation and pointer dereference.
This way we reduce number of loops from look-over-all-inputs to
loop-over-collision, which is expected to be much less CPU ticks.
There is still possible optimization: use memory pool of some sort
to manage memory needed for hash entries, but that will only speedup
shader interface construction / deconstruction time.
There are also some trickery happening to speed up process even more
in the case there is no hash collisions detected when constructing
shader interface.
- Separate the Post Processes settings into sub panel.
- Rename "Viewport Anti-Aliasing" to sampling & super-sampling as it also reduce the noise of other effects.
- Remove Temporal Anti-Aliasing toggle and make it always active unless the number of samples is 1.
Notes:
- Changes in paint_vertex.c were simple to merge, mainly related on passing
evaluation context.
- Conflicts in EditDM and drawmesh.c are solved using code from blender2.8
branch. Those areas are deprecated and not to be used in final release.
However, it's possible that some reference code from master is lost, so
keep attention when adding alpha support for vertex painting.
This required some small changes to the data display shaders so that they match the way the object mode renders them.
Strangely enough, I had to remove the normal attribute from the display code because it was being not bound as soon as I created another rendering call in object mode. The problem may be deeper but I did not have time for this so I derive the normal from the sphere pos.
This is really convenient for development. Either for profiling the
generated shaders or to check if the generated code is correct.
It writes the shaders to the temporary blender session folder.
This adds TAA to eevee. The only thing important to note is that we need to keep the unjittered depth buffer so that the other engines are composited correctly.
The problem was that orthographic views can have hit position that are negative. Thus we cannot encode the hit in the sign of the Z component.
The workaround is to store the hit position in screenspace. But since we are using floating point render target, we are loosing quite a bit of precision.
TODO: use RGBA16 instead of RGBA16F. But that means encoding the pdf value somehow.
You can change the amount of samples in the user preferences. You do not need to restart blender to see the effect in the new viewport.
This adds another Multisample Framebuffer and textures (so even more memory required).
It works by blitting the default_fb to the multisample_fb each time the renderer need to render one or more "wire" pass.
It it then blit back to the default_fb so that the rest of pipeline is working as expected.
We COULD lower the GPU memory / bandwidth usage to render everything to the same multisample fbo and change the logic depending on if MSAA is enabled or not, but I think it's a bit too much work for now.
Now uses "Text Selected" theme color of "Menu Back" widget colors. Also
repositioned text slightly to have same margin on top and right (measured
by eye ;) ).
Tested with all bundled themes (contrib and no-contrib) and worked fine.
Considering that different splashes may need different colors for
overlaid text, using theme color may not be the best solution. I would
like to try how this works before adding an ugly way to force a certain
text color though.
Also tried different approaches, but this one I find the least ugly :S
As far as longer term plans go, we wanted to get a redesigned multi-page
splash screen anyway. At this point we can rethink how splash colors work
in general (i.e. auto-contrast, own splash theme colors, etc).
Adds a FXAA for smoothing out the extracted outlines.
The Post Process Anti Aliasing is only done on the Alpha channel of the outlines.
Because of that we need to add bleed the outline color out of the silouhette so the AA'd alpha can blend the right color and not pick black when the alpha is smoothed out of the silhouette.
Also because of the AA needs to have clear contrast to work with, I decided to ditch the "bluring" or the occluded outlines.
The FXAA adds an overhead of 0.17ms but we gain back 0.22ms * 4 = 0.88ms by removing the blur.
The FXAA Implementation is from Corey Richardson (cmr) (D2717). I had to modify it a bit to only filter the alpha channel.
This introduce some little artifacts on the border of edges because some pixel with very low opacity does not get discarded and then occlude the face rendered behind if it has not been drawn yet.
To fix this. I added an offset in the geometry shader for the edge fixup. This make the artifact only visible on the border of the object if there is a very dense wire region. It's only visible in edge select mode since vertex and face center also hides the artifacts.
We can enable this only if AA is enabled but for now it's always enabled.
Introducing a new header using the Blender socket logo,
commit of the source file will follow soon.
Splash committee: Ton Roosendaal, Dalai Felinto, Pablo Vazquez.
Artwork is a screenshot of 'Wanderer', an Eevee sample file
by Daniel Bystedt, available on blender.org (license: CC-BY-SA)
Textures were bound once. But since it was not unbound it's bind_num would not change and considered still bound next time a shader needed it.
Fix T52866
Fix T52855
Partial revert of 9068c0743e.
This commit tried to do two things:
(1) Fix UBO binding logic [good]
(2) "Improve" texture binding logic [bad]
Don't ever mix different fixes and refactors in the same commit.
Iterate over invisible objects too, so lamps can still lit the scene.
Also, now you can use a collection to set an object to invisible, not
only to visible.
For example:
Scene > Master collection > bedroom > furniture
Scene > View Layer > bedroom (visible)
> furniture (invisible)
The View Layer has two linked collections, bedroom and furniture.
This setup will make the furniture collection invisible.
Note: Unlike what was suggested on D2849, this does not make collection
visibility influence camera visibility. I will keep this as a separate
patch.
Reviewers: sergey
Subscribers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D2849
Right now this is exposed in the outliner, though all this
(visible/selectable/enable) should be moved to a new panel soon.
This removes objects from the depsgraph when the collection is disabled.
It allows you to "hide" lamps but still having them lighting the scene.
Same for light probes and other support objects.
Pending tasks:
* Have depsgraph to include invisible objects in the DEG_OBJECTS_ITER, and
then have Eevee and other engines to make a distinction between an
invisible and a visible object.
(for example, we probably want invisible objects to not show in the
viewport, but cast shadows and show up in light probes).
* Change how we evaluate collection settings so that an invisible
collection can force an object to be invisible.
Reviewers: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D2848
Ubo needs to be rebound every times the shader changes.
This simplify the logic a bit.
Also modify texture binding logic to potentially reuse more already bound textures.
This fix the crappy binding logic.
Note the current method is doing a lot of useless binding. We should somewhat order the texture so that reused textures are already bound most of the time.
Add sanitizer. I wanted to stay away from this because I think we should fix what causes NaNs in the first place. But there can be too much different factor causing NaNs and it can be because of user inputs.
The branching introduced by the uniform caused problems on mesa + AMD in the resolve stage.
This patch create one shader per sample count without branching.
This improves performance of a single ray per pixel case (3.0ms against 3.6ms in my testing)
This was cause by a fairly funky unitialize buffer (last frame) that was causing NANs during the SSR resolve stage.
They were then propagated to the whole image during the next swap.
Bypassing the SSR completly if no valid history exists fixes the problem. Also disabling SSR data output in this case so we can have correct reflection in the 1st history buffer.
You can now use a transparent shader as a completly transparent bsdf. And use whatever alpha mask in a mix shader between a transparent bsdf and another bsdf.
This is in order to use the same texture on multiple sampler.
Also texture counter is reset after each shading group. This mimics the previous behaviour.
- Replace poisson by concentric samples: Less variance. They are sorted by radius then by angle.
- Separate filtering into 2 blur. First blur is 3x3 box blur. Second is user dependant.
- Group fetches by group of 4.
This brings some data structure changes.
Shared shadow data are stored in ShadowData (in glsl) (aka EEVEE_Shadow in C).
This structure contains the array indices of the first shadow element of this shadow "object".
It also contains how many shadow to evaluate (to be used for Multiple shadow maps).
The filtering is noisy and needs improvement.
- Use only one 2d texture array to store all shadowmaps.
- Allow to change shadow maps resolution.
- Do not output radial distance when rendering shadowmaps. This will allow fast rendering of shadowmaps when we will drop the use of geometry shaders.
Since the change to prevent shader recompilation at every update, we got
a regression when clearcoat was used.
Basically at the shader build time we would determine if the shader
needed clear coat, and if it didin't, it would build a different GLSL
program.
However if later the user updated the clearcoat value so that it would
then require the full clearcoat shader, the user wouldn't get it until
manually forcing the shader to recompile, or reopening the file.
We now handle the optimization in the GLSL code. That adds a minimum
overhead due to branching. But the overall performance seems unchanged
(tested on linux in AMD and NVidia).
Reviewers: pascal, brecht, fclem
Differential Revision: https://developer.blender.org/D2822
This reverts commit 134e927965.
Writing into const event is very bad,
but this change broke compositor manipulators.
Will look into better solution eventually.
Mostly internal changes, keeping both manipulators
could have worked but there was no point long term.
There are still some glitches to resolve, will work on those next.
Basically since g_data was malloc'ed (instead of calloc'ed)
g_data->minzbuffer was never initialized.
So when running DRW_framebuffer_init after EEVEE_effects_init, the test
to *g_data->minzbuffer would lead to unpredictable results.
This was caught by valgrind, reported by Sergey Sharybin.
The is following: split copy on write update for node trees, and if we are only
tagging for uniform buffer update we skip whole datablock copy and only invoke
copy default_values form original nodetree to a copied one.
Thing which i'm not sure is: whether we need to use different branches in graph
itself to control such a conditional behavior, or whether we need to store tag
somewhere in the dependency graph. There are obviously cons and pros in both
approaches, and need to think about this. Maybe with more examples it becomes
more obvious which way is better.
This only fixes manual tweaks for now, animation support is coming.
Adding alongside the existing one for now,
but it should eventually replace it.
Uses a matrix instead of (position + scale),
written so rotation can be done more easily.
Currently has a primitive handle for rotation, supports corner scaling.
There were two issues here:
1. material_update did not do anything, because DEG_id_tag_update was storing
update tags in original IDs, which had nothing evaluated. Even more, material
update should have been called with evaluated version of material, Solved
this by copying update tag from original ID to a copied one.
However, perhaps DEG_id_tag_update should tag both original and copied ID,
so updates are never gets lots if some depsgraph is not visible.
2. Tagging material for update should ensure it's copied version of node tree is
up to date, otherwise material will still use old node tree.
This solves missing material updates when changing topology. Tweaking values is
still broken, because of GPUMaterial using pointer to original node's socket
value, which gets broken after copy-on-write of the node tree (pointers of nodes
are changing).
A single manipulator could only assign a single operator to each part.
Now each part can have it's own.
Also modify 2D selection callback, 2D started at 1, 3D at 0.
Now use -1 for unset value, start both at 0.
This reverts commit 3888227a7b.
This "Fix" was made while ORCO was broken. Now that orco itself is fixed
this is no longer required, otherwise Tangent node produces different
results in Cycles and Eevee.
Orco should behave the same if it comes from unconnected vec inputs, or
from the Texture Coordinate -> Generated node output.
Fixup for 11e7e0769a.
This is related to T52528. The coordinates are still different between
Eevee and Cycles, but at least it behaves consistent within itself.
In fact the shader should now be correct, but the orco attributes we are
passing the shader seems to be where the problem is. But it's to be
tackled separately.
Some manipulators are used like on-screen buttons,
in this case it doesn't make sense to keep track of their state,
so zero the offset when its unused.
Needed for lamp-target manipulator.
Re-use operator return flags for manipulator modal & invoke,
this means manipulators can allow navigation or other events to be
handled as they run - see T52499
Although the problem was exposed in 9457715d9a, the problem was in the
original code that was copied over. To have:
```
} else { /* EXPECTED_VALUE */
```
Without an BLI_assert(value == EXPECTED_VALUE); is asking for troubles.
Yet another reason to favour switch statements with:
```
default:
BLI_assert(!"value not implemented or supported");
```
Instead of chained if/else if/else /* expected_value */.
- NOCHECK -> ALL
- ALL -> MAYBE_ALL
Where 'MAYBE_ALL' checks to see if the mesh has changed.
This is clearer that `BKE_MESH_BATCH_DIRTY_ALL` is dirty and
going to be updated without any guess-work.
- WM_manipulatorgrouptype_remove- > free
- WM_manipulator_group -> WM_manipulator_group_type
Naming here is still a bit confusing,
now at least free/remove are differentiated.
This means we have less overall noise for rendered image.
SSR, AO, and Refraction are affected by this change.
SSR still exhibit artifacts because the reconstruction pattern needs to change every frame (TODO).
This exposes 2 methods for manipulators:
- new_custom_shape
- draw_custom_shape
This can be used for script authors to create and re-use shapes
without dealing with lower level API's.
It's purpose is to limit the amount of light that spread across the screen.
Not entierly sure if it's very usefull, but it sure help to avoid to drown the screen in bloom.
This function was called to recreate the lower mip level of the probe texture. But this is not it's usage and it introduced a stall.
This patch add cubemap mipmap level regeneration in eevee_effects.c
Since we started supporting the (Cycles) Material Output old files
stopped working. There is no reason to keep the original Eevee material
otuput anymore.
It includes doversion for old files.
Move floats around when needed to accomodate vec3 arrays efficiently.
With this we use slightly less memory when possible. Basically vec3s are not
treated as vec4 unless we have no float to use for padding).
Reviewers: fclem, sergey
Differential Revision: https://developer.blender.org/D2800
This includes big improvement:
- The horizon search is decoupled from the BSDF evaluation. This means using multiple BSDF nodes have a much lower impact when enbaling AO.
- The horizon search is optimized by splitting the search into 4 corners searching similar directions to help which GPU cache coherence.
- The AO options are now uniforms and do not trigger shader recompilation (aka. freeze UI).
- Include a quality slider similar to the SSR one.
- Add a switch for disabling bounce light approximation.
- Fix problem with Bent Normals when occlusion get very dark.
- Add a denoise option to that takes the neighbors pixel values via glsl derivatives. This reduces noise but exhibit 2x2 blocky artifacts.
The downside : Separating the horizon search uses more memory (~3MB for each samples on HD viewport). We could lower the bit depth to 4bit per horizon but it produce noticeable banding (might be fixed with some dithering).
Diffuse was not outputing the right normal. (this is not a problem with SSR actually)
Glass did not have proper ssr_id and was receiving environment lighting twice.
Also it did not have proper fresnel on lamps.
This fixes the Principled shader in Eevee, among other nodes.
Basically before we were treating all the vec3 as vec4 as far as memory
goes. We now only do it when required (aka, when the vec3 is not
followed by a float).
We can be even smarter about that and move the floats around to provide
padding for the vec3s. However this is for a separate patch.
That said, there seems to be some strong consensus in corners of the
internet against using vec3 at all [1]. Basically even if we get all the
padding correct, we may still suffer from poor driver implementations in
some consumer graphic cards.
It's not hard to move to vec4, but I think we can avoid doing it as much
as possible. By the time 2.8 is out hopefully most drivers will be
implementing things correctly.
[1] - https://stackoverflow.com/questions/38172696
Deleting the old internal audaspace.
Major changes from there are:
- The whole library was refactored to use C++11.
- Many stability and performance improvements.
- Major Python API refactor:
- Most requested: Play self generated sounds using numpy arrays.
- For games: Sound list, random sounds and dynamic music.
- Writing sounds to files.
- Sequencing API.
- Opening sound devices, eg. Jack.
- Ability to choose different OpenAL devices in the user settings.
Use mesh batch cache for mesh selection.
Note that we could create the batches and free immediately
so they don't take up memory.
This resolves a problem where selection was limited
to immediate-mode buffer size.
Since the paste object is pasted in the active collection, and not on
its original one, we need to flush/calculate the new collection base
settings (visibility, selectability, ...).
DEG_id_tag_update() for the scene now. Though it may be better to tag
only the object specific IDs in the future.
Originally we were not respecting the original visibility flags of the
collections. However this is required for Copy-on-write (CoW).
Remember to update the svn lib tests folder. I had to update some of the
json files there.
Also adding a new unittest for this particular issue:
Test render_layer_scene_copy_f
Flag ownership for each index array & vbo's
so we don't have to manually keep track of this and use the right free call.
Instead this can be passed on creation.
See D2676
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
I couldn't reproduce either, but calling min() with different argument
data types and indexing vectors with an index not known at compile time
seem likely to cause problems.
Ref T52404, T52404.
We now have to support more complex copying types, which are controlled
by flags, so all copying logic will need to take those at some point (at
least, all potentially dealing with IDs).
_copy_data() functions shall not do that at all anymore. Kept as option
for now even though that helper is only called from here...
Also moar varnames renaming to standard _src/_dst sufixes.
We do have an history of those pieces of evil in our code, would be nice
to get fully rid of it, but at the very least let's not add more of them
in new code. :)
Was complicating general use case, also support for transforming with matrix_space set.
Add matrix_space support for manipulator_window_project_2d too.
This fix a bug when occluder are on the edge of the screen and occludes more than they should.
Grouped the texture fetches together and clamp the ray at the border of the screen.
Also add a few util functions.
This should fixes the error message that a stall occured because of busy mipmap.
This happened on the minmax buffer generation and introduced a random 0.2ms latency.
I'm not sure of what was happening though.
* 255 maximum seems excessive for F-Curve handle vertices; now reduced to 100
* Vertex Size is no longer restricted to the old 10px maximum size limit
(used because Windows limited the maximum vertex size drivers needed to
support)
It's more important that there is some form of feedback that the strips
are muted (i.e. dotted borders) than the fact that those dotted borders
may have slightly rounded corners. So, just use a regular sharp-cornered
rect when the strips need to be muted.
There's no reason to manually iterate over items in a DLRBT_Tree,
as the structure is designed to be able to be safely casted down
to a ListBase and ListBase-like nodes..
Changes for 2.8x to use EvaluationContext caused some confusion
- Would use scene layer passed from snap context.
- Would generate duplis from Main eval context.
- Would take context argument and use it to create another eval context.
Adding context args all over and filling in a new eval-context
for every ray-cast test isn't ideal either.
Remove the context argument since the purpose of
SnapObjectContext is to avoid this kind of confusion.
Store the EvaluationContext once and re-use.
This effectivly reduce firefly bleeding all over the place.
We still need the clamp in the resolve pass because the level 0 has not been clamped.
NOTE: I did not clamped each sample individually for performance BUT I did not profile it to know how much it cost.
This was surely cause by float overflow. Limit roughness in this case to limit the brdf intensity.
Also compute VH faster.
Add a sanitizer to the SSR pass for investigating where NANs come from. Play with the roughness until you see where the black pixel is / comes from.
Group texture fetches to hide latency. 3.2ms -> 2.2ms (constant time improvement, not depending on scene complexity)
Could optimize further with textureGather (require OpenGL 4.0).
Theses Materials are rendered after the SSR pass.
The only difference with previous method is that they have a depth prepass (less overdraw) and are not sorted.
For the moment the only way to enable this is to:
- enable Screen Space REFLECTIONS.
- enable Screen Space Refraction in the SSR parameters.
- enable Screen Space Refraction in the material tab.
We track the previous ray position offseted by the thickness. If the sampled depth is between this value and the current ray position then we have a hit.
This fixes rays that are almost colinear with the view vector. Thickness is now only important for rays that are comming back to the camera.
As a consequence, this simplify a lot of things.
Also include some refactor.
Since we are working with non power of 2 textures, the mipmap level UV does not line up perfectly.
This resulted in skewed filtering and bad sampling of the min/max depth buffer.
We generate a 3D lut to precompute the btdf intensity.
I decided to use a 64*64*16 (N dot V, ior, roughness) because the btdf varies less with roughness than with IOR.
We also remap the ior to better use the space in the LUT.
Also internal changes so arrow3d matches grab3d's behavior.
Needed to add WM_MANIPULATOR_DRAW_OFFSET_SCALE flag so
we can optionally apply offset in worldspace or screen scaled values.
This will allow much finer controll over how we copy data-blocks, from
full copy in Main database, to "lighter" ones (out of Main, inside an
already allocated datablock, etc.).
This commit also transfers a llot of what was previously handled by
per-ID-type custom code to generic ID handling code in BKE_library.
Hopefully will avoid in future inconsistencies and missing bits we had
all over the codebase in the past.
It also adds missing copying handling for a few types, most notably
Scene (which where using a fully customized handling previously).
Note that the type of allocation used during copying (regular in Main,
allocated but outside of Main, or not allocated by ID handling code at
all) is stored in ID's, which allows to handle them correctly when
freeing. This needs to be taken care of with caution when doing 'weird'
unusual things with ID copying and/or allocation!
As a final note, while rather noisy, this commit will hopefully not
break too much existing branches, old 'API' has been kept for the main
part, as a wrapper around new code. Cleaning it up will happen later.
Design task : T51804
Phab Diff: D2714
Note these are intended for platform maintainers, we do not intend to
support users making their own builds with these. For that precompiled
libraries from lib/ should be used.
Implemented by Martijn Berger, Ray Molenkamp and Brecht Van Lommel.
Differential Revision: https://developer.blender.org/D2753
Since all the shadow catchers are already assumed to be in the footage,
the shadows they cast on each other are already in the footage too. So
don't just let shadow catchers skip self, but all shadow catchers.
Another justification is that it should not matter if the shadow catcher
is modeled as one object or multiple separate objects, the resulting
render should be the same.
Differential Revision: https://developer.blender.org/D2763
- New manipulator tracks lamps to position under cursor.
- Works with multiple lamps, keeping relative offsets.
- Holding Ctrl moves the lamp.
- Access via manipulator or Shift-T.
Code could be improved, but like to get feedback from users.
Render-border & crop-node 2d-cage manipulators where unreasonably
complicated to implement because there was no good way to define
the sub-region the manipulator was transforming in
(render border within the camera's frame for example).
Add matrix-space variable,
remove scale property from cage2d manipulator, use matrix instead.
Was doing this with property get/set but this made view operations
require refreshing manipulator properties.
Simplify by operating on properties in their own space.
Also disable clamping for now since it assumes pixel-space.
Keyframe handle vertices (the circles on the ends of the handles)
should always be larger than the central vertex. This brings back the
"outer" radius value from the old gluDisk(), and doubles it to get the
necessary diameter, to scale it properly.
TODO's:
- Get rid of all fills inside these circles
- Make the central vertex square-shaped again
* Outlines of keyframes were too thick and ugly
* Size differences between keyframe types was being swallowed
by the pixel-fudge factor, leaving colour as the only distinguishing
factor (bad!)
This changes the Cycles exporting and Cycles/Eevee UI code to support both
output material nodes, giving priority to the renderer native one. Still
missing is Eevee code to prefer the Eevee output node.
It now uses a quality slider instead of stride.
Lower quality takes larger strides between samples and use lower mips when tracing rough rays.
Now raytracing is done entierly in homogeneous coordinate space. This run much faster.
Should be fairly optimized. We are still Bandwidth bound.
Add a line-line intersection refine.
Add a ray jitter between the multiple ray per pixel to fill some undersampling in mirror reflections.
The tracing now stops if it goes behind an object. This needs some work to allow it to continue even if behind objects.
Running undo would notify manipulators to refresh,
but this still allowed for events in the queue to be handled,
where manipulators could be drawn for selection before
their refresh callback runs.
This made Python manipulators raise exceptions
about referencing invalid data (or crash).
Now tag manipulator update on file load (including undo)
and ensure the refresh callback runs
before drawing manipulator selection.
Also split manipulator map refresh flag in two since selection doesn't
perform the same operations as regular drawing.
This will only be noticeable for drawing many instances.
In contrived use-case with many instances, and `USE_PROFILE` disabled
this can close to double playback FPS.
The option to disable this is left in the code in case we want to
debug memory use.
See D2756 for details.
- Each allocation can be a different size
(but should be smaller than the chunk size).
- Result can be looped over in order of allocation.
- Allocations are aligned to pointer size to avoid unaligned reads.
This commit is a work forward having less updates during playback, which speeds
things up a lot here. The idea is simple: stop update all copy-on-write
datablocks (which implies full re-evaluation actually) on frame change and
re-use existing evaluated meshes as much as possible.
This brings playback speed to 24 fps on the dino test scene here. Performance
drops down a lot when armature is animated tho, but that's because of need of
tangent space calculation which we can't do much about from just a dependency
graph.
Hopefully this doesn't make copy-on-write too unstable, quick tests here are
surviving fine.
Old performance debug was doing queries for every frame even if not debugging perf.
Also, it did not record when a pass was draw multiple time, leading to incorect measurement.
New module also allows to group the timers to limit infos displayed.
Also fix the background CPU draw timer.
The purpose of the keymap strings is probably for un-embossed menu items
like seen in most pulldowns. I can't see a reason for also adding that
string for regularly drawn buttons within popups, we don't add it
anywhere else in the UI either. So this commit makes sure shortcut
strings are only added to buttons that are drawn like pulldown-menu
items.
This means once an ID is created,
it will keep using the same PyObject instance.
This has some advantages:
- Avoids unnecessary re-creation of instances on UI poll / redraw.
- Accessing free'd ID's gives an exception instead of crashing.
(long standing annoyance!, though this only applies to ID's
and not yet other data that uses the ID's - vertices for eg).
- Allows using instance comparison (a little faster).
Note that the instances won't be kept between undo.
Was doing 2x lookups which is OK for click-select
but this runs on mouse-move and can become slow.
May enable this again if highlighting logic changes.
Also scale hotspot by pixelsize.
- Cleanup array access, move into functions.
- Store allocated size to avoid realloc's on every add/remove.
- Make select editable from Python.
- Rename select callback to select_refresh
(collided with select boolean).
- Call select_refresh when de-selecting as well as selection.
This was cause by some post process not always sampling the highest mipmap.
But if there is no need for mipmapping (i.e. no SSR) these levels will be undefined.
So forcing all Post FX shader to sample level 0 fix this.
This add the possibility to use planar probe informations to create SSR.
This has 2 advantages:
- Tracing is less expensive since the hit is found much quicker.
- We have much less artifact due to missing information.
There is still area for improvement.
BKE_scene_copy explicitly ignores visibility of "source" collections make all
collections visible. This is also tested by regression tests.
While it seems more logical to simply preserve all possible visibility flags
and overrides, don't feel like submitting to a behavior-changes without talking
to author of those guards first.
This commit fixes cycles material preview.
If object is only listed in collection but not added to any of layers we shouldn't create
placeholder for it, because otherwise we'll leave lots of placeholder ID nodes.
Question: can we make this exception to be more reliable?
This commit separate the depth texture into another texture array.
This remove the need to output radial depth into alpha.
Unfortunatly it's difficult to recover position from the non linear depth buffer when applying reflection without adding a bunch of stuff.
This is in preparation of SSR planar reflections.
- Encode normals for other opaque bsdf so they are not rejected by the normal facing test.
- Early out non reflective surfaces.
- Add small offset to raytrace to avoid self intersection.
- Fix fallback probes not appearing.
Output in 2 buffers Normals, Specular Color and roughness.
This way we can raytrace in a defered fashion and blend the exact contribution of the specular lobe on top of the opaque pass.
Ideally need to clean and sane and impossible-to-break way of making sure
evaluation context is fully initialized, but that would need some thoughts
and experimentation.
Otherwise we'll have confused dependency graph builder, which wouldn't be able to
build proper graph.
Didn't find a way to avoid world copy here, we can probably escape with some shallow
copy here, but that will currently complicate code a lot.
Ideas to consider here:
- Use shallow copy of existing world after new ID management API is in place.
Downside would be thread safety, kind of nice to have everything local.
- Switch depsgraph away from ID_TAG and do hash lookup or so.
This will slow down depsgraph builder, but will make code more reliable.
Those functions did not use evaluation context.
Also fixed lots of unused variables warnings caused by commented out code which
needs to be ported away from DerivedMesh and to evaluation context.
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
The remapping code was creating plkaceholders for objects coming from legacy
bases, but since those objects were never created by dependency graph (since
they are supposed to be ignored) the copy on write relations creation was
confused.
Now we do some special trickery to clear legacy bases on copy on write.
Currently RNA doesn't give us a good way of accessing singleton layers,
for now expose as a layer list (skin & paint-pask do this too).
Noted in T47811 that this should be changed.
Those checks are not always helpful, since id remapping doesn't want to
worry about which components to tag for update. Perhaps in the future we
will introduce special flag which would mean "tag everything possible"/
We get already enough reports of people complaining about crashes on
edit mode unaware that they are in the non-supported Blender Render
engine.
Blender Render is going away, no reason to keep it around. Once we have
a nice fallback on Eevee and fast file loading we can default to Eevee
instead.
This is the fake ID nature of compositor again. Need to discard such
pointers before freeing datablock even for scenes (before it was done
for objects only).
Previously it was possible to run into situation when armature is constructed prior to
objects which are used for it's constraints. This was causing wrong scene evaluation.
Now we create placeholders for objects used by armature in case they don't have ID node
yet, which ensures we have proper mapping from original to copy-on-write ID pointer.
This shows the bug when IK solver doesn't update reliably when targeted an external
object and when that object is handled by build_object() after the armature.
The issue was caused by id_copy_no_main() changing pointers of constraints used
in pose to a newly allocated ID. This is correct, but caused confusion too our
copy on write remapping, because we are mimicing inplace duplication by copying
memory over from a temporarily duplicated ID to a proper placeholder. This was
causing dangling pointers in pose to a temporarily allocated ID.
Now we add special code to remapping callback which replaces temporary ID with
a proper one.
Couple of main things here:
- Properly handle PSYS_UPDATE_* flags from DEG_id_tag_update.
There are still some possible issues here related on the fact
that we don't differentiate different PSYS_UPDATE_* flags here
and handle the mall the same.
Other possibility here is that object level particle settings
evaluation might be forced when particle system evaluation is
tagged for update. Didn't see actual issue here yet, but need
a closer look.
- Don't tag non-object datablocks on visibility changes.
Those don't depend on visibility anyway. This prevents particle
settings IDs from flushing updates to all objects, causing all
cached particles to be lsot.
- Only update translation and geometry components on visibility
changes.
Once again, this prevents particle cache from being invalidated.
We might need to tag material components here still tho.
This commit makes it so that only ID components which correspond to the tag
flag are tagged for update (previously the whole ID would have been updated
in the most of cases).
This allows us to have more granular tag flags and prevent tagging of things
we don't want to be tagged.
Previously tagging particle settings for update will iterate over all objects and
all their particle system to see whether something needs an update or not. Now we
put ParticleSettings as an ID to the dependency graph, so tagging it for update
will nicely flush updates to all dependent particle systems.
Current downside of this is that due to limitation of flush routines it will cause
some extra particle system re-evaluation when it technically not needed, and what's
more annoying currently it will discard point caches more often.
However, this is a good and simple demonstration case to improve tagging/flushing
system to accommodate for such cases (similar issues happens with CoW and shading
components). So let's try to find some generic solution to the problem!
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.
For users that means you can tweak shaders in the nodetree and things
are way faster. This is a huge improvement, particularly in
systems that have no shader cache.
From the code perspective it means we are no longer re-compiling the
shader every time a value is tweaked in the UI. We are using uniforms
for those values.
It would be slow to add that many uniforms for all the shaders. So
instead we are using UBO (Uniform Buffer Objects).
This fixes the main issue of T51467. However GWN_shaderinterface_create() still
needs to be improvedi. When opening a .blend all shaders are compiled once, so
optimizing it will bring a measurable impact.
========================================================================
NOTE: This breaks update of Cycles material upon nodetree nodes
tweaking. It will be fixed separately by depsgraph, once tackling T51925
(Animated Eevee values slowdown).
The idea is to make Depsgraph update more granular. The XXX TODO in
rna_nodetree.c will be tackled at that time as well.
========================================================================
Reviewers: sergey, brecht, fclem
Differential Revision: https://developer.blender.org/D2739
This commit makes simple cases to work, for example:
- IK solver to an external object
- Object with Armature modifier, "parented" to the deforming armature
(via animation).
More complicated setups (like agent rig) are crashing still.
If you merge from master to blender2.8 after a commit, remember to test in 2.8, otherwise what is the point?
Specially if it's a non-essential commit such as c9817c67fc.
Bug introduced on: f4155d3778 (the merge
that included the above commit).
This commit effectively makes workspace switching useless as far as the
active scene layer goes.
The functions from the scene layer API to get the correct scene layer
from "context" were a placeholder to be addressed by the workspace
commit.
When workspace was merged, however G.main was used as a replacement to pass the
correct argument for the functions. As it turned out (surprise!) this
leads to crash on render preview.
We need to get rid of:
* BKE_scene_layer_context_active_ex_PLACEHOLDER
* BKE_scene_layer_context_active_PLACEHOLDER
And either use SceneLayer explicitly or replace it by:
* BKE_scene_layer_from_workspace_get
Goal is to make them more modular, to allow more variants (variable
single-color, thickness, ...) to be added without having to
copy-and-change-one-line of whole chain of shaders.
This is a first step towards proper depsgraph "ownership", where
we would allow scene to be in multiple states dependent on active
workspace or scene layer.
This commit introduces a basic API to get proper dependency graph
for a given scene layer. It also renames scene->depsgraph to
depsgraph_legacy, so it's easier to search0-n-replace in the future.
Hashed Alpha transparency offers a noisy output but has the benefit of being correctly ordered. Noise can be attenuated with Multisampling / AntiAliasing.
The "fix" happened due to a mistake in copy-on-write commit, that mistake solved
preview render but broke something else.
This reverts commit 45720922f7.
UVs need specific data in the VBO, which is not computed unless the
shaders assigned to the mesh actually use UVs. When adding UVs to the
shader, the VBOs were not being recomputed to include the required data.
This adds a DEG relation between the shader and the mesh, and recomputes
the required data if the shader changed.
Thanks Sergey, for all the DEG stuff...
A pointer to the uniform data for the empty drawing was being freed
before the actual draw call, which invalidates the uniform.
This makes the data only be freed after drawing.
Up until now users had to switch to Blender Internal to set the dimension of their openGl renderings. This simple change adds the panel at the top of the scene render tab.
It's cause by degenerate triangle having normals set to (0,0,0) which may not be compressed like it should.
This fix the problem in the final indirect lighting evaluation which might be costly.
The issue was caused by updates being flushed for all scenes, while actual update
was only called for an active one.
Not sure why do we need to flush updates for all scenes, so now we only flush
scenes which are updated.
This makes no sense to add theses. In cycles, each volume node is computed separatly. In eevee only the combined parameters are evaluated and phase should be averaged in this case.
This allow specialized shaders to redefine the closure interface to fit their needs.
For instance, Volumetric closure needs to pass more than one vec4 (absorption vec3, scattering vec3, anisotropy float).
At the moment libblock_remap_data_preprocess is using
FOREACH_SCENE_OBJECT to iterate over all the objects of the scene and
unlink them.
However we were storing a reference to the Base of the removed object.
Anyways, the loop is now sanitized so that this crash no longer happens.
Also now we have an unittest for this.
Now computers that support OpenGl3.3 (but not 4.5) can run Blender 2.8.
For any given HDC, you may only call SetPixelFormat *ONCE* any future
calls for the same HDC will fail. And computers that would support only
OpenGL 3.3 wouldn't have a change to get a valid OpenGL context because
the pixelformat was already set while trying to probe the supported
contexts.
We fix this by splitting the final context creation from the query of
supported OpenGL versions.
Patch by Ray Molenkamp (bzzt_ploink/LazyDodo) with code style fixes and
comments by me.
To recompile all the shaders is expensive. And something to be avoided at all costs.
It was needed before because for every new lamp in the file we needed to
recompile the shaders. Now this is no longer required since we are using
UBOs for the sahders.
This avoids using GWN_vertbuf_attr_set which needs to calculate the
offset and perform a memcpy every call.
Exposing the data directly allows us to avoid a memcpy in some cases
and means we can write to the vertex buffer's memory directly.
Was doing O(n^2) list lookups with blender-render drawing & transform.
Also missing NULL checks would crash.
Use Object.base_flag (already used by new draw manager in places)
to avoid list lookup.
Note, transform still performs inefficient lookups,
but only for selected parents (like 2.7x), not all parents.
Read from the GPUMaterial to find custom-data layers used for drawing.
This resolves problem where having UV's would always calculate tangents
causing noticeable slow down compared to 2.7x.
Add a safe version of normalize since all uses of normalize
did zero length checks, move this into a function.
Also avoid unnecessary conversion.
Gives minor speedup here (approx 3-5%).
This commit makes the fullsample option for viewport renderings always
on: Render > OpenGL Render Options > Full Sample.
(The UI still allows users to set this, so we will need to revisit this
before 2.8 releases).
Even in computers that can handle MSAA we had issues.
The way Blender gpu_* implementation is handling anti-aliasing is buggy.
For example, in Blender 2.7x if you have depth of field in a viewport
with multi-sampling, the DoF gives us jagged edges.
Since Eevee uses framebuffers for a lot of things, this issue was
leading to very visible buggy render in some computers, and more subtle
inconsistent buggy renders in others (easy to test with the depth of
field in Eevee).
Some code for freeing shaders on scene updates (because of previous
dependency shaders had on lamps) had been disabled, as it is no longer
required. This removes that code altogether.
Object shaders no longer depend on lamp data at compile time, thus they
don't need to be invalidated when lamps change. Disabling shader
recompilation allows fast viewport updates when changing lamp settings.
Note that even though shaders for lamps are currently not being used,
`lamp_changed` is still freeing the lamp shaders, as at some point we
might want to use shaders for lamps...
This also renames some flags/variables to be more generic for updating
purposes. The call used here was previously only used for updating
paint data, but as it was reused here, flags and variables were renamed
to accomodate more clearly to the new usages.
Shadow catching was disabled for hair in Eevee, because of an issue in
the shadow maps. The issue has since been resolved, so this re-enables
shadow catching for hair.
Not a single node based shader was working since a recent merge from
master.
The merge brought changes from the principle bsdf shader where
unsupported gl_ProjectionMatrix was still being used.
Initial support for Python/Manipulator integration
from 'custom-manipulators' branch.
Supports:
- Registering custom manipulators & manipulator-groups.
- Modifying RNA properties, custom values via get/set callbacks,
or invoking an operator.
- Drawing shape presets for Python defined manipulators (arrow, circle, face-maps)
Limitations:
- Only float properties supported.
- Drawing only supported via shape presets.
(we'll likely want a way to define custom geometry or draw directly).
- When to refresh, recalculate manipulators will likely need
integration with notifier system.
Development will be continued in the 2.8 branch
Note that this drops all changes from master,
useful commits will need to be cherry-picked.
Did this since most commits were relating to UV/textures
which is complicated by texface being removed in 2.8
Technically this enables the use of MinmaxZ pyramid inside the probe captures.
Also Disable AO for cubemap probes because it shows big discontinuities at cubeface limits.
The problem was that the depth prepass was using the clip plane but not the shading pass.
During the clipping stage, the triangle is converted to a quad clipped to the given clip plane.
But this introduce subtle changes in the depth when this new geometry is rasterized. Since the shading pass was using an EQUAL depth test, the depth values from the shading pass were not always equal to the depth prepass.
Enabling clipping in the shading vertex shader has a too small impact to require a dedicated shader.
This fixes an issue introduced by the new output node system, where "No
output node" was displayed in the material panel even when an output
node was present.
Naming was confusing, while technically correct -
the result is no scaling (manipulator ignores zoom-level).
Also remove 3D from name since this can be supported for 2D views too.
Although we are calling all of them light probes, there are a lot of
differences between them. This commit does the following:
* Prevent user from changing the probe type once added
* Unify "sphere" and "cube" probes into reflection cubemap
(as before you can switch between them from the probe UI)
To be done
==========
* Don't show add probe menus unless we are on Eevee
* Light probes panels should not be visible in Clay. Light probe objects
should not be visible in Clay viewport (nor on Cycles).
Notes
=====
* We need icons for the different light probes, and for lightprobes as a
whole (we are using RADIO for now).
Changes from custom-manipulator branch.
- use property type definitions.
- add property free callback.
- move properties into the wmManipulator struct (over alloc).
- use array length from property types instead of arg passing.
Implement GTAO (Ground Truth Ambient Occlusion) which is a special case of Horizon Based Ambient Occlusion that is more physically accurate.
Also add a bent normal option to sample indirect irradiance (diffuse lighting) with the least occluded direction.
- Unify variations between default shaders and material shader.
- Only create default shader passes if needed.
Downside is that we have a big array of passes and shading grp in the vedata ... And it will double in size each time a new variation flag is added.
This commit introduce the computation of a depth pyramid containing min and max depth values of the original depth buffer.
This is useful for Clustered Light Culling but also for raytracing on the depth buffer (SSR).
It's also usefull to have to fetch higher mips in order to improve texture cache usage.
As of now, 1st mip (highest res) is half the resolution of the depth buffer, but everything is already done to be able to make a fullres copy of the depth buffer in the 1st mip instead of downsampling.
Also, the texture used is RG_32F which is a too much but enough to cover the 24bits of the depth buffer. Reducing the texture size would make things quite faster.
This special case function enables rendering to a miplevel while using the miplevels above as texture input.
This is needed for some algorithm (i.e. creating a min-max depth pyramid texture).
This makes manipulator access closer to operators,
and allows Python access.
This adds RNA for manipulators, but not Python registration yet.
- Split draw style into 2x settings:
`draw_style` (enum) & `draw_options` (enum-flag)
- Rename wmManipulator.properties -> properties_edit,
Use wmManipulator.properties for ID-properties.
Note that this area of the API will need further work since
manipulators now have 2 kinds of properties & API's to access them.
Quicker to find the ID-subtype then use direct pointer comparisons.
Also modify `ID_code_to_RNA_type` so missing ID-codes raise a warning
(handy when adding new ID types).
We should be able to differentiate between OpenGL render (viewport
render), offline render (F12), and view render (viewport draw).
This allows for us preventing offline render to skip mode drawings, grid, ...
Even OpenGL render can benefit from this forcing a higher quality
anti-alias and sampling than the viewport drawing.
I'm not sure if it's clever to keep the memset(0x00) outside the render
loop function as it is in this patch. An alternative is to just pass the
render "type" as a flag to the render function, and set DST.options
inside it. (I may change this tomorrow, I will wait to hear from
Campbell on that).
This makes the node menus aware of the Cycles/Eevee distinction, and
only show the relevant nodes for the current engine. Names have also
been changed to accomodate for the new output node system.
This makes Eevee consistent with Cycles, by having a single output node,
and multiple shader nodes that connect to it.
Note that node systems for Eevee saved before this will be missing the
output node, and thus will show an invalid material. This is easily
resolved by connecting the shader output to a new output node.
This makes it possible to select objects in the viewport.
Selection in edit mode is still tricky, mainly because currently such update
would require tagging batch as updated, which is not possible with using just
and original object because it will never have batch.
Possible solution here would be to introduce some "batch" or "render" component
to depsgraph ID node for objects, so we can tag batch for update via depsgraph
tagging API.
< Dependency graph Copy-on-Write >
--------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
This is an initial commit of Copy-on-write support added to dependency graph.
Main priority for now: get playback (Alt-A) and all operators (selection,
transform etc) to work with the new concept of clear separation between
evaluated data coming from dependency graph and original data coming from
.blend file (and stored in bmain).
= How does this work? =
The idea is to support Copy-on-Write on the ID level. This means, we duplicate
the whole ID before we cann it's evaluaiton function. This is currently done
in the following way:
- At the depsgraph construction time we create "shallow" copy of the ID
datablock, just so we know it's pointer in memory and can use for function
bindings.
- At the evaluaiton time, the copy of ID get's "expanded" (needs a better
name internally, so it does not conflict with expanding datablocks during
library linking), which means the content of the datablock is being
copied over and all IDs are getting remapped to the copied ones.
Currently we do the whole copy, in the future we will support some tricks
here to prevent duplicating geometry arrays (verts, edges, loops, faces
and polys) when we don't need that.
- Evaluation functions are operating on copied datablocks and never touching
original datablock.
- There are some cases when we need to know non-ID pointers for function
bindings. This mainly applies to scene collections and armatures. The
idea of dealing with this is to "expand" copy-on-write datablock at
the dependency graph build time. This might introduce some slowdown to the
dependency graph construction time, but allows us to have minimal changes
in the code and avoid any hash look-up from evaluation function (one of
the ideas to avoid using pointers as function bindings is to pass name
of layer or a bone to the evaluation function and look up actual data based
on that name).
Currently there is a special function in depsgraph which does such a
synchronization, in the future we might want to make it more generic.
At some point we need to synchronize copy-on-write version of datablock with
the original version. This happens, i.e., when we change active object or
change selection. We don't want any actual evaluation of update flush happening
for such thins, so now we have a special update tag:
DEG_id_tag_update((id, DEG_TAG_COPY_ON_WRITE)
- For the render engines we now have special call for the dependency graph to
give evaluated datablock for the given original one. This isn't fully ideal
but allows to have Cycles viewport render.
This is definitely a subject for further investigation / improvement.
This call will tag copy-on-write component tagged for update without causing
updates to be flushed to any other objects, causing chain reaction of updates.
This tag is handy when selection in the scene changes.
This basically summarizes ideas underneath this commit. The code should be
reasonably documented.
Here is a demo of dependency graph with all copy-on-write stuff in it:
https://developer.blender.org/F635468
= What to expect to (not) work? =
- Only meshes are properly-ish aware of copy-on-write currently, Non-mesh
geometry will probably crash or will not work at all.
- Armatures will need similar depsgraph built-time expansion of the copied
datablock.
- There are some extra tags / relations added, to keep things demo-able but
which are slowing things down for evaluation.
- Edit mode works for until click selection is used (due to the selection
code using EditDerivedMesh created ad-hoc).
- Lots of tools will lack tagging synchronization of copied datablock for
sync with original ID.
= How to move forward? =
There is some tedious work related on going over all the tools, checking
whether they need to work with original or final evaluated object and make
the required changes.
Additionally, there need synchronization tag done in fair amount of tools
and operators as well. For example, currently it's not possible to change
render engine without re-opening the file or forcing dependency graph for
re-build via python console.
There is also now some thoughts required about copying evaluated properties
between objects or from collection to a new object. Perhaps easiest way
would be to move base flag flush to Object ID node and tag new objects for
update instead of doing manual copy.
here is some WIP patch which moves such evaluaiton / flush:
https://developer.blender.org/F635479
Lots of TODOs in the code, with possible optimization.
= How to test? =
This is a feature under heavy development, so obviously it is disabled by
default. The only reason it goes to 2.8 branch is to avoid possible merge
hell.
In order to enable this feature use WITH_DEPSGRAPH_COPY_ON_WRITE CMake
configuration option.
Maybe not very useful but it's here for feature parity with the other probes.
The fragment shader clipping is here because I'm lazy and don't want to creating a proper quad Batch.
This avoids having to use manipulator-type specific functions
to set the orientation.
And will make it simpler to access transformation from Python.
Currently the matrix is still used as an offset in places.
Also per-type orientation values still need to be removed.
- Option to start helper angle lines based on a vector
instead of the initial mouse coords (useful for bisect & spin).
- Option to show 2x helper lines
useful when dial is used to rotate an axis value.
Calculation was done in screen-space giving inaccuracy,
making the angle incorrect for tool code.
Cast mouse coords onto the dial plane to calculate the angle instead.
Instead use generic 'WM_manipulator_new', adding a new 'setup'
callback (like wmManipulatorGroup.setup) used to initialize type vars.
This moves conventions closer to wmOperator and simplifies exposing to
Python.
This is needed so manipulators can tag themselves for removal
without causing problems from freeing data within a callback.
Also use properties within the dial manipulator and fix an error where
removing a wmManipulatorGroupType didn't remove its keymap.
While this is work-in-progress from custom-manipulators branch
its stable so adding into 2.8 so we don't get too much out of sync.
- ManipulatorGroupType's are moved out of the manipulator-map and are now
global (like operators, panels etc) and added into spaces as needed.
Without this all operators that might ever use a manipulator in the 3D
view would be polling the viewport.
- Add optional get/set callbacks for non-RNA properties
Needed so re-usable manipulators can control values that
don't correspond to a single properly or need conversion.
- Fix divide by zero bug in arrow manipulator (when moving zero pixels).
Early implementation. Slow and still has quality
3 ways of storing irradiance:
- Spherical Harmonics: Have problem with directionnal lighting.
- HL2 diffuse cube: Very low resolution but smooth transitions.
- Diffuse cube: High storage requirement.
Also include some name change.
This is similar to some other datablocks. Mainly applies to collections,
so freeing scene does not involve changing any non-directly owned data.
There are two main usecases foreseen for the future:
- Less CPU ticks on bmain free, where everything is freed anyway and
there is no need to preserve id counters.
- Easier freeing of temporary data, including data which is used by
depsgraph's copy-on-write mechanism.
Neither of those are currently implemented, but will be shortly.
New implementation of hair for Eevee.
Note: A hard coded "transmission" property is being used. This should
eventually be exposed to the UI, possibly in the form of SSS
properties.
This stops the memory breakage caused by the material preview jobs,
to enable the new hair drawing implementation.
(This should be reverted once T51796 is actually fixed!)
There is no reason to be special for workspace and go against other design
decision in Blender. If something like this is going to become a common
practice in Blender it should be well thought and well tested, including
tests of all supported compilers and configurations.
This feature was relying on type re-definition, which is not only confusing
but also available in C11 only.
I considered just copying the evaluated data from the LayerCollection.
However we need to run the evaluation so Depsgraph can handle overrides.
I will double-check with Sergey Sharybin.
We need to traverse the same exact objects for both nodes and relationship
builder. We were using FOREACH_SCENE_OBJECT for relationships, which
would lead to plenty of warnings in multiple situations.
In the future we will need to change this to build the depsgraph
relations and nodes to one single render_layer.
Fix T51780: If an object is in two collections and I do a full copy of
scene things go bad
Sync with custom-manipulators branch
- Use identifiers for properties.
- Property array index access.
- Remove operator from manipulators
(wasn't used and will likely add in a different way).
One 1024px² octahedral probe (according to the GPU mem stats):
- RGBA16F = 17Mb
- RGB_11_11_10 = 4Mb
For the time being I prefer to maximize the number of probe possible in the scene for users to test.
This is obviously a temporary solution and the final choice of cubemap format should be exposed to the user.
After using it for like 30 sec, the min max bound box is absolutely not practical. Reverting into using a unit cube with object transform.
This also simplify the code.
In the future of center probes will be implemented using another object matrix (via an object pointer).
Probes were completely out of depsgraph, so tagging them could not work at all.
For now using some placeholder operations just to ensure order of updates.
We still do it a few times, but that helps already. Related to T51718.
Note that it also reinforces the idea that any geometry datablock will
have a generated copy-on-write Mesh provided by Depsgraph.
Regular camera lens have a ratio of 1.0. The anamorphic bokeh can be
used freely as an artistic decision, but it's nice to clamp it to 2.0,
to match real cameras.
That end up giving a reference for artistis playing with the
parameters unaware of the more realistic limits.
This was introduced in 23c93873f4.
This could be moved to deg_flush_base_flags_and_settings but since we
only need this for duplis I think it's fine to be handled separately.
Use indirect access to it via object.
It was already flushing from base to object, now we can avoid such flushing.
Still weird to have selection color filled in by dependency graph, but now
there is no synchronization going on at least.
As with operators, the window-manager has the API for defining,
the editor can implement and register its own manipulators.
This exposes wmManipulator, keeping it opaque isn't
practical if editors and Python are to implement their own.
UNIFORM_NONE should never match a valid uniform (builtin or custom).
The logic for UNIFORM_CUSTOM was just wrong, since it returned the first custom uniform. This function should only accept builtin (non-custom) uniforms.
Quick hash rejection instead of string comparison. Uniform lookups already work this way. I don't expect a major overall speedup since attributes are looked up less frequently than uniforms.
The issue was caused by usage of address of dupli-object (which will vary
from iteration process to iteration process) as something denoting whether
we've got the data synchronized to Cycles or not.
For now solved by using address of original object (the one DupliObject
points to) as a pointer for the map.
Need to do more thoughts about this.
This is supposed to help catch bugs if referrencing stack data out of
the draw loop context.
No change is suppose to happen for users (specially because the changes
here happens mostly on debug).
It includes a change in the logic for render loop, to make sure DST is
not accessed before we enter it - contribution by Campbell Barton.
This commit extends the work from Dalai made around scene iterators to
support iterating into objects from dupli-lists.
Changes can be summarized as:
- Depsgraph iterator will hold pointer to an object which created current
duplilist. It is available via `dupli_parent` field of the iterator.
It is only set when duplilist is not NULL and guaranteed to be NULL
for all other cases.
- Introduced new depsgraph.duplis collection which gives a more extended
information about depsgraph iterator. It is basically a collection on top
of DEGObjectsIteratorData.
It is used to provide access to such data as persistent ID, generated space
and so on.
Things which still needs to be done/finished/clarified:
- Need to introduce some sort of `is_instance` boolean property which will
indicate Python and C++ RNA that we are inside of dupli-list.
- Introduce a way to skip dupli-list for particular objects.
So, for example, if we are culling object due to distance we can skip all
objects it was duplicating.
- Introduce a way to skip particular duplicators.
So we can skip iterating into particle system.
- Introduce some cleaner API for C side of operators to access all data such as
persistent ID and friends.
This way we wouldn't need de-reference iterator and could keep access to such
data really abstract. Who knows how we'll be storing internal state of the
operator in the future.
While there is still stuff to do, current state works and moves us in the proper
direction.
We only show object center if object is selected, active or if viewport
has the "All Object Origins" options.
The viewport display options can migrate to renderlayer options.
However, we can mimic 2.7x as a compromise while the final design is
finalized.
This way we are not afraid of recursion being too deep.
That could have happened when having two collections which
are sharing same list of 1000s of objects.
- Move callbacks into type struct.
- Rename render_3d_intersection -> draw_select.
- Add header for function signatures (needed for types and api headers).
- Add WM_manipulatormaptype_find
Replace completly random noise by Blue noisen, giving a better aspect.
Also randomize the distance in the sample direction to cover the whole distance even with 1 sample. Using another blue noise for this.
Replace spiral samples (that had tendency to align if the number of samples was near the chosen constant) with Hammersley samples that have good coverage even for low number of samples.
Use a UBO instead of Texture (a bit less latency) making things a tiny bit faster.
Move the noise data to the SceneLayerData, because each render layer can have a different sample count.
Separate material handling inside another file.
Make use of enums to identify shader variations.
Group all 64*64 LUTs into one array texture.
Only update world probe if world changes.
Cycles is using rna_depsgraph, not rna_scene. Duplis are still not working there
but now at least it shows it was showing before the commit.
To show duplis in Cycles do:
- data->flag = DEG_OBJECT_ITER_FLAG_SET;
+ data->flag = DEG_OBJECT_ITER_FLAG_ALL;
Now dupli groups, objects, particles, ... are all working.
This introduces a flag for the iterator to determine whether we go over
Set and dupli objects or not.
Important to remember to keep the iteration of DEG_ as readonly.
Cycles is not working well for dupli groups, and it's memleaking
for dupli particles. So for now we iterate over main objects and set
only, not dupli.
To change that go in rna_scene.c and:
-DEG_OBJECT_ITER(graph, ob, DEG_OBJECT_ITER_FLAG_SET)
+DEG_OBJECT_ITER(graph, ob, DEG_OBJECT_ITER_FLAG_ALL)
Review and suggestions by Sergey Sharybin
This commit moves the list of transform orientations from scenes to workspaces.
Main reasons for this are:
* Transform orientations are UI data and should not be stored in the scene.
* Introducion of workspaces caused some (expected) glitches with transform orientations. Mainly when removing one.
* Improves code.
More technically speaking, this commit does:
* Move list of custom transform orientations from Scene to WorkSpace struct.
* Store active transform orientation index separate from View3D.twmode (twmode can only be set to preprocessor defined values now).
* Display custom transform orientation name in header when transforming in it (used to show "global" which isn't really correct).
This commit does the main integration of workspaces, which is a design we agreed on during the 2.8 UI workshop (see https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup)
Workspaces should generally be stable, I'm not aware of any remaining bugs (or I've forgotten them :) ). If you find any, let me know!
(Exception: mode switching button might get out of sync with actual mode in some cases, would consider that a limitation/ToDo. Needs to be resolved at some point.)
== Main Changes/Features
* Introduces the new Workspaces as data-blocks.
* Allow storing a number of custom workspaces as part of the user configuration. Needs further work to allow adding and deleting individual workspaces.
* Bundle a default workspace configuration with Blender (current screen-layouts converted to workspaces).
* Pressing button to add a workspace spawns a menu to select between "Duplicate Current" and the workspaces from the user configuration. If no workspaces are stored in the user configuration, the default workspaces are listed instead.
* Store screen-layouts (`bScreen`) per workspace.
* Store an active screen-layout per workspace. Changing the workspace will enable this layout.
* Store active mode in workspace. Changing the workspace will also enter the mode of the new workspace. (Note that we still store the active mode in the object, moving this completely to workspaces is a separate project.)
* Store an active render layer per workspace.
* Moved mode switch from 3D View header to Info Editor header.
* Store active scene in window (not directly workspace related, but overlaps quite a bit).
* Removed 'Use Global Scene' User Preference option.
* Compatibility with old files - a new workspace is created for every screen-layout of old files. Old Blender versions should be able to read files saved with workspace support as well.
* Default .blend only contains one workspace ("General").
* Support appending workspaces.
Opening files without UI and commandline rendering should work fine.
Note that the UI is temporary! We plan to introduce a new global topbar
that contains the workspace options and tabs for switching workspaces.
== Technical Notes
* Workspaces are data-blocks.
* Adding and removing `bScreen`s should be done through `ED_workspace_layout` API now.
* A workspace can be active in multiple windows at the same time.
* The mode menu (which is now in the Info Editor header) doesn't display "Grease Pencil Edit" mode anymore since its availability depends on the active editor. Will be fixed by making Grease Pencil an own object type (as planned).
* The button to change the active workspace object mode may get out of sync with the mode of the active object. Will either be resolved by moving mode out of object data, or we'll disable workspace modes again (there's a `#define USE_WORKSPACE_MODE` for that).
* Screen-layouts (`bScreen`) are IDs and thus stored in a main list-base. Had to add a wrapper `WorkSpaceLayout` so we can store them in a list-base within workspaces, too. On the long run we could completely replace `bScreen` by workspace structs.
* `WorkSpace` types use some special compiler trickery to allow marking structs and struct members as private. BKE_workspace API should be used for accessing those.
* Added scene operators `SCENE_OT_`. Was previously done through screen operators.
== BPY API Changes
* Removed `Screen.scene`, added `Window.scene`
* Removed `UserPreferencesView.use_global_scene`
* Added `Context.workspace`, `Window.workspace` and `BlendData.workspaces`
* Added `bpy.types.WorkSpace` containing `screens`, `object_mode` and `render_layer`
* Added Screen.layout_name for the layout name that'll be displayed in the UI (may differ from internal name)
== What's left?
* There are a few open design questions (T50521). We should find the needed answers and implement them.
* Allow adding and removing individual workspaces from workspace configuration (needs UI design).
* Get the override system ready and support overrides per workspace.
* Support custom UI setups as part of workspaces (hidden panels, hidden buttons, customizable toolbars, etc).
* Allow enabling add-ons per workspace.
* Support custom workspace keymaps.
* Remove special exception for workspaces in linking code (so they're always appended, never linked). Depends on a few things, so best to solve later.
* Get the topbar done.
* Workspaces need a proper icon, current one is just a placeholder :)
Reviewed By: campbellbarton, mont29
Tags: #user_interface, #bf_blender_2.8
Maniphest Tasks: T50521
Differential Revision: https://developer.blender.org/D2451
Before this change Gawain was doing list lookup twice,
doing string comparison of every and each input which
is not efficient and not friendly for CPUs with small
cache size.
Now we store hash of input name together with actual
name and compare hashes first. Additionally, we do
everything in a single pass which is much better from
cache coherency point of view.
This brings Eevee cache population time from 80ms to
60ms on my desktop and from 800ms to 400ms for Clement
when navigating in a file from T50027.
Reviewers: merwin, dfelinto
Subscribers: fclem
Differential Revision: https://developer.blender.org/D2697
Add face maps, needed for face-map widgets,
only data structure, widgets will be separate commit.
This comes from 'custom-manipulator' branch with only minor changes.
This enables us to use 2D texture arrays for multiple probes.
There is a little artifact with very high roughness caused elongated pixel due to the projection (along every 90° meridian).
We now floor the corner position and use this position as origin.
This gives us perfect derivatives in all cases even if very far from the origin.
Unfortunately this won't fix the low precision of coordinates used for computing the actual grid size, resulting in thick, non-smoothed lines.
Also did a bit of refactor how the axes are drawn.
Do not use the inverse perspective matrix inside the shader to recover world positions.
That leads to severe float imprecision leading to nasty artifacts.
Instead we compute the world view vector for each pixels and do a ray to plane intersection.
We are still getting low precision derivatives when going far away from the origin, and thus artifacts.
This commit also fixes the non-appearing negative Z axis in 3D view.
Note for users
==============
The active_layer option used for the filebrowser operators is now called
active_collection.
If there is no collections in the scenelayer or if this option is not selected
we automatically create a new collection for the new objects.
This is the same behaviour of trying to add a new object when there is
no collection.
Note for developers
===================
For those cases I moved the object user count handling from readfile to
the scene collection system. It's working fine for those, but we still
need to re-visit this for Add objects, and Duplicate - In those cases
the usercount is 2 when it should be 1.
Reviewers: mont29, sergey
Differential Revision: https://developer.blender.org/D2686
- Derived-mesh drawing.
- All non UV members of TexFace structs.
MTexPoly is now redundant but keeping with a dummy member,
will check on complete removal later.
TexFace complicates the now more popular shading pipeline by having
per-face images, see: T51382 for details.
To keep the ability to select a per-material edit-image
(used with UV-mapping workflow), the material now stores an image
which will be set when changing images in edit-mode.
This is used as a bake-target when not using Cycles too.
Storing edit-mesh data as indices for passing
only to get back edit-mesh data.
This also complicated checks for real edges in tessellation tris.
Simpler to pass data directly.
This function is not performance critical, but I prefer the branch-free code and no hack needed to appease gcc.
Follow-up to recent 23035cf46f and f637145450.
Goal is to make most of the API independent of OpenGL, Vulkan, any other backend.
Able to remove default case from ElementList_size because IndexType only covers index types. Not that and *everything else* like GLenum.
We render linear distance to the light in a R32 texture and store it into an octahedron projection inside a 2D texture array.
This render the sampling function much more simpler and without edge artifacts.
Shader stages need to agree about interpolation qualifiers. Apparently implicit smooth (the default) and explicit smooth are considered different by some GLSL compilers. Found by @letterrip on Linux + Intel.
Follow-up to 941e739d70
prefer vector math over scalar
prefer * over /
shorten vec3(x, x, x) to vec3(x)
use clamp, max, etc. instead of custom logic
declare loop vars as part of for loop
spacing
vertexColor output was not being written --> shader failed to link --> assert hit while setting that shader's uniforms.
Vertex attribs are smooth by default, so I shortened the declaration.
@fclem or @dfelinto: is color = 0 ok here?
This still has a couple of issues:
* Instancing is not working when multiple particle systems use the same
primitive. Only the last particle system to be drawn with a particular
primitive shows up.
* Because of colors being passed as uniforms with static variables, the
color of the collection of the last object to be evauluated is used for
all particles being displayed.
Also, note that while this is being drawn in the clay engine, this might
be moved to the object mode later intead.
Part of T51378
This was introduced by a removed line in
rB0eb32ab22809d9c0c41bfff5082f58b1a7aa9965
If we want to change the value to a differen default, it should be done
in a separated commit.
We only keep this as a way to get GPU_stubs to run, in case we want to do a
throughout cleanup in the codebase and want code using legacy calls to
fail to build.
There is no more point of keep those around. ES20 may need special case
when/if we dabble with it again. Meanwhile no point on polluting the
code with this.
(ghost still has reference for the PROFILE, but that's reasonable)
In the move to OpenGL 3.3 core profile, we drop support for compatibility profile and older versions.
OpenSubdiv was the only user; I'll update OSD next.
Now we always use GLSL 3.3, AKA #version 330. Most of the extensions we used are built into OpenGL 3.3 so we don't need them anymore.
Cleaned up comments related to GLSL version.
Part of T49012
These are always supported now
- instancing as of GL 3.1
- geometry shaders as of GL 3.2
The change to rna_scene.c could use some cleanup, since we don't really need a runtime query function.
The "Modern Viewport" was an option in the Viewport panel that would use
the new fancy wire frame code and some depth debugging functionality.
This was introduced as a quick and dirty way to get the new drawing
system showing in the viewport.
Overtime we built a complete Draw Manager system, leaving this original
approach deprecated which adds clutter to Blender code since it would be
removed sooner or later.
Note: The new fancy wireframes and related shaders (white out other
objects) are still in Blender code, though you can't use them anymore.
If we are to have any of those drawing options they should be integrated
in the new draw manager, instead of integrated in the old drawing
pipeline as it was originally coded.
This commit fixes two issues:
- UV/Image editor uvs menu did not match the 3D View's which was changed in rB2b240b043078
- Circle select tool was missing in particle edit mode
Reviewers: Severin
Differential Revision: https://developer.blender.org/D2329
It works with Cycles and Blender Internal for now.
The Blender Internal support will disappear, but we should be able to
integrate it with the Draw manager and use it with Clay, Eevee, ...
Mainly adding 'wire' suffix to wire/distance drawing func and shader.
Also, match wire vertex shader behavior with solid one regarding
head/tail only drawing (i.e. alwas expect head bone mat, never tail one,
and assume that if a radius is negative, then we only draw on the other
end of the bone).
Envelope bones are now pretty much identical to old drawing code.
Note that currently new DwM drawing code does not seem to care about
wire/solid drawing modes at all, guess this is still TODO... For now we
hence just get both wire and solid for envelope bones, this can be
refined later.
This is not complete, it does not implement 3D solid drawing of
envelope bones. 2D wire is hence always drawn for now.
Some notes:
I did not try to implement the 'capsule' approach suggested by @fclem, because:
1. I spent enough time on this already, and finally got something working.
2. I managed to get rid of geometry shader completely.
3. Current approach allows us to use same shader for
distance outline and envelope wire.
It's working fine, except for one glitch - superpositions of envelope
outlines do not work as expected, not sure what's wrong here, tried to
disable zbuff, enable GL_BLEND, no luck so far...
I think we need our own 'background' drawpass to get them working (also
to avoid them drawing over the wire lines).
Was using intermediate functions to store each data type.
This is still done in some places (for more involved access).
For basic data: coords, normals, colors..etc this is unnecessarily indirect.
-Use 11_11_10 buffers for hdr content.
-Eevee compositing share 1 buffer if bloom and DOF are both activated.
-Fix slowdown when resizing EEVEE viewport.
-Removed DRW_BUF_*** enums causing confusion.
We should avoid casting from an int to a flag.
In this case it is probably fine, but if the OB_MODE_SCULPT
was too high it can overflow the bool.
(also adding explicit parenthesis to a flag check)
Although this is working fine, there are two changes expected in the new
future once depsgraph copy on write is implemented:
1) To call ED_info_stats_clear a callback from depsgraph, instead of the
notifier system. (that would also allow us to clear only one
SceneLayer).
2) To store/get stats from the evaluated SceneLayer, as well as iterate
over the evaluated objects as well.
Revert 7a18ee62eb and 1ff97bbfff after discussing with @fclem.
VertexBuffer_size should always report the same buffer size, but without asking/calling OpenGL.
Deactivated by default.
All shading attribs can be packed to take less VRAM at the cost of precision (not noticable in this case).
UVs can be packed into I16 but that limits their positions into the [-1, +1] range.
This could be a setting option in the future.
Follow-up to 0722e41f9e which removed all uses of this struct. Gawain VertexFormat auto aligns attributes as described in @nicholasbishop's performance note.
Only mask are handled by sculpt mode engine and are multiplied on top of the render.
There is room for improvement:
- Shaded meshes don't have correct tangents or uvs.
- Masks are in range 0.8 - 0.2 thus always darkening at least 20% the render.
- It only uses the first material slot of the mesh.
Physics panels are not all back, and the material related panels (e.g.,
hair render panel) should go be changed since there should be no
material for those.
The original idea was to use Clay as the default. But since clay may not
even be in the final release, we can't afford to have a startup.blend
that doesn't deliver a reliable result regardless of build options.
Adds a version of template_ID that can be used for non-ID properties.
The property to search for and the collection to search in has to be
passed to it.
Like template_ID it also takes arguments to define a 'new' and 'unlink'
operator. They will be displayed as icon-only buttons then.
Also added a version that can display preview thumbnails.
Had to do some additional changes to make text-buttons support
displaying/modifying empty RNA properties.
This will be needed for workspaces, see D2451.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D2666
This removes a few options from CMake:
* WITH_LEGACY_OPENGL
* WITH_GL_PROFILE_COMPAT
* WITH_GL_PROFILE_CORE
We still have WITH_GL_PROFILE_ES20. So you can still alternate between
ES20 and CORE profile (when es20 is disabled).
If you want to explicitly see the stubs errors just define
WITH_LEGACY_OPENGL.
Nothing terribly exciting, just a hackish implementation of solid mode CDDM
drawing for cases when we are building with core profile.
The goal is to be able to see SOMETHING with new OpenGL for thew guys who
tests alembic and friends in blender2.8 branch. This is a temporary solution,
the whole drawing will be reworked. Limited to hardcoded material and lighting.
Selection outline color is also hardcoded because of lack of glColor() in the
core profile.
After this commit there is no big stoppers from stop worrying about legacy
OpenGL, so we can go core profile as the only way for Blender.
While some areas will become broken after that, we'd better just fix them
after that and for now just focus on more important design work.
We still need to update the RNA interface to access those. But since
there is no RNA_def_property_float_array_funcs I'm not sure how many
changes this will require.
A bit too early to disable workaround for particles.
Guess it was commented out after particles removal but was not brought back
after particles restore commit.
The issue was happening when display device is set to None, which makes it so
all the color transformation is a no-op which does not really require any LUT.
This is something we can not know from Blender side easily, because LUT sampling
and related logic is fully done in OCIO library itself. The following happens:
- OCIO sees that no LUT is needed and uses simple pass-through logic in the
color conversion function.
- GLSL compiles sees that uniform used for LUT is unused in the GLSL code and
strips it out.
We can not know this from Blender side because technically any conversion to
the same space might be a no-op and that we wouldn't know without some tricky
parse of the OCIO configuration.
So for now we simply avoid crash but are disabling checks for existence of the
uniform.
Ideally would be nice to have some GLSL-code parses which gets the uniforms
from the code itself, so we can distinguish between typo in the uniform name
and uniform being optimized out.
Would cause pointer to allocated memory to be overridden.
Steps to recreate were:
* Start Blender
* Save
* Open saved .blend
* Close Blender -> should report unfreed memory
This is routinely mis-used to continuously run scripts,
causing performance problems.
This should be replaced with more specific handlers, or possibly timers.
See: T47811
Caused by rBe87ddda149b. Selecting objects shouldn't be done in such a
low level function anyway (IMHO).
Made sure duplicating objects still works correctly.
This add a new set of (possible) render settings that can be defined at
the scene level and overridable at the scene layer level.
Once we get workspaces we can either add workspace inbetween scene and
scene layer evaluation. Or to replace layer settings, to avoid extra
confusion to users.
An example of this setting is "samples", as implemented now for the clay
engine.
Adds 2 static unsigned int to Gawain and GPUTexture to roughly keep track of the memory stats on the GPU.
Stats can be view at the bottom of the GPU stats with debug value > 20.
This join them with \n separators.(right now they clash on top of each
other).
Note: We still need to change "ED_region_info_draw" to accept multi-line strings.
Disabled by default. Set ENABLE_EFFECT_MOTION_BLUR to 1 to enable.
No fancy motion blur. Use depth and camera matrix to get the motion vectors. Then blur in this direction.
Only available in camera view.
Only Camera animation is supported, does not take into account the parents motion
This can be used by any engine actually. For example to give feedback
regarding probe caching in Eevee, ....
Unline master, we try to conciliate both the original viewport info
(FPS, view name) and the render info.
Note: I had to split the function in two because the camera alpha
passepartout is handled inside the view3d_draw_region_info function.
Review: Campbell Barton and Clement Foucault.
Thanks to Sergey Sharybin and Pablo Vazquez for some of the design
discussions.
This fix doesn't really fix the situaion now because at the moment we
only flush the evaluated flags at DEG_OBJECT_ITER time, which is silly.
But it's all we can do until we have CoW.
So the parent visibility flag is not flushed. And even if we flushed its
visibility flag, we would need to rely on having the parent flag flushed
before we get to the object in question.
Anyways, take this commit as a future fix for when depsgraph comes to
rescue all our souls.
This implements weight rendering with the draw manager, with all drawing
options (Shading, wire, face masking, vertex masking).
This is part of T51208
Reviewers: campbellbarton
Subscribers: dfelinto
Differential Revision: https://developer.blender.org/D2654
Note: We should test if the armature is the "armature modifier" parent of the
object.
If any good samaritan feels like tackling this, the function to change
is: DRW_pose_mode_armature
Since offscreen drawing now uses draw engine, this doesn't need to be
considered legacy.
Note that there are some calls into view3d_draw_legacy.c from view3d_draw.c
this is generally not accepted, so its only dont where there are checks
for new/old engine.
Functions exposed to do this use a VP_deprecated prefix.
We still need to bring pose bone drawing for the pose engine.
Note: In the future, once we get face-widget selection, we will need to
make sure the pose engien only draws then if "weight paint mode" is not
enabled too.
In the future this will allow us to implement things like face manipulators.
For now however, this is getting on the way of using pose mode
(mesh objects are drawn green).
NOTE: pose engine should also be the one taking care of pose bones
(and for that matter, X-Ray armature option should/could be a property
of the Pose engine even).
8b2640f08 introduced the error,
caused by external-engine needing depth mask to be disabled,
which happened to be the case before changing state changing logic.
With this we also do not need IDP_MergeGroupValues anymore.
If this causes problems in the future we can always make recursion an
option (like overwrite is).
Most of this was copying/adapting code from octahedral existing draw
code, tough part was to get BBone matrices to behave as expected, they
are using a fairly specific setup...
Addresses T51365 and T51362.
Changing states didn't properly reset between shading groups
causing the GL state to be wrong based on draw order.
States are now only set when changed.
We can now use object and other modes on top of Cycles.
Since we are now always on "render_to_view" (old Rendered mode), the
pause button is always visible.
Note: In one case (rna_Scene_editmesh_select_mode_set) I had to resort
to the temporary solution of BKE_scene_layer_context_active.
This is fine for now, but it will be a problem once workspaces are
introduced. In this case the fix is to use a temporary value in the set
routine, and actually only set the active object in the update function
(which can take bContext).
- code_generate_fragment : Making sure that shaders uses the new uniforms.
- code_generate_vertex_new : create require attribute based on their names and not their id (see draw_cache_impl_mesh.c).
- add support for ramp textures.
This is a bad implementation waiting for some improvement that are :
- Gawain support for multiple names. -> will remove duplication of attribute alloc
- Glsl safe name string escaping. -> will remove any risk of hash colision.
Old glsl drawing was relying on attribute being choosen by DerivedMesh at drawing time.
For this reason, we declare all possible attrib "name" for each data layer inside the batches.
In the glsl code, we declare required data by type and name.
Then Gawain only bind vbos if names correspond.
This is way cleaner as we do not need to access the CD itself when drawing.
One other problem is that the hash maybe 11 caracters long and rapidly overload gawain's attrib name buffer.
- Unify GPUMaterial creation (world/mesh).
- Support for multiple shader variations (not used for now).
- Convert GPUInputs to DRWUniforms to be used with the draw manager.
- Nodetree Update is not supported. The only way to refresh the shaders is to change render engine.
- Cleanup in GPUPass.
- Add new temporary Node Compatibility type. Compatibility types should be removed in the future.
Note that smooth-shaded outlines of muted NLA strips should also be
dashed, not sure how to do that currently (in a simple way), so kept
them solid for now.
Using geometry shader allows us to get rid of the 'line origin' extra
vertex attribute, which means dashed shader no longer requires fiddling
with those vertex attributes definition, and, most importantly, does not
require anymore special drawing code!
As you can see, this makes code much simpler, and much less verbose,
especially in complex cases.
In addition, changed how dashes are handled, to have two 'modes', a
simple one with single color (using default "color" uniform name), and a
more advanced one allowing more complex and multi-color patterns.
Note that since GLSL 1.2 does not support geometry shaders, a hack was
added for now (which gives solid lines, but at least does not make
Blender crash).
There was a bug in older GLEW version which kept glGenVertexArrays as NULL
when 3.2 core context is requested [1].
Didn't find a way to check GLEW version from CMake, it seems the version
is not really exposed to the header.
[1] https://sourceforge.net/p/glew/bugs/124/
Needed a bit of twisting in generic private func behind the imm_draw_circle
helpers, but think it's fine.
Note that this demonstrate yet another downside of new dashed shader
compared to olde line style: not only does it needs more complex setup,
and can only work with PRIM_LINES type of primitives, but it also
behaves totally wrong with chained short segments!
We really need to find a better way to do this effect at some point. :(
Also restore drawing of local action markers in NLA strips...
Note: there is another usage of setlinestyle in this file, not sure how
to hanlde it for now, so will leave it for later...
This upgrade the drawing code to use latest opengl calls.
Also, it adds a fallback shader for opencolorio.
Reviewers: sergey, brecht
Subscribers: merwin, fclem
Differential Revision: https://developer.blender.org/D2652
This one has been painful, it's doing lots of nifty conditional drawing
of all kind... Also, very nice illustration of how cumbersome it is to
use dashed shader currently, we really need to find a simpler way at
some point imho. But this is not critical issue either, for now we can
live with some uglyness like that. :/
- enabled lights
- alpha test
- texture environment
- point sprites (always enabled in modern GL)
Moved is_clip_plane for better struct packing, no functional change there.
Part of T51164
These parts will not be part of final viewport, but are called indirectly during the transition. To avoid runtime errors on core profile, exit early -- functions effectively do nothing.
I put the early exits inside the functions to avoid cluttering the code that calls these. But (long term) the calling functions need to change.
Basic shader's detect_options function was unused and full of old, so I deleted it.
Part of T51164
GL_LOGIC_OP is a synonym for GL_INDEX_LOGIC_OP, from OpenGL 1.0's indexed color drawing. It's not part of modern GL and causes an error in core profile.
GL_COLOR_LOGIC_OP is still supported in the latest GL. It's the last stage before writing to the framebuffer.
Part of T51164
There are multiple ways to orphan a buffer resource, and this code picks the oldest/safest way no matter which OpenGL version we're running.
TODO: use other (more recent) methods after thorough testing
Follow up to 8e0c57a812
Texturing is always enabled in GLSL. Simply use a sampler in the shader.
Replaced gpu_generate_mipmap with glGenerateMipmap since the former just Enabled/Disabled the texture target and called the latter.
Part of T51164
Note that I also made 'dash anchor point' consistent (the static one,
not the mouse one), in previous code somtimes dashed were anchored to
the static center point, in others, to the moving mouse position, the
later was rather disturbing imho...
Previously canceling a render done by the split kernel could cause artifacts
such as very bright or dark tiles. This was caused by unfinished samples
being included in the output buffer. To avoid this we now wait till all the
currently rendering samples have finished, up to a limit of twice the
expected time for them to finish (currently this is no more than 20 seconds,
but usually its much less). If samples still haven't finished by then we
stop anyways in case there's an endless loop occurring.
The scale version was working(ish), but it was not really extendable to
a 3D line version of the shader.
Also note that sequencer view still keeps its 'UI scale' adaptation
(dashes grow together with UI scale setting). Would be nice to do that
everywhere ultimately imho, but nothing urgent here.
Not much to add here, except that it needs the scale of its MVP matrix
to be taken into account here...
Reviewers: merwin, dfelinto
Differential Revision: https://developer.blender.org/D2647
Use new 2D dashed line shader in 3DView camera view.
Note that this also involved converting UI_draw_safe_areas() to this
dashed shader, which means it cannot be used anymore with other shaders.
Part of D2647.
Even though in some cases this does not seems useful, in others (like
zommed 2D views) we have to correct MVP matrix scaling to get fixed
dashes size.
Note that we could do that differently (commented about it in shader),
would also have been cleaner to extract that MVP scale from within the
shader, but there does not seem to be a way to initialize uniform values
from within a shader, and would rather avoid recomputing the scale for
every run (especially since 3DViewport does not need it e.g.).
Part of D2647.
That still not ideal, but so be it. IS_VIEWPORT_LEGACY should be
removed anyways, this is code from pre-draw manager and the
"modern viewport" as well as legacy will go away entirely once the draw
manager is feature complete.
Selection code needs to iterate over DEG_OBJECT_ITER otherwise we won't
get modifiers, dupli objects, ...
Also make selection respect selectability flag.
Review by: Sergey Sharybin
- use DRW_engine prefix for engine types.
- use engine suffix for files that define a draw engine.
- remove engines from include path (they're only referenced once)
- Use uniform color world for the world probe.
- Refactored the Fresnel expression to be better with Area Lights.
- Squared the roughness for default materials.
Needed to remove old draw code entirely.
Object mode selection support, pose and armature still need to be added.
Enabled when 'use_modern_viewport' is set.
- Added New Batch cache routine to get the split mesh for each material. (optimization needed)
- Did some shader modifications to create default_frag and support a somwhat correct fresnel for lamps (to finish)
Otherwise if we create a new collection, and drag a collection into it we either
get a crash, or at the very least we dont get the visibility flags correct.
This is part of the new draw manager design. Any engine (even clay, eevee, ...) should be able to draw to the viewport, as well as render to an image directly.
Changing the API names to conform to that.
Now we just iterate over all objects. It may be a better idea to use a
smarter approach for performance. However, since this function is not
called regularly (only when changing Alembic file paths), it's not a very
big deal.
Was performing context access per object for scene, region etc.
While not very slow they don't change during drawing so cache in a struct.
This also makes it possible to draw in views besides the current context.
Compatibility profile was working fine, this is mostly to get the highest GL core profile version available.
Our minimum requirement is 3.3 core profile. When we request a specific GL version:
- AMD and Intel give us exactly this version
- NVIDIA gives at least this version <-- desired behavior
so we ask for 4.5, 4.4 ... 3.3 in descending order to get the best version on the user's system.
Accept OpenGL 3.0 on Mesa instead of 3.3+ compatibility profile. (requested by @LazyDodo) This will be removed after we finish moving to core profile.
Part of T49012 and T51164
Blender subsystems that care about OpenGL use GL_DEFINITIONS, which now includes the newest (temporary) WITH_LEGACY_OPENGL.
Also updated Gawain's CMake to use this instead of its own logic.
MX (Multiple conteXt) support was dropped from the GLEW 2.0 library to make core profile support cleaner.
Our WITH_GLEW_MX build option was OFF by default already; this commit removes the inactive code paths.
I'm working on a plan for multiple GPUs, contexts, resource sharing, etc. This commit gives us a cleaner starting point for that upcoming work.
Tested on Mac, will test on Linux & Windows immediately after pushing.
This was blocking core context setup on Mac, since accumulation buffers are obsolete. With this (and appropriate CMake options) I now get
renderer: 'Intel HD Graphics 4000 OpenGL Engine'
vendor: 'Intel Inc.'
version: '4.1 INTEL-10.24.45'
in system-info.txt intead of
version: '2.1 INTEL-10.24.45'
The original code was failing because the base to object flushing was
only happening as part of the depsgraph. However we can use the
evaluated values to set the initial values of the base.
In this particular case, we couldn't set the new object visible because
its selectability flag was not set yet.
We were not updating depsgraph when collection just "became" selectable,
but although this doesn't change object selection, it change its
selectability.
Pending: Include the set in the rna depsgraph.objects
In fact it would be nice to unify them both. However this will likely
change once Depsgraph incorporate this iterator, so I'm not sure we
should bother with that.
Related to T51203
Iterator to return the objects evaluated from depsgraph. The
iterator itself will change once CoW is implemented.
This reproduces the behaviour of DEG_OBJECT_ITER but for Python.
Even though this will have to change once we get workspaces, we will
still have a depsgraph for the Scene.
This is required for the upcoming depsgraph.objects RNA iterator.
Example, imagine an object Cube in collections 1 and 2 where both
collections are nested to A. Now we set a "color" property as follow:
```
Scene -> GREEN
--
A -> RED
↳ 1 -> BLUE
↳ 2 -> -
```
In this case the object will be RED, because of A↳ 2.
Now if we have:
```
Scene -> GREEN
--
A -> RED
↳ 1 -> -
↳ 2 -> PINK
1 -> -
--
The object will be PINK because of A↳ 2.
Note that the (top level) collection 1 doesn't influence the object color
because there are no overrides on it. The scene render settings (GREEN
in this case) are only used as fallback if an override is not set at
all.
Immediate mode built-in shader is used for this drawing already.
So there is no reason to try building basic shader which is not
supported in the core profile.
This replaces all direct usage of:
- FIRSTBASE
- LASTBASE
- BASACT
- OBACT
Some usages still remain in legacy utility functions which are called
all over the place.
With the explicit calls we don't need to worry about current state
outside of the GPU module now. In fact. we don't need to worry about
current matrix mode in core profile at all.
Legacy OpenGL now has some code which ensures current matrix mode
when using explicit calls to push/pop matrix.
There is no need to break assumptions of what's being modified
by this call and what's restored. The changes in this function
simply spread crappyness outside of the UI block.
There are two major things in this commit.
First one is to have proper stack for projection matrices. This is
something what OpenGL specification grants to have at least 2 elements
for and what is required to have for proper editor drawing without
refactoring the way how we restore projection matrix.
Supporting this stack have following advantages:
- Our GPU stack is closer to OpenGL specs, making it easier to follow
by other developers who are always familiar with OpenGL.
- Makes it easier to port all editors to a new API.
- Should help us getting rid of extra matrix push/pop added in
various commits to 2.8 branch.
The new API follows the following convention:
- gpuPushMatrix/gpuPopMatrix ALWAYS deals with model view matrix
and nothing more.
While this name does not fully indicate that it's only model view
matrix operator, it matches behavior of other matrix operations
such as transform which also doesn't indicate what matrix type
they are operating on.
- Projection matrix has dedicated calls for push/pop which are
gpuPushProjectionMatrix/gpuPopProjectionMatrix.
There is only two places which are using texture matrix mode:
- Tiled tface support.
- Texture shading mode for texture mapping.
Both cases are subject for reconsideration: it is likely that we'll be getting
rid of tface, which means game properties like tiles needs to be revisited
anyway. As for texture shading it is using basic shader which is also not
supported by core profile anyway.
It is required for our new matrix stack to only have projection and model view
matrix modes. This commit ports paint cursor overlay to model view matrix.
This is an OpenGL 3.3 feature, currently being used for surface normals. It's 1/3 the size of floating point triples and perfect for normals or colors.
See T49012 for why Windows can use this feature regardless of core vs compatibility.
This combines the Mesa fix (16e929e6ff by @brita_) with the Mac fix (89e23c743e by @merwin).
And uses the same fix for another call to glFramebufferTexture introduced in f1fb605ec9.
The issue was going to the fact that GL_ALPHA was deprecated in core profile
and common solution online is to use GL_RED instead. That is what is done in
this commit.
Those tokens are still valid. Although we should not being using them,
they should not prevent us from building with core profile.
In the future we can have a new flag WITH_GL_CORE_STRICT for those.
But only after we build with core profile by default
Object Info node can be useful to give some variation to a single material assigned to multiple instances. This patch adds support for Viewport and BI.
{F499530}
Example: {F499528}
Reviewers: merwin, brecht, dfelinto
Reviewed By: brecht
Subscribers: duarteframos, fclem, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D2425
This replaces access to the first scene layer (which was wrong) with a linear
lookup of scene layer by it's active index.
This seems to be a better temporary solution to have things working for until
we've got proper workspace, depsgraph and it's per-layer storage in place.
For now only compute GGX convolution. The GGX LUT used for the split sum approximation (UE4) is merged with the LTX mag LUT that uses the same parameters (theta and roughness)
First: we settle on core profile 3.3, not 4.1. Second, GL_CURRENT_PROGRAM still exists in 4.1 and 4.2. But it is recommented to use GL_ACTIVE_PROGRAM instead.
Following the logic of gl-deprecated.h we should define it to USE_GL_ACTIVE_PROGRAM instead. That said, removing it for now.
glFramebufferTexture() is only available from OGL 3.2, it is also not part of the ARB_framebuffer_object extension.
I don't know if there is a better way to check for mesa drivers or if using the 2D version will have issues with f2f16a256, but so far I had no problems
Follow-up to 3bc6b831d8
Initial code was getting the number of ShaderInterfaces that could fit between two pointers (which makes no sense). I really meant number of bytes.
Surprised it worked on Mac, glad I tested on Windows before bed :D
ShaderInterface stores names of custom uniforms and all attributes in an internal buffer, but it doesn't know how large to make this buffer until all inputs are scanned.
This commit shrinks the buffer to the exact size needed.
ShaderInterface_uniform searches custom uniforms first, then builtin uniforms if needed.
This reduces the amount of string matching since you're almost certainly looking for one of those custom uniforms. Otherwise you would've called ShaderInterface_**builtin**_uniform.
- test for 2D textures first since it's the most common case
- declare variables close to where they're used
- fix compiler warning for proxy (uninitialized use)
- safe return if n != 1, 2, 3 (should never happen)
- white space
The fragment shader expects a normal, but the vertex shader was not providing one.
Fix: added a new vertex shader that has normals + smooth color interpolation.
I also split gpu_shader_3D_vert in two:
- one with just position
- one with position + normal
For each of the builtin shaders, we should be able to look at the GLSL and tell exactly what it's doing. Using #defines and #ifdefs for rendering options makes the shaders hard to read and easy to break.
The specialized color functions are better in every way:
- faster lookup (don't have to match "color" string)
- flexible inputs (RGB with separate alpha)
- automatic alpha = 1.0 if not specified
Sort of related to T49043
attrib_binding.c uses NULL, so include stddef.
Also swapped stdlib for stddef in vertex_format.c, since it only needs NULL.
Not sure why MSVC 2017 and clang/Mac work without this...
Thanks to @youle for reporting!
This eliminates tons of glGetAttribLocation calls from the drawing loop. Vast majority of code can keep making the same function calls. They're just faster now!
- remove 2D-specific variants of BuiltinUniform enum
- rename remaining builtins to exclude "_3D" since they can be used by 2D or 3D shaders
Follow up to D2626
See GPU_matrix.h & gpu_matrix.c for the important changes. Other files are mostly just updated to use the latest API.
- remove unused functions, defines, enums, comments
- remove "3D" from function names
- init to Identity transform (otherwise empty stack)
- gpuMatrixReset lets outside code return to initial state
Part of T49450
Follow up to D2626 and 49fc9cff3b
* Brings us closer to core profile, all matrices are working, and apart
from a problem with text drawing, Blender is working fine.
* Reduce the coding overhead of having to setup/teardown when
alternating between 2D and 3D drawing sessions.
* Gives us fewer modes and states we need to keep track of.
Unfortunatelly this also "rejects a fundamental change" the original
design was trying to make - that 2D is different from 3D and
deserves its own best implementation.
That said, it is still aligned with the function API design as
originally implemented (i.e., it still uses gpuTranslate2D, ...).
Finally, if you build with core profile and this patch you get:
https://developer.blender.org/F545352
[The text glitch is an unrelated issue].
Reviewers: merwin, sergey, brecht
Differential Revision: https://developer.blender.org/D2626
On Apple we use OpenGL 2.1 + an ARB extension for framebuffers.
The glFramebufferTexture function is part of OpenGL 3.0 but not part of the ARB extension. This commit fills that gap.
All other platforms are using GL 3.0+ already so it's not an issue there. All platforms (Mac too) will use GL 3.3+ soon so this workaround will be removed.
These were the last few glGetUniformLocation calls in source/blender.
The new system gets uniform information once when a shader is created, then uses this cached info every time after that.
This removes glGetBooleanv queries for GL_LIGHTING. This has been #ifdef'd
out with legacy opengl disabled. Thus a false positive still shows up in
the gl queries. Also, note that this removes support for wireframes in
opensubdiv, when desabling legacy opengl, which should be fixed later.
Part of T49043
Some elbeem debug functions had old gl drawing calls. I removed the
functions instead of converting, because Blender doesn't even build
with them enabled anymore, because some elbeem debug libs got removed
at some point.
Part of T49043
... even though 3x3 feels better.
This is a compromise to get core profile up & running sooner. Eventually I'd like to finish the original 3x3 plans, but this commit will let us get on with other tasks.
External API stays (almost) the same. Our GLSL shaders can use this without any changes.
Part of T49450 and T51164
These functions mark the beginning and end of 3D drawing, causing the matrix API to use our own implementation instead of legacy OpenGL.
Part of T49450
Look up "name[0]" when asked for "name", since that marks the beginning of the array.
We're comparing to the name stored in ShaderInterface which comes from glGetActiveUniform.
This eliminates tons of glGetUniformLocation calls from the drawing loop. Vast majority of code can keep making the same function calls. They're just faster now!
- Batch_Uniform*
- immUniform*
- gpuBindMatrices
- and others
- builtin uniforms match what Blender needs
- set input counts in struct (stupid mistake)
- look up uniforms by name
- look up builtin uniforms by enum
- check attrib/uniform locations for error
Same as MEM_SAFE_FREE macro,
checks for NULL, runs free then sets NULL.
Blocks of code that do this many times are noisy and likely
errors here wouldn't be noticed immediately.
Also NULL's static vars which were being left set.
Problem was an edge case where vertex_ct logic and draw logic disagreed on how many dividers to draw.
Fix: copy draw logic to earlier vertex_ct
I also skip any drawing or setup if vertex_ct = 0, and set color attribute only for each line's provoking vertex. Small optimizations but these things add up.
This removes MAX_STORAGE, MAX_BUFFERS, MAX_TEXTURES, MAX_PASSES limits.
Actual memory saving isn't so important, it just means we don't need to
manually bump these based on changes to engines.
The issue was caused here by usage of deprecated GL_CURRENT_PROGRAM
which was returning rubbish value.
Now we use imm API and create vertex format prior to immBindProgram.
This made us required to have some sort of state passed from setup
function to actual drawing.
Note: I’d assume gawain equivalent to glDrawArrays would be batches? But
for two lines drawn twice this looks totally overkill anyway, so
switched back to basic immediate-mode-like API.
A bit frustrating to work on this code, since afaict you cannot check
the results in Blender, being mostly unused currently...
This was slightly less obvious, especially particle billboard drawing.
That one now requires 1.5 times more space in VBOs and ParticleDrawData
buffers, since we have to draw two triangles per particle, instead of a
single quad... And diagonal of each quad is now drawn in wire mode, not
sure how much we consider this an issue (as in, will this particle draw
code change a lot in future?).
From quick check on the web seems there is no other way to do anyway. :/
Using Texture Arrays to store shadow maps so less texture slots are used when shading. This means a large amount of shadows can be supported.
Support Projection Shadow Map for sun like in old BI/BGE.
Support Cube Shadow Map for Point/Spot/Area lights. the benefit of using it for spot light is that the spot angle does not change shadow resolution (at the cost of more memory used). The implementation of the cubemap sampling is targeted for 3.3 core. We rely on 2D texture arrays to store cubemaps faces and sample the right one manualy. Significant performance improvement can be done using Cubemap Arrays on supported hardware.
Shadows are only hardware filtered. Prefiltered shadows and settings comming next.
This is an auto-generated list, crossing gl-deprecated.h, glew.h and the
Blender code. It allows Blender to build with core profile.
WITH_OPENGL_LEGACY=ON: nothing changes
WITH_OPENGL_LEGACY=OFF and WITH_GL_PROFILE_CORE=OFF:
It stubs deprecated legacy calls.
WITH_OPENGL_LEGACY=OFF and WITH_GL_PROFILE_CORE=ON:
It stubs deprecated legacy calls thus allowing Blender to build with
core profile only.
Technically you only want to use WITH_OPENGL_LEGACY=OFF when
WITH_GL_PROFILE_CORE=ON. But it doesn't hurt to have it working for both
scenarios.
Reviewed by: merwin
Differential Revision: https://developer.blender.org/D2610
See gpu_shader.c for the main changes.
EXT_geometry_shader4 brought this feature to GL versions < 3.2, but now it's just cluttering up our code.
Soon all platforms will be on version 3.3 so we won't even have to check support at runtime!
Callers now have to use Gawain's PRIM enum to specify geometric primitives.
This makes the API more bullet-proof (at least less vulnerable) since GLenum covers waaay more than GL_POINTS, GL_LINES, etc.
Also prepares us for Vulkan.
Callers now have to use Gawain's COMP enum to specify vertex attributes.
This makes the API more bullet-proof (at least less vulnerable) since GLenum covers waaay more than component types.
Also prepares us for Vulkan.
Single quads are drawn as a TRIANGLE_FAN, with 4 verts in the same order.
Multiple quads now use PRIM_QUADS_XXX and will need further work. Only 8 places still use this.
Part of T49043
Quads are not part of modern GL or Vulkan, so we should avoid them. XXX makes coders think "hmm how could I draw this without using quads?"
Quads will be removed during the transition to core profile.
Part of T49043
We concatenate #defines and #extensions into these, and can count the max string lengths needed. 256 is enough to hold today's strings; we can adjust later if needed.
When WITH_LEGACY_OPENGL = OFF.
This is our final target for Blender 2.8, all previous versions will be dropped in the future. GLSL 3.3 is richer so we don't require as many extensions.
Original code from @Severin with changes from @dfelinto & @hypersomniac.
This doesn't cause many functional changes
besides using new transform manipulators.
Submitted as D2604
This fixes T51143.
gl_ClipDistance is part of GLSL version 1.3 but Mac is stuck on 1.2 for now.
This workaround uses GPU_SHADER_3D_UNIFORM_COLOR for the entire rotation widget, ignoring any clipping plane. The CLIPPING shader only works on GLSL 1.3+ so I removed its 1.2 cruft.
A legacy implementation using gl_ClipVertex might be possible, but is not worth the effort. This problem (and workaround) goes away when all platforms move to 3.3 core profile.
changes:
- exact vertex count
- take bool (filled vs outline) instead of GLenum
This function has some flexibility that is not currently used. I left that in.
Each function takes a bool (filled vs outline) and a color. We already had multiple ways of passing color in; these are still here. Special variant for anti-aliasing.
- took GLenum out of interface
- removed UI_RB_ALPHA flag (only one place really used it)
- use exact vertex count
- removed redundant state changes (BLEND, LINE_SMOOTH)
This introduces a new CMake option - WITH_LEGACY_OPENGL. Without this option
things may not draw perfectly, however, we should soon be able to build with
OpenGL core profile.
The matrix-related api calls are (still) not handled here (glTranslate, ...).
There seems to be no consensus on whether to make this build option the
default. We can talk about this later. For now two things are the
priority:
(1) To get rid of deprecated calls when WITH_LEGACY_OPENGL is ON
(2) To make core profile work for Mesa/Mac when WITH_LEGACY_OPENGL is OFF
Reviewers: merwin, sergey, campbellbarton
Differential Revision: https://developer.blender.org/D2603
Many thanks for Sergey Sharybin for the help.
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
Reference document: http://docs.gl/gl3/glPushAttrib
This patch only tackles the bits that are set by Blender with the
following exceptions:
1) Deprecated states (e.g., GL_STIPPLE) are not saved/restored
2) The exception being GL_ALPHA_TEST, which will be removed, but it may
affect drawing too much now. To be removed once we no longer set GL_ALPHA_TEST
elsewhere.
3) paint_cursor will be tackled separated, since it was abusing
glPush/PopAttrib in the first place.
4) Despite what the glPushAttrib page above may suggest, GL_DEPTH_WRITEMASK needs glGet, not glIsEnabled
5) BGE is still a problem since it relies on GL_ALL_ATTRIB_BITS which
would lead to a way more complete/lenghty solution. Since the BGE has
other (OpenGL deprecated) problems anyways, it can be handled on its own
time.
Finally, the original design for 2.8 was to implement a proper stack
system. However we need to move to core profile sooner than later. So
this is a pragmatic temporary (that may be permanent) solution.
Reviewers: merwin, campbellbarton
Differential Revision: https://developer.blender.org/D2600
These bits became obsolete with the new layer system, so we can
simplify some code around them or avoid existing workarounds which
were trying to keep things working for them.
There are still work needed to be done for on_visible_change to
avoid unnecessary updates, but that can also happen later.
Core of the issue was that some of our Theme colors are RGB-only, but
were loaded as RGBA.
Note that tracking all possible cases is pretty impossible, so we'll
have to tackle those as they get reported am afraid.
- use 'imm_draw_' prefix for functions that draw.
- use '_3d' suffix for 3d functions, no suffix for 2d functions.
- use terms fill/wire (shorter than filled / lined).
Also add `imm_draw_circle_fill_3d` (only had wire version)
Added new shader for clipping, also cleaned up rotation manipulator
drawing code a bit.
This code should be replaced by new transform manipulators soon, just
keeping this working in the meanwhile.
I started cleaning up UI_view2d_scale_get where the y scale was unused, then got carried away...
- for loop scope
- declare variables closer to where they are used
- move early exits closer to function start
- unsigned --> unsigned int
Fixed a few issues
- wrong transform matrices
- assert on node with no sockets
- color of collapsed nodes, some title areas
Also includes minor cleanup.
Objects that were using the same lamp data were having the same display matrices.
This is fixed by allowing engine to store a memory block inside the object itself.
Using Linear Transform Cosines to compute area lighting. This is far more accurate than other techniques but also slower.
We use rotating quad to mimic sphere area light. For a better approximation, we use a rotating octogon.
This moves selectability/visibility flag flush from some hardcoded
places in the code to depsgraph. This way it is possible to simply
tag depsgraph to update those flags and rest it'll do on its own.
Using depsgraph for such flush is an overkill: those flags are fully
static and can not be animated, so it doesn't really make sense to
hook only those to depsgraph.
However, in the future we will have overrides on collections, which
ideally would need to be animatable and drivable and easiest way
to support this is to do this on depsgraph level, so it ensures
proper order of evaluation for animation and drivers. And it seems
logical to do both overrides and flags flush from depsgraph from
this point of view.
This commit also includes the evaluation of IDProperty for collections,
which basically are just another form of override. So once we implement
the other kind of overrides the flushing and collection evaluation won't
change.
Patch by Sergey Sharybin and Dalai Felinto
This should have been done earlier. But now that we may see more activity in master due to bcon3 merges, it is even more important to stress out the separation between master and 2.8.
Also I needed the version bump for idproperties doversion (they needed
to happen in _after_linking, and we don't have access to
DNA_struct_elem_find there).
Last but not least, every time I posted a video or image from 2.80, I
got someone confused about the version showing in the infobar.
First this replace a custom data struct with IDProperty, and use
IDProperty group merge and copying functions. Which means that a collection
property setting is only created if necessary.
This implements the "Layer Collection settings" override system, as
suggested in the "Override Manifesto" document.
The core is working, with Scene, LayerCollection and Object using a
single IDProperty to store all the render settings data. Next step is to
migrate this to depsgraph.
Note: Clay engine "ssao_samples" was hardcoded to 32 for now. It will come
back as part of "Workspace Settings" later.
Many thanks for Bastien Montagne for the help with the UI template
nightmare ;)
Differential Revision: https://developer.blender.org/D2563
GPU_framebuffer no longer handles transform matrices, which this code was relying on. Made screen_preview_draw responsible for its own ModelView matrix.
This restores the feature for legacy viewport only. Modern viewport, Clay, Eevee, etc. will need further work.
Eventually we should rename this something other than "OpenGL".
I was hoping this would fix the issue of the object not moving after you copy it (right now you need to manually grab the object afterwards). But unfortunatelly it does not
rB870440dee910c9 just did NULL-check for Main pointer, actual issue is
that bContext pointer was NULL. This can be fixed by ensuring
PROP_ENUM_NO_CONTEXT flag is not set by calling
WM_operator_properties_sanitize when creating RNA buttons. Now, layout
previews are visible in keymap editor too.
Client vertex array state is deprecated, and these are the default values anyway.
No need to bind any basic shader. Let drawing code decide which shader it wants to use.
Part of T49165 (general OpenGL upgrade)
- use in/out instead of attribute/varying
- use named output instead of gl_FragColor
- use texture() instead of the multitude of older texture sampling functions
The #if __VERSION__ == 120 paths (needed on Mac) will be removed after we switch to 3.3 core profile.
Part of T49165 (general OpenGL upgrade)
This change looks small, but it switches the entire 3D viewport from legacy OpenGL functions to our own code.
Kept non-modern viewport on legacy path so we can compare easily (via the Modern Viewport checkbox).
Part of T49450
Builtin names staring with gl_ will not be available in core profile. Same with the ftransform function. New matrix API provides the same names minus the gl_ prefix.
Part of T49450
- init projection matrices with identity
- fix copy/paste mistake in GetProjectionMatrix3D
- add extra matrices needed by material GLSL
Working toward T49450
New matrix API does not support texture matrices. Not sure what the final code will look like, but this at least avoids interference with new ModelView matrix.
Marked each line with TEXTURE so they can be disregarded during searches.
Related to T49450
Removed infinite details and went for decreasing details with the distance instead (like the axis aligned ortho view auto sized grid).
Separate drawing of the Z axis into 2 pass (using shading group) to render ordered transparency with the main grid pass.
Take advantage of 2D functions, rotation about the X Y or Z axis, uniform scale factors.
We no longer need to call gpuMatrixBegin_legacy() before using the new API locally in functions.
related to T49450
Mass replacing the common code of all tests
```
echo "Fixing $1"
ed "$1" <<'EOF'
1,/Testing/d
i
from render_layer_common import *
import unittest
import os
import sys
sys.path.append(os.path.dirname(__file__))
.
w
q
EOF
```
Using line-width of 120
Pretty sure source/blender is now finished, with all legacy matrix calls confined to gpu_matrix.c.
This was the easy part, but doing it first makes the next part much easier. TODO and XXX notes describe what is left.
glMatrixMode is still in place, since the new API does not share this concept of modes. Similar for glOrtho and glFrustum which I'll tackle very soon.
Part of T49450
For functions that expect a 4x4 matrix, you can pass in that, or array[16], or float*, or... Casting at each call site can get annoying, and obscures the logic.
The C11 section still needs work, but the non-C11 macros help on the system I tested on (Mac/clang).
Part of T49450
This is used to send latest matrix values to shader when drawing.
Previously handled by calling OpenGL matrix functions, followed by gpuMatrixUpdate_legacy. With this change that function is no longer needed.
Part of T49450
For the sake of forward progress on T49450
We can now replace legacy gl* matrix function calls with their gpu equivalents. "Inactive" in this code means we're using the legacy matrix stacks, not our own. Setting up the proper gpuMatrixBegin2D/3D/End calls can be done afterward.
Most or all of this will be removed after the transition to core profile.
We render selected meshes into another buffer and use a screen space shader to expand the color out of the mesh silouhette.
Pros: only one additionnal render pass is needed (like old outline code), and we have occluded informations.
Cons: memory usage is a problem. This method needs 2 color buffer to ping pong when expanding the outline and 1 depth buffer to test occluded fragments. This gives a 88 bits/pix memory footprint.
Idea: Since we don't need all color range but only some uniform colors (theme colors) we could manipulate only the color ID instead of the whole color this could cut the color buffer size and lower the memory footprint to 58 bits/pix.
It also adds nice occluded silouhette information for selected objects that are behind visible objects.
This methods is really heavy because it needs to render the wires twices.
This attempt at TLS was leftover from an earlier prototype. It never worked with Blender's build system, and was defined to just exist, not to actually do anything.
NOTE: This is really a backend-only implementation, nothing is changed in the UI
Adds a tab button-type and the basic drawing and handling code for it.
More work needs to be done on it, but idea is to get in ready for usage in the
topbar.
Differential Revision: https://developer.blender.org/D1371
Before now it lived in source/blender/gpu for convenience. Only a few files in the gpu module use Gawain directly.
Tested on Mac, time to push and test on Windows.
Todo: some CMake magic to make it easy to
#include "gawain/some_header.h"
from any C or H file. Main problem here is the many editors that include GPU_immediate.h which includes Gawain's immediate.h -- is there a way to avoid changing every editor's CMakeLists?
Now that we're almost done with T49043, let's run immediate mode at full speed. Debug builds will still do strict checks.
Developers should still test their changes before committing! Recommended:
$ make debug (or make lite debug)
$ blender --debug-gpu
We concluded this is going to be the display mode users will need to work
with the most, so makes sense to make it the default one.
Also, if the opened file only has one collection in the active render
layer, we expand it (almost empty list would be misleading).
What I had to do to make the expanding work is a bit ugly, but didn't
find a better way. During do_version we don't have access to the
TreeElement instances, and including ED_outliner.h to share code here
should be avoided too.
GL_SELECT is really slow in this branch and will be removed.
For now we simply change AUTO behavior to avoid possible conflicts with merges
and upcoming color-id-based selection.
Talked with Pablo Vazquez (venomgfx) and Julian Eisel (Severin), and we came up with this solution instead.
Basically, if the file has only one layer, it is converted to a collection named "Default Collection". Otherwise we name the collections: "Collection 1 [converted from 2.75]"
Just do early output and don't bother with any GLSL program bind when
there is not enough points of lasso to draw.
This could have happened at the very beginning of the stroke.
So we can store (for example) vertex positions in one buffer and normals + colors in another buffer. Not super exciting right now, but very useful once we start changing some attribute values.
Supports future work by Clément et al. Only tested with one VBO per Batch since that's all our current code uses.
glMaterial
glColorMaterial
glPixelTransfer
and glEnable/Disable for
GL_FOG, GL_LIGHTING, GL_COLOR_MATERIAL
All of these were just setting default values, so I don't expect any visible change.
Part of T49165 (general OpenGL upgrade)
GPU_viewport_bind & unbind should be called as pairs. A recent commit -- 3b91989a09 -- called unbind only for some code paths, overflowing OpenGL's matrix & attrib stacks.
These are from the ARB_vertex_type_2_10_10_10_rev extension that became part of OpenGL 3.3.
So they are new, but only exist for compatibility with immediate mode, which is old.
Related to T49165 (general OpenGL upgrade)
A user doesn't want to necessarily create a new Screen only because she
wants a new window.
This patch allows the user to pick the screen to use for the new Window.
If the screen picked is the active one, it duplicates it (as the old
behaviour in Blender).
Patch with contributions and fixes by Julian Eisel (Severin)
Subscribers: venomgfx
Differential Revision: https://developer.blender.org/D2555
Turned out to be a quite easy fix. I thought the issue was that we
couldn't identify the TreeStoreElem when (re)creating its TreeElement item
correctly, because for non-ID elements that would be index dependent (=
bad for drag & drop). Turns out that we're actually allowed to store
custom data within the TreeStoreElem, the thing is just that it gets
stored as ID pointer (highly ugly and highly misleading).
Anyway, seems to work now so I won't complain too much :)
This way we can ensure the overlay to indicate where the item would be
placed if it was dropped now is always at the correct place and doesn't
mislead the user.
Two issues are remaining, they'll be fixed separately:
* Graphical feedback when dragging within the master collection is wrong
* There's some bug where collections swap places instead, Dalai will investigate
Note 1: renamed draw_cursor to draw_text_decoration, since it was drawing
cursor, margin, selection and line highlight
Note 2: commented out code update coming next
Part of T49043
This also fixes a little bug, which caused `draw_fcurve_samples` to
never be called, and thus sampled curve range boundaries were not drawn.
Part of T49043
All engines are now called by the draw manager. Engines are separate entities that cannot interfer with each others.
Also separated draw_mode_pass.c into the mode engines.
This is to be used from the Outliner, when dragging and dropping
collections from the Active Render Layer
It also includes a cleanup on the outliner so it calls the new
functions. Note: the outliner still needs fix to allow all the
functionality here exposed.
But this will be tackled by Julian Eisel later.
This helper function was marked DEPRECATED since it uses old OpenGL calls.
Switched last 2 uses to imm_draw_checker_box, which does the same thing, only awesome.
Part of T49043
Renamed existing getter/setter that only FX shaders use. We could convert FX code to use the richer new interface or leave it as is.
Removed unused GPUShader fields. ShaderInterface tracks the same information.
It wasn't using old immediate mode, but was using
- client vertex arrays (obsolete)
- quads (obsolete)
- state attrib stack (obsolete)
- polygon mode (still allowed, but gross)
After a GLSL program is linked we can get all its inputs & never have to ask it again.
Several uniforms are considered "built-in". Nothing special about these to OpenGL itself, they just follow conventions of our built-in shaders.
This will help the matrix API, immediate & batch drawing APIs, and allow extra error/compatibility checking.
PrimitiveClass will help match shaders to draw calls & detect usage errors. For example a point sprite shader only makes sense with PRIM_POINTS.
Updated other files to include new primitive.h
Nothing happen yet when it's supposed to insert the collection into
another one, that part will be handled by @dfelinto.
See gif for demo of how it works UI wise: {F500337}
Also fixed off-by-one error in utility function.
There are now only referenced in:
* drawobject.c
* particle_edit.c
* space_image.c (a single case to be handled on workspace branch)
* rigidbody_constraint.c (to be handled in the following commit)
There were some issues with how we store outliner tree elements:
Apparently the only removable elements have been data-blocks so far.
When recreating the TreeElements, their TreeStoreElem instances were
mainly identified by their ID pointer. However non-data-blocks mostly
depend on an index. For collections, such an index isn't a reliable
measure though if we want to allow removing items. Depending on it for
identifying the TreeStoreElem instance would cause some quite noticeable
glitches (wrong highlights, two elements sharing highlight, etc).
For now I've solved that by actually removing the TreeStoreElem that
represents the removed element. A little limitation of this is that
after undoing the removal, some information might get lost, like
flags to store selection, or opened/closed state.
A better solution that would also fix this issue would be having a real
unique identifier for each non-data-block element, like an idname or even
its data-pointer. Not sure if we can get those to work reliable with
file read/write though, would have to investigate...
Also added a general Outliner tree traversal utility.
Artifacts still remained when 2 vertices were linedup in orthographic mode or with very acute vertex angles.
This commit fix that by adding even more geometry.
ifdef out most debugging code since Apple does not implement any debug extensions. We can revisit this if they ever do (don't expect that).
Changed output message so Mac users don't think --debug-gpu is broken.
I was removing deprecated/obsolete state from this function. About halfway through I started questioning the need for the whole thing.
GPU_state_print is not called anywhere, but is (was) available as a development aid.
External GL debugging tools are really good these days! We should use those to examine state & not roll our own.
Updated shader names and code that uses them.
All of these shaders produce round points that are anti-aliased and blended against the background.
These were initially named SMOOTH because they replace glEnable(GL_POINT_SMOOTH). But SMOOTH in shader-land refers to vertex attribute interpolation (like glShadeModel(GL_SMOOTH)).
Using SMOOTH to mean two things is confusing, so we now use AA to mean "the point is anti-aliased".
- Size parameter is total size of the shape, not its radius (half size). Updated hard-coded sizes to match this.
- Shader expands size to include outline.
- Fixed fringe between outline color and transparent background.
We do a strip of triangles around the triangle of interest and modify the variying vars to "trick" the fragment shader into rendering what we need.
This keeps the compatibility for both shaders.
Vertex still get half displayed when angle at the vertex is very acute.
This patch is only for the simple, no vert clipped case.
This is 2.5x slower than without the trick (on my hardware with 1million tris).
Based on the previous overlay shader from merwin.
This shader takes care of clipped vertex cases and do all edit mode face info in one pass (except face centers).
As the shading is done one the triangle itself the visual can't go beyond the surface of the mesh. That leads to half displayed edges on the outline of the mesh.
This problem can be fixed by a second pass.
This is work in progress.
This was causing blender to segfault.
We now add create a new collection and link to the layer before adding
the new object
(also included unittests, and requires updated lib/tests)
Note that since there is no (efficient) ways to get arrays of
MVert/MEdge/etc. out of a BMesh, I refactored quite heavily internals of
BKE_mesh_render.
Now, when you do need acess to mesh data to generate cached batches, you
create an abstract struct from mesh (either Mesh or BMesh if available),
and then use advanced helpers to extract needed data, on a per-item
basis (no more handling of arrays of verts/edges/... in batches code).
This allows to:
* Avoid having to create arrays of BMesh elements.
* Take advantage of existing advanced BMesh topology and connectivity data.
Reviewers: dfelinto, fclem, merwin
Differential Revision: https://developer.blender.org/D2521
Replaced all calls to `imm_draw_line` by plain `immVertex2f` calls, and
removed `imm_draw_line`, as that function was not supposed to exist in
the first place, and causes unnecessary calls to `immBegin`/`immEnd`.
Part of T49043
* Fix several wrong coordinates, causing things to be drawn in the wrong places.
* Remove unexpected return.
* Slight peformance improvement, by reducing number of shader binds.
* Minor code style stuff.
Part of T49043
This adds initial support for reordering collections from the Outliner
using drag & drop.
Although drag & drop support is limited to collections for now, this
lays most foundations for general drag & drop reordering support in the
Outliner. There are some design questions to be answered though:
* Would reordering of other data types (like objects) be a purely visual change or would it affect the order in which they are stored? (Would that make a difference for the user?)
* Should/can we allow mixing of different data types? (e.g. mixing render layers with objects)
* How could we realize this technically?
Notes:
* "Sort Alphabetically" has to be disabled to use this ("View" menu).
* Reordering only works with collections on the same hierarchy level.
* Added some visual feedback that should work quite well, it's by far not a final design though: {F493806}
* Modified collection orders are stored in .blends.
* Reordering can be undone.
* Did minor cleanups here and there.
This should give the overall direction to whom wants to finish it.
- Renamed EDIT mode engine to EDIT_MESH mode engine
- Introduce EDIT_ARMATURE mode engine
- Started to port legacy drawarmature.c to draw_armature.c
- Added runtime display matrices to EditBone and bPoseChannel
- Added Object space instance vertex shader and modified the simple lighting shader accordingly
This way we can point submodules to different branches.
There are two side-effects to this:
- Git 1.8.2 becomes the minimal required version now
to support this feature.
- Not sure how doing local changes in submodules followed
by `make update` will behave. We don't use explicit rebase
now.
Perhaps this is not so bad, since it was already quite
dangerous thing to do.
Basically DEG_OBJECT_ITER (or rather,
BKE_scene_layer_engine_settings_update) wasn't creating
Object->collection_settings data for invisible objects.
Now I'm removing those objects from the loop entirely. If we are to
bring them back we need to either create CollectionEngineSettings dat
from them or to skip them in DRW_mode_cache_populate.
test_evaluation_visibility_a failed before, but it is now fixed
test_evaluation_visibility_b passed before and was used as control to make sure it was not broken
Based on D2371 from @ryry. Mostly T49043, a little T49042.
Deleted some unused drawing code instead of updating it.
I have a few more things in mind for this file... tomorrow!
[Note: this patch functionality was implemented in parallel, independently at bf83f097ad
That said, the original patch was also removing an unnecessary include,
so here it is]
Replaced the one call to `glutil_draw_lined_arc`.
This seems to be the only draw call in this file.
Reviewers: merwin
Tags: #bf_blender_2.8
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2497
This is a more complex approach, which makes me really want to use
IDProperty instead (assuming we handle their merging nicely).
In fact I would expect this to happen in readfile.c, not during
doversion, but I can revert this later.
For now this allow for demo files saved with 2.8 to keep working even
after we add/remove engine settings properties.
The values are merged. There is no purge though, so
old CollectionEngineSettings and CollectionEngineProperty will live
forever (for the time being).
This prevents crashes when a file was saved with 2.8, but a new
engine settings property was created.
In those cases any previous collection settings are wiped out. We can do
an elegant merge soon.
Other than the general conversion:
* Made some slight aesthetic improvements.
** Removed gradients.
** Replaced stipples with transparency for hidden strips.
** Made strip borders less harsh.
** Removed stripes from offsets and made them brighter.
* Made only the visible parts of waveforms be drawn.
* Fixed a few drawing bugs.
** Background was not being drawn when buffer is NULL, and no
grease pencil is being drawn.
** Offset drawing ignored strip visibility.
Also, note that diagonal stripes for locked and error strips, are still
being drawn with the old api, as they await a new shader in order to
be converted.
Part of 49043
`SEQUENCER_OT_slip` was calling `draw_sequence_extensions` to redraw the
extensions during modal operation, but that is redundant, as it is
already called by the regular draw loop. Because it was called on top of
the draw loop, it was actually obscuring other parts of the strip that
would normally be drawn on top of it.
Somewhat part of 49043
The idea is to iterator over the active layer of the current scene and
then over the active layer of the set scenes.
In the future, once we get workspace we will get the initial renderlayer
from context, while the background sets will still use their active
renderlayer.
Some tests may break Blender, which makes the entire unittest routine to fail.
They are now I isolate the tests into individual files
Kudos to Sybren Stüvel and Sergey Sharybin for the advice.
Note: at the moment test_link.py is failing (since a41bbfb7)
Instead of bothering with matrix transformations, I am simply adding the jitter to the vertices.
Related to: rB31a21135cf72c8623be7f5aee2bfdac983ceae2e
Note: This makes the jittering to not work :/
@merwin, would you know how to use gpuMatrixBegin2D for this case? I
think it must be the reason behind the lack of jittering. But I couldn't
get it to work (the 2D shader is asking for a 3D Matrix).
Part of T49043
All (except for stick and wire) are now rendered using batch or immediate API.
Using simple front facing lighting for now, waiting for gpu_basic_shader.c to be recoded.
This involved some refactoring. The original code was relying on a cache of pre-allocated arrays which in turn were still re-populated every redraw loop.
We now ditch those arrays, and make the draw "on the fly".
Part of T49043
@merwin can you just check if you foresee any performance impact with this approach?
How to test this drawing: create and edit a curve and press shift + drag your mouse (or tablet). The Curve needs a Bevel Depth > 0.0.
Note: The ideal solution would be to use a different shader, that takes
no lighting. However according to Clément Foucault there is an assert preventing the same batch to
me used with different attributes (or something like that). Il wait
until the end of such resolution before revisiting this. That said, it
is working fine.
Part of T49043
Differential Revision: https://developer.blender.org/D2501
Note: we are now merging all the collection engines (mode and render), which eventually may get slow. But as stated before, this is to expose the functionality, while waiting for proper depsgraph integrated solution.
I didn't manage to get the proper object context in the collection
properties editor. That said I got it working for now in a temporary way
since this will change once we get workspaces anyways
(see changes in buttons_context.c and
rna_scene.c::rna_LayerCollection_mode_settings_get)
I still need to handle the merging of the settings. I will find a
provisory solution while we wait for depsgraph.
(also layer_collection_create_mode_settings_object and layer_collection_create_mode_settings_edit could probably be elsewhere - under draw/engines likely)
Also some conversion to new imm mode (T49043).
Multiple editors affected.
We could push this even further & draw all keyframes in an editor with a single draw call.
Something is strange with keyframe markers in blender2.8 -- they're not showing up before or after this commit. They do appear in master. This commit probably needs some follow-up work after keyframes are showing again. Better to share this code now instead of sitting on it.
Now we can draw keyframe markers as point sprites, with fewer draw calls and state changes.
Based on the builtin shader for round points with anti-aliased outline. This one is more pointy.
Changed the color function to output a float[4] to use with shaders.
Temporary leaving the UI_ThemeColor/glColor function.
Porting draw_bone_octahedral (wire) to Batch API.
ui_draw_but_TRACKPREVIEW
Changed stipple shader usage to a bunch of GL_LINES with flat color
OpenGL immediate mode: interface_draw.c (end)
Eradicate leftover legacy functions.
Fix a crash with histogram resolution.
coding style, float literals
Converted some (expr / literal) to (expr * literal) where it does not impact readability.
Simplified a few function calls.
ui_draw_but_COLORBAND
Introduced a new checker shader to be used mostly on transparent areas.
OpenGL immediate mode: interface_draw.c (cont)
ui_draw_but_UNITVEC
Introduced a new shader to be used for simple lighting.
Some `UI_ThemeColor` calls were left in converted files, in some cases
because they were just overlooked, and in the case of text drawing,
because the new BLF color functions were not yet implemented at the
time of conversion.
Also converted one `drawcircball` call that was left in
transform_constraints.c
Part of T49043
Still has one `UI_ThemeColor` call, because drawing is happening in a DM
drawing callback which hasn't been converted yet.
Also has some old gl calls that are #ifdef'ed out.
This also changes active face drawing in UVs from stippled to a solid
color, which makes active faces much more visible, and also looks nicer.
The same should probably be done for active face drawing in the 3d view.
(has been discussed with merwin on IRC)
Part of T49043
The parent_selected() function mixed semantics of "needs to be exported"
and "is selected", which is confusing. Now just selected objects are
exported to Alembic; any parent transforms that are required were already
taken care of by other code.
Things like selection outlines didn't work at all.
Caused by rBc973e8d2da5cf3f.
When splitting up bitflags, the equivalent to `foo->flag & (bar1 + bar2)` is
`(foo->flag1 & bar1) || (foo->flag2 & bar2)`, *not*
`(foo->flag1 & bar1) && (foo->flag2 & bar2)`.
Also, let's please avoid using '+' operator for bitwise operations, a
binary addition is a binary OR *with* cary, which can cause quite some damage.
Fix outliner related crashes. Basically in some functions bContext was
not passed around, so CTX_data_scene_layer(C) was crashing.
Right now we still rely on ob->flag SELECT in some places. In order to use the base flag we will need to bring back the Bases to the outliner.
Adds a new outliner display mode "Collections" which draws the active
collection. We might want to rename it to "Active Collection" if we don't
plan to support showing other collections there.
Also added the buttons for restricting visibility and selectability.
@dfelinto, code in restrictbutton_collection_hide_cb and
restrictbutton_collection_hide_select_cb is duplicated from
rna_LayerCollection_hide_update and
rna_LayerCollection_hide_select_update, maybe utility functions would be
handy for this?
(and replace more instances of BaseLegacy/scene->base with Base/sl->object_bases)
Still need mouse selection, box selection, and menu selection
Also, there is still a problem with BA_WAS_SEL, at the moment only the
objects centers are highlighted.
To bring this fix a step further we need to address all the BA_WAS_SEL instances, and make sure they follow the new design.
This commit allow you to see the object selected (its center anyways) when you do select all.
Note: in the clay engine selection (a) was already working fine.
Every time:
* A collection settings is set
* A collection visibility changes
* An object is added/removed/ ...
We need to recalculate the "accumulated" CollectionEngineSettings that
the render engine should use for an object.
This is to be handled by the depsgraph. Meanwhile this code should allow
us to start using those settings in the render engines.
Note: We are storing this in the objects, which means we can only have
one active calculated option every time.
This is intended to get the conversation with the Depsgraph department
going.
Initial work by Clément Foucault with contributions from Dalai Felinto
(mainly per-collection engine settings logic, and depsgraph iterator placeholder).
This makes Blender require OpenGL 3.3. Which means Intel graphic card
and OSX will break. Disable CLAY_ENGINE in CMake in those cases.
This is a prototype render engine intended to help the design of real
render engines. This is mainly an engine with enphasis in matcap and
ambient occlusion.
Implemented Features
--------------------
* Clay Render Engine, following the new API, to be used as reference for
future engines
* A more complete Matcap customization with more options
* Per-Collection render engine settings
* New Ground Truth AO - not enabled
Missing Features
----------------
* Finish object edit mode
- Fix shaders to use new matrix
- Fix artifacts when edge does off screen
- Fix depth issue
- Selection sillhouette
- Mesh wires
- Use mesh normals (for higher quality matcap)
- Non-Mesh objects drawing
- Widget drawing
- Performance issues
* Finish mesh edit mode
- Derived-Mesh-less edit mode API (mesh_rende.c)
* General edit mode
- Per-collection edit mode settings
* General engines
- Per-collection engine settings
(they are their, but they still need to be flushed by depsgraph, and
used by the drawing code)
Design Documents
----------------
* https://wiki.blender.org/index.php/Dev:2.8/Source/Layers
* https://wiki.blender.org/index.php/Dev:2.8/Source/DataDesignRevised
User Commit Log
---------------
* New Layer and Collection system to replace render layers and viewport layers.
* A layer is a set of collections of objects (and their drawing options) required for specific tasks.
* A collection is a set of objects, equivalent of the old layers in Blender. A collection can be shared across multiple layers.
* All Scenes have a master collection that all other collections are children of.
* New collection "context" tab (in Properties Editor)
* New temporary viewport "collections" panel to control per-collection
visibility
Missing User Features
---------------------
* Collection "Filter"
Option to add objects based on their names
* Collection Manager operators
The existing buttons are placeholders
* Collection Manager drawing
The editor main region is empty
* Collection Override
* Per-Collection engine settings
This will come as a separate commit, as part of the clay-engine branch
Dev Commit Log
--------------
* New DNA file (DNA_layer_types.h) with the new structs
We are replacing Base by a new extended Base while keeping it backward
compatible with some legacy settings (i.e., lay, flag_legacy).
Renamed all Base to BaseLegacy to make it clear the areas of code that
still need to be converted
Note: manual changes were required on - deg_builder_nodes.h, rna_object.c, KX_Light.cpp
* Unittesting for main syncronization requirements
- read, write, add/copy/remove objects, copy scene, collection
link/unlinking, context)
* New Editor: Collection Manager
Based on patch by Julian Eisel
This is extracted from the layer-manager branch. With the following changes:
- Renamed references of layer manager to collections manager
- I doesn't include the editors/space_collections/ draw and util files
- The drawing code itself will be implemented separately by Julian
* Base / Object:
A little note about them. Original Blender code would try to keep them
in sync through the code, juggling flags back and forth. This will now
be handled by Depsgraph, keeping Object and Bases more separated
throughout the non-rendering code.
Scene.base is being cleared in doversion, and the old viewport drawing
code was poorly converted to use the new bases while the new viewport
code doesn't get merged and replace the old one.
Python API Changes
------------------
```
- scene.layers
+ # no longer exists
- scene.objects
+ scene.scene_layers.active.objects
- scene.objects.active
+ scene.render_layers.active.objects.active
- bpy.context.scene.objects.link()
+ bpy.context.scene_collection.objects.link()
- bpy_extras.object_utils.object_data_add(context, obdata, operator=None, use_active_layer=True, name=None)
+ bpy_extras.object_utils.object_data_add(context, obdata, operator=None, name=None)
- bpy.context.object.select
+ bpy.context.object.select = True
+ bpy.context.object.select = False
+ bpy.context.object.select_get()
+ bpy.context.object.select_set(action='SELECT')
+ bpy.context.object.select_set(action='DESELECT')
-AddObjectHelper.layers
+ # no longer exists
```
Marks matrix state as dirty so shader will use the latest values from glScale, glTranslate, etc.
We'll remove this after transitioning 100% to the new matrix API, which handles this sort of thing automatically.
Part of T49450
We had two versions of several BLF functions -- one for a specific font ID & another for the default font.
New BLF_default function lets us simplify this API & delete the redundant code.
There are still many places to fix. I'll miss the bright yellow!
This commit also uses the new BLF_default function where possible.
Part of T49043 since we call glColor less often.
Minimum target is still 3.3
On AMD pro driver, asking for a 3.3 context gives us *exactly* 3.3, not 3.3+ as desired.
Have not tested proprietary NV or Intel drivers, but this fix should work on all vendors.
-Remove NPOT check as it should be supported by default with OGL 3.3
-All custom texture creation follow the same path now
-Now explicit texture format is required when creating a custom texture (Non RGBA8)
-Support for arrays of textures
Reviewers: dfelinto, merwin
Differential Revision: https://developer.blender.org/D2452
blenderplayer uses BLF but not Editor UI, so we got a link error for the missing UI_GetThemeColor function.
Moved the new function from BLF to UI.
@Blendify reported problem in IRC
For anything fancier than regular Theme colors (shading, alpha, etc.) do this:
unsigned char color[4]
UI_GetThemeColor[Fancy]4ubv(... color)
BLF_color4ubv(fontid, color)
That way the BLF color API stays simple.
This code was already disabled.
We might be able to simplify GPU_check_scaled_image even further. Maybe even delete it? Just removing the obvious stuff now.
Keeping is_power_of_2_resolution function since it is still used in DXT logic.
Note: when in edit mode this depsgraph update is not being called. We are using DerivedMesh in those cases, so it is fine. I would like to investigate this though
This includes a few fixes in the MBC_ api.
The idea here is for this to be the only interface the render engines
will deal with for the meshes.
If we need to expose special options for sculpting engine we refactor
this accordingly. But for now we are shaping this in a per-case base.
Note:
* We still need to hook up to the depsgraph to force clear/update of
batch_cache when mesh changes
(I'm waiting for Sergey Sharybin's depsgraph update for this though)
* Also ideally we could/should use BMesh directly instead of
DerivedMesh, but this will do for now.
Note 2:
In the end I renamed the `BKE_mesh_render` functions to `static
mesh_render`. We can re-expose them as BKE_* later once we need it.
Reviewers: merwin
Subscribers: fclem
Differential Revision: https://developer.blender.org/D2476
Took pieces from D2316 and D2359, changed a few more things.
- use new immediate mode
- use new matrix stack
- remove state push/pop
Part of T49043 and T49450
After revert the commit rB4b99958ca12642, the line added at the end of the enum is not necessary anymore because it is replaced by the corresponding element in the list in the right position.
This is part of T49043
fixed up some color/rect calls
fixed up ANIM_channel_draw()
Reviewers: krash, merwin
Reviewed By: merwin
Tags: #bf_blender_2.8
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2377
Had to add a few utility functions to replace existing functions. Let me know if these are duplicates.
Reviewers: merwin
Reviewed By: merwin
Tags: #bf_blender_2.8
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2434
This does not address stapling shader in 2.8, though the solution can be
similar (own shader, not polutting interlace shader).
part of T49043
Reviewers: merwin
Differential Revision: https://developer.blender.org/D2440
Please **DO NOT** add changes from master when it's totally uneeded!
Changes to BLI_ area most certainly shall *always* be done in master,
there is absolutely no point in adding more diff between the two
branches than needed, will only makes merging more cumbersome!
Conflicts:
CMakeLists.txt
source/blender/blenlib/intern/math_vector_inline.c
This reverts commit 5aa19be912 and b4a721af69.
Due to postponement of particle system rewrite it was decided to put particle code
back into the 2.8 branch for the time being.
Shuffle existing code, hook it up to the new (& old) viewport.
Also the 3D mouse rotation guide for NEW viewport only. Minor feature not worth enabling for legacy 3D view.
Basically all this does is drawing layout previews into the opened layout search menu.
https://youtu.be/RHYWtZP7pyA
The previews are drawn using offscreen rendering so they can't use multi-threading (yet!). But that shouldn't be an issue since only a handful of previews are drawn at the same time. Normally we only need to redraw the preview if a screen layout was changed. Would be nice if PreviewImage could store if it supports threaded rendering.
Previews are saved in files, might be useful if you later want to support appending layouts.
Adds a new file screen_draw.c.
This fixes multiple problems on latest Mac OS + Xcode. Hopefully does not cause any on other platforms.
The Xcode detection logic could use further cleanup. It's checking several old versions that are unsupported for Blender 2.8+ development.
Needed because deps graph can destroy objects from any thread. We ran into the same problem & solved it in GPU_buffers.
Implemented in C++11 since it provides the needed machinery. The interface is in C like the rest of Gawain.
This means editing a property will now always affect all selected objects, bones or sequencer strips. Support for this was added in rBdfbb876d4660 but you had to hold the Alt-key to use it. The old behavior of only editing the active object will not be kept like decided in the 2.8 workflow meeting (reports comming). If you only want to edit the active object, you have to deselect others.
There are still a couple of issues to be resolved (listed below), but having it enabled by default helps testing and getting used to it and should motivate us to fix them ;)
To be fixed:
* Give users hint when edits are applied to all objects/bones/strips ("Applying to x objects") - there are ideas but we need to finalize and implement them
* Make it work better in corner cases (material editing, modifier property editing, etc)
Note: Values usually override the initial value of the object/bones/strips, except of number buttons where it depends if you enter the value (absolute override) or drag the value (add value change). This behavior is consistent with multi-button editing.
Updated the GL calls to the new immediate mode.
I left some glcolor calls which I'm not sure wether thats right?
Part of T49043
warm regards,
Sebastian Witt
Reviewers: merwin
Reviewed By: merwin
Tags: #bf_blender_2.8
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2305
Just as mentioned in title. Need new functions for calls found in `transform.c`
T49043
Reviewers: merwin
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2358
This conversion is pretty straightforward.
The code for debug drawing is not great, but it does the job.
Rewriting it is for another day, if it becomes more widely used.
Convert UI_view2d_constant_grid_draw to new immediate mode.
Part of T49043.
Reviewers: merwin
Reviewed By: merwin
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2298
Convert ED_region_grid_draw to new immediate mode.
Part of T49043
Reviewers: merwin
Reviewed By: merwin
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2289
all is in the title too..
Reviewers: merwin
Reviewed By: merwin
Subscribers: Blendify, Severin
Tags: #bf_blender_2.8, #opengl_gfx
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2337
Consumes much less memory (1/3 for both normals = 32 bytes less per edge). Same visual result.
We can pack normals for other draw modes to get similar savings.
Part of T49165
Most useful for packed normals, which take 1/3 the space of float32 normals.
2-bit alpha|w component is ignored for now.
Batch API can use these now, will add support to immediate mode API if desired.
Enabling on Windows first. Will enable on all platforms after we switch Blender to core profile.
Drop SciTech support & workarounds for WinCE and OpenGL ES.
AMD_debug_output is still in the code but disabled. Once I verify the newer extensions are available on all the GPU + OS combos we support we can delete this disabled code.
Motivations:
1) GLenum is too broad; tightly-defined enum just for this is safer.
2) enable a Vulkan future
New code should use these instead of GL_FLOAT etc. When all existing code has been updated to use new enum, we can drop compatibility with GLenum values.
Early work towards 10_10_10 format, more to come soon.
Caused by 4811b2d356 which caused the event handler hack that is used to fire up the file browser from other operators to fail. Basically the context from before the file browser is opened gets stored and used later for executing the actual file read/write operation (in this case, saving image). This context storage is cleared when exiting an editor since 4811b2d356, which is technically correct, but causes usage of NULLed context data in this case, because the file browser is exited before the file read/write operation is executed.
For now I solved this by moving the fileselect handler to list of normal handlers, instead of modal ones. 4811b2d356 only touches list of modal handlers so we avoid the crash. Ideally we'd completely refactor how the file browser opening works to get rid of these event handler hacks.
Note that I wouldn't be suprised if this causes other regressions, but I couldn't find one so worth a try.
As our library of built-in shaders grows, it's important to create, access, and discard them efficiently.
Lookup via GPU_shader_get_builtin is now constant time instead of linear (# of built-in shaders). This is called very often with our new immediate mode.
Creation and discard are unified.
Adding a new shader requires fewer steps.
365 lines shorter :D
all is in the title.
Reviewers: merwin
Tags: #bf_blender_2.8, #opengl_gfx
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2336
This one is for the straight line (white with width 2.0 over a black with width 4.0) drawn when you use the gradient tool.
To test: Image editor, create / open an image, choose image paint mode and on the tool shelf: choose the Fill brush and enable "Use Gradient" for it. Then click and drag on the image.
From what I checked, calls to glLineWidth are not being removed yet, so I kept them.
Reviewers: dfelinto, Severin, merwin
Reviewed By: merwin
Tags: #bf_blender_2.8, #opengl_gfx
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2312
D2311 by @ianwill
This is the radial control that appears when we change the size of a brush in sculpt and vertex and texture painting modes, by pressing "f".
Also includes a new built-in shader that can be useful in other places.
Part of T49043
Gawain does very strict runtime checking to help us catch coding errors. Final release should disable most of these checks, so I'm disabling now for all non-debug builds.
When writing Blender code that uses Gawain, always make debug builds and test there! "make lite debug" is my favorite.
Right now this only affects other objects in wireframe. The idea is to do something similar for other draw modes, and keep focus on the edit object.
As seen at #bcon16
Most of this was already in place, just enabling & adding comments.
One fix was needed to make batch uniforms stick between multiple draws.
Added comments to selection outline; no functional changes there.
As seen at #bcon16
Geometry shader version is automatically used on modern GL runtimes. Legacy version is used on pre-3.2 systems (Mac, Mesa compat profile). They have the same inputs and visual result.
TODO: specialized versions that are less flexible -- draw ALL edges or draw JUST silhouette edges.
Part of T49165
(also, fix warning regarding const float being written)
You only see the color if you use the "modern" viewport option
(otherwise I believe Blender is drawing the old on top of the new outline).
That said, in the "modern" viewport we have unfreed mem. To be
investigated separately.
Totally WIP.
Started with copies of legacy routines, modified to use the new shaders & batch cache. Not all features are implemented; this is why we keep legacy viewport around during development!
Gawain batches are built on demand while drawing, then kept in this per-DerivedMesh cache.
A mesh's batches try to share vertex buffers as much as possible.
Not sure if this file is the best home for this code, but functions in this file are the only users of the cache. So maybe.
Big part of T49165
Surveying buffer usage & clears for new viewport. Not yet perfect, but closer. Committing from Mac so I can test this on Windows.
Using new matrix API (T49450) for gradient background.
Removed some of my earlier glActiveTexture calls. After reviewing the
code I now trust that GL_TEXTURE0 is active by default. Fewer GL calls,
same results.
Fixed some misuse of glActiveTexture & glUniformi, mostly my fault.
Caught by --debug-gpu on Windows. Don't know why this appeared to be
working previously!
Plus some easy cleanup nearby.
Works great on Mac now. Will test on Windows & Linux (Mesa) tomorrow. Related to T49505
Main fix is glActiveTexture and immUniform1i.
TEXTURE_2D vs TEXTURE_RECTANGLE is now a compile-time option. Both are available starting in GL 3.1 so there's no need for a run-time check.
Removed glClears that I don't think are necessary.
Prevent TEXTURE_2D from creating extra mipmap levels. We only need level 0.
Some minor cleanup: booleans and variable declarations.
At the moment this already shows that the depth is the same after the solid plates and in the very end of drawing, while they should be different. Later on we can adapt this to show different buffers we want to debug.
I am using near=0.1, far=2.0 for my tests. I decided not to make a doversion for near/far because this is for debugging only
The active camera has a solid "up" triangle instead of the usual outline. We want to see both sides of this triangle. Disable face culling only when drawing the active camera, not for every camera.
- any shader program can use matrix state (not only built-in shaders)
- you can mix matrix & begin/end calls, and the bound shader will use the latest matrix state
Part of T49450 & T49043
Mostly the same as before. Except:
- avoid drawing same lines multiple times
- helper functions take "bool filled" argument instead of GLenum
- drawcamera_volume draws its own near & far planes
widget_draw_text was calculating wrong display length when field is too narrow to show entire input string. Gawain assert caught this 11 function calls away!
Thanks to @ianwill for reporting.
Fixes an assert in drawing code.
Might need further work to support variable-thickness strokes (from pressure-sensitive stylus). This all is due for geometry shader overhaul anyway.
- rename image shaders to describe exactly what they do
- rename inputs to match other built-in shaders
- set & use active texture unit
- no need to enable/disable textures with GLSL
- pull vertex format setup out of loops
Turns out CTX_wm_region returns mostly NULL in wm_manipulatormaps_handled_modal_update. Now propertly unsetting area/region data of handlers when deleting area/region.
Non-power-of-two textures are always allowed. Keeping the disabled checks in the code in case we support OpenGL ES in the future. Even then it should be a compile-time check, not at run-time.
Own mistake in 9a9a663f40. Guessed there is a case where we have to rebuild the tree but everything seemed fine... It didn't work in display modes like "Data-Blocks".
Couple of issues here:
* Missing initialization for 3D view keyframe options for "Reset to Default Theme"
* Alpha values not reset correctly on "Reset to Default Theme"
* Alpha values of timeline keyframe options not reset correctly for old files
Also corrected old version patches even though they're overridden later, to avoid more issues in case people copy this code.
Corrections to d7af7a1e04 and 8d573aa0ec
* LMB now replaces selection instead of adding to it. Shift+LMB adds to selection (or removes if already selected). This is usual selection behavior Blender.
* Outliner selection isn't completely separate from object/sequencer-strip/render-layer/... selection anymore, when selecting an outliner item we now always try to select (and activate) the object it belongs to. Previously you had to click the name or icon of an item to select the object (or whatever) and on empty space within the row to set outliner selection.
* Collapsed items may show click-able icons for their children (nothing new). Clicking on such an icon will also select the hidden item it represents now, you'll notice after opening the parent. This valid from a technical POV, I'm not sure if this is wanted from user POV though. Changing would be easy, feedback welcome!
* Code cleanup.
Part of T37430.
GL 3.3 is the new minimum. Compatibility profile for now, core profile eventually. During development, GL 3.0 (on Mesa) and 2.1 (on Mac) will still work.
Part of T49012
Make color values compact. Set color once per primitive. Use new immSkipAttrib to avoid useless color copies.
All of this should make text drawing less CPU hungry.
Now you can explicitly skip a vertex attribute -- you don't give it a value and it won't get a copy of the previous vert's value. Useful for flat interpolated per-primitive values.
This is an advanced feature. Expect garbage in the empty spaces, and copies of garbage if you rely on the attrib copy behavior after skipping.
This was already fast on Apple, but @Severin and @dfelinto noticed slowdowns in user prefs, which is text heavy.
The problem was immBeginAtMost not being smart about VBO write flushing. immBeginAtMost can use all of its allocated range or only a subrange. The previous code was forcing back-to-back draw calls and buffer writes to serialize. This commit lets OpenGL know that our VBO writes never overlap, so there's no need to wait.
Should be much faster now!
1 or 2 draw calls per node instead of 1 per socket (inputs + outputs).
Rearranged draw order so we set uniforms less frequently.
Some style & dead code cleanup.
Part of T49043
Smooth round point with outline (uniform color) and fill (varying color).
Updated shader naming scheme: a shader that doesn't deal with color does not have to say "no color". Vertex shaders do not have to say "uniform color" since their frag counterpart actually has the uniform. Each name should describe what that shader *does*, not what it *doesn't do*.
I use your new point shader to draw the node's soket
Reviewers: Severin, merwin
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2286
Some little UI polish to get familiar with outliner code (but also because it's a useful feature). Committing to blender2.8 branch but can also port to master (2.7) if wanted.
This basically causes the mouse hovered element to be highlighted. Contrast of the highlight should be fine, even with a non-default theme. Also did some minor cleanup.
The problem was the function tried to draw a line with one point only. This fix will be replaced by new geometry shaders, but we need while this change is not ready.
Before this change, the stroke was filled only after complete the stroke drawing. For artist is better to get a feedback of the area he is filling while drawing, so this commit draws the filling area while drawing.
The triangulation of the stroke is recalculated every time the function is called because using a cache is not useful because the points information is changing all the time while the stroke is being drawing.
API stays exactly the same.
Attribute names can still be of variable length, as long as the average length does not exceed AVG_VERTEX_ATTRIB_NAME_LEN. Since this includes unused attributes (length = 0) the current avg of 5 might even be too high.
New functions activate & deactivate immediate mode. Call these when switching context and the internal VAO will be handled properly. VAOs are one of the few things *not* shared between OpenGL contexts.
Was multiplying matrices backward, so concatenation was broken. Fixed!
Also a way to mix legacy matrix stacks with the new library. Just during the transition! Anything within SUPPORT_LEGACY_MATRIX will go away after we switch to core profile.
Part of T49450
Reworked logic in the few places that still called this. Deleted the "GLSL not supported" fallbacks.
Also removed some nearby checks for ARB_multitexture and OpenGL 1.1. Blender 2.77 removed checks like this, but game engine still has some.
Built-in shaders now use uniforms instead of legacy built-in matrices. So far I only hooked this up for new immediate mode.
We use the same matrix naming convention as OpenGL, but without the gl_ prefix, e.g. gl_ModelView becomes ModelView.
Right now it can skip the new matrix stack and use the legacy built-in matrices app-side. This will help us transition gradually from glMatrix functions to gpuMatrix functions.
Still some work to do in gpuBindMatrices. See TODO comments in gpu_matrix.c for specifics.
@zeauro reported this issue:
texture2DRect needs the ARB_texture_rectangle extension.
But isn't that an OpenGL 2.1 feature and should be part of GLSL 1.2+?
This should fix it, and future shaders should do something similar.
Got rid of GLU and some matrix manipulation. Everything is shader driven now, drawn with point sprites.
Still plenty to do in this file...
Part of T49042 and T49043
Simple convert of drawing emboss lines to new immediate mode.
Part of T49043
Reviewers: merwin
Reviewed By: merwin
Subscribers: dfelinto
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D2271
Made function categories more clear & added more notes about how to use this API.
immEndVertex is no longer part of the public API.
Minor cleanup & organizing of recent additions.
I change UI_draw_roundbox_gl_mode to use immediate API.
The rest of the change is the call to the function.
I also make some change in UI_ThemeColor4(int colorid) for eg to make convenience to use.
I would really like to know if it's the good way to do, if yes I will make all the change in the node_daw.c after, else say me what's wrong and how to deal with color else.
Reviewers: merwin, dfelinto, Severin
Reviewed By: merwin
Subscribers: fablefox, Severin
Tags: #bf_blender_2.8, #opengl_gfx
Maniphest Tasks: T49043
Differential Revision: https://developer.blender.org/D2274
@dfelinto reported crash when setting grid subdivisions too low.
Code was setting color twice and Gawain was catching this. Fix is to only set regular grid color when we have regular grid lines to draw. Then emphasized grid lines are free to set their own color further down.
This commit lands the core backend of the Custom Manipulators project onto the blender2.8 branch. It is a generic backend for managinig interactive on-screen controls that can be integrated into any 2D or 3D edito. It's also already integrated into the window-manager and editor code where needed.
NOTE: The changes here should not be visible for users at all. It's really just a back-end patch. Neither does this include any RNA or Python integration.
Of course, there's still lots of work ahead for custom manipulators, but this is a big milestone. WIP code that actually uses this backend can be found in the 'custom-manipulators' branch (previously called 'wiggly-widgets').
The work here isn't completely my own, all the initial work was done by @Antony Riakiotakis (psy-fi) and - although it has changed a lot since them - it's still the same in essence. He definitely deserves a big credit! Some changes in this patch were also done by @Campbell Barton (campbellbarton). Thank you guys!
Merge accepted by @brecht and @merwin.
Patch: https://developer.blender.org/D2232
Code documentation: https://wiki.blender.org/index.php/Dev:2.8/Source/Custom_Manipulator
Main task: https://developer.blender.org/T47343
More info: https://code.blender.org/2015/09/the-custom-manipulator-project-widget-project/
Want to avoid updating code we no longer use anyway.
Comments for areas to investigate or deadlines for deletion.
also some minor bool cleanup
Part of T49165
We can't prevent users from using this branch, so I'd say it's reasonable to be a bit careful about what we store to files. In this concrete case we were storing a bit-flag for temporary use (only during early viewport transition) in a bit-field that's saved in files. Doing so would mean we either can't reuse this bit later or we risk breaking files (admittedly, likely in a pretty minor way). Moved the bit-flag to a new bit-field which can be removed later.
Makes it easier to enable it and avoids jumping of the panel when activating/deactivating it (because some panels disappear then). Also changed how panel title is drawn to make it behave like other panels.
We will keep the old system working as long as we can. At the moment even the visibility flags we are getting from the old system. That will continue like this until we have decided on the new UI
A new option (set in the properties region) allows the user to pick the
"new viewport" for the rendering (in the UI: Modern Viewport).
For now we have a semi-blank file (view3d_draw.c) that can starts to take
over the drawing pipeline.
I can't guarantee we will be able to keep both drawing systems working
through the entire 2.8 development, but it should do for now.
also, we can use branches for some of the viewport development, but it's
better to keep things in 2.8 whenever we can, so people can test it.
Transition away from GLU and legacy matrix stack. Using point sprites eliminated the need for most of the matrix math!
Depends on decent support of large aliased points. NVIDIA is good at this, must test limits on AMD & Intel systems.
Still needs proper scaling based on view zoom.
Part of T49042, touches on T49043 and T49450.
Apparently GL_POINT_SPRITE is important to GL 3.2+ compatibility profile, not just to GL 2.1 as thought.
We'll remove this during the core profile transition.
At context startup, make sure our assumptions about the OpenGL version are true. Should match since we set up the contexts... but this is what asserts are for, to check "should"s!
Part of T49012
patch P397 by @lichtwert + minor const by @merwin
Notes from drawvertsN function:
this used to be called twice (once for selected/active, once for unselected -- guess: to avoid state switches[color]?)
this used to be called in a loop, too (subcurves), moved the loop here to avoid multiple init stuff
Part of T49043
WARNING! Full build is broken, alembic has not been merged in correctly and has some references to particle stuff.
Don't have time to tackle this now (and probably would be better if someone knowing what he's doing does it anyway).
Conflicts:
release/scripts/startup/bl_ui/properties_particle.py
source/blender/blenkernel/intern/library_remap.c
source/blender/blenkernel/intern/smoke.c
source/blender/editors/physics/particle_object.c
source/blender/editors/physics/physics_intern.h
source/blender/editors/physics/physics_ops.c
source/blender/editors/space_outliner/outliner_intern.h
source/blender/editors/space_view3d/drawvolume.c
source/blender/makesrna/intern/rna_smoke.c
Complete (for our needs) 2D & 3D transformation API. Should be easy to port legacy OpenGL matrix stack-based code to this. Still needs testing.
Ported ortho, frustum, lookAt functions from Viewport FX (rB194998766c65). Kept plenty of Viewport FX code from previous commit.
Stack API and 2D routines ported from Gawain. This version uses BLI_math library so everything is licensed under GPL instead of the usual MPL.
Part of T49450
mul_m4_m4m4(R, A, B) gives us R = AB in general. Existing code assumed the worst, that A and B both alias the output R. For safety it makes internal copies of A and B before calculating & writing R.
This is the least common case. Usually all 3 matrices differ. Often we see M = AM or M = MB, but never M = MM.
With this revision mul_m4_m4m4 is called in exactly the same way but copies inputs only when needed. If you know the inputs are independent of the output use the "uniq" variant to skip the saftety checks.
Is actually a redundant cast since Blender uses -funsigned-char, however I think it's fine to be explicit about it in new code so cast is required to make compiler happy. Am not a fan of -funsigned-char anyway...
Changed drawing to use smooth lines, and to fade away when axis points toward / away from screen. (transform manipulators do this already)
Also fixed a nearby (but unrelated) missing immUnbindProgram.
Part of T49043
Ignore texture matrix in the shader, stop messing with texture matrix in BLF code.
Use linear screen-space interpolation instead of perspective.
Avoid redundant call to glMatrixMode.
With USE_GLSL enabled, GPU_basic_shader(TEXTURE|COLOR) always rendered black. New shader uses a solid color + alpha channel of texture (which in our case is a font glyph). See fragment shader for details.
I prefer this approah -- multiple shaders that each do one thing well (and are easy to read/write/understand), instead of one shader that can do many things given the right options.
Fixed compile error in debug build (thanks mont29)
Renamed some functions for consistency.
New features:
Create a Batch with immediate mode! Just use immBeginBatch instead of immBegin. You can keep the result and draw it as many times as you like. This partially replaces the need for display lists.
Copy a VertexFormat, and create a VertexBuffer using an existing format.
Resize a VertexBuffer to a different number of vertices. (can only resize BEFORE using it to draw)
Was already done for immediate mode, but rearranged code to make a clean separation. Cleaned up #includes for code that uses this feature.
Added same for batched rendering.
Follow-up to rBddb1d5648dbd
API is nearly complete but untested.
1) create batch with vertex buffer & optional index buffer
2) choose shader program
3) draw!
This function modifies the GL program object, which reduces our ability to share a shader among meshes with different vertex formats. Recommended approach is to use get_attrib_locations.
Vertex Buffer to store vertex attribute data.
Element List (AKA Index Buffer) to select which vertices to use.
Batch combines these into an object that can be built once then drawn
many times.
Porting over from the C++ version… Most of this C code is compiled but
unused. Some of it is not even compiled. Committing now in case I’m
lost at sea.
Put Gawain source code in a subfolder to make the boundary between the
library and the rest of Blender clear.
Changed Gawain’s license from Apache to Mozilla Public License. Has
more essence of copyleft — closer to GPL but not as restrictive.
Split immediate.c into several files so parts can be reused (adding
more files soon…)
immBegin requires us to know how many vertices will be drawn. Most times this is fine, but sometimes it can be tricky. Do we make the effort to count everything in one pass, then draw it in a second?
immBeginAtMost makes this simple. Example: I'll draw at most 100 vertices. Supply only 6 verts and it draws only 6.
Any unused space is reclaimed and given to the next immBegin.
Was using GL_NONE to mean "no primitive" but GL_NONE and GL_POINTS are both defined as 0x0000.
Introducing PRIM_NONE = 0xF which does not clash with any primitive types.
Application code can pass ubytes, Gawain converts to float vec4 expected by shader.
For now the conversion is simple linear. We can add sRGB support later if needed.
Significant rewrite with some improvements.
Maintain visual hierarchy of the grid:
- emphasized lines draw atop normal lines
- axes draw atop all lines (same as before)
Draw axes only once, not twice.
Return early if nothing to draw.
Single draw call for the default case (grid floor with X and Y axes).
Z axis needs a second draw call because it uses 3D coordinates.
Part of T49043
Also reduced number of matrix ops by generating final positions directly.
Also removed a display list (deprecated in modern GL).
Tried to reuse sinval & cosval tables but those values are skewed (last value repeats first value, middle values are squished to compensate). Went with sinf & cosf instead.
Part of T49042
The little grabby handle in the corner of an area. Now uses 1 draw call
instead of 6.
Also one version of the (+) icon to show a hidden region. Why do we
have multiple versions of this?
Fixed a harmless signed/unsigned error.
Fixed a GL state error that prematurely disabled blending.
Added imm_draw_filled_circle function, which can be used for drawing
other widgets.
Work toward T49042 and T49043
In addition to pack of conflicts listed below, also had to comment out particle part of new Alembic code... :/
Conflicts:
intern/ghost/intern/GHOST_WindowWin32.cpp
source/blender/blenkernel/BKE_effect.h
source/blender/blenkernel/BKE_pointcache.h
source/blender/blenkernel/intern/cloth.c
source/blender/blenkernel/intern/depsgraph.c
source/blender/blenkernel/intern/dynamicpaint.c
source/blender/blenkernel/intern/effect.c
source/blender/blenkernel/intern/particle_system.c
source/blender/blenkernel/intern/pointcache.c
source/blender/blenkernel/intern/rigidbody.c
source/blender/blenkernel/intern/smoke.c
source/blender/blenkernel/intern/softbody.c
source/blender/depsgraph/intern/builder/deg_builder_relations.cc
source/blender/gpu/intern/gpu_debug.c
source/blender/makesdna/DNA_object_types.h
source/blender/makesrna/intern/rna_particle.c
Scanned Blender code for commonly used glVertex, glColor functions.
Implemented immVertex, immAttrib versions of these to ease transition
away from legacy OpenGL.
Keeping unused gla2D code because it might be useful, or inspire
something useful, for Blender 2.8 development.
Also removed an old Mac driver bug workaround. Disabled this before the
2.77 release and nobody has complained.
Errors are caught & reported by our GL debug callback. This gives us way more useful information than sporadic calls to glGetError.
I removed almost all use of glGetError, including our own GPU_ASSERT_NO_GL_ERRORS and GPU_CHECK_ERRORS_AROUND macros.
Still used in rna_Image_gl_load because it passes unvalidated input to OpenGL functions.
Still used in gpu_state_print_fl_ex as an exception handling hack -- will rewrite this soon.
The optimism embodied by this commit will not prevent OpenGL errors. We need to analyze what would cause GL to fail at certain points and proactively intercept these failures. Or guarantee they can't happen.
Legacy OpenGL has a matching Vertex3fv for every Vertex3f, and so on. Add something similar to Gawain, just for a few common functions. Might add more as the need arises.
These are intended for very simple drawing. No lighting etc.
Shares some fragment code with the 2D shaders.
Similar to their 2D counterparts, but are not combined because of
future plans for separate 2D & 3D matrix stacks.
EXT_gpu_shader4 lets us say “noperspective” in GLSL #version 120 just
like in later GLSL.
Mac shader now matches modern GLSL available on other platforms.
When we ask for GL 3.2 compatibility profile:
AMD (Radeon HD 6970) gives us exactly this version
NVIDIA (Quadro K600) gives at least this version
Still need to check Intel behavior
We want *at least* the version requested, plus more recent features if
available.
Both GPUs tested & mentioned above are capable of GL 4.5. With this
commit they both give 4.5 to Blender.
Helps most when real-world units are used.
Previous code started at the smallest visible unit (e.g. Inches) then
followed to Feet, Yards, Chains, Furlongs, Miles. Always to the largest
unit of the set, even though most would be way off screen.
New code knows whether it skipped any grid lines for the next unit to
fill in, can stop once all lines are on screen.
Previous commit works on Windows, found some issues after trying on Mac.
- benign warnings about && within ||
- replaced nearbyint() with round() to avoid floating point environment
surprises
- remquo function appears to be broken on Mac (!) results were way way
off. Replaced with simple division.
- minor tweaks to debug output
Work toward T49043, with a side of client vertex arrays.
Not a straightforward port from glVertex to immVertex since Gawain needs
to know how many vertices we'll be drawing *before* we start drawing.
Fixed these not-so-great aspects of grid drawing:
- coarse grids would draw atop some lines from the finer grids
- visible axes would draw atop lines from coarse grid
- axes were drawn even if they weren't in view
- terrible misuse of vertex arrays
- each line issued its own draw call
New code draws each line exactly once. The entire grid is one draw call.
Bonus: I had to / got to learn how the units system works!
New value of 4MB should handle our needs without taking up too many GPU
resources.
Old value of 1KB was for observing what happens when the buffer fills up
and we need to flush and start a new one.
Getting this ready for Gawain treatment.
Removed setlinestyle(0) -- solid lines are the default, hope this isn't
really needed.
Eliminated redundant math.
Arithmetic is still double precision, passed to OpenGL as single
precision. Even though it said GL_DOUBLE before, values were converted
to GL_FLOAT internally.
Use C99-isms for declaring variables close to where they're used.
Minor whitespace tweaks.
This serves as a good example of the Gawain API. (I’ve thought of a
better way to draw drop shadows, but that can wait!)
Part of T49043.
This is what I had in mind for D1753.
If you don’t specify a vertex’s color, it will use the color of the
previous vertex. Similar for all other attributes.
This matches the legacy behavior of glColor, glNormal, etc. *except* in
Gawain the first vertex of each immBegin must be fully specified. There
is no “current” color in the new system.
Should be simpler to use now.
Made vertex format structure private. New immVertexFormat() function
clears and returns the format. Devs can start with add_attrib(format...)
and not have to clear it first.
immBindProgram automatically packs the vertex format if needed.
Updated 3D cursor drawing to use new API.
glBindAttribLocation does not take effect until the program is
re-linked. In other words I was doing it wrong!
New code gets attrib locations from program, then remembers the attrib
-> location mapping for subsequent draw calls.
The program and VertexFormat are not modified (makes threading and reuse
easier).
There are older ways to give OpenGL hints about buffer invalidation, but
glInvalidateBufferData does exactly what we want. Use this function when
OpenGL 4.3 is available (Windows and proprietary Linux drivers).
Part of Gawain immediate mode.
When running blender --debug-gpu
Display which debug facilities are available. One of these, in order of preference:
- OpenGL 4.3
- KHR_debug
- ARB_debug_output
- AMD_debug_output
All messages are logged now, not just errors. Will probably turn some of these off later.
GL_DEBUG_OUTPUT_SYNCHRONOUS lets us break on errors and backtrace to the exact trouble spot.
Callers of GPU_string_marker no longer pass in a message length, just the message itself (null terminated).
Apple provides no GL debug logging features.
Old code had a mix of framebuffer error codes from OpenGL ES, EXT_framebuffer_object, and desktop GL. We use desktop GL (or ARB_framebuffer_object which acts just like GL 3.x) so I made it compatible with that.
Changed messages to the actual GL_FRAMEBUFFER_XXX symbols. These are less friendly and more accurate. Can easily look up what an error means, unfiltered by what a Blender dev thinks it means.
Kept ES error codes around in case we support that one day. Just flip the #if or use a compile-time option.
Replace legacy OpenGL with Gawain. Use shaders instead of fixed
function pipeline.
This simple UI element is shown at startup so is easy to verify things
are working. It also serves as a good example for people converting
other parts of the code.
Part of T49043
Use simple alternating colored lines instead of stippled overdraw.
Reimplement circ function to not use deprecated GLU (T49042). It also
leaves matrix stack untouched.
Remove unused circf function.
immBindBuiltinProgram extends Gawain’s immBindProgram to use Blender’s
library of built-in shader programs.
It uses imm prefix instead of GPU_ so people won’t be tempted to call
GPU_unbind_program() afterward.
From my understanding, Apache code is not allowed to call GPL code, so
this function needs to be in the GPU lib.
How to use:
1) set up vertex format
2) bind a shader
3) draw with immBegin … immEnd
4) unbind shader
TODO: expand this a little, so we can send uniform values to the bound
shader.
glMapBufferRange is a wonderful function that doesn’t exist on GL < 3.0.
Use the APPLE_flush_buffer_range extension on Mac. It offers several of
glMapBufferRange’s benefits.
Use older “black arts” method to orphan VBOs when we are done with
them. In modern OpenGL this behavior is more obvious.
Add APPLE_flush_buffer_range to Mac requirements. Every GPU is
supported. T49012
Apple invented VAOs and exposes them via an extension in legacy GL.
Other platforms use at least GL 3.0 which has VAOs built in.
QUADS were removed from core profile but are useful for immediate-mode
drawing. We’ll have to implement our own QUAD drawing before switching
to core profile.
Immediate mode no longer leaves its internals bound after use. Part of
transition from a simple prototype app to non-simple Blender, which has
lots of other parts using OpenGL.
More ways to send values via immAttrib:
2D float vectors
3 & 4 component ubytes (for colors mostly)
New immVertex functions that act more like familiar glVertex. We’ll
find a balance between making this API convenient and keeping it small.
2f and 3f are enough for now.
ARB_framebuffer_object replaces several related EXT extensions. The ARB
version pulls GL 3 FBO features into GL 2.1, useful for Mac platform.
Its functions and enums have no ARB suffix so transition to modern GL
will be seamless!
Extension is checked at startup, so is guaranteed to be true at runtime.
Part of T49012
Mac’s OpenGL version is furthest away from our target of GL 3.2. This
commit brings Mac closer to other platforms, so that our shaders and
other code don’t diverge too much during development.
According to Apple’s OpenGL matrix these useful extensions are
available on all GPUs that will be able to run Blender 2.8.
Only checked in debug builds; we might need something more forceful.
Part of T49012
The first two of several new simple built-in shaders (will test these
before adding more). These are intended for the new immediate mode API,
but you can use them just like any built-in GPUShader.
Due to limitations on different platforms, shaders need to work with
GLSL versions 120, 130 and 150. Final Blender 2.8 will be pure #version
150.
Introducing an immediate mode drawing API that works with modern GL 3.2
core profile. I wrote and tested this using a core context on Mac.
This is part of the Gawain library which is Apache 2 licensed. Be very
careful not to pull other Blender code into these files.
Modifications for the Blender integration:
- prefix filenames to match rest of Blender’s GPU libs
- include GPU_glew.h instead of <OpenGL/gl3.h>
- disable thread-local vars until we figure out how best to do this
This implements Mac part of T49012.
Removed options for EGL, ES2, compatibility profile. None of these
exist on Mac platform.
Create a GL 3.2 core context when requested at build time. Old code
just pretended to support core profile.
Implements the Linux part of T49012.
Simplify the options for context creation. No options for legacy GL or EGL or ES2. Select 3.2 CORE or COMPATIBILITY profile at build time.
If that fails, use a GL 3.0 context. This keeps Mesa supported while we work on full 3.2 core elsewhere in the code.
This greatly simplifies the options for context creation. No options for
legacy GL or EGL or ES2. Select CORE or COMPATIBILITY profile at build
time.
OpenGL 3.2 core profile will be our final target on all platforms. Until
all our code is ready we can use 3.2 compatibility profile or "legacy"
GL 2.1 on platforms that don't support compatibility profile.
At the moment light shading in Blender is produced in viewspace. Apparently, that's why
shader nodes work with normals in camera space. But it is not convenient for artists.
The more convenient approach is implemented in Cycles where normals are represented in world space.
Blend4Web Team designed the engine keeping in mind shader parameters readability,
so normals are interpreted in world space as well. And now our users have to use some tweaks, like
empty node group with the name "Replace", which is replacing one input by another on the engine side
(replacing working configuration in Blender Viewport by the configuration that has the same behavior in the engine).
This patch adds the ability to switch to world space for normals and lamp vector in BI and Viewport.
This patch is very important to us and we crave to see this patch in Blender 2.7 because
it will significantly simplify Blend4Web material creation workflow.
{F315547}
{F315548}
Reviewers: campbellbarton, brecht
Reviewed By: brecht
Subscribers: homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D2046
The purpose of the patch is to replace deprecated glShadeModel.
To decrease glShadeModel calls I've set GL_SMOOTH by default
Reviewers: merwin, brecht
Reviewed By: brecht
Subscribers: blueprintrandom, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D1958
Note that this only removes the actual dependencies of Cycles on the
particle code in Blender, but not the internal "particle" definition
or the curve type handling inside Cycles. These structures may be in need
of some improvement themselves, but that is out of scope here.
There are a lot of cases here where deciding for removal is a bit tricky.
Many features have options for "use_particles" and similar settings. Only
features which actually store a particle object reference or work on actual
particle data have been removed.
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.")
Proxy to armature pose channel. Allows to read and set armature pose.
The attributes are identical to RNA attributes, but mostly in read-only mode.
..attribute:: name
channel name (=bone name), read-only.
:type:string
..attribute:: bone
return the bone object corresponding to this pose channel, read-only.
:type::class:`BL_ArmatureBone`
..attribute:: parent
return the parent channel object, None if root channel, read-only.
:type::class:`BL_ArmatureChannel`
..attribute:: has_ik
true if the bone is part of an active IK chain, read-only.
This flag is not set when an IK constraint is defined but not enabled (miss target information for example).
:type:boolean
..attribute:: ik_dof_x
true if the bone is free to rotation in the X axis, read-only.
:type:boolean
..attribute:: ik_dof_y
true if the bone is free to rotation in the Y axis, read-only.
:type:boolean
..attribute:: ik_dof_z
true if the bone is free to rotation in the Z axis, read-only.
:type:boolean
..attribute:: ik_limit_x
true if a limit is imposed on X rotation, read-only.
:type:boolean
..attribute:: ik_limit_y
true if a limit is imposed on Y rotation, read-only.
:type:boolean
..attribute:: ik_limit_z
true if a limit is imposed on Z rotation, read-only.
:type:boolean
..attribute:: ik_rot_control
true if channel rotation should applied as IK constraint, read-only.
:type:boolean
..attribute:: ik_lin_control
true if channel size should applied as IK constraint, read-only.
:type:boolean
..attribute:: location
displacement of the bone head in armature local space, read-write.
:type:vector [X, Y, Z].
..note::
You can only move a bone if it is unconnected to its parent. An action playing on the armature may change the value. An IK chain does not update this value, see joint_rotation.
..note::
Changing this field has no immediate effect, the pose is updated when the armature is updated during the graphic render (see :data:`BL_ArmatureObject.update`).
..attribute:: scale
scale of the bone relative to its parent, read-write.
:type:vector [sizeX, sizeY, sizeZ].
..note::
An action playing on the armature may change the value. An IK chain does not update this value, see joint_rotation.
..note::
Changing this field has no immediate effect, the pose is updated when the armature is updated during the graphic render (see :data:`BL_ArmatureObject.update`)
..attribute:: rotation_quaternion
rotation of the bone relative to its parent expressed as a quaternion, read-write.
:type:vector [qr, qi, qj, qk].
..note::
This field is only used if rotation_mode is 0. An action playing on the armature may change the value. An IK chain does not update this value, see joint_rotation.
..note::
Changing this field has no immediate effect, the pose is updated when the armature is updated during the graphic render (see :data:`BL_ArmatureObject.update`)
..attribute:: rotation_euler
rotation of the bone relative to its parent expressed as a set of euler angles, read-write.
:type:vector [X, Y, Z].
..note::
This field is only used if rotation_mode is > 0. You must always pass the angles in [X, Y, Z] order; the order of applying the angles to the bone depends on rotation_mode. An action playing on the armature may change this field. An IK chain does not update this value, see joint_rotation.
..note::
Changing this field has no immediate effect, the pose is updated when the armature is updated during the graphic render (see :data:`BL_ArmatureObject.update`)
..attribute:: rotation_mode
Method of updating the bone rotation, read-write.
:type:integer (one of :ref:`these constants <armaturechannel-constants-rotation-mode>`)
..attribute:: channel_matrix
pose matrix in bone space (deformation of the bone due to action, constraint, etc), Read-only.
This field is updated after the graphic render, it represents the current pose.
:type:matrix [4][4]
..attribute:: pose_matrix
pose matrix in armature space, read-only,
This field is updated after the graphic render, it represents the current pose.
:type:matrix [4][4]
..attribute:: pose_head
position of bone head in armature space, read-only.
:type:vector [x, y, z]
..attribute:: pose_tail
position of bone tail in armature space, read-only.
:type:vector [x, y, z]
..attribute:: ik_min_x
minimum value of X rotation in degree (<= 0) when X rotation is limited (see ik_limit_x), read-only.
:type:float
..attribute:: ik_max_x
maximum value of X rotation in degree (>= 0) when X rotation is limited (see ik_limit_x), read-only.
:type:float
..attribute:: ik_min_y
minimum value of Y rotation in degree (<= 0) when Y rotation is limited (see ik_limit_y), read-only.
:type:float
..attribute:: ik_max_y
maximum value of Y rotation in degree (>= 0) when Y rotation is limited (see ik_limit_y), read-only.
:type:float
..attribute:: ik_min_z
minimum value of Z rotation in degree (<= 0) when Z rotation is limited (see ik_limit_z), read-only.
:type:float
..attribute:: ik_max_z
maximum value of Z rotation in degree (>= 0) when Z rotation is limited (see ik_limit_z), read-only.
:type:float
..attribute:: ik_stiffness_x
bone rotation stiffness in X axis, read-only.
:type:float between 0 and 1
..attribute:: ik_stiffness_y
bone rotation stiffness in Y axis, read-only.
:type:float between 0 and 1
..attribute:: ik_stiffness_z
bone rotation stiffness in Z axis, read-only.
:type:float between 0 and 1
..attribute:: ik_stretch
ratio of scale change that is allowed, 0=bone can't change size, read-only.
:type:float
..attribute:: ik_rot_weight
weight of rotation constraint when ik_rot_control is set, read-write.
:type:float between 0 and 1
..attribute:: ik_lin_weight
weight of size constraint when ik_lin_control is set, read-write.
:type:float between 0 and 1
..attribute:: joint_rotation
Control bone rotation in term of joint angle (for robotic applications), read-write.
When writing to this attribute, you pass a [x, y, z] vector and an appropriate set of euler angles or quaternion is calculated according to the rotation_mode.
When you read this attribute, the current pose matrix is converted into a [x, y, z] vector representing the joint angles.
The value and the meaning of the x, y, z depends on the ik_dof_x/ik_dof_y/ik_dof_z attributes:
* 1DoF joint X, Y or Z: the corresponding x, y, or z value is used an a joint angle in radiant
* 2DoF joint X+Y or Z+Y: treated as 2 successive 1DoF joints: first X or Z, then Y. The x or z value is used as a joint angle in radiant along the X or Z axis, followed by a rotation along the new Y axis of y radiants.
* 2DoF joint X+Z: treated as a 2DoF joint with rotation axis on the X/Z plane. The x and z values are used as the coordinates of the rotation vector in the X/Z plane.
* 3DoF joint X+Y+Z: treated as a revolute joint. The [x, y, z] vector represents the equivalent rotation vector to bring the joint from the rest pose to the new pose.
:type:vector [x, y, z]
..note::
The bone must be part of an IK chain if you want to set the ik_dof_x/ik_dof_y/ik_dof_z attributes via the UI, but this will interfere with this attribute since the IK solver will overwrite the pose. You can stay in control of the armature if you create an IK constraint but do not finalize it (e.g. don't set a target) the IK solver will not run but the IK panel will show up on the UI for each bone in the chain.
..note::
[0, 0, 0] always corresponds to the rest pose.
..note::
You must request the armature pose to update and wait for the next graphic frame to see the effect of setting this attribute (see :data:`BL_ArmatureObject.update`).
..note::
You can read the result of the calculation in rotation or euler_rotation attributes after setting this attribute.
This is a list like object used in the game engine internally that behaves similar to a python list in most ways.
As well as the normal index lookup (``val= clist[i]``), CListValue supports string lookups (``val= scene.objects["Cube"]``)
Other operations such as ``len(clist)``, ``list(clist)``, ``clist[0:10]`` are also supported.
..method:: append(val)
Add an item to the list (like pythons append)
..warning::
Appending values to the list can cause crashes when the list is used internally by the game engine.
..method:: count(val)
Count the number of instances of a value in the list.
:return:number of instances
:rtype:integer
..method:: index(val)
Return the index of a value in the list.
:return:The index of the value in the list.
:rtype:integer
..method:: reverse()
Reverse the order of the list.
..method:: get(key, default=None)
Return the value matching key, or the default value if its not found.
:return:The key value or a default.
..method:: from_id(id)
This is a funtion especially for the game engine to return a value with a spesific id.
Since object names are not always unique, the id of an object can be used to get an object from the CValueList.
Example:
..code-block::python
myObID=id(gameObject)
ob=scene.objects.from_id(myObID)
Where ``myObID`` is an int or long from the id function.
This has the advantage that you can store the id in places you could not store a gameObject.
..warning::
The id is derived from a memory location and will be different each time the game engine starts.
..warning::
The id can't be stored as an integer in game object properties, as those only have a limited range that the id may not be contained in. Instead an id can be stored as a string game property and converted back to an integer for use in from_id lookups.
The type of measurement that the sensor make when it is active.
Can be one of :ref:`these constants <armaturesensor-type>`
:type:integer.
..attribute:: constraint
The constraint object this sensor is watching.
:type::class:`BL_ArmatureConstraint`
..attribute:: value
The threshold used in the comparison with the constraint error
The linear error is only updated on CopyPose/Distance IK constraint with iTaSC solver
The rotation error is only updated on CopyPose+rotation IK constraint with iTaSC solver
The linear error on CopyPose is always >= 0: it is the norm of the distance between the target and the bone
The rotation error on CopyPose is always >= 0: it is the norm of the equivalent rotation vector between the bone and the target orientations
The linear error on Distance can be positive if the distance between the bone and the target is greater than the desired distance, and negative if the distance is smaller.
See :data:`sphereInsideFrustum` and :data:`boxInsideFrustum`
..data:: INTERSECT
See :data:`sphereInsideFrustum` and :data:`boxInsideFrustum`
..data:: OUTSIDE
See :data:`sphereInsideFrustum` and :data:`boxInsideFrustum`
..attribute:: lens
The camera's lens value.
:type:float
..attribute:: fov
The camera's field of view value.
:type:float
..attribute:: ortho_scale
The camera's view scale when in orthographic mode.
:type:float
..attribute:: near
The camera's near clip distance.
:type:float
..attribute:: far
The camera's far clip distance.
:type:float
..attribute:: shift_x
The camera's horizontal shift.
:type:float
..attribute:: shift_y
The camera's vertical shift.
:type:float
..attribute:: perspective
True if this camera has a perspective transform, False for an orthographic projection.
:type:boolean
..attribute:: frustum_culling
True if this camera is frustum culling.
:type:boolean
..attribute:: projection_matrix
This camera's 4x4 projection matrix.
..note::
This is the identity matrix prior to rendering the first frame (any Python done on frame 1).
:type:4x4 Matrix [[float]]
..attribute:: modelview_matrix
This camera's 4x4 model view matrix. (read-only).
:type:4x4 Matrix [[float]]
..note::
This matrix is regenerated every frame from the camera's position and orientation. Also, this is the identity matrix prior to rendering the first frame (any Python done on frame 1).
..attribute:: camera_to_world
This camera's camera to world transform. (read-only).
:type:4x4 Matrix [[float]]
..note::
This matrix is regenerated every frame from the camera's position and orientation.
..attribute:: world_to_camera
This camera's world to camera transform. (read-only).
:type:4x4 Matrix [[float]]
..note::
Regenerated every frame from the camera's position and orientation.
..note::
This is camera_to_world inverted.
..attribute:: useViewport
True when the camera is used as a viewport, set True to enable a viewport for this camera.
:type:boolean
..method:: sphereInsideFrustum(centre, radius)
Tests the given sphere against the view frustum.
:arg centre:The centre of the sphere (in world coordinates.)
:type centre:list [x, y, z]
:arg radius:the radius of the sphere
:type radius:float
:return::data:`~bge.types.KX_Camera.INSIDE`, :data:`~bge.types.KX_Camera.OUTSIDE` or :data:`~bge.types.KX_Camera.INTERSECT`
:rtype:integer
..note::
When the camera is first initialized the result will be invalid because the projection matrix has not been set.
..code-block::python
frombgeimportlogic
cont=logic.getCurrentController()
cam=cont.owner
# A sphere of radius 4.0 located at [x, y, z] = [1.0, 1.0, 1.0]
Whether or not the character is on the ground. (read-only)
:type:boolean
..attribute:: gravity
The gravity value used for the character.
:type:float
..attribute:: maxJumps
The maximum number of jumps a character can perform before having to touch the ground. By default this is set to 1. 2 allows for a double jump, etc.
:type:int in [0, 255], default 1
..attribute:: jumpCount
The current jump count. This can be used to have different logic for a single jump versus a double jump. For example, a different animation for the second jump.
:type:int
..attribute:: walkDirection
The speed and direction the character is traveling in using world coordinates. This should be used instead of applyMovement() to properly move the character.
Servo control allows to regulate force to achieve a certain speed target.
..attribute:: force
The force applied by the actuator.
:type:Vector((x, y, z))
..attribute:: useLocalForce
A flag specifying if the force is local.
:type:boolean
..attribute:: torque
The torque applied by the actuator.
:type:Vector((x, y, z))
..attribute:: useLocalTorque
A flag specifying if the torque is local.
:type:boolean
..attribute:: dLoc
The displacement vector applied by the actuator.
:type:Vector((x, y, z))
..attribute:: useLocalDLoc
A flag specifying if the dLoc is local.
:type:boolean
..attribute:: dRot
The angular displacement vector applied by the actuator
:type:Vector((x, y, z))
..note::
Since the displacement is applied every frame, you must adjust the displacement based on the frame rate, or you game experience will depend on the player's computer speed.
..attribute:: useLocalDRot
A flag specifying if the dRot is local.
:type:boolean
..attribute:: linV
The linear velocity applied by the actuator.
:type:Vector((x, y, z))
..attribute:: useLocalLinV
A flag specifying if the linear velocity is local.
:type:boolean
..note::
This is the target speed for servo controllers.
..attribute:: angV
The angular velocity applied by the actuator.
:type:Vector((x, y, z))
..attribute:: useLocalAngV
A flag specifying if the angular velocity is local.
:type:boolean
..attribute:: damping
The damping parameter of the servo controller.
:type:short
..attribute:: forceLimitX
The min/max force limit along the X axis and activates or deactivates the limits in the servo controller.
:type:list [min(float), max(float), bool]
..attribute:: forceLimitY
The min/max force limit along the Y axis and activates or deactivates the limits in the servo controller.
:type:list [min(float), max(float), bool]
..attribute:: forceLimitZ
The min/max force limit along the Z axis and activates or deactivates the limits in the servo controller.
:type:list [min(float), max(float), bool]
..attribute:: pid
The PID coefficients of the servo controller.
:type:list of floats [proportional, integral, derivate]
..attribute:: reference
The object that is used as reference to compute the velocity for the servo controller.
:class:`MeshProxy` or the name of the mesh that will replace the current one.
Set to None to disable actuator.
:type::class:`MeshProxy` or None if no mesh is set
..attribute:: useDisplayMesh
when true the displayed mesh is replaced.
:type:boolean
..attribute:: usePhysicsMesh
when true the physics mesh is replaced.
:type:boolean
..method:: instantReplaceMesh()
Immediately replace mesh without delay.
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.
