See #129009 for context.
The preprocessor parses metadata and writes a header file containing
an inline function that inits the `GPUSource` with the metadata.
These header files are then included inside `gpu_shader_dependency.cc`.
This still keep the usage of the `metadata` enums and classes to avoid
pulling the whole blender module inside the preprocessor executable.
This speeds-up startup time in Debug build:
`gpu_shader_dependency_init`
- Before : 37ms
- After : 4ms
I didn't measure release, but it is unlikely to be noticeable (in the
order of 4ms > 1ms).
Pull Request: https://projects.blender.org/blender/blender/pulls/138070
(when done from python)
When changing those setting via the **UI**, we somehow get the
dependency graph tagged for changes.
If this happens, the update ripples through the following (and we are
all good):
- `DEG_editors_update` (here the depsgraph update is detected via
`DEG_id_type_any_updated`)
- `deg_editors_scene_update`
- `ED_render_scene_update`
- `ED_render_view3d_update`
- `engine_view_update` which finally calls the renderengine `sync_func`
When doing this from python though, the DEG tag is missing, now added
(similar to 4f15c24705)
We could as well just do a broader update though and use
`update_render_engine`
Since it seems `CyclesVisibilitySettings` are only used for the World
nowadays, this PR also corrects the property descriptions accordingly
(might make sense to split this into a separate commit).
Pull Request: https://projects.blender.org/blender/blender/pulls/138093
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
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
* 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
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).
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
In forward path tracing, when we pass volume bounding meshes, we
accumulate `volume_bounds_bounce`. We should match this behaviour in NEE
instead of accumulating `transparent_bounce`.
Pull Request: https://projects.blender.org/blender/blender/pulls/137556
The object was not properly tagged for update when syncing object motion
blur transforms. This caused issue with the camera in volume test after
recent scene update refactoring in 86b67a20d6, but potentially also
other ones.
Pull Request: https://projects.blender.org/blender/blender/pulls/137930
According to the OptiX denoising guide lines, renders should be in the
0..10000 range. As a result, clamping was applied to renders
prior to GPU denoising.
However this lead to a issue where denoising of bright images would
behave differently between CPU OIDN and GPU OIDN as this same clamping
was also applied to the GPU OIDN denoiser.
According to Attila Áfra, a developer working on OIDN, this clamping
isn't neccesary for OIDN. So this commit removes the clamping from
OIDN.
Pull Request: https://projects.blender.org/blender/blender/pulls/137879
This commit fixes a issue where Cycles adaptive kernel compilation
would always undefine adaptive kernel features, resulting in various
issues like incorrect renders.
Pull Request: https://projects.blender.org/blender/blender/pulls/137804
When Emission Sampling in None, we loop through
kernel_data.integrator.num_lights to find the light intersection.
If the light shader changes, the number of lights might change, so we
need to tag the light manager for update to recount the lights.
Pull Request: https://projects.blender.org/blender/blender/pulls/137605
Emission estimate from auto conversion is downscaled to avoid building
a light tree that is expensive to evaluate; however, this estimate is
also used as the final emission value in the kernel if the emission is
constant.
Therefore, only downscale the estimate for the EMISSION_SAMPLING_AUTO
case.
Pull Request: https://projects.blender.org/blender/blender/pulls/137606
When grabbing & hiding cursor under Wayland visually restored the
cursor location but didn't generate a motion event to update the
`wmWindow::eventstate`. Further events that used the cursor location
used the hidden location unless the user moved the cursor beforehand.
It is more convenient for math reasons, for Blender to treat a pen tilt
toward the user as a positive angle. This PR just reverses all the
comments about the expected values. And also reverses the values from
WinTab, Windows Ink, and Wayland to match.
Pull Request: https://projects.blender.org/blender/blender/pulls/137636
This PR removes unused Win32 code that we've had for about 13 years,
hidden behind a define that we've never enabled. The intent of this
optional code was to allow showing Blender windows as transparent,
something that looked pretty cool back then. The main method used was
an API call of DwmEnableBlurBehindWindow, but this function has not
done anything since Windows 8 because styles and tastes have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/137620
On the Windows platform we get an initial bright white flash during
startup, before we start drawing on our canvas. This PR changes that
initial color to a mid-grey that is much less noticeable. After this
initial fill is done we then clear the background brush so Windows will
not use it later and slow down resizing by adding extra WM_PAINT
messages and fills.
Pull Request: https://projects.blender.org/blender/blender/pulls/137488
The GLSL code generated by some OCIO configuration was
not MSL ready. Use our preprocessor on them in order
to make them compatible before creating the GPUShader.
Needs ac7e361f3d
Pen tilt values come into Blender through ghost platforms and device
drivers with inconsistent and ambiguous directions. This PR codifies
that we consider tilt-x positive values to be rightward, negative
values as leftward. Similarly tilt-y positive is away from the user,
negative is toward the user. Comments are updated to make this clear.
This fixes Windows Ink (currently always returning left and away). This
also reverses the Wayland tily-y values to match. We might still have
to consider a user preference to swap directions if we find differences
within a platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/137501
This commit adds some extra prints to terminal related to oneAPI driver
information in the situation that the driver version is considered
incompatible with the current version of Cycles.
Pull Request: https://projects.blender.org/blender/blender/pulls/137272
This patch adds initial cursor support for the blade tool, with bitmaps
for 16x16, 24x24, and 32x32 cursors.
Additional Changes:
- Locked strips now show a "stop" icon when hovered over.
- Previously, the frame to split was truncated when clicking in between frames.
Now, round to the closest frame.
- Previously, the blade operator was able to select padded strip handles
outside of strip bounds. This bug has been resolved, so that selection with
the blade tool can only happen via box-select passthrough.
Pull Request: https://projects.blender.org/blender/blender/pulls/136749
