| Age | Commit message (Collapse) | Author |
|---|
|
It was totally useless to multiply diffuse color with the vertex color
when doing texture painting. It was masking actual texture and only was
forcing artists to create an empty vertex color layer to work this around.
|
|
Normal Map node support for GLSL mode and the internal render (multiple tangents support).
The Normal Map node is a useful node which is present in the Cycles render.
It makes it possible to use normal mapping without additional material node in a node tree.
This patch implements Normal Map node for GLSL mode and the internal render.
Previously only the active UV layer was used to calculate tangents.
|
|
|
|
This generates warnings with MSVC. Similar typecast was
already done in other cases, so think it's all fine.
|
|
|
|
Was called both, however this isn't mainly for uv's so just call 'flag'.
Also remove redundant NULL check.
|
|
Support for skipping hidden faces in sculpt mode w/ texture drawing.
|
|
leading to corrupted geometry.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
|
|
|
|
- Only do this if PBVH is not used for display, this should correspond
to whats' happening in sculpt.c now.
- No need to do such synchronization for solid drawing, it supports
optimal display from PBVH.
In fact, such synchronization is only needed in the following case:
Drawing callback does not support PBVH draw and sculpt session is
configured to use PBVH for display and related operations.
|
|
Regression in 4d33c37c9
Only copy normal arrays from sculpt to the DerivedMesh when the mesh is deformed.
Constructive modifiers calculate their own normals.
|
|
Also rearranged code here to not issue a draw call (explicit flush) per
face and not set shader per face either when stippled drawing is mixed
with regular drawing. Not good at all for performance.
|
|
The is intended to replace the deprecated glPolygonStipple() calls with a shader
based alternative, once we switch over to GLSL shaders.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D1688
|
|
|
|
Habit is a bad thing: Update polys, not tessfaces.
|
|
|
|
GPUBuffer rendering is now done using vertex buffers.
Vertex arrays are completely removed from GL 3.2 core profile, so we'll
have to do this change at some point anyway.
This commit, though big, is not modifying blender in any way. Use should
be exactly as if the vetex buffer option is constantly on.
|
|
This fixes two issues:
* Normals were not being recalculated correctly when not using optimized
drawing for CDDerivedMesh (Multires actually handles that correctly).
* Loop normals (autosmooth option) were also not being calculated. Doing
this calculation is not desirable, since it can't be done correctly
without a severe performance hit. This is easy to test by doing a
dependency flush on the mesh after each scuplt stroke step. Instead they
are now disabled during sculpting.
|
|
shapekey.
Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and
loop normals of a given shapekey.
This will be used e.g. in FBX exporter (shapekeys need normal data too).
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1510
|
|
|
|
|
|
|
|
Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion.
thanks to Sergey for finding root cause!
|
|
|
|
The generic tangent calculation relied on CDDM arrays which aren't available in edit-mode.
Add a tangent calculation callback, which has its own implementation for editmesh data.
|
|
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.
|
|
Caused crash because MFace is no longer a layer which is added unless requested,
causing CDDM to have numTessFaceData nonzero, but mface set to NULL.
|
|
Notes:
* Code in rendering and in game engine will still convert
tangents to a tessface representation. Added code that
takes care of tangent layer only, might be removed
when BGE and rendering goes full mlooptri mode.
* Baking should work discovered some dead code while
I was working on the patch, also tangents are broken
when baking from multires (also in master), but those
are separate issues that can be fixed later.
This should fix T45491 as well
|
|
Looks like derivedmesh draw code always assumed a mesh is available.
Make sure that if we use a bmesh, a flag is used to control that.
|
|
if we skip creating the selection color layer.
|
|
Replace checks in various places
|
|
It's not actually used during drawing though.
|
|
This commit begins implementation of the idea about hidden face
separation outlined in
http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh-
We split hidden and visible faces to different parts of the triangle
buffer.
Mapped drawing will now skip iterating through hidden polys.
Of course the final target, when all derived mesh types use
VBO sorting, is to skip checking for hide flag per face
completely. All faces will be pre-sorted anyway and we'll
be able to draw them with one draw call.
|
|
Separate and reuse some shared code.
Also avoid counting for information we already know,
such as total loop triangles etc.
|
|
|
|
Caused by own fix for too much allocated memory not taking all code
into account.
|
|
don't support VBOs.
Exposed by initialization error in GLEW, which should be fixed
seperately.
|
|
Also 'com' as abbreviation for center-of-mass is a bit confusing, rename to 'center'.
|
|
Code was actually skipping setting color selection indices and previous
commit actually broke mask selection in texture painting.
All should work now.
|
|
|
|
|
|
by scorpion81 on irc
|
|
artifacts in cycles textured mode.
|
|
incorrectly.
|
|
Instead only create MFace layer when its requested
|
|
Easy one, we don't draw quads anymore. Also normal
didn't use polygon index
|
|
subdivision.
Classic integet overflow/size_t substitution case. Machines are getting
powerful enough to easily expose these kinds of error now.
|
|
|
|
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.
|
