| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Currently, audio and video strips are synchronized based on data from
media stream, which is nice, but this causes gaps between strips.
This synchronization was implemented by moving movie strip position
relative to sound, which doesn't make much sense for user which is
mostly interested in editing video.
Code was bit hard to read, so it has been simplified. Ideally video
stream time would be easily accessible so synchronization could be done
at any time, but this is not necessary at this point.
Reviewed By: zeddb
Differential Revision: https://developer.blender.org/D13948
|
|
|
|
Ref T95249, D13935
|
|
23775f3914d6474fd73eff7 removed this comment, but it's
preferred to keep it instead.
|
|
This could result in a shading errors is some cases such as undo.
Follow up to rB1405787142d1f87f18631114167675ed145f6d75
|
|
This could result in a shading errors is some cases such as undo.
Follow up to rB1405787142d1f87f18631114167675ed145f6d75
|
|
The name `type` was confusing, since we usually use that in other ways.
Also updated the relating comments.
|
|
Long namespace qualifiers add visual noice and make code harder to read.
|
|
|
|
Correct corner radius of the node outline to prevent a noticeable gap in
some cases.
---
Currently we make a small mistake in the creation of the node outline:
We offset the rectangle describing the outline by the outline thickness,
but we don't adjust the corner radius accordingly.
Therefore the rounded corner of the outline and the node body are not
concentric which can sometimes lead to a visible gap at the corner.
How noticeable it is depends on the theme, the screen's dpi and the
line thickness set in the preferences.
Simply adjusting the corner radius for the outline to also be increased
by the outline thickness fixes this small issue.
| display, line thickness | **patch** | **master** |
| --- | --- | --- |
| 1080p, default/thin | {F12835304} | {F12835305} |
| retina, thin | {F12835306} | {F12835307} |
The issue was mentioned by @hitrpr
Reviewed By: Blendify
Differential Revision: https://developer.blender.org/D13955
|
|
Use the evaluated mesh to generate the Adjacent Faces margin.
Baking used the evaluated mesh, but generating the margin used the base
mesh. This would lead to generating the margin from a stale UV map when the
UV editor was open and the UV map was changed. Fix it by passing the same
mesh as used for baking through to the margin generation.
Differential Revision: https://developer.blender.org/D13938
|
|
The new adjacent faces method border lookup fails in some directions around
45 degrees
* Use 8 Dijkstra directions (also diagonally) to determine which polygon is the
closest to each pixel. Using only Manhattan distance lead to large parts of
the texture which were matched with the wrong polygon.
* Use neighbroing polygons for edge search. The Adjacent Faces algorithm needs
to determine the closest edge, in UV space, each pixel. To speed this up
first as map is built which finds the closest polygon for each pixel along
horizontal, vertical and diagonal steps. Because this can sometimes be one
edge off we first look in the polygon from the map, if that fails also
check the edges of its neighbouring UV polygons.
Differential Revision: https://developer.blender.org/D13935
|
|
Was accidentally left in after refactoring.
Fixes T95347
Differential Revision: https://developer.blender.org/D13963
|
|
|
|
The bug was caused by a typo.
|
|
Missing include statements of the gpu_shader_colorspace_lib.glsl in
various shaders ignored the target texture color space.
|
|
|
|
|
|
For those EEVEE passes a bit of trickery with pointer offsets allows to
get the owning viewlayer, so path generation is not too bad.
Also moved ViewLayer path generation itself into a public utils, to
avoid duplicating code.
NOTE: Doing the same for AOV would be needed, but since pointer offsets
won't help us here to find the owning viewlayer, not sure how to do it
nicely yet (only solution I think is to loop over all AOVs of all
ViewLayer of the scene to find it :( ).
Reported by Beau Gerbrands (@Beaug), thanks.
|
|
Set an appropriate range and default value for the property.
|
|
|
|
|
|
|
|
|
|
Image buffer was visible but buffer wasn't available. In the case
the color only overlay of the render result was displayed the image
buffer was not check to be valid.
This patch adds a null pointer check to check in `IMB_alpha_affects_rgb`
to solve this crash.
|
|
Use the input depth texture to determine if the color of the texture
should be shown.
|
|
When an image buffer cannot be read the checkerboard should not be
drawn.
|
|
Empty (UDIM) tiles where drawn with a transparency checkerboard. They
should be rendered with a border background. The cause is that the image
engine would select a single area that contained all tiles and draw them
as being part of an image.
The fix is to separate the color and depth part of the image engine
shader and only draw the depths of tiles that are enabled.
|
|
While this didn't cause any user visible bugs, this wouldn't
have behaved as intended since the timer would never run again once
wmTimer.ntime was set to NAN.
|
|
- Remove outdated references to glReadPixels & OpenGL.
- Rename GPUPickState.{gl => gpu}
- Add doc-string for MAXPICKELEMS.
- Use doxygen comments & other minor doc-string improvements.
|
|
GPU_select originally used GL_SELECT which defined the format for
storing the selection result.
Now this is no longer the case, define our own struct - making the code
easier to follow:
- Avoid having to deal with arrays in both `uint*` and `uint(*)[4]`
multiplying offsets by 4 in some cases & not others.
- No magic numbers for the offsets of depth & selection-ID.
- No need to allocate unused members to match GL_SELECT
(halving the buffer size).
|
|
|
|
|
|
The value of this flag was never used.
|
|
Remove functions and function pointers that were never set or never
used at all. The "tessface" original index handling in `subsurf_ccg.c`
can be removed because the data was never used.
|
|
|
|
|
|
This function and flags weren't used outside of DerivedMesh
code, and since the plan is to remove the data structure, it makes
sense to remove complexity where possible.
|
|
The "Paint" mode is wrong, must be "Draw"
|
|
This is a patch from Aras Pranckevicius, D13927. See that patch for full
details. On Windows, the many small fprintfs were taking up a large amount
of time and significant speedup comes from using snprintf into chained buffers,
and writing them all out later.
On both Windows and Linux, parallelizing the processing by Object can also lead
to a significant increase in speed.
The 3.0 splash screen scene exports 8 times faster than the current C++ exporter
on a Windows machine with 32 threads, and 5.8 times faster on a Linux machine
with 48 threads.
There is admittedly more memory usage for this, but it is still using 25 times
less memory than the old python exporter on the 3.0 splash screen scene, so
this seems an acceptable tradeoff. If use cases come up for exporting obj files
that exceed the memory size of users, a flag could be added to not parallelize
and write the buffers out every so often.
|
|
|
|
Previously, the new obj exporter was only exporting per-vertex normals for faces
marked as "smooth". But a face can have custom normals, as soon as the normals
data layer exists. This change makes it follow the behavior of USD & Collada
exporters and the old Python one, which also export per-vertex normals as soon
as the layer is there. (From Patch D13957.)
|
|
See rB0c5a9a0e776eeb724f7266694153f98721e34fde for the issue with this.
This reverts commit 0c5a9a0e776eeb724f7266694153f98721e34fde.
|
|
This is similar to e032ca2e25bf2e305b66 which removed the
callback for volumes. Now that we have geometry sets, there is
no need to define a callback for every data type, and this wasn't
used. Procedural curves/hair editing will use nodes rather than new
modifier types anyway.
|
|
Blender is the name of the software, it does not make sense to
translate into a language's term for the kitchen appliance.
|
|
Since `event->xy` is now an array these functions can be
simplified to accept the sample point as an array.
Clarifications were also made to variable names:
- `eye->last_x/y` --> `eye->cursor_last`
- `mx/my` --> `cursor`
Differential Revision: https://developer.blender.org/D13671
|
|
|
|
|
