Blender crashes if the compositor runs from the render pipeline while
the node tree is being drawn. That's because the render pipeline
adjusting the original node tree by calling ntreeCompositTagRender from
a different thread during compositor evaluation, which is unsafe while
the node tree is being drawn on the main thread.
ntreeCompositTagRender seems to update Composite and Texture nodes, but
they don't have update function, so it seems to do nothing in those
cases. It also updates nodes that reference the scene, like the Render
Layers and Cryptomatte nodes, but this seems to be already done in other
places like do_render_compositor_scenes and ntreeCompositUpdateRLayers.
Furthermore, in one of the calls in the render pipeline, it does raw
pointer comparison with the evaluated scene, so the comparison fails and
it does nothing.
Considering the above, it seems this can be omitted from the render
pipeline code.
Pull Request: https://projects.blender.org/blender/blender/pulls/138087
The GHOST_DisplayManager and its implementations are for the most part
unmaintained and almost completely unused in all backends. To clean
things up, and avoid any confusion about how displays are handled in
each respective GHOST backend, this PR completely removes the GHOST
Display Manager, and move the few remaining logic it still held directly
to the corresponding backends.
The backends that were modified (apart from removing the display manager
initialization call from their init) are:
- Win32: `GHOST_SystemWin32::getNumDisplays()` was calling
`m_displayManager->getNumDisplays`, the underlying system metric call
(`GetSystemMetrics(SM_CMONITORS)`) was substituted in place.
- SDL: `GHOST_SystemSDL::createWindow` was calling
`GHOST_DisplayManagerSDL::getCurrentDisplayModeSDL` which returned its
`m_mode` data member by reference. Since none of the
`GHOST_DisplayManagerSDL` member function that modified this data member
were ever called, the variable `memset` initialization call was
substituted in place from the `DisplayManagerSDL` constructor
Pull Request: https://projects.blender.org/blender/blender/pulls/138066
The issue here is that the automatic bump shader in OSL adjusts globals.N,
which is used to define each closure's shading normal, but sd->N remains
as it was (unlike SVM, which sets it from svm_node_set_normal).
This is a problem since some code like the shadow terminator stuff uses sd->N,
so to make behavior consistent the fix is to set it from OSL as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/138092
When allocating a large vertex buffer on NVIDIA it tried to allocate it
on the GPU and host visible. This section is limited in size (256MB).
However when allocating a large vertex buffer it should not have been
chosen.
Detected during investigation of #137909.
It removes the validation error, but it is unclear yet if this solves the'
crash as I wasn't able to reproduce the crash.
Pull Request: https://projects.blender.org/blender/blender/pulls/138079
This PR adds a separate "Grease Pencil" render pass. Once
the "Grease Pencil" option is checked in the passes list, the
Grease Pencil engine will render to a new render pass for various
composition uses.
Notes:
- Occluded Grease Pencil geometry is not rendered.
- In most cases, using an "Alpha Over" with the rest will result
in the same render as the "Combined" output. The exception is
when there are Grease Pencil layers that use a blending mode
that changes the chromaticity of the alpha channel.
Pull Request: https://projects.blender.org/blender/blender/pulls/137638
On the one hand, this improves initialization time since we don't need to
load/compile the full OSL module with all the shading logic if we're only
using a custom camera with SVM shading.
On the other hand, it also fixes a bug I noticed while preparing test scenes:
The AO and Bevel nodes don't work when using custom cameras with SVM on OptiX.
The issue there is that those two are handled by the SHADE_SURFACE_RAYTRACE
kernel, but since that one has intersection logic, we use the OptiX-specific
kernel even if OSL shading is disabled.
However, with the previous unified OSL module, this would mean loading
SHADE_SURFACE_RAYTRACE from kernel_osl.cu, which has `#undef __SVM__` and
therefore doesn't handle them correctly.
With this change, we'll use the kernels from kernel_shader_raytrace.cu in that
case, which do support SVM nodes just fine.
Disk usage of the new kernel_optix_osl_camera.ptx.zst file is 30KB, so this
also doesn't blow up the kernel disk size (and kernel_optix_osl.ptx.zst is
probably smaller by that amount now).
Since it seems that we can mix modules just fine, I'm suspecting that we could
split the modules properly (intersection, SVM shading with raytracing,
OSL shading, OSL camera), instead of the current approach where modules
essentially correspond to feature set tiers and each includes the previous
one's kernels as well - but that's a separate refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/138021
osl_transform_triple(), osl_transform_dvmdv() and so on are supposed to apply
the given transform in the context of OSL's auto-differentiation system.
Therefore, the given input is a dual vector, containing both the value as v[0]
and its derivatives w.r.t. X and Y in v[1] and v[2].
However, the existing code treats these as a simple list of vectors, applying
the same operation to all three instead of propagating the derivatives.
On top of that, it also treated the given matrix input as if there were three
of them, which isn't the case.
Therefore, this commit replaces the implementation to do the right thing.
The Vector and Normal case are straightforward since the operation is linear,
so applying the same operation to all three vectors works.
The Point case is a bit more complicated, but not too bad when written out.
This bug mostly became apparent when using Object or Camera texture coordinates
with a Bump node, since that node uses OSL differentials and Object/Camera
coordinates are implemented using transform().
I'm pretty sure that all the other builtin functions (e.g. sin) at the bottom
of services_gpu.h have the same problem, but one thing at a time...
Pull Request: https://projects.blender.org/blender/blender/pulls/138045
Blender crashes when rendering a scene that has a file output node with
no inputs. That's because the preview code assumes that nodes would
always have inputs. So we simply guard against this case.
Numpad * is being used for grease pencil object to isolate active layer
while inside edit/paint mode and mouse is over viewport. This PR
includes same keyitem into dopesheet keymap, so that shortcut
can be used in dopesheet editor context.
Pull Request: https://projects.blender.org/blender/blender/pulls/132054
* Add GraphicsInteropDevice to check if interop is possible with device
* Rename GraphcisInterop to GraphicsInteropBuffer
* Include display device type and memory size in GraphicsInteropBuffer
* Unnest graphics interop class to make forward declarations possible
Pull Request: https://projects.blender.org/blender/blender/pulls/137363
* Pixel buffer is always allocated with export and dedicated memory flags.
* Returns an opaque file descriptor (Unix) or handle (Windows).
* Native handle now includes memory size as it may be slightly bigger
than the requested size.
Pull Request: https://projects.blender.org/blender/blender/pulls/137363
This PR adds Grease Pencil type filter in the view layer, so users can
control whether Grease Pencil objects should be rendered or not. When
the option is turned off, Grease Pencil rendering is skipped.
Pull Request: https://projects.blender.org/blender/blender/pulls/137667
In American English, this would be a long dash (called an em dash),
not a short dash/hyphen (called an en dash). However, for a global
audience, switching to the colon may be better. The short dash is not
correct anywhere, I don't think.
The original short dash makes the joint between thoughts smoosh together
in a way that's hard to read, it really needs more white space to separate the
thoughts.
Pull Request: https://projects.blender.org/blender/blender/pulls/131834
The list of bug fixes per release tool has a option to override which
issue a commit fixed (Useful if someone accidentally put the wrong
fix report number in their commit message).
The way the feature was setup previously wasn't that great, requiring
commiting information to the Blender repository, and it was prone to
bad merge conflicts if multiple people worked on it.
This commit fixes this issue by shifting the overrides list to a bug
report in the Blender repository, detaching it from commits to the
Blender repo, avoiding merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/136750
Custom normals are interpolated with the new Manifold boolean
code. In the other two solvers, there is no interplation for the
CD_PROP_INT16_2D type so custom normals were left at (0,0) when
an exact copy from the input corner isn't possible.
The new code for manifold first does a join mesh, which converts
custom normals to float3, which can be (and are) interpolated.
However, if the input face (or face fragment) has flipped normal
in the boolean output, then the custom normal should be flipped to.
The fix is to do that for attributes called "custom_normal".
The general case of a "normal-like" thing with a different name
remains unsolved, but I doubt that case comes up often.
This converts the public `uiLayoutColumnWithHeading` function to an
object oriented API (an `uiLayout::column` overloaded version), matching
the python API.
Like the original `uiLayout::column`, this overloaded version now also
returns an `uiLayout` reference instead of a pointer. New calls to this
method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138056
This patch fixes an issue where the splash screen width clamping
calculation would result in a very narrow size on HiDPI/Retina
display due to the native pixel size not being taken into account.
Fixed by using the `WM_window_native_pixel_x()` function to obtain
the horizontal window size instead of directly using
`CTX_wm_window(C)->sizex`.
Pull Request: https://projects.blender.org/blender/blender/pulls/137997
This converts the public `uiLayoutColumn` function to an object oriented
API (`uiLayout::column`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::column` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Pull Request: https://projects.blender.org/blender/blender/pulls/138034
Previously spell checker ignored text in single quotes however this
meant incorrect spelling was ignored in text where it shouldn't have
been.
In cases single quotes were used for literal strings
(such as variables, code & compiler flags),
replace these with back-ticks.
In cases they were used for UI labels,
replace these with double quotes.
In cases they were used to reference symbols,
replace them with doxygens symbol link syntax (leading hash).
Apply some spelling corrections & tweaks (for check_spelling_* targets).
When skipping terms, support combinations of language & token types
ignoring different expressions.
This means Python can exclude double back-ticks for doc-strings
and doxygen expressions only need to be detected for C-family languages.
This converts the public `uiLayoutRowWithHeading` function to an object oriented
API (an `uiLayout::row` overloaded version), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
Same as the original `uiLayout::row`, this overloaded version also now returns an
`uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/138014
Changes the default distance to something suitable for working on human
sized objects. The previous default required the object to be quite
massive in scale to look correct.
This not only improves the display but also makes accidental back facing
selection significantly less likely. There will be more cases where the
source object clips through the retopology, but this can also be helpful
as it shows where there are significant differences is the silhouette.
0.01 was chosen in Blender Chat as a nice round number that works for a
variety of objects.
See PR for comparison images.
Pull Request: https://projects.blender.org/blender/blender/pulls/137978
**Problem**
When using Sculpt Texture Paint to paint objects in a debug build,
Blender will crash due to an Address Sanitizer exception,
`stack-use-after-free`. This makes development for Sculpt Texture
Paint harder since the feature can't be used in debug builds without
turning off Address Sanitizer.
Code-wise, the issue here happens when extending UV island borders.
When creating and adding UV primitives to extend the UV border, the
primitives are allocated locally and then added to a list. This means
that when these primitives are accessed later from the list, the ASAN
error is triggered since the primitives have been freed. Freed
primitives are generally accessed when checking if a primitive has
already been added to the primitive list belonging to its connected UV
Edges.
**Solution**
The solution here is to change UV Edges to store the index of a UV
primitive, and not use a pointer to the object itself. This is the best
solution since it makes it fast and simple to check if an UV Edge
already has a reference to its connected primitives, while still
allowing access to the primitive objects since primitives can be
accessed using indexes from mesh data objects.
Co-authored-by: T0MIS0N <50230774+T0MIS0N@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/137032
Imports in the following animated data from UsdGeomCameras:
- Focal length
- DOF distance
- DOF fstop
- Clip start, Clip end
- Tilt shift x, Tilt shift y
- Aperture sizes (with caveats)
Implementation wise, it's more complicated than I'd like due to needing
to read in both non-animated and animated data for each property. And
because I've tried to reduce the duplication of various transforms we
have to do on each value. E.g. scaling values by "tenth of scene units"
or the extraction of the USD clipping range from a GfVec2f into 2
separate properties, and 2 separate fcurves, in Blender etc. The current
approach was the best I could come up with so far.
Aperture sizes remain problematic for import, with animation data and
without, due to how Blender selects the largest sensor dimension to base
downstream calculations on and for which there's no concept in USD to
strictly dictate which dimension to use. Additionally, changing the
sensor size will impact the Tilt values as well. This means that if the
Aperture sizes are animated, we must also animate the tilt values; leads
to more fcurves being created than perhaps expected.
The `projection` attribute (perspective and orthographic) remains
unchanged (non animated only) due to differences in how USD<>Blender
interoperate with the Orthographic projection method. Note: Blender only
exports perspective cameras due to the same reason.
Pull Request: https://projects.blender.org/blender/blender/pulls/137487
This converts the public `uiLayoutRow` function to an object oriented
API (`uiLayout::row`), matching the python API.
This reduces the difference between the C++ API with the python version,
its also helps while converting code from python to C++ code (or vice-versa),
making it almost seamless.
`uiLayout::row` now returns an `uiLayout` reference instead of a pointer.
New calls to this method should use references too.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/137979
This allows users to implement arbitrary camera models using OSL by writing
shaders that take an image position as input and compute ray origin and
direction.
The obvious applications for this are e.g. panorama modes, lens distortion
models and realistic lens simulation, but the possibilities are endless.
Currently, this is only supported on devices with OSL support, so CPU and
OptiX. However, it is independent from the shading model used, so custom
cameras can be used without getting the performance hit of OSL shading.
A few samples are provided as Text Editor templates.
One notable current limitation (in addition to the limited device support)
is that inverse mapping is not supported, so Window texture coordinates and
the Vector pass will not work with custom cameras.
Pull Request: https://projects.blender.org/blender/blender/pulls/129495
This implement the design detailed in #135935.
A new per object property called `Shadow Terminator Normal Offset` is
introduced to shift the shadowed position along the shading normal.
The amount of shift is defined in object space on the object datablock.
This amount is modulated by the facing ratio to the light. Faces
already facing the light will get no offset. This avoids most light
leaking artifacts.
In case of multiple shading normal, the normal used for the shift
is arbitrary. Note that this is the same behavior for other biases.
The magnitude of the bias is controlled by `Shadow Terminator Normal Offset`.
The amount of faces affected by the bias is controlled using
`Shadow Terminator Geometry Offset` just like cycles.
Tweaking the `Shadow Terminator Geometry Offset` allows to avoid too much
shadow distortion on surfaces with bump mapping.
Cycles properties are copied from the Cycles object datablock to the
blender datablock. This break the python API for Cycles.
The defaults are set to no bias because:
- There is no good default. The best value depends on the geometry.
- The best value might depend on real-time displacement.
- Any bias will introduce light leaking on surfaces that do not need it.
- There is an additional cost of enabling it, which is proportional
to the amount of pixels on screen using it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136935
This was caused by missing depth of objects.
The old implementation was relying on the external engine
to provide the correct depth of the objects.
This patch does exactly this.
The downside is that, if overlays are present, the prepass
will be also drawn by the overlay engine.
Pull Request: https://projects.blender.org/blender/blender/pulls/138004
