| Age | Commit message (Collapse) | Author |
|---|
|
https://developer.blender.org/D643
Separates graphics context creation from window code in Ghost so that they can vary separately.
|
|
|
|
|
|
|
|
|
|
|
|
Bring back shading in texture painting.
This works now but it uses 3 texture units instead of two. Most GPUs of
DirectX 8 (OpenGL 1.4 should cover that) functionality even should have
those, but some old GPUs might not work with that. In any case, I hope
we will be moving to OpenGL 2.1 requirement soon anyway where 4-8
texture units are usually the norm.
|
|
Patch by PatB with own edits
- replace BMesh with CDDM functions.
- faster remove-vertex merging.
- extend CDDM_merge_verts to be more flexible.
|
|
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
|
|
Bounds check the stack while debugging, also add STACK_PEEK
|
|
|
|
also rename BLI_edgeset_reinsert -> BLI_edgeset_add, in this case its the same.
|
|
|
|
while hiding verts.
Stupid mistake that showed only when there was some hidden faces
(lnors should always be increased... even when the face is not drawned!).
|
|
|
|
It's still gives some slowdown when painting a locked
key in the solid view, but since shape key is now longer
being re-used by DM.
but this change should still give some degree of speedup
propagating delta onto the keyblock if i remember the
code correct.
|
|
show diffuse option not correctly calculated on opening a file.
Make sure we call pbvh_show_diffuse_color_set after building the pbvh so
vertex data are available to it.
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
too when in "vertex per face" display
So, turned out after all we need a foreachmapped helper for loops as well... :/
CDDM and EBDM were reasonably simple, but I fought hours with CCGDM (subsurf) to find only a
bad working solution (see D478). So I fallback to a code similar to CDDM one.
Probably not nice for performances, but loops and subsurf are not matching well...
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D478
|
|
Don't use a dedicated node layer but use temporary int layer instead.
Works like a charm as long as we are careful resetting the layer when
needed (after pbvh clearing and always after bmesh has been filled in
undo)
Tip by Campbell, thanks!
|
|
|
|
handling.
Most notably, BM_LOOP and BM_FACE index recompute should now be fully decoupled.
|
|
Mostly monkey coding in gpu ("modern" VBO drawing) and DM variants ("legacy" drawing) code...
Reviewers: brecht
Reviewed By: brecht
CC: campbellbarton
Differential Revision: https://developer.blender.org/D367
|
|
here):
* Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf).
EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit.
* Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it
(tessellation, rna access, etc.).
* Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable
split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding
this option is now incoherent, will be addressed in a separate commit.
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D365
|
|
|
|
also replace AT with __func__ since AT expands the full pathname
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
Factorized a bit the code here, think it's more readable now... No performance enhancement though.
Reviewed by: campbellbarton
Differential Revision: https://developer.blender.org/D259
|
|
to true/false in code using them).
|
|
also remove CDDM_Check, theres no need for it.
|
|
|
|
|
|
|
|
|
|
|
|
a wanring :S
|
|
My previous fix for uninitialized texture coordinates was not working well,
and in fact there was a bigger issue with GLSL drawing and missing attributes
with immediate draw mode. Now it will explicitly pass zero rather than having
it use whatever value was set last.
|
|
|
|
pass in the argument to reserve the size.
|
|
|
|
Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.
This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.
The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.
--
svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt
|
|
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now data which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
|
|
|
|
|
|
foreachMappedVert/foreachMappedFaceCenter when needed,
this means in editmode with wire draw, face and vertex normals don't have to be calculated at all.
in most cases the normals are not used so add a flag that makes calculating them only for functions that need them.
also fix face normal calculation for CDDM, was using quad calculation for ngons too.
|
