Also replace integer with bool in Ghost API when only used as boolean,
and uint8* with char* in Ghost API when variable is a string.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11617
Signed-off-by: Nicholas Rishel <rishel.nick@gmail.com>
This patch extends D11695 to provide full support for Chinese and Korean
input on macOS.
Chinese input notes:
You can input symbolic characters (such as '! , '$') during Chinese input.
The difference from Japanese input is that multiple `insertText` may be
called with a single key down (`keyDown` method). This happens when you input
a symbolic character (such as '! , '$') during conversion.
The conversion is confirmed (`insertText`) and the symbolic character is
entered (`insertText`). To solve this problem, I have `result_text` to
concatenate the strings and store them in `result`.
Korean input notes:
Korean does not display a conversion suggestion window.
Like Chinese, Korean input may call multiple `insertText` methods. Also,
in Korean, the previous confirmation (`setMarkedText` and `insertText`) and
the next conversion is processed (`setMarkedText`) may be called
simultaneously with a single key down (`keyDown` method).
For example:
1. press g ㅎ (`setMarkedText`)
2. press k 하 (`setMarkedText`)
3. press t 앗 (`setMarkedText`)
4. press k 하세 (`setMarkedText`, `insertText`, `setMarkedText`)
Fixed so that the `insertText` and the last `setMarkedText` are processed.
Also, if a control character (such as Arrow, Enter) is input during Korean
input, the conversion will be confirmed (`setMarkedText`, `insertText`) and
the original control character will be processed.
In other words, if you press the left arrow key while typing in Korean, the
cursor will move to the left after the character is confirmed. Therefore, I
modified the `keyDown` method so that the `handleKeyEvent` is called again
after the `insertText` is processed in the `interpretKeyEvents` method.
Differential Revision: https://developer.blender.org/D11699
Blender did not support to input East Asian characters (Chinese, Japanese,
Korean) on macOS. This patch adds support for Japanese input, by implementing
the appropriate processing for the NSTextInputClient protocol.
Technical notes:
* The conversion candidate window is drawn by the input method program calling
`firstRectForCharacterRange`.
* The string before confirmation (called `composite` in blender) is handled in
the `setMarkedText` method called by the input method program.
* The string after confirmation (called `result` in the blender) is processed
in the `insertText` method called by the input method program.
Ref T51283
Differential Revision: https://developer.blender.org/D11695
In the Win32 platform our setTitle() can properly assign a Unicode
utf-8 window title. Unfortunately our getTitle() will only read regular
8-bit character strings. This means that we can never compare what we
set to what we get. This patch updates getTitle() to use Unicode-aware
GetWindowTextLengthW and GetWindowTextW.
see T88909 for an example of this affecting user experience.
Differential Revision: https://developer.blender.org/D11782
Reviewed by Ray Molenkamp
When using multiple monitors that differ in scale and/or dpi, the
varying sizes of the window titles and borders can cause the placement
of those windows to be out by a small amount. This patch adjusts for
those differences on Windows 10 and newer.
see D10863 for details and examples.
Differential Revision: https://developer.blender.org/D10863
Reviewed by Ray Molenkamp
This is just some cleanup of the Win32 window creation code. After
CreateWindowExW() this patch uses some early exits to replace some
potentially confusing if blocks. No functional changes.
Differential Revision: https://developer.blender.org/D11446
Reviewed by Ray Molenkamp
When compiling BSDF nodes, we only assing stack space to the normal and
tangent inputs if they are linked. However, it could be that the
ConstantFolder removed the link, so checking if there is a link fails
to take this into account.
To fix this, added a flag to ShaderInput to keep track of whether a
constant was folded into the input, and use it as well to verify that
the socket is linked when assigning stack space.
Reviewed By: brecht
Maniphest Tasks: T70615
Differential Revision: https://developer.blender.org/D11731
Custom properties defined on objects are not accessible from the
attribute node when rendering a volume in Cycles. This is because
this case is not handled.
To handle it, added a primitive type for volumes in the kernel,
which is then used in the initialization of ShaderData and to
check whether an attribute lookup is for a volume.
`volume_attribute_float4` is also now checking the attribute
element type to dispatch to the right lookup function.
Reviewed By: #cycles, brecht
Maniphest Tasks: T87194
Differential Revision: https://developer.blender.org/D11728
Offset rays from the flat surface to match where they would be for a smooth
surface as specified by the normals. In the shading panel there is now a
Shading Offset (existing option) and Geometry Offset (new).
The Geometry Offset works as follows:
* 0: disabled
* 0.001: only terminated triangles (normal points to the light, geometry
doesn't) are affected
* 0.1 (default): triangles at grazing angles are affected, and the effect
fades out
* 1: all triangles are affected
Limitations:
* The artifact is still visible in some cases, it could be that some quads
require to be treated specifically as quads.
* Inconsistent normals cause artifacts.
* If small objects cast shadows to a big low poly surface, the shadows can
appear to be in a wrong place - because the surface moved slightly above
the geometry. This can be noticed only at grazing angles to light.
* Approximated surfaces of two non-intersecting low-poly objects can overlap
that causes off-the-wall shadows.
Generally, using one or a few levels of subdivision can get rid of artifacts
faster than before.
Differential Revision: https://developer.blender.org/D11065
* Mark either all or no class methods with override
* Don't use zero sized array since it has a different size in C and C++.
Using a little more memory here is not significant.
* Don't use deprecated mechanism to mark private GSet members in clang
just like we don't for MSVC, it warns even for simple zero initialization.
Iteration was incorrectly calling the same object. Had it called every
window it would still be unnecessary as WM_DISPLAYCHANGE is sent to all
broadcast receiving windows.
In certain CMake configurations it was possible
that OCIO gave linker errors due to it thinking
it was using the shared library rather than the
static library we ship.
The check on the transformation introduced in rBb313525c1bd0 to fix
T88515 would sometimes prevent to update the light if the Blender object
changed. To fix this, reverse the order in which the checks happen so
that we do not shortcuit the object change check.
