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
triangles.
It is possible to end up with such nodes using brushes in aggressive
collapse mode. Those nodes should normally be cleaned up, since they can
never be actually reused (adding more geometry to a node requires the
node having some geometry to begin with) but until we support dynamic
nodes, better delete those to avoid binding graphics driver resources.
If such zero elements buffers were used, GL error out of memory would be
reported.
This commit does various changes for matcaps:
One is taking advantage of drawing with pbvh (which would only happen
with dyntopo previously) and drawing with partial redraw during
sculpting.
The second one is support for masks. To make this work in the special
case of multires, which uses flat shading, I use the only available flat
shaded builtins in OpenGL 2.0 which are color and secondary color.
Abusing colors in that way is also essential for flat shading to work if
we are to use pbvh draw in multires, since it is the color that is being
interpolated flatly, not the normal (which can only interpolated
smoothly). The pbvh drawing code for multires used last triangle
element's normal to compute the shading which would only produce smooth
results. This could change if we did the shading in the vertex shader
for flat shaded primitives, but this is more complex and makes it harder
to have one shader to rule the mole.
Also increased the brightness of the default diffuse color for
sculpting. This should be useful since artists like to tweak the
lighting settings and it will give them the full dynamic range of the
lights, but also it helps with correct brightness of sculpted matcaps.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D435
A question here might be: why?
The answer is that GPUs will convert this to triangles so we are wasting
memory during conversion of the element buffer to a triangle buffer
anyway.
The second reason is that some modern GPUs are slower rendering GL_QUADS
The third reason is that due to element caching, this should not in
theory be slower (cached elements do not get recalculated on the GPU).
Main issue here is that glBuf* calls were invoked from threads different than
main thread. This caused a crash (since those do not have a GL context active).
Fix here is twofold:
* add an ID buffer in buffer pool that handles pbvh buffers and is freed
from main thread when gpu_buffer_pool_free_unused is called.
* do not create glbuffers in derivedmesh creation routine, rather tag nodes
for update and create those in the draw function
(guaranteed to be called from main thread)
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D169
Code in GPU_buffers_free was already trying to be safe
for threading, by skipping OGL calls there, but in fact
it was still buggy.
Namely, freeing was doing buffers shift in a cycle, and
if two threads will call this function shifting will go
crazy.
Now made it so GPU_buffers_alloc and GPU_buffers_free
are using mutex lock, so they're completely safe for
threading. Same goes to gpu_buffer_setup function.
It required minor functions reshuffle, so there're no
locks happening from locked thread, but it's all very
straightforward change
--
svn merge -r58276:58277 ^/branches/soc-2013-depsgraph_mt
after objects are deleted until another big object is added. There's no good reason
to do this, or to think that our pool is somehow much faster than using the OpenGL
API to allocate and free buffers.
Moved the GPU function gpu_bmesh_face_visible() to BKE_paint and
inverted the test to match equivalent tests for other mesh types:
paint_is_bmesh_face_hidden().
Changed BKE_pbvh_bmesh_node_save_orig() to not save hidden faces into
the triangle array.
Modified the non-use-original branch of pbvh_bmesh_node_raycast() to
skip hidden faces.
Fixes bug #33914:
projects.blender.org/tracker/index.php?func=detail&aid=33914&group_id=9&atid=498
This adds an override to the CDDM edge drawing function that switches
to GPU_Buffers drawing for PBVHes of type PBVH_BMESH.
Within the GPU_Buffers code, glPolygonMode() is used to draw lines
instead of faces.
The GPU interface for PBVH drawing gets a new pair of build/update
buffers functions for drawing BMFaces and BMVerts.
TODO: the diffuse color is hardcoded to 0.8 gray rather than using
material color.
TODO: only VBO drawing is implemented, no immediate mode.
Refactoring of draw code showed another problem: The MCol we want to draw may change without dm rebuild (e.g. when enabling solid textured option)! Also, choosing which MCol layer to use in GPU code is stupid, different draw modes use different layers/order of precedence!
Solved this by adding a new colType parameter to GPU_color_setup, and removing any 'color choosing' code from gpu_buffers.c.
Appart from the color glitch, there was several problems with vpaint:
* "fast_update" mode was never on, because of wrong testing code;
* drawing refresh during stroke in "fast_update" (i.e. no dm rebuild) mode was broken in VBO mode, because updated (tess data) mcol wasn't moved to colors GPUBuffer.
Solved the later point by adding a new DM_DIRTY_MCOL_UPDATE_DRAW flag to DerivedMesh dirty var, which is set each time vpaint stroke directly update me->mcol, and forces GPU_color_setup() to refresh the gpu's colors buffer.
Also got rid of the uggly GPU_color3_upload(), which basically did the same thing, but with an additional intermediate buffer !
Added option to display object's diffuse color multiplied by sculpting
mask. This option could be found in Options panel of toolshelf when in
sculpting mode.
Thanks to Nicholas and Brecht for reviewing the patch!
Was a mistake in a code cleanup commit, r51118.
Fixes bug [#32919] Sculting performance regression in svn_51118
projects.blender.org/tracker/?func=detail&aid=32919&group_id=9&atid=498
Separate vertex copies are now made for flat-shading, such that the
normal is correctly flat-shaded. The element index buffer is not
created in this case.
* De-duplicate GPU code to check if VBO should be used.
* Add a flag to indicate if the buffer should be drawn smooth or not,
rather than checking each time the node is drawn.
This changes are not stable enough and trying fix it could backfire in some
other regressions which isn't wanted so much close to the release.
This means objects will have gray color as diffuse which becomes darker in
masked areas for 2.64.
Proper fix is aimed for 2.65.
This commit reverts 50827 and 50898.
It was missing since sculpting mask implementation.
Now object's color would be multiplied by sculpt mask value.
For VBOs it's done by storing final color in VertexBufferFormat and
mimic behavior of setMaterial callback for getting current diffuse
color.
For non-VBOs diffuse color is getting from current OpenGL context.
Crash was caused by incorrect restoring OpenGL context due to some
weird bit operations used to indicate whether stuff like color arrays
is initialized resulting in some unpredictable results on different
platforms and drivers.
