Source (i.e. other) mesh should not be modified in any case in modifier
evaluation case (this is forbidden by design and can lead to all kind of
threaded locks and crashes), and doing so even in operator case was
never a good idea either.
Now that we can specifically request needed data (poly and/or loop
normals) from evaluation code, we can finally get rid of those
computations inside data transfer/mesh remapping area.
This is hopefully the last remaining bit of this 'bad crashing code' in
datatransfer area.
In some cases (currently, only when using avanced mapping of loops),
code needs access to some cddata of the source mesh (CD_NORMAL...).
We need a way to inform calling code about that (actual issue requiring
this change is fixed in next commit).
This is merely making behaviors of this function a bit more explicit,
and avoid re-adding another CD_NORMAL layer to polys in the (unlikely)
case it would already have one.
It also handles CD_MASK_NORMAL in cd_dirty_poly, but this is more like
future-proof thing, this is not used anywhere currently afaik.
This change displays the stroke in the deformed position, but the edition is done in rest position.
This is no the final solution, but at least we have some visual feedback in edit mode.
The real solution is to create a full system to manage derived strokes in Edit mode, but this needs a lot of work and we haven't resources now to do it.
* Rename "Use Smoke Highres" to "Use High-resolution Smoke"
* Use 'Display' instead of 'Draw', following the naming conventions in 2.8
* Drop the 'Use' prefix in the UI, a "High-resolution Smoke' checkbox sufficiently communicates what it does.
This removes special dependency graph code that was intended to avoid GPU
shader recompiles by preserving the node tree and GPU material in specific
cases. This is no longer needed now that we have a general shader pass
cache that compares the generated shader code. The GPU material is already
being freed in material and world eval as well, so there's no point.
Note also that GPU materials are now safe to free from threads, actual
OpenGL buffer freeing happens delayed.
Commit 208fafb to fix bevel tool units included a change to always
start modal in offset mode. This was may or may not be right but
broke a way in which users could set percent mode and then subsequently
start a modal that bevels in that mode. So going back to old way.
GHOST event handling does not need a window in the context, and restoring
it to the previous value is problematic if the window was deleted in the
meantime.
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
The UI was trying to use screen_context.c for its poll and draw
functions. So the active object and active object data and active layer
was used in the UI, instead of the context one.
Besides, for the material, the wrong context path was used altogether
when the active object was a greasepencil.
This would lead to all sort of pinning problems:
* A Mesh panel is pinned, but the active object is a grease pencil, the
grease pencil panels would show.
* If a Grease Pencil (data) panel is pinned, but the active object is not
the one pinned, nothing would show.
* Material panels and pinning were totally broken, showing the material
context for pinned mesh data panels even.
I also sanitized the name of the panels, their inheritance and poll
functions.
Reviewers: antoniov, brecht
Subscribers: billrey
Differential Revision: https://developer.blender.org/D4470
The issue was that `bNodeSocketValueVector` and `bNodeSocketValueRGBA`
don't store the value at the same location in the struct.
I kept the cases for `SOCK_VECTOR` and `SOCK_RGBA` completely separate
for now, because they only share code by coincidence and not because
they are actually the same. Eventually there could be a "Vector Input"
node similar to the "RGB" node.
Reviewers: fclem
Differential Revision: https://developer.blender.org/D4472
The fix was move the grease pencil engine before overlays
This also fix the origin not visible bug T62100
There is a limitation of this fix, but we cannot fix both problems. If you have object behind a transparent graese pencil objects, this objects will not be visible.
Thanks @fclem for his advices to fix this bug.
The SubdivCCG structure was re-allocated, but the cached one in
the sculpt session was still pointing to an original one.
This is rather a workaround, but is least evil from what i can
currently think. Remember something similar was also required in
2.7 as well.
Definitely need to revision this change.
