Issue was caused by VBOs using CD_TEXTURE_MCOL for faces colors. This
layer was creating on mesh display (from draw_tface_mapped__set_draw)
in cases there's no such a layer.
If material settings are changing, this layer wasn't updated and old
colors were used.
Fixed by performing an update of this layer in cases it's already
exists. This would give some % of slowdown, but don't think it'll
be dramatically bad.
Would be nice to find a nice way to update such a layer in cases
material is actually changes only, or get completely rid of it/
There is an FAQ that mentions a mythical GL_LIGHT_POSITION, and lots of programmers speak of it, but this mythical creature does not exist!
The correct symbol is GL_POSITION
mask drawing.
Now refactored the code a bit so that in no longer calls textured mesh drawing
for the face mask drawing, just handle it as part of regular paint color drawing.
Should also make the blender internal behavior more logical where it would start
showing textures in solid mode when enabling face masking.
It was a regression since 2.62 caused by how texface is passing to drawParamsMapped
Previously it was used from CD layer but now it's getting copied from MexPoly
into a variable allocated in stack for function void emDM_drawFacesTex_common.
To set texture needed to draw particular face function set_draw_settings_cached
is used, which tries to not to copy texture into GPU when it's not needed (for
example, when drawing bunch of faces with the same texture) and one of condition
if texture should be updated in GPU was comparing address of texface passed to
this function and cached texface. But this address are exactly the sane and
points to a memory inside stack of emDM_drawFacesTex_common.
Fixed by cacheing texface content, not it's address.
old mesh MCol 'r' was blue, 'b' was red, but theres no reason to keep this for bmesh with MLoopCol.
Loading old files works, saving legacy format works too.
What wont work is loading a file after this revision and loading it in an older revision since the bmesh merge.
(it wont crash but the blue and red will be swapped on vertex color layers).
The DMSetDrawOptions[Tex] callbacks return 0 (skip), 1 (draw), or 2
(either stipple or skip mcols.) In the CDDM, EDDM, and CCGDM draw
functions, as well as the callbacks in drawmesh/drawobject, replace
these numbers with values from an enum, DMDrawOptions.
This function pointer's 'setDrawOptions' parameter took a slightly
different type than the other drawing callbacks. In particular, it
could set a 'drawSmooth' value to indicate that smoothing should
always be enabled, overriding the face flag. However, all callbacks
either did not set this value, or set it unconditionally to
1. Replaced this by adding a new 'flag' parameter to drawFacesMapped,
which can be set to DM_DRAW_ALWAYS_SMOOTH where appropriate.
Also removed the 'useColors' parameter and replaced it with another
flag value, DM_DRAW_USE_COLORS.
Removed the 'wpaint__setSolidDrawOptions' callback, was only being
used to set the shading to smooth.
It's currently not respecting the material color, probably since the
BMesh merge. There are a couple problems, both involving "dummy"
variables taking the place of actual MTFace/MCol data.
Code review: http://codereview.appspot.com/5753050/
These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete.
This uses similar convention to RNA.
* use face/loop/edge/vert as a prefix for functions.
* use 'elem' as a prefix too for functions that can take any type with a BMHeader.
* changed from camel case to underscore separated (like RNA).
User side:
* Preview for DynamicPaint should keep the same behavior (for now). Weight preview should be somawhat quicker, though.
* Preview for WeightVG modifiers is only active in WeightPaint mode, and if the affected vgroup is the active one.
* Last active preview modifier in stack wins!
Note: that modifier preview topic is yet to be further refined, quite raw/incomplete for now.
Dev side:
* In draw code, renamed DRAW_DYNAMIC_PAINT_PREVIEW flag to DRAW_MODIFIERS_PREVIEW
* Removed use of MOD_DPAINT_PREVIEW_READY in DynamicPaint code (seems unecessary, and if it was, should be of more general scope).
* Added eModifierTypeFlag_UsesPreview to ModifierTypeFlag, for modifiers that can generate some preview data.
* Added three new modifier funcs, to handle preview modifiers in draw code / mod stack.
* For weights preview: added the generic DM_update_weight_mcol func, which can update WEIGHT_MCOL layer with either a given array of weights (currently used by DynamicPaint only), or from current active vgroup(s).
So now, draw code is fully generic (i.e. no more modifier-type checking in it). Mod stack code is generic to some extent, but will need more work.
Structures passing to DM callbacks as userData used to be defined in both callee
and callbacks itself which made it difficult and unsafe to add new properties
to user data.
Added typedefs for this structures and use them in callbacks and callee functions.
- Pass MFace, MTface and OrigIndex arrays via userData to compareDrawParams callback
rather than looking up for this layers for each face
- This allowed to avoid massing DM to compare callback which seems like a bad-level pass
- Fixed crashes on some video cards when assigning different materials to different
faces in edit mode. Both of intel and nvidia cards in my laptop were affected by
this error
