Check for both `CF_TEXT` and `CF_UNICODETEXT` in
`GHOST_DropTargetWin32::getGhostType` because, unlike for the clipboard,
Windows does not synthesize `CF_TEXT` from `CF_UNICODETEXT` and vice
versa for drag and drop operations. Since `getGhostData` already
supports `CF_UNICODETEXT`, this is all that's necessary to make it work.
I encountered this issue when trying to drag text from Notepad++ into
Blender's text editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/138524
Now results are similar under different time steps. Additionally it is
now working correctly with different time scale, where smoke lifetime
is proportional to time scale.
Pull Request: https://projects.blender.org/blender/blender/pulls/138347
Note: this is a partial fix, that makes NEE and forward path consistent
only when `max_transparent_bounce > 0`. It is much more involved to make
forward path tracing support a max transparent bounce of 0, but since we
don't expect people to set up a very low number of transparent bounces,
it is less important to support that specific case.
Pull Request: https://projects.blender.org/blender/blender/pulls/138098
OpenColorIO exceptions would abort when WITH_ASSERT_ABORT is enabled.
But these do not generally indicate a bug in Blender. They may just be a
blend file using an unknown color space, or an error loading the
configuration file, which we can handle gracefully.
Previous conversion to scene linear was done in the display transform
shader. Having a separate shader to convert texture to scene linear
allows drawing input textures with different color spaces into a
viewport and apply display transform on all of them.
Currently unused, but is required for !138094. It could also be used
in the future to avoid host-side linearization in the image engine.
Internally it uses a lot of the same logic for shader caching and
binding, but the code is refactored a bit to make it easier to have
a stronger separation in the future if needed.
Ref #138094
Pull Request: https://projects.blender.org/blender/blender/pulls/138308
This reflects better the more detailed info in comments of each sections
of the API in that file, and the info in the on-going work for a related
handbook page at blender/blender-developer-docs!139.
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
