Age | Commit message (Collapse) | Author |
|
The new data structure uses open addressing instead of chaining to resolve collisions in the hash table.
This new structure was never slower than the old implementation in my tests. Code that first inserts all edges and then iterates through all edges (e.g. to remove duplicates) benefits the most, because the `EdgeHashIterator` becomes a simple for loop over a continuous array.
Reviewer: campbellbarton
Differential Revision: D4050
|
|
|
|
Conflicts:
source/blenderplayer/CMakeLists.txt
tests/gtests/blenlib/CMakeLists.txt
|
|
Seriously... like, seriously...
|
|
|
|
|
|
These only exposed a few options, which didn't end up helping
much to make Blender's key-map fit the behavior of other applications.
|
|
|
|
Not all Object.select_set() cases had been updated to new API... Tsst. ;)
|
|
- Was setting active state, making it necessary to backup/restore
active object in cases where this isn't needed.
Existing scripts are explicitly setting the active object when needed.
- Use a boolean select arg (toggle selection wasn't used anywhere).
- Add an optional view layer argument since scripts should be able to
operate outside the user context.
|
|
We already had a BKE_main.h header, no reason not to put there
Main-specific functions, BKE_library has already more than enough to
handle with IDs and library management!
|
|
Simple find_nearest relies on a heuristic for efficient culling of
the BVH tree, which involves a fast callback that always updates the
result, and the caller reusing the result of the previous find_nearest
to prime the process for the next vertex.
If the callback is slow and/or applies significant restrictions on
what kind of nodes can qualify for the result, the heuristic can't
work. Thus for such tasks it is necessary to order and prune nodes
before the callback at BVH tree level using a priority queue.
Since, according to code history, for simple find_nearest the
heuristic approach is faster, this mode has to be an option.
|
|
This reverts reverting commit rB55324b8a2e6799300, and do proper 'cleanup' (sigh)
in gtest as well.
Sorry for the noise, did not understood what had happened here
immediately. :/
|
|
Most certainly commite by mistake, FastHeap is not in BLI yet!
|
|
If the user only needs insertion and removal from top, there is
no need to allocate and manage separate HeapNode objects: the
data can be stored directly in the main tree array.
This measured a 24% FPS increase on a ~50% heap-heavy workload.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3898
|
|
It is very commonly needed in loop conditions to check if
the items in the heap are good enough to continue.
|
|
|
|
|
|
Previously, parallel tests would overwrite each others temporary outputs.
|
|
Currently some modes share tool keymaps, we might want to disable
this since it's confusing editing one thing in multiple places.
However this should be resolved in the tool definitions.
|
|
|
|
|
|
|
|
This is useful to run OpenGL tests while continuing to do other tasks
without windows constantly popping up in the foreground.
|
|
|
|
Differential Revision: https://developer.blender.org/D3700
|
|
Terms get/set don't make much sense when casting values.
Name macros so the conversion is obvious,
use common prefix for easier completion.
- GET_INT_FROM_POINTER -> POINTER_AS_INT
- SET_INT_IN_POINTER -> POINTER_FROM_INT
- GET_UINT_FROM_POINTER -> POINTER_AS_UINT
- SET_UINT_IN_POINTER -> POINTER_FROM_UINT
|
|
|
|
- Order array length after the array.
- Put return argument last.
|
|
Simple isn't a good prefix for library names since
lots of unrelated modules could be called 'simple'.
Include 'py' in module name since this is a subset of Python,
one of the main motivations for this is to be Python like/compatible.
|
|
Recently @sergey found that hard-coding evaluation of certain very
common driver expressions without calling the Python interpreter
produces a 30-40% performance improvement. Since hard-coding is
obviously not suitable for production, I implemented a proper
parser and interpreter for simple arithmetic expressions in C.
The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=,
and, or, not, ternary if; driver variables, frame, pi, True, False,
and a subset of standard math functions that seem most useful.
Booleans are represented as numbers, since within the supported
operation set it seems to be impossible to distinguish True/False
from 1.0/0.0. Boolean operations properly implement lazy evaluation
with jumps, and comparisons support chaining like 'a < b < c...'.
Expressions are parsed into a very simple stack machine program
that can then be safely evaluated in multiple threads.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D3698
|
|
See T56648.
|
|
|
|
This differential revision implements the code for T56276
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3587
|
|
Internally it's still mostly named lamps, though some modules like Cycles
were already calling them lights.
|
|
|
|
|
|
|
|
|
|
|
|
This at least makes sure the tests don't fail any more. Possibly there
should be more evaluation happening there.
|
|
The ClayEngine was introduced to test the blender2.8 architecture during
development. As currently we have the wanted features implemented with
matcaps we are going to remove the clay engine as it was never intended
to be an official releasable engine
Note: The test cases are never run. But when enabled will be skipped as
they were implemented over the Clay Engine
|
|
Two tests are still failing, but at least the API changes in 2.8 have been
applied now.
|
|
This doesn't mean the code is correct, but at least it builds.
|
|
|
|
|
|
|
|
|
|
This commit adds number formatting (thousands separator) to the baking panel. It also adds a new function to format memory sizes (KB/GB/etc) and applies it to the baking panel and scene stats. The new function is unit tested.
Reviewers: Severin
Tags: #user_interface
Differential Revision: https://developer.blender.org/D1248
|
|
|