| Age | Commit message (Collapse) | Author |
|---|
|
That was a nice and funny hunt, albeit rather time consumming!
To summarize, so far code was using a static global gpu_buffer for pbvh vbo drawing
of 'grid' types (multires mostly?).
There were two issues here:
1) Global gpu buffer was assigned to GPU_PBVH_Buffers->index_buf, but then nearly no
check was done when freeing that buffer, to ensure we were not freeing the global one
(not totally sure this one was actually causing any issue, but was bad and unsafe anyway).
Was solved by adding a flag to GPU_PBVH_Buffers to indicate when we are using some
'common' buffer here, which freeing is handled separately.
2) Main issue: if several multires objects in sculpt mode with different grid size
were present simultaneously, the global gpu buffer had to be resized for each object draw
(i.e., freed and re-allocated), but then the pbvh nodes from other objects storing freed reference
to that global buffer had no way to know that it had been freed, which was causing the segfault & crash.
Was solved by getting rid of that global buffer, and instead allocating one 'grid_commmon_gpu_buffer' per pbvh.
Told ya baby, globals are *PURE EVIL*!
|
|
This commit:
* Removes most of all dirty internal details from public atomi_ops.h file, and move them into /intern private subdir.
* Removes unused 'architectures' (__apple__ and jemalloc).
* Split each implementation into its own file.
* Makes use of C99's limits.h system header to determine pointer and int size, instead of using fix hardcoded list of architectures.
* Introduces new 'faked' atomics ops for floats.
Note that we may add a lot more real and 'faked' atomic operations over integers and floats
(multiplication, division, bitshift, bitwise booleans, etc.), as needs arise.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1982
|
|
|
|
Gives minor speedup entering sculpt mode and with undo.
|
|
On undo, sculpting regular meshes would update _all_ GPU VBO's.
Avoiding the update gives noticeably faster undo.
This is also a fix/workaround for strange behavior with NVidia's driver (T47232),
Where locking and unlocking all buffers for updating
slows down redraw speed permanently after the first undo.
However the problem isn't avoided entirely since a single brush stroke might modify most of the mesh.
|
|
|
|
Should be the last bit of sculpt/paint code, now this is fully using BLI_task.
Note that PBVH normals update is now about 20% quicker than with OMP code
(from 27ms to 21ms with a big stroke over a 500k vertices monkey), even though
a missing thread-protection was added... atomic primitives ftw!
For the records, with the missing `#pragma omp critical` section added,
previous code was like four times slower (above 100ms).
|
|
BKE_pbvh_node_add_proxy/free_proxies.
Not so useful now that we use BLI_task! Not sure why those were ever added actually,
readng carefully that code only modified data here is the PBVHNode, which is only
used/affected by one thread at a time ever. And shared read data (PBVH itself) is
not modified during brush execution itself, so it's safe to use it threaded too.
|
|
Follow isect_ray_tri_watertight_v3 naming.
|
|
Looptri are not mesh data, they are allocated and built for PBVH only, and totally 'local' to it,
so duplicating like we do for verts & co leads to leaking memory.
|
|
|
|
Differential Revision: https://developer.blender.org/D1645
|
|
|
|
Keep index using the outer scope for GHASH iter macros,
while its often nice, in some cases to declare in the for loop,
it means you cant use as a counter after the loop exits, and in some cases signed/unsigned may matter.
API changes should really be split off in their own commits too.
|
|
GPU_buffer no longer has a fallback to client vertex arrays, so remove
comments about it.
Changed a few internal structs/function interfaces to use bool where
appropriate.
Use for-loop scope and flexible declaration placement. PBVH does the
same thing but needs ~150 fewer lines to do it!
The change to BLI_ghashIterator_init is admittedly hackish but makes
GHASH_ITER_INDEX nicer to use.
|
|
Two issues here, normal update was not happening due to own sillyness in
viewport refactor, also normal update code still used triangles.
Now reused Campbell's poly normal recalculation code.
|
|
mode.
Issue from looptri merge.
|
|
Since many callers only need a single triangle
|
|
This stores loop indices into the loop array giving easier acess
to data such as vertex-colors and UV's,
removing the need to store an MFace duplicate of custom-data.
This doesn't yet move all internal code from MFace to LoopTri just yet.
Only applies to:
- opengl drawing
- sculpting (pbvh)
- vertex/weight paint
Thanks to @psy-fi for review, fixes and improvements to drawing!
|
|
Remove legacy code completely, now dyntopo, multires et al even work on
GL 1.1 for really hardcore users :p
Real purpose here though is to be able to have fast multires drawing
even with VBO off, since it requires using indices for vertex buffers.
Also made own code elf puke an eaten normal update function which
made multires not update normals in solid mode...sorry.
|
|
This patch changes the way we draw meshes by introducing
indexed drawing. This makes it possible to easily
upload and rearrange faces ad lib according to any criteria.
Currently we use material sorting but textured sorting and
hiding will be added to optimize textured drawing and skip
per face testing.
It also adds support for vertex buffers for subsurf
modifiers (Except from GLSL drawing), making drawing of
subsurf much faster without need for bogus modifiers.
Tests show that we gain approximately 20-25% performance
by that for solid mode drawing with up to 50% gains for
material drawing. Textured drawing should also have a
small performance gain, but more substantial optimizations
are possible there.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1406
|
|
resolves building with gcc4.9
|
|
|
|
multires.
Code had special guards for such edges to stop this from happening. I
don't see why this is needed though since code above assigns smoothed
positions for all vertices in the grid.
After removing the guards I saw that this in fact was the only place
where grd adjacency was used, so I completely removed it.
|
|
|
|
Clay brush had a feedback loop with dyntopo,
getting the plane from the cursor center didn't support original data.
|
|
Tessellation data isn't used for drawing or sculpting.
This frees up some memory ~approx 10% in own tests.
Also slight spee-up since it avoids calculating it in the first place.
|
|
|
|
|
|
|
|
|
|
https://developer.blender.org/D643
Separates graphics context creation from window code in Ghost so that they can vary separately.
|
|
|
|
Issue wascaused by the famous OpenMP crap in MSVC2013,
so only way is to use openmp threading if number of BVH
nodes is high enough.
Made it 8 for now, which seems to work rather fine on my
laptop and adult dragon from sintel. But maybe it's to be
adjusted a bit more.
|
|
- BLI_BITMAP_SET -> BLI_BITMAP_ENABLE
- BLI_BITMAP_CLEAR -> BLI_BITMAP_DISABLE
- BLI_BITMAP_GET -> BLI_BITMAP_TEST
- BLI_BITMAP_MODIFY -> BLI_BITMAP_SET
|
|
|
|
Looks like the normal update flag is used internally in the modifier
itself. So as a workaround just pass normal update to the nodes when
flood filling
|
|
Cleanup the normal flag or else the smooth tool will work on more and
more nodes as we sculpt.
|
|
|
|
Set hidden when rebuilding the PBVH tree if all primitives are hidden.
|
|
Avoid filling up buffers when total buffer triangles are zero.
Better still would be to tag a node as hidden when doing recreation of
the PBVH tree by checking for any visible elements. Original bug report
probably has to do with OpenGL doing something funky but hidden nodes
should be tagged as hidden to completely avoid iterating for painting.
This is to be done in a later commit.
Also some naming cleanup for consistency, GPU_build_pbvh_mesh_buffers to
GPU_build_mesh_pbvh_buffers.
|
|
To enable enter debug value 14.
Leaf nodes are green while container nodes are red.
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
Store PBVH node ID in CustomData. This avoids a number of hash deletions
and checks/insertions on big hashes.
|
|
|
|
Issue here is that "show diffuse" option does not respect its intended
purpose which is to be used only for masking.
There are a couple of caveats here:
Dyntopo and multires -always- have mask data enabled, and thus as soon
as one goes to dyntopo mode or adds a multires modifier he would get the
default grey color instead.
Matcaps would break when nodes asked for a diffuse material color (this
was broken before too). Solved by adding global material state for when
matcaps are enabled. Also matcaps don't always played well with VBOs
off.
Added a few more missing updates for mask operators to notify
show_diffuse property as changed. This was also needed on rebuilding
dyntopo pbvh.
Also make zero mask color duller again after artist feedback.
|
|
Was marked as a todo in the code.
This does not yet take care of correct display for multi material
meshes, since it would need correct separation of faces during pbvh
creation. Instead we just take material of first face in node and assume
that the rest faces have the same. This will create some funky effects
if one attempts to sculpt in this way.
Note: This does not yet address T39517
|
|
|
|
|
