Extends Ghost to include an abstraction for OpenXR, which I refer to as
Ghost-XR. Such an API is the base for the following commit, which introduces VR
support to Blender.
Main features:
* Simple and high-level interface for Blender specific code to call.
* Extensible for muliple graphics backends, currently OpenGL and a DirectX
compatibility layer are supported.
* Carefully designed error handling strategy allowing Blender to handle errors
gracefully and with useful error messages.
* OpenXR extension and API-layer management.
* OpenXR session management.
* Basic OpenXR event management.
* Debug utilities for Ghost-XR and OpenXR
For more information on this API, check
https://wiki.blender.org/wiki/Source/Interface/XR.
Reviewed by: Brecht Van Lommel
Differential Revision: https://developer.blender.org/D6188
The initial code from earlier from today didn't really work reliable
since it is not possible to apply virtual modifiers but not the real
multires one (in a situation like mesh with shapekeys and multires).
New code uses less memory and has better performance for the case
when there are actual modifiers leading the multires. The case when
there is only multires will not be as performant as possible at this
moment.
The parenting was using the old logic, but with new engine the draw is done using eval data.
Fixed the depsgraph relationship missing with bones to get an update when the bone is transformed.
Also fixed Snap cursor to Selected
BKE_ocean.h uses the bool type without including stdbool.h
counting on someone else including that before it.
With D6811 enabling automatic sorting of the includes
this can no longer be counted on. This changes includes
stdbool.h in BKE_ocean.h so it can build without being
depended on others including the right headers before it.
Fix crash when the operator search is used while no active object exists. The cause of the issue is an attempt to dereference `ob` when it is `NULL`. Therefore this patch checks the return value of `SCULPT_mode_poll()` first, to ensure that `ob` isn't `NULL`.
Reviewed By: pablodp606
Maniphest Tasks: T74838
Differential Revision: https://developer.blender.org/D7156
The code would have break the first (deform only) modifiers
once the index is reached, but it will not prevent second
loop (over remaining modifiers) from run.
This was applying deform modifier twice in some conditions:
having single deform modifier and calculating deformed mesh
up to the first modifier (index=0).
Use full argument name.
Also order arguments in the generosity order: from depsgraph
(which has everything) to object (which contains multires)
specific multires modifier.
The feature is hidden behind an experimental option, you'll have to
enable it in the preferences to try it.
This feature is not yet considered fully stable, crashes may happen, as
well as .blend file corruptions (very unlikely, but still possible).
In a nutshell, the ideas behind this code are to:
* Detect unchanged IDs across an undo step.
* Reuse as much as possible existing IDs memory, even when its content
did change.
* Re-use existing depsgraphs instead of building new ones from scratch.
* Store accumulated recalc flags, to avoid needless re-compute of things
that did not change, when the ID itself is detected as modified.
See T60695 and D6580 for more technical details.
Unreported Crash. When hidden faces are active (retopology) the depth
test could fail as the default framebuffers aren't set. This patch will
check if we are rendering a depth only and skip the clearing of the
buffer.
With this change baking jobs will be aborted faster. The user will not have to wait for the current frame to finish baking. The bake job will exit early and discard the incomplete frame.
This option existed already and was just hidden in the UI. With the new fluids system though, it will only be used for rendering - and not to optimize the cache.
Extract will steal all depsgraphs currently stored in given bmain, and
restore will put them back in place, using scene and viewlayers as keys.
Preliminary work for undo-speedup.
Part of T60695/D6580.
Mask extract modifies the topology when adding the boundary loop, so
previous face sets may not be correct in the new mesh. Remove the face
sets datalayer and let sculpt mode rebuild it when entering sculpt mode
in the new object.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7129
The previous behaivour didn't make sense as sculpt mode was still active
when switching to the new object, so it was rendering inconrrectly.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7130
The face set color variable needs to be declared inside of the loop in
order to reset it per iteration.
Reviewed By: jbakker
Maniphest Tasks: T74626
Differential Revision: https://developer.blender.org/D7096
Small UX fix. When hidding everything but the active face set with H,
the last stroke lotation center can be in a part of the model that is
hidden, so viewport navigation becomes confusing until you start a new
stroke on the visible face set. Now the viewport navigation rotation
center is updated to the active vertex when using a visibility operation
that uses it, so it always rotates using the visible face set as the
origin.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7137
`ANIM_animdata_update()` did not sort grease pencil frames. A
pre-existing comment stated this wouldn't be necessary as
`posttrans_gpd_clean()` already does this. However, this is only
applicable when the change is performed via the transform system. The
mirror operator doesn't call `posttrans_gpd_clean()`, invalidating the
assumption in the comment.
I moved the sorting code into `BKE_gpencil_layer_frames_sort()`, which
is now called from both `ANIM_animdata_update()` and
`posttrans_gpd_clean()`.
This commit adds 7 themes submitted by the community on Devtalk. These themes both serve specific purposes, provide a greater variety in look & feel, and serve as welcoming homes for users coming on board from other packages. This is the initial commit, but these themes can be continuously updated over time to fix issues and keep them up to date with changes.
Thanks to all contributors, and in particular the makes of the picked themes: Pierre Schiller, Edward Agwi, Vojtěch Lacina, Michail Soluyanov, Jason van Gumster, Mr Wax Police & Jonathan Lampel.
An overview is here: https://developer.blender.org/T74360
This patch fixes various problems of alignment and element backdrops for
the animation channels drawing, mainly in the Graph editor but also for
grease pencil and mask layers in the Dope Sheet.
Reviewed By: billreynish, sybren
Differential Revision: https://developer.blender.org/D5204
This fix jitter of overlay and GPencil. But I'm not sure this should
be the responsibility of the subsequent draw engines or the responsibility
of the current engine to reset the view.
Test specs are read from strings, and there was a comma instead
of a decimal point, and then an extra decimal point in the Quad0 test.
This test has been flaky on Windows buildbot. Perhaps this is why.
- Remove Shift for drawing poly-lines, just as in the default keymap
- Use consistent hotkeys for size and strength radial controls
- Fix some bugs/missing items from the GP merge
selections
Previously this was only supported in single click selections, doing an
island selection with box/circle/lasso would just select individual
vertices instead. Now selects islands properly.
This also unifys some logic between box/circle/lasso:
- use early selection test from lasso [makes things faster] in box/
circle
- circle wasnt checking visible face
- Add icons for Sculpt Cloth, Clay Thumb and Draw Face Sets, as well as GP Tint, Replace and Transform Fill tools
- Tweak icons for Sculpt Rotate, Pinch, Multiplane Scrape, Inflate, Blob, Draw Sharp, based on feedback on Devtalk
Fixed memory leak that showed up after the original issue (crash) had been fixed in 93ac4709eb. The fix ensures that light cache bakes free up GPU smoke textures and the smoke domain list correctly.
This commit also removes the workaround (f3a33a9298) that disabled light cache bakes for fluid objects.
The `check_is_animated()` function will be used by the upcoming Alembic
exporter as well. There is nothing USD-specific in the function.
No functional changes.
Owner of filelisting job was changed, without proper update of all
access/usages of that owner to reach the job, leading to failure of
timer removal from the WM, and attempt to double-free the job...
Caused by rB2c4dfbb00246ff.
The issue was that we were creating temporary mesh copies and storing
them in bmain and then later using BKE_mesh_nomain_to_mesh which would
add them to bmain once more (duplicates).
This would lead to crashes later as the custom data of the mesh could be
trashed quite easily.
Was happening when object does not have CD_MDISPS allocated yet.
Need to make sure totdisp and level is specified on CD_MDISPS data
prior to loading (as the load expects them to be properly set).
Part of the fix was to get gputexture to use an array to accomodate each
eye. This takes care of viewports showing individual Left or Right
views.
For the combined view the fix was in overlay_image.c:camera_background_images_stereo_setup.
Note 1: Referece images are still not supporting stereo.
Note 2: For painting, and getting image bindcode I'm hardcording a
single-view experience.
Note 3: Without D6922 stereo is too broken to even test this patch.
With D6922 + this patch the fullscreen modes work (anaglyph/interlace
not yet).
Differential Revision: D7143
This change fixes artifacts produced by these operations.
On a technical aspect this is done by porting all of the operations
to the new subdivision surface implementation which ensures that
tangent space used to evaluate modifier and those operations is
exactly the same (before modifier will use new code and the operations
will still use an old one).
The next step is to get sculpting on a non-top level to work, and
that actually requires fixes in the undo system.
Makes it work better "out of the box" for irregular topology like
Suzanne mesh.
There might be some performance impact on non-regular meshes, but
those are not very common usecase for multires and for those its
always possible to lower the quality if needed.
Loose vertices and vertices of loose edges callback was not working
correct if some of other callbacks were set to NULL.
Was caused by missing bitmask set in the callbacks which were set
to NULL.
Allow to mark individual vertices as infinitely sharp even if there is
no full topology and no access to edges: infinite sharp vertices do not
need connectivity information.
This allows fast access to various arrays in the Python API.
Most notably, `image.pixels` can be accessed much more efficiently now.
**Benchmark**
Below are the results of a benchmark that compares different ways to
set/get all pixel values. I do the tests on 2048x2048 rgba images.
The benchmark tests the following dimensions:
- Byte vs. float per color channel
- Python list vs. numpy array containing floats
- `foreach_set` (new) vs. `image.pixels = ...` (old)
```
Pixel amount: 2048 * 2048 = 4.194.304
Byte buffer size: 16.8 mb
Float buffer size: 67.1 mb
Set pixel colors:
byte - new - list: 271 ms
byte - new - buffer: 29 ms
byte - old - list: 350 ms
byte - old - buffer: 2900 ms
float - new - list: 249 ms
float - new - buffer: 8 ms
float - old - list: 330 ms
float - old - buffer: 2880 ms
Get pixel colors:
byte - list: 128 ms
byte - buffer: 9 ms
float - list: 125 ms
float - buffer: 8 ms
```
**Observations**
The best set and get speed can be achieved with buffers and a float image,
at the cost of higher memory consumption. Furthermore, using buffers when
using `pixels = ...` is incredibly slow, because it is not optimized.
Optimizing this is possible, but might not be trivial (there were multiple
attempts afaik).
Float images are faster due to overhead introduced by the api for byte images.
If I profiled it correctly, a lot of time is spend in the `[0, 1] -> {0, ..., 255}`
conversion. The functions doing that conversion is `unit_float_to_uchar_clamp`.
While I have an idea on how it can be optimized, I do not know if it can be done
without changing its functionality slightly. Performance wise the best solution
would be to not do this conversion at all and accept byte input from the api
user directly, but that seems to be a more involved task as well.
Differential Revision: https://developer.blender.org/D7053
Reviewers: JacquesLucke, mont29
The code was copied from the Alembic exporter, and some of the options are
no longer used.
Not updating the Alembic exporter itself, as this will be done in a much
larger rewrite.
Both are doing almost the same and can be merged. This reduce complexity for user and less code to maintain.
Reviewed By: mendio, pepeland, fclem
Differential Revision: https://developer.blender.org/D7134
The Deform modifiers was reallocating buffers that only fit the vertices
of the inner loop. This patch first counts the maximum needed buffer and
allocates one.
When using the daily dweebs animation file the playback performance went
from 0.66 fps to 0.93 fps.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D7132
If one of the faces connected to a vertex is hidden in the face sets, we
can assume that the vertex is part of a boundary edge, so it should be
cosidered like that in all automasking and edge detection functions.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7126
The idea of the visibility system is that tools should behave like
hidden vertices do not exist, so the flood fill operation should ignore
hidden vertices for all operators.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7125
The face set ID is sequential, so implementing this was straightforward.
Suggested by Jeroen Bakker
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7123
The face_set_set function which sets a face sets given a vertex index
can ignore all modifications to hidden face sets, so we can skip all
vertex visibility checks outside that function. This makes the code
faster, simpler and fixes multiple bugs.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7122
The previous solution was also working fine as the white face set has no
meaning, but now it is a little bit more random. Also, bigger face sets
have more chance of getting the white color.
Reviewed By: jbakker
Maniphest Tasks: T74646
Differential Revision: https://developer.blender.org/D7111
The mesh provided in the report has 0 area faces and overlapping
vertices, causing the relax code to fail when calculating the plane to
constraint the vertex movement. Now it works fine both in the brush and
in the mesh filter.
Reviewed By: jbakker
Maniphest Tasks: T74648
Differential Revision: https://developer.blender.org/D7109
If the relax mesh filter was used on a non manifold mesh with open
boundaries, all the vertices were relaxed and the mesh was shrinking.
This was an unintended behavior that was making the filter unusable with
these meshes.
The mesh filter is now initializing an automasking buffer using the same
boundary automasking function from the brush code. Now edges are
preserved and the relax filter works as it should.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7097
Embedded data should always be considered as outside of Main database
here.
Note that it's a bit of an edge case to decide whether those should
always have their `LIB_TAG_NOMAIN` set too, or not? For now, let's keep
things as they are here.
The behaviour of GP layers is the same as annotation layers: they show
in the dope sheet regardless of whether they have frames or not. This is
easily resolved by adding some extra filtering.
Part of the function was following an "if-ok: do-this" pattern, and then
mid-function switched to a "if-bad: skip" pattern. The function now just
uses the latter.
No functional changes.
Some draw state bits are mutual exclusive. This patch will free some
draw state bits by packing the mutual exclusive bits in a mask.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D7088
- Use typed enum for line_data callback.
- Pass in 'const' arguments where possible.
- Use 'r_' prefix for return arguments.
- Remove unused return value from line_get callback.
- Remove redundant casts.
This extends the ocean modifier to add new spectra
(Pierson-Moskowitz, Jonswap, TMA).
These models are very different to the Phillips spectrum.
They are intended for more established,
large area, oceans and/or shallow water situations.
Bullet currently generates the majority of the warnings
on windows all of them are silly. This patch disables
all warns from bullet for now.
We should revisit this if/when we update bullet
to a newer version.
Reviewed By: sergey brecht
Differential Revision: https://developer.blender.org/D7118
`google::LogMessageFatal::~LogMessageFatal` calls `abort`
which MSVC correctly identifies as 'not returning'
and warns about a potential memory leak.
Given this is intended behaviour and glog is not overly
concerned with shutting down the process nicely, we
can safely ignore this warning.
Rather than passing around void pointers, various Blender image sources now
subclass this. OIIO is also just another type of image loader.
Also fixes T67718: Cycles viewport render crash editing point density settings
This is mostly straightforward, but required some refactoring to ensure that
the default volume material does not always turn on the volume feature for GPU
rendering.
printf is called for a size_t (64 bit on x64) type
but the formatter is `%lu` (32 bit) leading to a
warning with MSVC.
`%zu` is the appropriate formatter.
Was happening when having compositor open with Viewer node attached
directly to Render Layers output.
There were two things involved here:
1. The code which was storing CoW-ed versions of IDs was checking all
IDs for whether they are expanded or not. This was causing access
of freed memory for deleted IDs which do not need CoW (such as IM).
Simple fix: store ID type as a scalar and use early check before
doing more elaborate check based on accessing fields of id_cow.
2. The code which was ensuring view layer pointer is doing CoW for
scene. This isn't an issue on its own, but scene might have an
embedded ID such as compositor which was actually traversed by the
ID remap routines. This was causing remapping procedure to go into
non-updated copy of compositor, accessing freed Viewer image ID.
Solved by not recursing into embedded IDs for datablocks as those
are supposed to have own copy-on-write operations which takes care
of re-mapping.
Reported my Bastien, and also pair-coded with him.
For debug builds we link the against the release mode libs
for C based libraries, which are technically linked against
a different CRT, which the linker will implicitly try to link.
Which results in a linker warning about mixing the debug/release CRT.
This patch prevents the implicit linking of the release
CRT in debug configurations for sub projects that had issues
with it.
We implement cubemap array support for EEVEE's lightcache reflection probes.
This removes stretched texels and bottom hemisphere seams artifacts caused
by the octahedral projection previously used.
This introduce versioning code for the lightcache which will discard any
lightcache version that is not compatible.
Differential Revision: https://developer.blender.org/D7066
This patch is (almost) a complete rewrite of workbench engine.
The features remain unchanged but the code quality is greatly improved.
Hair shading is brighter but also more correct.
This also introduce the concept of `DRWShaderLibrary` to make a simple
include system inside the GLSL files.
Differential Revision: https://developer.blender.org/D7060
Casting a 64 bit pointer to a 32 bit DWORD gave 2 warnings.
Solved by storing the actual DWORD in the registry table.
Would have preferred to use a union, but C++ doesn't let you
initialize anything other than the first field, and C99 style
initializers are not supported until C++20, so this solution
will have to do until then.
Update Dopesheet header to include missing buttons, remove Scene Active only buttton and also removed duplicated search box.
The removed options come from old 2.7x version and they are not required now.
Reviewed By: mendio, pepeland
Differential Revision: https://developer.blender.org/D7107
Select Similar Group and Select Similar Shape had this issue since they
were added. Basically it assumes there is pose data which in some cases
it does not.
This has no user visible impact yet since smoke volumes only support a fixed
set of attributes, but will become important with the new volume object.
For GPU shader compilation, volume grids are now handled separately from
image textures. They are somewhere between a vertex attribute and an image
texture, basically an attribute that is stored as a texture.
Differential Revision: https://developer.blender.org/D6952
This is more in line with standard grids and means we don't have to make
many special exceptions in the upcoming change for arbitrary number of volume
grids support in Eevee.
The workbench shader was also changed to fix bugs where squared density was
used, and the smoke color would affect the density so that black smoke would
be invisible. This can change the look of smoke in workbench significantly.
When using the color grid when smoke has a constant color, the color grid
will no longer be premultiplied by the density. If the color is constant
we want to be able not to store a grid at all. This breaks one test for
Cycles and Eevee, but the setup in that test using a color without density
does not make sense. It suffers from artifacts since the unpremultiplied
color grid by itself will not have smooth boundaries.
Differential Revision: https://developer.blender.org/D6951
Issue revealed by own recent cleanup in rB8820ab4, and moticed by
@brecht, thanks.
Note that am not 100% sure whether we should allow call on lib_query
without a proper valid owner_id, for embedded data-blocks. But this can
be investifated later, so far things have been working like that.
'Private' can be a rather confusing term, especially when considering
its meaning in programming languages.
So now root node trees and master collections are 'embedded' IDs
instead.
The former is always a real, in-Main data-block, while the later, when
different, should be one of those embedded 'private' IDs (like root node
ree or master collection).
- Move gpuPush/Pop from GPU_draw.h into GPU_state.h
as this is for pushing/popping state.
- Add 'GPU_STANDALONE' define, to bypass use of user-preferences
for theme colors and pixelsize, as well as pbvh init/free functions.
Needed to get GHOST tests working again.
I've added a very minimal mesh validation before the Alembic mesh is actually
converted to a Blender mesh. This prevents a specific crash with an example
file attached to T74200.
A default face set color was not being set in previously saved meshes,
so it will always render the default face set with a random color until
the colors were recalculated.
Bump subversion to 283.8
Reviewed By: dfelinto
Maniphest Tasks: T74613
Differential Revision: https://developer.blender.org/D7094
Good to be explicit about the fact that we may still use the pixel
property sub-type when DPI will be applied.
See comments in https://developer.blender.org/D7077.
The 3D view grid size property is a multiplier, not the size of the grid itself.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7085
The Extrapolation Mode menu in the graph editor channel list was
incorrectly using the operator for the Action/Dopesheet editor. The
operator was even missing in the generic dopesheet hotkeys, so
{key Shift E} was listed as hotkey but didn't work. This is now all
fixed.
EasingType was implemented rBdaccaa713b6e for the GraphEditor (but never
made it to the Dopesheet). If you can select Easing Mode in the
DopeSheet, then you should also be able to select the associated Easing
Type.
Thanks @lichtwerk for the initial implementation.
Maniphest Tasks: T65076
Differential Revision: https://developer.blender.org/D6094
Caused by the introduction of UDIM (rBc30d6571bb47).
We need to make sure the tiles ImageUser is set up correctly [especially
the framenr], otherwise BKE_image_acquire_ibuf() and friends will fail
to find the correct ImBuf.
Also instead of initializing a minimal BKE_imageuser_default, now use
an appropriate ImageUser if avaliable and pass this around (instead of
just the tile_number). 2D painting can reuse the Image Editor ImageUser,
for 3D painting we still rely on a default ImageUser in most places, but
at least set the framenr correctly].
This also fixes crashes when doing image operations such as inverting or
resizing on images in a sequence in the Image Editor.
This also fixes color sampling (S) from the 3DView going wrong for image
sequences (would fallback to OpenGL sampling because an ImBuf could not
be found).
Maniphest Tasks: T74425
Differential Revision: https://developer.blender.org/D7022
This started happening after changing filter ID to 64 bit in rB2841b2be3949,
however there was a pre-existing error here in the comparison to detect updates
to filter flags.
When scaling the root bone of a rig to apply a global scale, the
corrective smooth modifier results in wrong deformation due to incorrect
scaling. The delta calculations are not taking into account any scale
value.
To fix it, a scale property is added to the modifier, allowing to set
manually the scale value for the deltas by simply multiplying the
vectors by this value. There is a similar implementation in Maya's Delta
Mush deformer. This property can be for example driven by the scale of
the root bone of the rig, to dynamically update when the animator scale
this bone.
Reviewed By: brecht, sybren
Differential Revision: https://developer.blender.org/D6622
When user used a custom background color, this color was also visible in
material preview mode, when the world opacity was less than 1. This
patch will draw the theme color as it was used to.
It seems like OSX drivers are using standard attributes for passing
gl_VertexID and gl_InstanceID to the vertex shader, and count them in the
limit of MAX_VERTEX_ATTRIBS.
This patch make sure to never use more than 13 attributes by packing some
attributes together.
I could not reproduce the issue, but it looks like it was produced by
this division by 0. In any case, the code here was wrong.
Reviewed By: jbakker
Maniphest Tasks: T74354
Differential Revision: https://developer.blender.org/D6987
This automasking option protects the open boundary edges of the mesh from the brush deformation. This is needed to sculpt cloths and it works nicely with the cloth brush.
It has a Propagation Steps property that controls the falloff of the mask from the edge.
Limitations:
- The automask is recalculated at the beginning of each stroke, creating a little bit of lag in high poly meshes, but it is not necessary. This can be fixed in the future by caching the edge distances, increasing a little bit the complexity of the code.
- The boundary vertex detection in meshes is not ideal and it fails with triangulated geometry, but it is the same as in the smooth brush. After fixing this, we should refactor the smooth brush to use the API and let the automasking option manually control the affected vertices.
- It does not work in Multires (it needs to be implemented in the API). The smooth brush in Multires is also not making boundary vertices.
- The falloff has a visible line artifact on grid patterns. We can smooth the final automasking factors several iterations, but it will make the initialization much slower. This can also be added in the future if we decided to cache the distances.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6705
This only applies to the case where preferences are opened as an editor in
a workspace, not with Edit > Preferences in a new window.
Differential Revision: https://developer.blender.org/D7001
This introduces a variable to store a face set ID which is going to be
rendered white. When initializing a mesh or randomizing the colors, this
variable gets updated to always render a white face set. This way the
face set overlay can be enabled without adding colors to the mesh if
face sets are not in use. After creating the first face set, new colors
are generated randomly like usual.
The face set stored as default does not have any special meaning for
tools or brushes, it just affects the rendering color.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7035
This enables a relax operation that works only on face sets boundaries,
which smooths the jagged edges that are produced when painting or
expanding face sets by sliding the topology without affecting the shape
of the mesh. This has many uses in hard surface sculpting for things
like sculpting panels or smoothing surfaces. It can also help when
working with remeshed topology as it makes the face sets looks better
and more organized if needed.
The operation is implemented as an Shift smooth in the Draw Face sets
tool, similar to the Slide/Relax tool.
The same operation is also available in the mesh filter to smooth all
the face sets boundaries uniformly or to smooth the face set under the
cursor with the Use Face Sets option.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7034
The cloth brush was not using the automasking values when calculating
the mask value on each vertex.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7083
Was crashing SculptSession data will not longer be valid if the total
number of polys is modified when rendering the mesh again.
This deletes all face sets in the mesh when slicing the mask. I'll try
to add code to generate a new face set in with faces that are created
when filling the holes, but for now this avoids the crash.
Reviewed By: brecht
Maniphest Tasks: T74500
Differential Revision: https://developer.blender.org/D7049
Create face sets by visibility needs to check if all face sets of a
vertex are visible to set the new face set. I renamed the functions to
make this more cleare in the API.
I also added a visibility check when creating by mask to avoid modifying
hidden areas.
Reviewed By: brecht
Maniphest Tasks: T74499
Differential Revision: https://developer.blender.org/D7048
Hardness is now a property implemented for all brushes, so this is no
longer needed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7078
The operator was resetting the mask data when cancelling instead of the
face set data, so it was crashing because mask data was not available
when starting the operator in expand face set mode.
Reviewed By: brecht
Maniphest Tasks: T74492
Differential Revision: https://developer.blender.org/D7043
This way we can change the color generation easily if we want to improve
it in the future. I also added more values to randomize a little bit the
saturation and value of the colors, as previously it was too easy to get
similar colors when creating new faces, forcing you to use the randomize
colors more than necessary.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7042
The problem happens because, in wireframe mode, `bool use_wire` is
always `true`, so the function that draws all edges is the called.
The solution is set `use_wire` as `false` when the mesh has no edges.
This matches the behavior of blender 2.79.
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D7041
This has been long standing TODO...
Note that remaining usages of BKE_xxx_delete should all be carefully
checked for and utilmately nuked in favor of `BKE_id_delete()`, think we
still have quiet a few bugs hidden in those (code seems to usually
assume those functions do a full ID deletion, which is not the case).
Only covers direct usages of new callbacks from IDTypeInfo.
We still have a lot of those switch/case, many can probably go away
with minimal refactor now, but that will be for later.
In rB7c5a44c71f13 I changed the way transform matrices are loaded from
Alembic. Instead of having the Alembic importer convert matrices from
local (in the Alembic file) to World (to pass to the constraint handling
the animation of transforms), I set the constraint space to
`CONSTRAINT_SPACE_LOCAL`.
This worked thanks to rB7728bfd4c45c. However, that commit was reverted,
which meant that for parentless objects `CONSTRAINT_SPACE_LOCAL` no
longer means "local space".
The situation is resolved by setting the constraint to world space
again, and computing the world matrix in the Alembic importer.
Steps to reproduce were:
* Disable tool settings region in 3D View (View > Tool Settings)
* Split the 3D View and drag all the way down
The removed code doesn't seem to be needed anymore. Tested this on hiDPI
too, seems fine.
These kind of fixes are always tricky, so I wouldn't be surprised if
there are any issues caused by this.
The issue of T72253 was that the density threshold (RNA adapt_threshold) was considering cells as empty cells too early and thus also shrinking the domain too early. The fix for this is to use smaller threshold values for the adaptive domain. This fix gives more flexibility in the UI to do just that.
This commit is a full refactor of the grease pencil modules including Draw Engine, Modifiers, VFX, depsgraph update, improvements in operators and conversion of Sculpt and Weight paint tools to real brushes.
Also, a huge code cleanup has been done at all levels.
Thanks to @fclem for his work and yo @pepeland and @mendio for the testing and help in the development.
Differential Revision: https://developer.blender.org/D6293
Unused no-op operation nodes are not bound to a callback function, and
have no outgoing relations. Incoming relations of such nodes are removed
since ff60dd8b18. However, this was done
too broadly, causing too many relations to be lost and indirectly linked
objects to be unevaluated.
This commit introduces a `DEPSOP_FLAG_FAKE_USER` flag for operation
nodes, which indicates they are not to be removed, even when they appear
to be unused.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7074
Apparently this happened when the object is in a flat view and has
customdata `CD_SCULPT_FACE_SETS`
Differential Revision: https://developer.blender.org/D7073
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
Currently, this change does not bring functional changes.
But it is necessary to extend the use of the snap system for gizmos,
since, after a Undo, the `depsgraph` pointed by the `snap_context`
has its memory invalidated.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D7013
This reverts commit 7728bfd4c4.
Although this brings back an inconsistency in the behaviour of
constraints on objects and bones, people were relying on the old
behaviour, and the new behaviour broke their files.
It is still desired to remove this inconsistency, but it will happen
more gradually.
This allows deleting both collections and objects in the outliner
selection at the same time. This only works using the keyboard shortcuts
(X or Delete).
While this works, a more robust solution should be implemented later to
allow deleting the whole selection from the context menu as well.
Missing changes from one of the renamings of the initial face sets
patch.
Reviewed By: brecht
Maniphest Tasks: T74513
Differential Revision: https://developer.blender.org/D7054
The initial iteration for all symmetry areas is always 0. We were using
1 for the main stroke, so it was 1 step behind.
This was broken for expanding masks and face sets, but with face sets it
is more noticeable.
Reviewed By: brecht
Maniphest Tasks: T74501
Differential Revision: https://developer.blender.org/D7050
By using PBVH_ITER_UNIQUE hidden vertices are skipped, like in the rest of
the brushes and tools.
Reviewed By: brecht
Maniphest Tasks: T74498
Differential Revision: https://developer.blender.org/D7047
This was particularly strange because we had a _free_data() function.
But still the one I replaced was of course the _free() one.
And we should rename the _free_data_ function later to avoid confusions.
Remove Windows special folder FOLDERID_Objects3D. Requires newer SDK.
Differential Revision: https://developer.blender.org/D7014
Reviewed by Brecht Van Lommel
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
Part of https://developer.blender.org/T74429.
There's a chance that this causes some issues becaue in some cases we
change from getting the window from context to getting it from somewhere
else.
This moves the `alembic`, `avi`, `collada`, and `usd` modules into a common
`io` directory.
This also cleans up some `#include "../../{somedir}/{somefile}.h"` by
adding `../../io/{somedir}` to `CMakeLists.txt` and then just using
`#include "{somefile}.h"`.
No functional changes.
This is the companion of D7031. That patch adds a new DIMENSIONS node to
the depsgraph for each object that has geometry. However, this node is
only necessary when there are drivers using an object's dimensions as
variable. Since this is rare, it's easiest to remove these nodes after
they turn out to be unnecessary. This is what (almost) happens in this
patch.
Removing nodes from the depsgraph is hard, and there are no functions to
do this yet. Instead, this patch recursively removes all the incoming
relations from unused no-op nodes (i.e. no-op operation nodes without
outgoing connections). Actually removing the nodes will be left as a
future improvement.
I've tested this on a Spring file [1]. Here are there results of blender
--debug-depsgraph-time spring_02_055_A.eevee.blend and letting it run
for a while to stabilise the reported FPS:
master: 11.7 FPS
Just D7031: 11.7 FPS
Just D7033: 11.8 FPS
Both D7031 + D7033: 12.3 FPS
[1] https://cloud.blender.org/p/spring/5d30a1076249366fa1939cf1
Differential Revision: https://developer.blender.org/D7033
`(size_t)(int * int)` will actually cast overflown integer to size_t,
which isn't what was intended here. Correct thing would be to cast
in the following manner `(size_t)int * int`.
In this particular case can as well use function which is designed to
allocate an array of memory without overflow.
Since hair collisions were integrated with the cloth solver
(rBd42a7bbd6ea5), there are a couple of relevant settings which were not
exposed to the User:
- Collision Quality
- Minimum Distance (this was reported in T73842, default of 0.015m was
still limiting in certain scenarios - this can now be made smaller)
- Impulse clamping
- Collision collection
This will add a 'Collisions' panel to Hair Dynamics with those settings
Note: in contrast to 'real' cloth, self-collisions are not supported for
hair
Maniphest Tasks: T73842
Differential Revision: https://developer.blender.org/D7032
Make it obvious that this relates to being in sculpt mode.
ref T74489
Maniphest Tasks: T74489
Differential Revision: https://developer.blender.org/D7044
The docstring was likely copy-pasted, and the return type was not adjusted.
Since the `bpy.msgbus.subscribe_rna()` returns nothing, I just removed the
return type documentation.
Previously, `writedata` was used to store `bNodeSocket->default_value`.
There are a couple of issues with that:
* Breaks if someone tries to load the file on a big endian system (afaik).
* There is a `/* do not use for structs */` comment on `writedata`.
* Depends on `MEM_allocN_len` which should be avoided in my opinion.
* Now it is more apparent, that this should be handled by callbacks as well.
The part in `readfile.c` should work just fine still. I could also do a case
distinction there, but the code would be the same for every case for now.
Just `sock->default_value = newdataadr(fd, sock->default_value);`.
This might change, if we want to store more complex socket type specific data
that does not fit into a single struct.
Differential Revision: https://developer.blender.org/D7039
Reviewers: brecht
Currently the link limit of sockets is stored in bNodeSocket->limit.
This allows for a lot of flexibility, but is also very redundant.
In every case I've had to deal with so far, it would have "more correct"
to set the link limit per socket type and not per socket. I did not enforce
this constraint yet, because the link limit is exposed in the Python API,
which I did not want to break here.
In the future it might even make sense to only support only three kinds of link limits:
a) no links, b) at most one link, c) an arbitrary number links links. The other link
limits usually don't work well with tools (e.g. which link should be removed when a new
one is connected?) and is not used in practice. However, that is for another day.
Eventually, I would like to get rid of bNodeSocket->limit completely and replace it
either with fixed link limits or a callback in bNodeSocketType.
This patch consists of three parts:
**1. Support defining link limit in socket type**
This introduces a new `nodeSocketLinkLimit` function that serves as an indirection to
hide where the link limit of a socket is defined.
**2. Define link limits for builtin sockets on socket type**
Data sockets: one input, many outputs
Virtual sockets: one input, one output
Undefined sockets: many inputs, many outputs (to avoid that links are removed when the type of the socket is not known)
**3. Remove `bNodeSocketTemplate->limit`**
This wasn't used anymore after the second commit. Removing it simplifies socket definitions
in hundreds of places and removes a lot of redundancy.
Differential Revision: https://developer.blender.org/D7038
Reviewers: brecht
We would previously not store the transforms that were added to the
group transform node. This would lead to pointer to allocated memory
being lost and not freed.
This patch will make use of the eDrawType where it was used as a
variable or parameter name. The eObjectDrawType was renamed to eDrawType
as it is also used by `View3DShading.type`.
Motivation the functions get 3 different kind of flag parameters (ImBuf,
DrawType, OffscreenRendering) the naming of the flags were not clear,
leading to mistakes and unnecessary time spend debugging.
This was not set anywhere, code relies on MLOOPUV_VERTSEL everywhere.
BMLoopUV.select_edge was never returning True and wasnt updating uv
select state when set manually.
Afaict, there were no official Addons using this from python.
Resolves T65836
Maniphest Tasks: T65836
Differential Revision: https://developer.blender.org/D6772
There are two ways in which adding/deleting keyframes can fail, but only
one of those was handled. The other would be shown as a successful
add/delete of -2 keyframes.
The `ANIM_apply_keyingset()` returns a value that indicates the number of
changed channels (if nonnegative) or an error state (negative). In the
places where the return value was actually used, this value was stored in
a badly named variable.
This fixes an issue where drivers using `object.dimension` only add a dependency on `GEOMETRY` to the depsgraph, whereas they should also depend on `TRANSFORM`.
This patch adds a new no-op operation that depends on the geometry and transform components to the Parameters component.
An alternative implementation would be to have `RNANodeQuery::construct_node_identifier` return multiple node identifiers. However, this would spread throughout the depsgraph code and unnecessarily force many other functions to either return or handle multiple nodes where in 99.999% of the time a single node would suffice.
The new `DIMENSIONS` node is added for each object. An upcoming patch will go over all no-op operation nodes and remove them from the depsgraph. Since this is a more dangerous operation, it'll be reviewed separately.
Differential Revision: https://developer.blender.org/D7031
Since the bounding boxes are now also being used for effector objects, there needs to be a better name for them. Instead of calling them EmissionMap, which caters only to emission objects, they will now be called FluidObjectBB.
- Keymap items now have 'repeat' boolean which can be set
to make keymap items respond to key repeat events or not.
- Support for X11 & WIN32 (not macOS currently).
This allows for the possibility to perform actions while a key is held
and finish the action upon release.
Thanks to @Severin for review and WIN32 support.
- Use 'int' for counters instead of short.
- Use 'bool' instead of a counter when only a change is being detected.
- Use typed enum for keying set flags.
- Include in comments when a negate error code may be returned.
- Split 'verify_fcurve' into two functions:
ED_action_fcurve_ensure which adds the f-curve if needed.
ED_action_fcurve_find which returns NULL when not found.
Callers of ED_action_fcurve_find had unused 'group'
argument which has been removed.
- Rename verify_adt_action to ED_id_action_ensure
It had an argument to add data which was always true,
remove this instead of splitting in into a separate function.
- Use 'BKE_object_defgroup' prefix for object functions.
- Rename 'defvert_verify_index' to 'defvert_ensure_index'
since this adds the group if it isn't found.
Use only one font icon in File Browser for all platforms. Correct mistake to allow this icon to be used.
Differential Revision: https://developer.blender.org/D7037
Reviewed by Brecht Van Lommel
Face Sets are the new system to control the visibility state of the mesh in sculpt and paint modes. They are designed to work in modes where brushes are the primary way of interaction and they provide much more control when working with meshes with complex shapes and overlapping surfaces.
This initial commit includes:
- Sculpt Face Sets data structures and PBVH rendering.
- Face Set overlay and opacity controls.
- Sculpt Undo support.
- Remesher reprojection support. The visibility state of the mesh is also preserved when remeshing.
- Automasking and Mesh filter support.
- Mask expand operator mode to expand Face Sets (Shift + W) and flood fill areas by connectivity (press Ctrl while expanding).
- Sculpt Mode Face Sets and Visibility API.
- Sculpt Face Sets creation and visibility management operators.
- Operator to randomize the Face Sets colors.
- Draw Face Sets brush tool to create and edit the Face Sets. Drawing on the mesh creates a new Face Set. Pressing Ctrl before drawing modifies the Face Set under the brush at the beginning of the stroke.
- Updated keymap and menu to work with Face Sets from Sculpt Mode (H to toggle visibility, Alt + H to show all, Shit + H to hide).
- Pie menu on the W key with Face common Sets operations.
Know limitations:
- Multires support. The Face Sets and Visibility API needs to be implemented for Multires.
Reviewed By: jbakker, #user_interface, Severin
Differential Revision: https://developer.blender.org/D6070
Adding more Windows special folder locations, used when browsing or bookmarking.
Differential Revision: https://developer.blender.org/D7014
Reviewed by Brecht Van Lommel
Nicer icons for File Browser System and Favorites lists on Mac.
Differential Revision: https://developer.blender.org/D6398
Reviewed by Brecht Van Lommel
Adds a minimal DirectX 11 Ghost context, plus some shared DirectX-OpenGL
resource interface using the NV_DX_interop2 WGL extension. From what I
know, this should be available on modern GPUs. If not, it should fail
gracefully.
There should be no user visible changes at this point.
Needed for DirectX-only OpenXR platforms (e.g. Windows Mixed Reality). I
heard there are other use-cases as well though.
It's known that this currently fails on some AMD systems, but that seems
to be fixable.
Most of this comes from the 2019 GSoC project, "Core Support of Virtual
Reality Headsets through OpenXR"
(https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Reviewed by: Jeroen Bakker, Ray Molenkam, Brecht van Lommel
Differential Revision: https://developer.blender.org/D6190
Since `std::deque` is used in a few areas of the Depsgraph, and an
upcoming patch adds one more, it's time it's considered as "commonly
used type".
No functional changes.
"session-wise" here mean while editing a same .blend file. So creating
or opening a new one will reset the uuid counter. This should avoid any
overflow in practice.
Only IDs added to Main database get an uuid, runtime-only ones are not
affected.
This is intended to provide undo with a way to find IDs across several
'memory realms' (undo speedup project).
No behavior change is expected from this commit itself.
Part of T60695.
Differential Revision: https://developer.blender.org/D7007
Enabling viewport denoising causes Cycles to use a multi-device, which always returned NULL when
asked for OSL memory and would subsequently crash. This fixes that by returning the correct OSL
memory pointer from the CPU device in the special viewport denoising multi-device.
Selecting certain child datablocks also selects the parent (e.g.
selecting a pose bone selects the armature). The base was selected, but
the outliner tree element was left unselected. The subsequent selection
sync would then deselect the parent base because it was not flagged as
selected in the outliner.
This led to issues like T74332 where selecting a pose bone in the
outliner did not show drivers in the driver editor unless the armature
was explicitly added to the selection afterwards.
The solution is to also flag the outliner elements as selected when
selecting parent bases.
Differential Revision: https://developer.blender.org/D7029
This feature takes some inspiration from
"RenderMan: An Advanced Path Tracing Architecture for Movie Rendering" and
"A Hierarchical Automatic Stopping Condition for Monte Carlo Global Illumination"
The basic principle is as follows:
While samples are being added to a pixel, the adaptive sampler writes half
of the samples to a separate buffer. This gives it two separate estimates
of the same pixel, and by comparing their difference it estimates convergence.
Once convergence drops below a given threshold, the pixel is considered done.
When a pixel has not converged yet and needs more samples than the minimum,
its immediate neighbors are also set to take more samples. This is done in order
to more reliably detect sharp features such as caustics. A 3x3 box filter that
is run periodically over the tile buffer is used for that purpose.
After a tile has finished rendering, the values of all passes are scaled as if
they were rendered with the full number of samples. This way, any code operating
on these buffers, for example the denoiser, does not need to be changed for
per-pixel sample counts.
Reviewed By: brecht, #cycles
Differential Revision: https://developer.blender.org/D4686
Introduce new IDTypeInfo structure.
Each ID type will have its own, with some minimal basic common info,
and ID management callbacks.
This patch only does it for Object type, for demo/testing purpose.
Moving all existing IDs is a goal of next "cleanup Friday".
Note that BKE_idcode features should then be merged back into BKE_idtype -
but this will have to be done later, once all ID types have been properly
converted to the new system.
Another later TODO might be to try and add callbacks for file read/write,
and lib_query ID usages looper.
This is part of T73719.
Thanks to @brecht for initial idea, and reviewing the patch.
Differential Revision: https://developer.blender.org/D6966
This was raised in T74017, the issue being that we point to `/dev`
version of the manual for the addons when we want to point to a specific
version instead.
Instead of manually updating the URL every release we can do this.
The `bl_info` for addons will need to be updated in the format of
`'doc_url':
{BLENDER_MANUAL_URL}/addons/import_export/scene_gltf2.html",`
Differential Revision: https://developer.blender.org/D6995
When running with debug enabled ('-d' argument),
warnings are printed for add-ons which are not yet updated.
Reminder to name things based on what they do,
not the technologies they use :)
- Use 'BKE_object_material_*', 'BKE_id_material_*' prefix
for functions that operate on Object and ID types.
- Use '_len' suffix for length (matching BLI naming).
- Use '_p' suffix for functions that return a pointer to values
where the value would typically be returned.
Functions renamed:
- BKE_object_material_resize was BKE_material_resize_object
- BKE_object_material_remap was BKE_material_remap_object
- BKE_object_material_remap_calc was BKE_material_remap_object_calc
- BKE_object_material_array_p was BKE_object_material_array
- BKE_object_material_len_p was BKE_object_material_num
- BKE_id_material_array_p was BKE_id_material_array
- BKE_id_material_len_p was BKE_id_material_num
- BKE_id_material_resize was BKE_material_resize_id
- BKE_id_material_append was BKE_material_append_id
- BKE_id_material_pop was BKE_material_pop_id
- BKE_id_material_clear was BKE_material_clear_id
This commit adds bounding box support for emission objects - similarly to flow objects. Before, each effector object had to iterate over the entire domain. Bake times of scenes with multiple obstacles improved significantly with this optimization.
Other improvements that were implemented alongside the bbox feature:
- Option for subframe sampling for effector objects
- Option to enable / disable effectors (can be animated)
- Optimization for static objects. If a flow or effector object does not move and the adaptive domain is not in use, the bake time will be optimized further by reusing the flow / effector grids from the previous frame (no recalculation).
not work for unlocking
Special case for when we do this on "lock":
- locked sequences are not in "selected_editable_sequences"
- use "selected_sequences" in that case
Maniphest Tasks: T74434
Differential Revision: https://developer.blender.org/D7023
The OpenXR-SDK contains utilities for using the OpenXR standard
(https://www.khronos.org/openxr/). Namely C-headers and a so called
"loader" to manage runtime linking to OpenXR platforms ("runtimes")
installed on the user's system.
The WITH_XR_OPENXR build option is disabled by default for now, as there
is no code using it yet. On macOS it will remain disabled for now, it's
untested and there's no OpenXR runtime in sight for it.
Some points on the OpenXR-SDK dependency:
* The repository is located at
https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* Notes on updating the dependency:
https://wiki.blender.org/wiki/Source/OpenXR_SDK_Dependency
* It contains a bunch of generated files, for which the sources are in a
separate repository
(https://github.com/KhronosGroup/OpenXR-SDK-Source).
* We could use that other repo by default, but I'd rather go with the
simpler solution and allow people to opt in if they want advanced dev
features.
* We currently use the OpenXR loader lib from it and the headers.
* To use the injected OpenXR API-layers from the SDK (e.g. API
validation layers), the SDK needs to be compiled from this other
repository.
The extra "XR_" prefix in the build option is to avoid mix-ups of OpenXR
with OpenEXR.
Most of this comes from the 2019 GSoC project, "Core Support of Virtual
Reality Headsets through OpenXR"
(https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Differential Revision: https://developer.blender.org/D6188
Reviewed by: Campbell Barton, Sergey Sharybin, Bastien Montagne, Ray
Molenkamp
After switching tools, the active vertex can be the same and the cursor
won't update the previews, so the pose_ik_chain_preview will be null.
This often happens in low poly meshes where chances of hovering the same
vertex are high.
Reviewed By: sergey
Maniphest Tasks: T74426
Differential Revision: https://developer.blender.org/D7021
Instead of using anonymous booleans flags, also allows to keep the same
behavior in all cases, without needing special handling from calling
code for our beloved oddballs object proxies...
fails
Exposed by rB50d5c03e2d14.
This was only a problem when _only_ 'Object Data' was made local.
If also e.g. 'Object' or 'Materials' was checked, these were already
making sure realations were updated [DEG_relations_tag_update(bmain)].
Now also call DEG_relations_tag_update(bmain) for the 'Object Data'
case.
I assume the underlying issue is that there is some ID_NEW_REMAP
happening in 'single_obdata_users()' -- including that for 'me-
>texcomesh', which might be responsible for the glitches in selection/
editing? Also not entirely sure why this wasnt a problem prior to
rB50d5c03e2d14.(I assume this was somewhat hidden by the fact this was
always called with a default action being nothing, the user would always
need to access the redo panel. So this might have been hidden by an Undo
step involved?)
Maniphest Tasks: T73797
Differential Revision: https://developer.blender.org/D7020
This would happen when done from editmode, on a mesh with any modifier,
after adding/removing geometry in editmode.
Similar to rBba0870713b9b (which did this for weightpaint and sculpt
already), ensure an evaluated depsgraph, otherwise
'runtime.mesh_deform_eval' would not be up to date causing problems
later.
Maniphest Tasks: T72028
Differential Revision: https://developer.blender.org/D7011
This does not affect the RNA access API, since how the boolean is read from
DNA abstracted away in the API.
Differential Revision: https://developer.blender.org/D7002
USD is being included before the blender headers.
USD includes TBB, which includes the windows headers
which define rad2 as a constant conflicting with a field
with that exact name in the MetaElem dna struct.
Added `-DWIN32_LEAN_AND_MEAN` to keep the windows headers
from defining rad2.
It was missing this local space conversion before calculating the rake
angle.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7008
Metaballs are exported as evaluated polygonal mesh.
USDExporterContext::depsgraph was made non-const to allow calling
`BKE_mesh_new_from_object()`. The alternative was to make the depsgraph
parameter of that function const, but that would be too intrusive as
that would require even more functions to accept a const depsgraph
pointer.
Made an explicit call to the exec function be a blocking call and a call
from invoke (or otherwise) be nonblocking.
Reviewed By: Bastien
Differential Revision: http://developer.blender.org/D7006
Both partial derivatives were evaluated to 0 for a special vertex on
Suzanne model: this is happening on a vertex where two adjacent faces
with 2 common edges are connected (in the nose of Suzanne).
This was breaking multires in this point since tangent matrix is all
zeroes, and hence no displacement can be applied in that vertex.
into account for duplicating actions
Previously actions remained linked after duplication, now this is based
on the User Preferences (PreferencesEdit.use_duplicate_action).
note: default is ON here, so this changes default behavior of separate
operators.
First intuition was to respect _all_ preferences here (e.g. also
duplicating materials if chosen in the User Preferences) but after
consideration this is probably not what the User would expect from such
'modeling' opertions (e.g. separate by loose parts resulting in possibly
many duplicate materials)
Fixes T71038
Maniphest Tasks: T71038
Differential Revision: https://developer.blender.org/D6120
Object Scale was not taken into account.
This lead to reports like T74247 where the user scaled the envelope
distance and radii to the supposedly right values inthe viewport, but
these were actually 'wrong' under the hood. Assigning weights from bone
envelopes seemed like it would fail, but this code would actually take
the armature scaling into account when checking envelope distance and
weight.
ref T74247
Maniphest Tasks: T74247
Differential Revision: https://developer.blender.org/D6964
Recent refactor external dependencies handling (D6642)
improperly linked all library dependencies with public
linkage rather than interface linkage. Causing excessive
(re)builds of subprojects when not needed.
This patch restores the interface linkage.
Reviewed By: brecht sergey
Differential Revision: https://developer.blender.org/D6983
This sampling pattern is particularly suited to adaptive sampling, and will
be used for that upcoming feature.
Based on "Progressive Multi-Jittered Sample Sequences" by Per Christensen,
Andrew Kensler and Charlie Kilpatrick.
Ref D4686
This patch refactors arrow keys navigation to move properties and enum
to generic ED_select_utils.h and property to
WM_operator_properties_select_walk_direction()
No functional change
Reviewed By: Julian Eisel
Differential Revision: https://developer.blender.org/D4771
gizmos are too big
Caused by rB9cac5fa681c5 which fixed the handles for the camera border
gizmo (being much too small)-- which in turn was broken by
rB98e4fbc7cc9e.
Camera border gizmo sets up its matrix_space a bit differently [this is
why we are getting very small values in gizmo_calc_rect_view_scale --
needs more investigation], but instead of breaking it for Light, Image
and Compositor Backdrop, lets just compensate by scaling the Camera
Border Gizmo for now.
Maniphest Tasks: T74278
Differential Revision: https://developer.blender.org/D6991
As explained in T65568 by @LucaRood, the self collision system should exclude triangles that are connected by sewing springs.
Differential Revision: https://developer.blender.org/D6911
Added check to see if the mesh has any polygons at all.
If there are no polygons, the bvh tree data will consist of null
pointers, so skip internal springs if this is the case.
When using Material Previews not all uniform blocks were filled. This
patch will add the renderpass_block when drawing the background.
Note that I wasn't able to reproduce the issue on my system, but
according the the backtrace it most likely solves the issue. I let the
reporter test.
Clay Thumb was using a custom hardness implementation and value to make
it functional. Hardness is now a property of brushes and it is
implemented for all brushes, so this is no longer needed.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6981
Color management currently happens after the python handlers. This means
that all common drawing operations needs to happen in SRS. The
PyGPUOffscreen requested that the color management was applied, that
resulted into applying colormanagement twice.
This patch makes sure that PyGPUOffscreen.draw_view3d renders in SRS.
There are more code paths that needs to be checked that the correct
space is being requested.
When beveling architectural objects like baseboards or crown mouldings that
may consist of multiple islands, it's useful if the orientation is at least
conistent.
This changes the arbitrary decision of how the orientation should start at a
chain beginning to use the highest side of the profile in the Z direction.
Reviewed By: howardt
Differential Revision: https://developer.blender.org/D6946
While animating sound strips volume within the graph editor, it is possible to set keyframes to negative values.
The drawing code of waveforms wasn't clamping these values to zero and was instead drawing an "inverted" curve
Author: a.monti
Reviewed By: iss
Differential Revision: https://developer.blender.org/D6971
The hardness property moves the brush falloff towards the edges, making
the brush sharper.
This should be the intended way to control the brush falloff instead of
tweaking the falloff curve manually, as it can be mapped to pressure to
make the falloff variable during the stroke.
It is also a good idea to show in the UI that the custom curves is an
advance features and it should almost never be modified when sculpting/
painting unless you want to create some advanced effects. By modifying
the curves freely it is really easy to break the brushes and make them
produce artifacts. This needs to be done in a later after merging the
pending projects to reorganize all the brush properties accordingly.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6902
At least a brush under each tool needs to exist by default in the blend
file to reset its properties. If it does not exist, the user needs to
reset it manually.
Reviewed By: brecht
Maniphest Tasks: T74307
Differential Revision: https://developer.blender.org/D6972
When sculpting on multi user data normals needs to be recalculated to
avoid artifacts. I refactored that line to make it more readable.
Reviewed By: brecht
Maniphest Tasks: T73707
Differential Revision: https://developer.blender.org/D6957
When processing a timer event WM_event_tablet_data returns 0 instead of
the last valid pressure value from the tablet. This always stores the
last pressure value and uses it in case a timer event is being
processed.
Reviewed By: brecht
Maniphest Tasks: T74074
Differential Revision: https://developer.blender.org/D6950
This includes the following changes:
- Use always the angle stored in the StrokeCache when deforming
- Interpolate between the previous and the new sampled angles
- Calculate the cursor matrix only on the 0 radial symmetry iteration
Reviewed By: brecht
Maniphest Tasks: T73947
Differential Revision: https://developer.blender.org/D6901
Now only the hue is different between different strip types, with the
saturation the same for all.
Differential Revision: https://developer.blender.org/D6775
The 'random' unit tests and some examples from the new boolean code
triggered asserts and crashes. This fixes those.
There is a new flag in the input that optionally disables a pass
over input to snap segment edges to other segments.
Removing the 'Large Cursors' option as it is no longer applicable or useful on any platform.
Differential Revision: https://developer.blender.org/D6958
Reviewed by Brecht Van Lommel
This brush has a simple physics solver that helps when sculpting cloth.
- The mass and the damping properties of the simulation are properties of the brush.
- It has two additional radius control to limit the influence and falloff of the simulation.
- Masked vertices are pinned in the simulation, and it applies the sculpt gravity directly in the solver.
- The Cloth Brush has 7 deformation modes with 2 falloff types (radial and plane).
The brush can create the constraints only on the required PBVH nodes, so the simulation is isolated on high poly meshes. As long
as the brush size is not too big it should be possible to keep it real time.
Known issues:
- The way constraints are created is extremely basic and it creates repeated constraints. Maybe there is another way to create fewer constraints while keeping the simulation quality decent. This part can also be multithreaded. (As it is it works ok, but it could be better)
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6715
The coordinates should be read from the PBVH when using deform modifiers.
This is needed for the cloth brush to work with subdivisions, as it reads the
vertex coordinates using this function when building and updating the
constraints.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6967
Updates include:
- std::move() cleanup in rcmatrix.h
- Enabled parallelization for fluid guiding (fairly noticeable speed improvement).
- More flexible flags setter function with control over boundary width.
This fixes denoising being delayed until after all rendering has finished. Instead, tile-based
denoising is now part of the "RENDER" task again, so that it is all in one task and does not
cause issues with dedicated task pools where tasks are serialized.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6940
This makes the memory allocation for the denoiser state use the memory allocator in Cycles, which
will evict textures to host memory when there is not enough space on the device. This means the
allocation for the denoiser state won't just fail if there is no more space and instead more space is
made for it to work. Also simplifies code somewhat.
Fix for fix (rB8bf7ca9fe31c).
The fix was not actually working [neither for multi-armature-editing as
intended nor for single armatures] and it broke single-armature bone
separation completely.
More or less indentation issue, move relevant code out of bone loop, do
after all bones have been checked, guess this was intended anyways.
Differential Revision: https://developer.blender.org/D6949
Use BASE_VISIBLE_VIEWLAYER (rather than BASE_VISIBLE_DEPSGRAPH -- which
is not including the 'Hide in Viewport')
Note: the is one case where this still 'fails':
- 'Show only Hidden' plus excluding the parent collection (would be nice
to show those -- but contents of excluded excluded collections dont get
show in any case... this would be more work and for another report...)
Maniphest Tasks: T71611
Differential Revision: https://developer.blender.org/D6953
Useful for cases when topology does not need to have any
crease or UV layers. Now instead of assigning callbacks
which returns zero data is possible to simply assign the
callback itself to NULL.
This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
This previously caused a bug in T74283, that should be fixed now.
Differential Revision: https://developer.blender.org/D6695
This reverts commit f2b95b9eae.
Fix T74283: modifier display lost when moving object in edit mode.
The cause is not immediately obvious so better to revert and look at this
carefully.
Under the special circumstance of double clicking and then opening a
panel with sub-panels again, the parent panel's offset in y-direction
was added twice to the child panels: once inside "get_panel_real_ofsy"
and once within "align_sub_panels".
This introduced a visible glitch.
Reviewed by: Julian Eisel
Differential Revision: https://developer.blender.org/D6942
Was affecting quad faces. where 0 was always passed for inner
loops and a wrong one for boundary ones.
In the current code this change shouldn't cause any difference
since the corner index is ignored in the actual callback, but
it is required to have his fixed for an upcoming changes.
There are still some issues left after the changes in master:
* Some optimizations need to be redone differently
* Color-space handling needs to be redone differently
* Upside-down drawing is broken
Some points on the OpenXR-SDK dependency:
* The repository is located at https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* We use the OpenXR loader lib from it, the headers, and some CMake utilities.
* It contains a bunch of generated files, for which the sources are in a separate repository.
* To use the injected OpenXR API-layers from the SDK (e.g. API validation layers), the SDK needs to be compiled from this other repository.
* We could use that other repo by default, but I'd rather go with the simpler solution and allow people to opt in if they want advanced dev features.
* For Windows a patch is needed to link the CRT in a compatible way.
All this is entirely untested on macOS.
Maniphest Tasks: T71365
Differential Revision: https://developer.blender.org/D6188
Changes for the higher level, more Blender specific side of the implementation.
Main additions:
* WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data
* wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU context)
* DNA/RNA for initial management of VR session settings
* Utility batch & config file for using the Oculus runtime (Windows only)
Differential Revision: https://developer.blender.org/D6193
## Design Overview
* For code using this API, the most important object is a GHOST_XrContext handle. Through it, all API functions and internal state can be accessed/modified.
* Main responsibilities of the Ghost XR-context are to manage lifetimes of the OpenXR runtime connection (represented by XrInstance), the session and to delegate operations/data to the session.
* The OpenXR related graphics code, which is OS dependent, is managed through a `GHOST_IXrGraphicsBinding` interface, that can be implemented for the different graphics libraries supported (currently OpenGL and DirectX).
* Much of this code here has to follow the OpenXR specification and is based on the OpenXR [[https://github.com/KhronosGroup/OpenXR-SDK-Source/tree/master/src/tests/hello_xr | `hello_xr`]] implentation.
* In future we may want to take some code out of the context, e.g. extension and API layer management.
* There are runtime debugging and benchmarking options (exposed through --debug-xr and --debug-xr-time, but not as part of this patch).
* Error handling is described in a section below.
## Why have this in Ghost?
Early on, I decided to do the OpenXR level access through GHOST. Main reasons:
* OpenXR requires access to low level, OS dependent graphics lib data (e.g. see [[https://www.khronos.org/registry/OpenXR/specs/0.90/man/html/openxr.html#XrGraphicsBindingOpenGLXlibKHR| XrGraphicsBindingOpenGLXlibKHR]])
* Some C++ features appeared handy (`std::vector`, RAII + exception handling, cleaner code through object methods, etc.)
* General low level nature of the OpenXR API
After all I think much of the functionality is too high level to live in GHOST however. I would like to address this by having a separate `VAMR` (virtual + augmented + mixed reality) module, placed in `intern/`. The main issue is getting this to work well with Ghost data, especially how to get the mentioned low level data out of Ghost.
This is something I'd like to look into again before too long, but for now I think having this in Ghost is reasonable.
## Error Handling Strategy
The error handling strategy I chose uses C++ exceptions, a controversial feature. Let me explain why I think this is reasonable here.
The strategy requirements were:
* If an error occurs, cleanly exit the VR session (or destroy the entire context), causing no resource leaks or side effects to the rest of Blender.
* Show a *useful* error message to the user.
* Don't impair readability of code too much with error handling.
Here's why I chose an exception based strategy:
* Most alternatives require early exiting functions. This early exiting has to be 'bubbled up' the call stack to the point that performs error handling. For safe code, early exit checks have to be performed everywhere and code gets really impaired by error checking. Tried this first and wasn't happy at all. Even if error handling is wrapped into macros.
* All `GHOST_Xr` resources are managed via RAII. So stack unwinding will cause them to be released cleanly whenever an exception is thrown.
* `GHOST_Xr` has a clear boundary (the Ghost C-API) with only a handful of public functions. That is the only place we need to have try-catch blocks at. (Generally, try-catch blocks at kinda random places are a bad code smell IMHO. Module boundaries are a valid place to put them.)
* Exceptions allow us to pass multiple bits of error information through mulitple layers of the call stack. This information can also be made specific with a useful error message. As of now, they conain a user error message, the OpenXR error code (if any), as well as the exact source code location the error was caught at.
So the strategy I went with works as follows:
* If a VR related error occurs within `GHOST_Xr`, throw an exception (`GHOST_XrException` currently).
* OpenXR calls are wrapped into a macro throwing an exception if the return value indicates an error.
* Useful debugging information and user messages are stored in the exceptions.
* All resources must be managed through RAII, so throwing an exception will release 'dangling' ones cleanly.
* In the GHOST C-API wrappers, the exceptions are caught and contained error information is forwarded to a custom error handling callback.
* The error handling callback is set in `wm_xr.c`, prior to creating the XR-Context, and implements clean destruction of the context.
Differential Revision: https://developer.blender.org/D6192
Needed for DirectX-only OpenXR runtimes (e.g. Windows Mixed Reality).
Adds a minimal DirectX 11 Ghost context, plus some shared DirectX-OpenGL resource interface using the NV_DX_interop2 WGL extension.
I know that the current implementation fails on some systems, which is something I'll have to fix at some point. Don't know if this is a showstopper though, I can fix that in master too. For now this isn't going to be used by many people anyway. Recently I also learned that OSVR uses the same extension, see https://github.com/sensics/OSVR-RenderManager/blob/master/osvr/RenderKit/RenderManagerD3DOpenGL.cpp. Their implementation may be useful to fix the issue, according to a OSVR dev, it works quite reliably for them.
Note: Didn't actually test just this patch on Windows yet.
Differential Revision: https://developer.blender.org/D6190
Some points on the OpenXR-SDK dependency:
* The repository is located at https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* We use the OpenXR loader lib from it, the headers, and some CMake utilities.
* It contains a bunch of generated files, for which the sources are in a separate repository.
* To use the injected OpenXR API-layers from the SDK (e.g. API validation layers), the SDK needs to be compiled from this other repository.
* We could use that other repo by default, but I'd rather go with the simpler solution and allow people to opt in if they want advanced dev features.
* I copied `presentation.cmake` and `xr_platform_defines.cmake` from the SDK. They contain logic that is not needed for us and prints at CMake generation. We could change that but figured it would also be helpful to keep the files equal to the SDK ones.
* For Windows a patch is needed to link the CRT in a compatible way.
* @LazyDodo already pushed the precompiled binaries for Windows.
All this is entirely untested on macOS.
Differential Revision: https://developer.blender.org/D6188
Just like the Windows Mixed Reality runtime, we have to apply a sRGB
OETF to get visually correct-ish looking colors.
We plan to further investigate if it's really WMR and Monado being wrong
here, or if it's Oculus (which doesn't need this additional transform),
but there are some details to check.
Reduces code duplication for the DirectX specific upside down drawing.
Didn't actually test the upside down drawing, since I need to do that on
Windows.
* Adds the needed bits to support VR session settings and access them in
the VR view drawing code.
* Added settings for: shading mode, grid floor, annotations, clipping.
More can easily be added.
* The Add-on adds a "VR" tab in the side bar, containing buttons for the
added settings
This fixes linking errors with the Monado runtime. The specification
says that extension functions have to be gotten through
`xrGetInstanceProcAddr()` which we did for some extensions, but not for
the graphics extensions. Worked fine earlier, but broke meanwhile.
Code now assumes that the view-draw callback left the OpenGL state for
ongoing use by Ghost-XR. So the state doesn't have to be set by the
swapchain image submission and thus it we don't need to pass the Ghost
OpenGL context to it in a hacky way.
Also, rename drawViewEnd (to submitToSwapchain) and remove
drawViewBegin.
These were previously used to blit from a offscreen (non-OpenGL)
context, into an onscreen one. We do this differently, and only within
GHOST_XrGraphicsBinding now, so this can be removed.
Rather than max. one shared resource per DirectX context, code can now
request a handle for a shared resource and ask the DirectX context to do
operations on that.
There were a few typos here and there, and the openxr_sdk does not respect the cflags we give it hence a patch was added to work around this undesirable behaviour.
Adds the SDK so that `make deps` works, on all platforms. On Windows,
the SDK headers and libraries are now assumed to be in the usual lib\
directory.
Also fixes a mistake in install_deps.sh
Note that none of this is tested as it requires an older Visual Studio
version than I have.
Removes the OPENXR_USE_BUNDLED_SRC option which allowed using the
OpenXR-SDK sources bundled in extern/. It would be too much hassle to
keept these updated.
Now these have to be provided on the system Blender is compiled on. I've
already added necessary bits to install_deps.sh and our Windows
maintainer is ready to provide builds with OpenXR-SDK linked.
Once this gets into master, platform maintainers will have to be
notified about the added dependency.
This also removes the JsonCpp dependency, it was only needed for the
OpenXR-SDK sources.
Discussed this in length with @sobotka, and it seems WMR has an utterly
broken pixel color pipeline. So we apply a SRGB OETF for this specific
runtime to compensate.
Only tested on Windows.
Updates loader sources from the OpenXR SDK to latest 1.0 SDK and updates
requiremed version to 1.0. The compile time generation of files is a
thing of the past now (although you can still force it).
1.0 got released yesterday. Only one line needed fixing in our OpenXR
code to get it to compile. Rendering is black though.
For now I tried to keep edits to CMakeList.txt files minimal. So now
there are OpenXR CMake options exposed (with bad names), CMake prints,
etc.
This way we avoid the big overhead of context switches. Makes frames
render about twice as fast here. For heavy Spring scenes I'm getting
around 20 FPS here, classroom scene is at 50 FPS.
This is great given that drawing itself still isn't optimized for dual
eye rendering.
Outputs frame render time in milliseconds and FPS this time would add up
to. We could average times so FPS is a bit more stable, but the
precision of un-averaged results may be helpful too.
I'm not really sure why the leak happened - draw manager kept allocating
certain buffers - but I figured I could avoid it by not recreating
GPU_offscreen/GPU_viewport on every redraw.
This should also improve performance a bit.
Adds generic unique_oxr_ptr to wrap xrCreate and xrDestroy functions of
OpenXR handles into a unique_ptr like RAII interface.
While for most cases, OpenXR resources can be freed by their owning
object, sometimes errors may occor before final ownership is established.
E.g. swapchain ownership is only transfered to the session object once
its swapchain-images are created - which may fail. With this RAII
wrapper, the swapchain would be freed on error (as this triggers stack
unwinding through an exception), no matter who holds ownership to it
currently.
There are other solutions to this problem, e.g. by establishing final
ownership right after/upon creation, or by explicit freeing in case an
error is spotted; it's too easy to make mistakes here though. Plus, we
may want to experiment with using this API for all OpenXR resources, to
entirely avoid the possibility of them leaking.
Fixes:
* Destruct surface when destroying session on error. Fixes null pointer
dereference when trying to draw the surface on next redraw.
* Fix trying to enable same extensions/API-layers multiple times due to
static array usage not being cleared after error.
* Null pointer dereference with OpenGL drawing
E.g. with an active OpenXR runtime installed, but no HMD plugged in,
Blender will now show: "Failed to get device information. Is a device
plugged in?".
In case of such errors, the VR-session will be cleanly exited, with
no side effects to the rest of Blender (at least if there are no bugs).
The GHOST_Xr API now allows setting a custom error handling callback
which may cleanly destroy all GHOST_Xr data.
This wraps all functions that could fail into some proper (although
unfinished) error handling.
These were the requirements for the error handling strategy:
* If an error occurs, cleanly exit the VR session (or the context if the
error happend during its set up), causing no resource leaks or side
effects to the rest of Blender.
* Show a *useful* error message to the user.
* Don't impair readability of code too much with error handling.
After some back and forth I decided Ghost internal exceptions are the
best way to go about this. I get exceptions are a controversial feature,
IMHO that's because most people use them 'wrong' however. Here's the
rationale:
* Most alternatives require early exiting functions. This early exiting
has to be 'bubbled up' the call stack to the point that performs error
handling. So the code gets really impaired by error checking. Tried
this first and wasn't happy with it at all. Even if error handling is
wrapped into macros.
* All GHOST_Xr resources are managed via RAII. So stack unwinding will
cause them to be released cleanly whenever an exception is thrown.
* GHOST_Xr has a clear boundary (the Ghost C-API) with only a handful of
public functions. That is the only place we need to have try-catch
blocks at.
(Generally, try-catch blocks at kinda random places are a bad code
smell IMHO. Module boundaries are a valid place to put them.)
* Exceptions allow us to pass multiple bits of error information through
mulitple layers of the call stack. This information can also be made
specific with a useful error message.
As of now, they conain a user error message, the OpenXR error code (if
any), as well as the exact source code location the error was caught
at.
So if an error is caught inside GHOST_Xr code, an exception is thrown
with specific and hopefully useful information in it. In the Ghost C-API,
these exceptions are caught and passed on to a custom error handling
callback. This callback will be defined by the Blender window-manager
and output the error information via a usual user report popup (not done
yet). It can also ensure the entire session is shut down.
Note that the majority of errors OpenXR can return are for invalid API
usage. Assuming the API usage is valid though, most error messages
should never reach users and can be left a bit more vague. Maybe we can
add something like "This is probably a bug and should be reported" to
those.
Unfortunately, enabling XR_EXT_debug_utils crashes instance creation
with the Windows Mixed Reality runtime. Maybe I'm doing something wrong,
for now, just disable it.
* Initialize all class member variables
* Add version to runtime name printing
* Separate functionality code from debug prints
* Improve code structure using Doxygen groups
* Make accessors const functions
* Add (Doxygen) comments
* Naming
* Reorder functions
Makes GHOST_Xr much more consistent with the rest of GHOST. Basically I
added a GHOST_IXrContext interface which can be called by the GHOST
C-API. The internal GHOST_XrContext class implements this.
Outside of GHOST only the opaque GHOST_XrContextHandle is accessible.
Kept GHOST_Xr_intern.h and GHOST_Xr.cpp for now. I'll probably remove
them soon. There's not much reason for both of them to be there.
Enables (or tries to) the XR_EXT_debug_utils extension which allows
setting a custom callback for additional debug prints. Note that I
haven't been able to test this really, as the Monado runtime appears to
not have this fully implemented (had to force sending a custom message
to find that out...). Will test with the Windows MR runtime in a bit. We
can also improve message quality then (it can print the exact function
name the message was sent from, print additional custom labels which
could indicate session state, etc.).
For this to work two environment variables have to be set:
XR_API_LAYER_PATH and LD_LIBRARY_PATH, both have to point to the API
layers built by the OpenXR SDK. It also requires you compile Blender
linked to your own SDK build (OPENXR_USE_BUNDLED_SRC disabled).
Further changes will make this set up unnecessary, so validation layers
can be enabled via some flag.
I was trying to set the camera pose as OpenXR reference pose. But then I
got really strange poses for drawing back from OpenXR. Couldn't figure
out a way to solve this.
Now we just apply OpenXR's draw pose to the Blender camera pose. If we
later want to support moving around in the scene (e.g. via teleporting),
that has to be changed.
Also uses flipped drawing for DirectX surface to correct DirectX upside
down drawing (compared to OpenGL).
Session code and data structures are now localized. But also, this
enables sessions to use deterministic destruction to end itself cleanly.
So whenever an error occurs, we can use stack unwinding which will cause
graceful ending of the session.
* Move GHOST_Xr types to GHOST_Types.h
* Add GHOST_XrPose. We'll have to pass around pose data at multiple
places.
* Don't require extra call to prepare session rendering, handle
everything through GHOST_XrSessionStart
* Naming
Finally: This makes it possible to render a viewport to an HMD via
OpenXR. Pure OpenGL rendering will need some more tweaks to work.
To my great delight, performance is quite good for reasonably sized
scenes.
Had to do some hacks and marked some TODOs. Nothing too bad though.
Here are a couple of notes:
* Current initial pose is pretty useless, think it just looks downwards
from world origin. Will change that soon.
* The rendered viewport has some issues: Too dark (bad lighting?), grid
doesn't show up even though I told it to, lighting seems to change with
view position/rotation, etc. Needs some polish.
* Ideally we'd just use the D3D11 Texture given to us via the OpenXR
swapchain and blit the OpenGL framebuffer into that. However the
NV_DX_interop extension fails doing this. Seems like this is a NVidia
Optimus only issue, but I'm missing the hardware to confirm.
So instead, we blit into the D3D11 back buffer first and then into the
Texture.
* The draw-manager uses its own offscreen context so we have to get the
render result from the draw-manager context to the VR session's
context first. Luckily I've already added code to support blitting from
one OpenGL context into another. But it requires blitting twice.
Blitting should be very cheap, but still...
Draw-manager could get a context to use passed instead.
Not visible yet, but it should draw in the offscreen. The way this is
now, we don't depend on the Window->Workspace->bScreen->... chain. We
simply draw an offscreen viewport in the draw callback of the XR session
surface.
The drawing also uses view and projection matrices from OpenXR (or
calculated from OpenXR data).
Uses the new wmSurface type (non-window drawable container) to manage
the OpenGL, DirectX and GPU module contexts. The draw callback of the XR
surface calls the GHOST_Xr session drawing routines.
What you should see when starting a VR session now (using the WMR
runtime): The Windows Mixed Reality Portal pops up, and a blue
background is drawn on the HMD. This is from the blue color clear call
we do in the drawing preparations of the GHOST_Xr session drawing.
Adds a wmSurface type which acts as a container for non-Window (offscreen)
draw surfaces. Ideally wmWindow would of course also just do C-style
inheritance from wmSurface, but I guess they can co-exist too.
For the VR session a surface is created on Linux and passed to the
graphics binding to use.
Note this is not used on Windows yet, it still opens a window there.
* Allow passing custom data to session draw function, passed to the
callback
* Actually call the callback
* Create and bind a WM level callback. Will later be used to draw the
viewport.
Also, check if session is actually visible before drawing.
Just a clear call for now, so all you see is a blue world. This blue
"world" is however drawn by Blender!
Also fixes use after destruction of compositor layer data.
Using a dummy identity pose at {0, 0, 0} to start with. This should
later use the current viewport position & orientation I guess.
Also adds function to set a draw callback. There's quite some OpenXR
related stuff to be done before and after drawing anyting, as well as
before and after drawing each view (eye). Quite some info would have to
be exposed to WM to let it manage drawing. So I think using a callback
called from GHOST_Xr to draw each eye instead is a good way to go.
VR session currently crashes after opening. Seems to be related to
blocking frame wait call. I'm not too worried about that though, might
disappear once OpenXR frame sync functions get proper timing info
passed.
Following the OpenXR SDK's example code very closely here. We have to do
some nasty converting of graphics binding specific image vectors to
generalized base ones. The SDK's approach seems like a good way to go
about this.
With this, the Windows Mixed Reality Portal finally pops up when
starting the session. That is how it's supposed to work. After it's
initialization phase all you see is black. That's expected too as we
don't send anything to the device yet.
Nothing special to say. Just calls needed OpenXR functions to create
swapchains. Swapchain images are not created yet.
Interestingly, the Windows Mixed Realtiy portal now pops up when closing
Blender after having created a VR session. So we're getting closer ;)
Monado now opens a window here when asking it to start a session. That
seems to be the case because it doesn't detect the HMD as direct mode
capable yet. But that shouldn't be an issue from our side.
Refactors function into a class, and make this class a friend of
GHOST_ContextGLX. That seems like a better way to access low level
graphics data for this specific case, rather than giving anyone access
via a getter.
Creating the context causes the OpenXR loader to try connect to a
runtime. That would involve reading the OS'es active_runtime.json and
dynamic linking based on that. So better avoid doing this on startup.
Also: don't pay for what you don't use!
DirectX is Y coordinates top to bottom, while OpenGL is the opposite.
For the final window manager on-screen drawing, draw to a texture first
and draw that upside down if needed.
Phew! That a fight. But this is also a pretty important feature as it
allows interfacing with Windows Mixed Reality OpenXR runtime and the
HMDs supported by it.
Important remaining issue: The rendered viewport is upside down :) That
is of course because DirectX has the opposite vertical direction than
OpenGL.
When creating a DirectX window, we also create an OpenGL offscreen
context to use for all drawing. Just before swapping framebuffers, the
DirectX window blits the framebuffer of the offscreen context into its
swapchain. This requires the WGL_NV_DX_interop and WGL_NV_DX_interop2
extensions.
For testing/dev purposes, also adds:
* Version of the offscreen to onscreen blitting that's OpenGL only. So
it blits the default framebuffer of the offscreen context into the one
of the onscreen context.
This is disabled by a #define.
* Code to draw a colored triangle using DirectX, also for testing.
Requires the D3DCompiler.lib to be available at compile time. This is
also disabled using a #define.
With this the VR window should open fine and get cleared in a red-ish
orange using Direct3D 11 calls (well, on Windows that is).
The window still draws a 3D view to an offscreen buffer. Where we
usually just swap the buffers, we now allow calling a GHOST function to
blit the offscreen OpenGL buffer to whatever type of graphics buffer the
window uses (DirectX here).
The nice thing about this approach is that all DirectX code stays in
GHOST_ContextD3D.cpp. And the entire compatibiliy code can go into a
single function higher level modules don't need to care about.
This also fixes a number of issues introduced in earlier commits.
The window doesn't show anything of course. However we draw (at least I
assume it does) as regular, just into a window offscreen context.
A valid 3D view is created in the window. It's not visible but you see
cursor changes as you move over the window. So handling works.
The window immediately crashes, hence keeping it disabled for now.
Not sure how much of this I'll leave in, for now this is mainly for
testing DirectX compatibility.
* Retrieve graphics context to bind through callbacks so the XR code can
manage their lifetime.
* Use static union to store system & chosen graphics lib specific
graphics binding data.
Makes some things a bit cleaner, too.
Adds support for creating a DirectX 11 Ghost context. It's not used yet
and more stuff besides creation is needed. Also, other versions than 11
should probably be supported.
We need a DirectX context to support the Windows Mixed Reality OpenXR
Runtime, a rather important one to support. Idea is to use an extension
for OpenGL-DirectX interoperability for drawing the OpenGL offscreen
viewport render using DirectX.
Similar to gizmo/ and message_bus/, there's now a xr/ directory
containing header files and a intern/ directory for source and internal
header files.
Guess this is reasonable to do. And better to do early on to avoid
loosing much git history.
OpenXR needs to interface with some graphics library (OpenGL, Vulkan,
DirectX, etc.). This is done through graphics binding extensions. The
OpenXR specification requires these to be properly set up before a
session is created.
Adds the following:
* Support priority list of multiple graphics binding extensions (e.g.
check OpenGL extension availability first, DirectX on Windows second,
etc.)
* Barebones for passing graphics library data to OpenXR session
creation. This is highly system dependent, e.g. it requires GLX data
for OpenGL on X11 systems (XrGraphicsBindingOpenGLXlibKHR). More work,
including additions to GHOST, will be needed once I get to the more
graphics related stuff.
* Create an own graphics context for the VR session. It's not doing
anything useful yet. This is just to fool the Monado OpenXR runtime
so that it actually attempts to create the OpenXR session.
* Had to add two CMake modules for platform dependent #define's required
by the OpenXR specification.
To correctly start a session, a graphics extension specific object needs
to be passed to the OpenXR runtime. E.g. for the Windows Mixed Reality
runtime, XrGraphicsBindingD3D11KHR needs to be passed with a valid
DirectX device. Since we don't have any DirectX compatibility working,
I can't test this on Windows yet.
So to test this I finally need to get Monado to work on Linux and
correctly setup the OpenGL extension there.
Adds operator to toggle a VR session, exposed in the Window top-bar
menu. It triggers the needed calls for session creation and destruction.
Setting up the XR-system (a configuration of related devices) is also
done now.
Calling WMR runtime functions fails currently. Not sure why. So while
this executes required routines, it doesn't really work.
We don't actually enable any extension or layer yet. We just put their
names into arrays and print them. The printing can be disabled via a
compiler define, later we should put them behind a proper
logging/debugging mechanism (CLOG).
Also fixes a Visual Studio compile error.
Adds wm_xr.c for an XR management API and creates/destroys the OpenXR
instance through this. This is as planned in my proposal, to lock the
OpenXR calls behind an abstraction.
XR data will be stored in a (non-public) wmXRContext struct within the
window-manager.
For now, creates the OpenXR instance on startup. I think it's better to
lazy setup this, as in, only creating the instance once the user starts
the first XR session. Just to avoid costs for something that may not be
used (the OpenXR loader we use will try loading and parsing the system's
OpenXR active_runtime.json on instance creation). That's for later when
I introduce session management though.
Also added a context getter for the xr-context, which is unused but may
be handy later.
Adds OPENXR_USE_BUNDLED_SRC so that if disabled, CMake tries to find
the SDK headers and libraries in system paths or in specified root
directory.
I guess this is the way we'd want to do this in master. However for
people testing the branch the bundled sources are much more convenient
(should work out of the box, no need to compile the SDK manually).
Calling OpenXR functions should now work on both Windows and Linux.
Also includes:
* Silence Linux only warnings
* Remove common_cmake_config.h and let CMake generate it when
configuring (contents vary on system it's compiled on)
* Remove JsonCpp CMake install target
* Remove unnecessary CMakeLists for JsonCpp includes
* Remove unnecessary CMake commands
* Style cleanup
Adds needed headers for OpenXR, the loader from the OpenXR SDK and
JsonCpp into extern. Took a while to get this to compile/link, but on
Win10 it works fine now without patching #includes. Linux probably
needs more work.
Added a compile option WITH_OPENXR to toggle XR feature compiling.
Also does a dummy xrCreateInstance() call to test linking.
2019-05-28 01:21:25 +02:00
2102 changed files with 84422 additions and 90267 deletions
('SOBOL',"Sobol","Use Sobol random sampling pattern"),
('CORRELATED_MUTI_JITTER',"Correlated Multi-Jitter","Use Correlated Multi-Jitter random sampling pattern"),
('PROGRESSIVE_MUTI_JITTER',"Progressive Multi-Jitter","Use Progressive Multi-Jitter random sampling pattern"),
)
enum_integrator=(
@@ -349,6 +350,26 @@ class CyclesRenderSettings(bpy.types.PropertyGroup):
default=0.01,
)
use_adaptive_sampling:BoolProperty(
name="Use Adaptive Sampling",
description="Automatically reduce the number of samples per pixel based on estimated noise level",
default=False,
)
adaptive_threshold:FloatProperty(
name="Adaptive Sampling Threshold",
description="Noise level step to stop sampling at, lower values reduce noise the cost of render time. Zero for automatic setting based on number of AA samples",
min=0.0,max=1.0,
default=0.0,
precision=4,
)
adaptive_min_samples:IntProperty(
name="Adaptive Min Samples",
description="Minimum AA samples for adaptive sampling, to discover noisy features before stopping sampling. Zero for automatic setting based on number of AA samples",
min=0,max=4096,
default=0,
)
min_light_bounces:IntProperty(
name="Min Light Bounces",
description="Minimum number of light bounces. Setting this higher reduces noise in the first bounces, "
@@ -1297,7 +1318,12 @@ class CyclesRenderLayerSettings(bpy.types.PropertyGroup):
default=False,
update=update_render_passes,
)
pass_debug_sample_count:BoolProperty(
name="Debug Sample Count",
description="Number of samples/camera rays per pixel",
default=False,
update=update_render_passes,
)
use_pass_volume_direct:BoolProperty(
name="Volume Direct",
description="Deliver direct volumetric scattering pass",
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.
