| Age | Commit message (Collapse) | Author |
|---|
|
Current convention is not to use this term, use "current frame",
and "timeline frame" in render.c as this is the argument passed in.
|
|
Move far plane last since it's the least likely to intersect edges.
|
|
Currently, the OptiX BVH build options are selected based on whether
we are in background mode (final renders) or not (viewport renders).
In background mode, the BVH is built for fast path tracing and low
memory footprint, while in viewport, it is built for fast updates.
However, on platforms without OpenGL support, the background flag is
always set to true and prevents using fast BVH builds in the viewport.
Now, the BVH options derive from the Scene BVH settings:
* if BVH is static, a fast to trace BVH is built
* if BVH is dynamic, a fast to update BVH is built
Reviewed By: #cycles, brecht
Differential Revision: https://developer.blender.org/D11154
|
|
Apply the same fix for T32214 (edge-select failing) to bones
which also failed when their end-points were outside of the view.
- Add V3D_PROJ_TEST_CLIP_CONTENT support for edit & pose bone iterator
and use for selection operators.
- Remove unnecessarily complicated checks with pose-mode lasso tagging.
- Correct error in pose-mode LassoSelectUserData.is_changed
(currently harmless as it's not read back).
|
|
|
|
|
|
Also use full sentences, and correct typos.
|
|
Previously this was mostly consistent, but not completely. It's helpful
to use the same name for the same meaning everywhere in this area.
|
|
`src` and `dst` are perfectly clear, and avoid repeating unecessary
characters when writing the variables many times, allowing more space
for everything else.
|
|
This commit piggybacks on rB3e695a27cdfad560d0b28e742cfa069d098200d6
|
|
When CMake detects and incompatible Python version
it errors out with an error saying at-least python 3.9
is required, but doesn't mention the version it detected.
This makes troubleshooting the problem harder than it
needs to be.
This diff changes the error message to include the python
version CMake detected.
Differential Revision: https://developer.blender.org/D11666
Reviewed By: Ray Molenkamp
|
|
This adds preliminary VS 2022 support, since
there currently is no CMake version that
supports the VS2022 IDE only ninja support
was tested.
IDE support should work without any additional
changes as soon as an updated CMake becomes
available.
As VS2022 appears to keep binary compatibility
with earlier MSVC versions, the current SVN
libraries will work for this version.
|
|
against system input.
Reviewed By: brecht, LazyDodo
Maniphest Tasks: T88852
Differential Revision: https://developer.blender.org/D11508
|
|
This commit optimizes the node for the case where it works on many
splines by allowing it to generate mesh data from their combinations
in parallel. By itself, this made the node around twice as fast in my
test file with a result of 20 million vertices, around 600ms instead of
1.2s before.
That isn't actually a very good result; it reveals another bottleneck,
a single threaded loop over all face corners in the mesh normal
calculation code. As a simple change that might improve performance
in some situations, this commit moves normal calculation out of this
node, so at least the work isn't wasted if the mesh is changed later
on in the node tree anyway.
|
|
The depth cache (located in `RegionView3D::depths`) is used for quick
and simple occlusion testing in:
- particle selection,
- "Draw Curve" operator and
- "Interactive Light Track to Cursor" operator,
However, keeping a texture buffer in cache is not a recommended practice.
For displays with high resolution like 8k this represents something
around 132MB.
Also, currently, each call to `ED_view3d_depth_override` invalidates
the depth cache. So that depth is never reused in multiple calls from
an operator (this was not the case in blender 2.79).
This commit allows to create a depth cache and release it in the same
operator. Thus, the buffer is kept in cache for a short time, freeing
up space.
No functional changes.
|
|
Quaternion correction was not implemented and Euler values were being
incorrectly combined.
|
|
The recent task isolation changes missed two mutex locks that also need task
isolation.
Ref D11603, T89194
|
|
Missing to disable default light ON when use separate operator.
|
|
This patch uses threading to flush selection from verts to edges and
from edges to faces. The solution is lockless and should scale well on
modern CPU architectures.
Master:{F10185359}
Patch:{F10185361}
End user performance went from 3.9 to 4.6 FPS (Stanford Dragon) but that
was measured on a Intel Core i7-6700 CPU and AMD RX480 Gpu. The more
cores the better improvements you get.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D11644
|
|
The problem was introduced with Bezier modification because the selection code was using the original stroke and not the evaluated version.
|
|
|
|
Get current pass only when needed.
|
|
detailed explanation of the issue and may help the Addon Developer to identify what exactly needs to be changed.
The current message 'addon not loaded' is a bit too sparse.
Differential Revision: https://developer.blender.org/D11655
|
|
The early `return` was wrong when there are multiple origin sockets
that need to be loaded.
|
|
Differential Revision: https://developer.blender.org/D11658
|
|
|
|
Consistently use a/b instead of 0/1.
|
|
This resolves a long standing bug in edge selection
(picking, circle, box & lasso).
Now when one of the edges vertices fails to project into screen space,
the edge is clipped by the viewport to calculate an on-screen location
that can be used instead.
This isn't default as it may be important for the on the screen location
not to be clipped by the viewport.
|
|
|
|
X & Z were ordered min/max, where as Y was max/min.
|
|
Mistake in recent commit {rBea4309925f1d2d2a224bd1dce12269a58ade9b62}.
|
|
The names were slightly longer than they needed to be clear,
and when they are shorter they tend to fit on one line better.
|
|
Optimize the node for the case of many splines. In a test file with
14000 splines, the node is 3x faster (72ms to 24ms) on an 8 core CPU.
|
|
|
|
The file path wasn't documented as being optional.
|
|
Adds two new output modes to the CDT api which detect and remove
holes. A hole is a face from which a ray shot to the outside
intersects an even number of constraint edges, except we don't
count constraint edges in the same connected region of faces,
where a region is connected via non-constraint edges.
These modes are useful for filling in outlines meant to represent
text characters and the like.
Original patch was from Erik Abrahamsson, modified by me to work
with the "valid Bmesh" output type too. I also added tests
for the new modes.
|
|
Caused by improper testing on my part, assuming a helper function
existed in the industry compatible keymap file, and also assuming it
also used the N and T keys for the left and right side-regions.
|
|
A different data structure / implementation is used for curves in the
node tree currently. Converting from the DNA `Curve` structure to this
wasn't slow, but it's nice to decrease overhead. In a test of 14000
splines with 128000 points, this halves the runtime from about 5ms
to about 2.5ms.
|
|
The spreadsheet filter tried to apply the mesh selection filter on non-
mesh geometry components. Add a check for the component type,
and also refactor the function to be more easily readable.
|
|
The normals were broken because the normal calculation mode wasn't set.
This patch adds a default normal mode so all code creating a spline does
not necessarily have to set it manually. In the future there should be a
way to change this value in the node tree.
|
|
It wasn't obvious this can be used for calculating the triangle index
from the polygon and loop index.
|
|
This convention is no longer used for Blender's CMake files.
|
|
|
|
|
|
|
|
Use the face normal (when available) for a faster concave quad test.
|
|
- Multi-thread BKE_mesh_recalc_looptri.
- Add BKE_mesh_recalc_looptri_with_normals,
this skips having to calculate normals for ngons.
Exact performance depends on number of faces, size of ngons and
available CPU cores.
For high poly meshes the isolated improvement to BKE_mesh_recalc_looptri
in my tests was between 6.7x .. 25.0x, with the largest gains seen in
meshes containing ngons with many sides.
The overall speedup for high poly meshes containing quads and triangles
is only ~20% although ngon heavy meshes can be much faster.
|
|
|
|
|
|
|
