| Age | Commit message (Collapse) | Author |
|---|
|
Removed unnecessary call to DM_update_tessface_data(). This call is
already performed by DM_ensure_tessface(dm). The call being performed
twice caused a failing BLI_assert().
Reviewed by: Kévin Dietrich
|
|
Also added some assertions for debugging purposes
Reviewed by: Kévin Dietrich
|
|
Reviewed by: Kévin Dietrich
|
|
TEST_RET is not defined anywhere in Blender's sources, and LAYER_CMP
is no longer used after this function ends.
|
|
This makes the code within the function consistent.
|
|
With the new names the arguments (yup, zup) are in the same order as
they appear in the function name. The old names used copy_src_dst(dst,
src), which I found very confusing. Furthermore, now it is clear from
where to where the copy is made.
This makes the function names a little bit longer, though. If that is
a real issue, we can just name them zup_from_yup(zup, yup).
Reviewed by: Kévin Dietrich
|
|
|
|
Use the new utility from coloranagement which multi-threads byte to
float conversion.
Gives extra 10% speedup from quick tests.
|
|
processor applied
|
|
Speedup is mainly gained by multi-threading. Gives about 3x
fps gain on an edit shot file.
There is still some room for improvements, will happen in one
of the upcoming commits.
|
|
The title says it all actually: now we can convert byte buffer
directly, without need of temporary float buffer.
|
|
This could cause bugs in the memory release
|
|
Derived mesh for particles did not include tessellated faces when it
was expected to. Now added explicit function to copy CDDM with tess
faces without need to re-tessellate the result.
|
|
|
|
|
|
Modernize some of it a bit, saves quite some lines of blabla (using
shile instead of for loops... tsssts...).
|
|
~edge_num~ edges_num_active
Not always all the edges enter in the build
|
|
Add `bvhtree_from_mesh_edges_ex` and callbacks to nearest_to_ray (Similar to the other functions of this code)
|
|
No reason to not make this private to this file, and it gave conflict
when using bpy as module and loading it in a GLib application (which
also has a g_atexit var).
|
|
|
|
Feel free to use those in the new code.
And stay away from simple "unsigned".
|
|
This avoids calling linear lookup 100s of time when dealing with
real-life character.
Still some tweaks possible.
|
|
The title says it all actually. Use BLI task to loop over vertices
and distort their locations. Gives 2x FPS increase in a file with
just time-dependent displace modifier on my desktop.
|
|
This version will give less spin locks and now well-tested by render engines.
This should reduce amount of threading overhead when having multiple objects
with displace modifier enabled.
In the future this will also help us threading the modifier.
There are more modifiers which could benefit from this, but let's first
investigate the new behavior with one of them.
|
|
Using image pool will reduce number of thread locks when acquiring image.
Useful when it's needed to sample texture fewzillion times a second.
|
|
|
|
We (the Microsoft C++ team) use the Blender project as part of our "Real world code" tests.
I noticed a place in WIN32 specific code (dvpapi.cpp:85) where a string literal is losing
its const-ness when being passed to BLI_dynlib_open(). This is not permitted when using the
/permissive- conformance compiler switch (see our blog
https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/)
My suggested fix is to add const and propagate it where needed. Another possible fix would be
to explicitly cast away the const.
Reviewers: mont29, sergey, LazyDodo
Subscribers: Blendify, sergey, mont29, LazyDodo
Tags: #platform:_windows
Differential Revision: https://developer.blender.org/D2495
|
|
`transform_snap_context_project_view3d_mixed` with `dist_px` NULL
|
|
This was a stupid mistake
|
|
Instead of reference the vertex first and test the bitmap afterwards. Test the bitmap first and reference the vertex after.
In a mesh with 31146 vertices and the entire bitmap disabled, the loop time is 243% faster
With all bitmap enabled, the time becomes 463473% faster!!!
One possible reason for this huge difference in peformance is that maybe the compiler is not putting the function "BM_vert_at_index" inline (I dont know if buildbot do this, but it's good to investigate).
|
|
Ray_start and ray_normal values were being ignored
|
|
Looks like `object_map` and `mem_arena` may be NULL sometimes...
Also, cleaned up function pointers declaration of Nearest2dUserData,
those were warning out in gcc. Please, *always* use typdef defined
prototypes for function pointers, it is sooooo much cleaner and clearer
that way. And easy to convert from compatible functions too.
|
|
BKE_lamp_free was somehow missing the refactor of datablocks handling
(which, among other things, completely separated ID refcounting and
linking management from ID freeing itself).
Either forgot during development, or lost during merge...
|
|
DerivedMeshs and Bmeshs
Before it was informed the type of object in the `userdata`, and a same function ran between the types to obtain the coordinates of the vertices
|
|
Since the cache is created in one way or another, this flag is not really making a difference
More details here: D2496
|
|
The code looks for the closest element between its centers. In the case of islands, the center of each vertex is the center of the island.
The solution here is to skip the search for islands when the operation is translation
|
|
In obect mode, the rotation matrix need to be restored to the initial value if a snap point is not found
|
|
possible.
Pretty straight forward actually, just do not bother about obdata part
of vgroups in that case, only copy object part of it.
And let's curse once again those stuff spread accross several types of
data-blocks...
|
|
|
|
|
|
transformation
The problem was simple, just transform the global coordinates of t->tsnap.snapTarget to local coordinates.
(Some comments were added to the code)
|
|
Issue was indeed in join operation, mesh in which we join all others
could be re-added to final data after others, leading to undesired
re-ordering of CD layers, and existing vertices etc. being shifted away
from their original indices, etc.
All kind of more or less bad and undesired changes, fixed by always
re-inserting destination mesh first.
Also cleaned up a bit that code, it was doing some rather
non-recommanded things (like allocating zero-sized mem, doing own
coocking to remove a data-block from main, etc.).
|
|
Root of the issue was BM_mesh_bm_to_me() breaking application of basis
offset to 'child' shapekeys, when called more than once from same BMesh.
|
|
|
|
particle modifier + UV material
Tricky issue caused by CDDM_copy() coying MFACE array but not MTFACE which
confused logic later on.
Now we don't copy ANY tessellation unless it is requested to.
Thanks Bastien for help and review!
|
|
This was my own mistake
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2378
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2379
|
|
scrolling speed.
'page' prop of scroll up/down operators would get stuck once set once by
pageup/down keys... Now only take this prop into account if explicitely
set, not when its value is inherited from previous run.
|
|
perspective view
Strangely this change does not affect the performance very much.
Suzanne subdividide 6x (ortho view):
Before:0.00013983
After :0.00013920
But it makes it easier to read the code
|
