Patch from be28706 made it so integrator will use last shader's transparent
shadow flag, which is wrong since last shader might not have transparent
shadow while shaders prior to it might have one.
CYCLES_OPENCL_TEST was removed, there was an insonsistency between
opencl_kernel_use_split() and opencl_get_usable_devices().
From now on, to test non whitelisted devices please use either
CYCLES_OPENCL_MEGA_KERNEL_TEST or CYCLES_OPENCL_SPLIT_KERNEL_TEST.
This commit changes the way how we pass bounce information to the Light
Path node. Instead of manualy copying the bounces into ShaderData, we now
directly pass PathState. This reduces the arguments that we need to pass
around and also makes it easier to extend the feature.
This commit also exposes the Transmission Bounce Depth to the Light Path
node. It works similar to the Transparent Depth Output: Replace a
Transmission lightpath after X bounces with another shader, e.g a Diffuse
one. This can be used to avoid black surfaces, due to low amount of max
bounces.
Reviewed by Sergey and Brecht, thanks for some hlp with this.
I tested compilation and usage on CPU (SVM and OSL), CUDA, OpenCL Split
and Mega kernel. Hopefully this covers all devices. :)
This mainly adds bpy.data.user_map() method, which goes over the whole Main database
to build a mapping (dict) {ID: {users_of_that_ID}}.
Very handy to check and debug ID usages, but could also be really valuable for py addons
creating temporary scenes, or some exporters, etc.
Note: current code in master's libquery misses some IDs (and reports some it should not,
like nodetrees), this is fixed in id-remap but still needs serious review before going to master.
This basically means that current bpy.data.user_map() **will not** report a complete and exhaustive
state of dependencies between IDs. Should work OK in most cases though.
Original work/idea comes from id-remap branch, was heavily reworked by @campbellbarton
and myself for master.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D1678
The issue was caused by wrong scaling applied on top of the image sampling.
It seems there's no reason to apply alpha clipping when using EWA filtering,
this filtering currently works in the way that it apples all needed clipping
and scaling to a clipped kernel already.
Note that this has little impact on current master - yet it allows to fix the 'Image Editor' bug
(open image in editor, use same image in texture, delete image from texture, image us is 0 and
red in image editor...) and probably a few other similar cases.
But that change is mandatory to get a proper handling of ID deletion/reamapping/reloading/etc. as done in id-remap branch.
Instead of just adding a user if none already present, new code use two new ID tags to get a three-states status:
- Normal: nothing changes.
- Needs extra user: we know that ID needs an extra user, so we take of never going down to 0 in 'real' usercount handling.
- Has extra user: we do have increased that ID usercount to get our needed extrauser.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1696
This can happen quite often in forloops, and would be annoying to have to check for this
in caller code! So now, just return without doing anything in this case.
Looptri are not mesh data, they are allocated and built for PBVH only, and totally 'local' to it,
so duplicating like we do for verts & co leads to leaking memory.
The remaining bits in editors' sculpt.c, which is now free from OMP.
All in all, changes in this file allow from below 2% to above %20 speedup per stroke, depending
on brush complexity, size, and definition of the mesh below it...
Note that this commit also unifies all 'threaded data' into a single struct, a few more
floats/pointers do not hurt here, and it makes code a bit simpler.
The idea is to split them into two separate targets and have dedicated include
directories list for each of them in order to avoid some annoying include header
modifications in comparison with upstream.
Reviewers: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1706
It also fixes another issue (crash) related to symmetric editing.
Quite involved, we (try to!) fix complete broken logic of parts of particle code, which would use poly index
as tessface one (or vice-versa). Issue most probably goes back to BMesh integration time...
This patch mostly fixes particle editing mode:
- Adding/removing particles when using generative modifiers (like subsurf) should now work.
- Adding/removing particles with a non-tessellated mesh (i.e. one having ngons) should also mostly work.
- X-axis-mirror-editing particles over ngons does not really work, not sure why currently.
- All this in both 'modes' (with or without using modifier stack for particles).
Tech side:
- Store a deformed-only DM in particle modifier data.
- Rename existing DM to make it clear it's a final one.
- Use deformed-only DM's tessface2poly mapping to 'solve' poly/tessface mismatches.
- Make (part of) mirror-editing code able to use a DM instead of raw mesh, so that we can mirror based on final DM
when editing particles using modifier stack (mandatory, since there is no way currently to find orig tessface
from an final DM tessface index).
Note that this patch is not really nice and clean (current particles are beyond hope on this side anyway),
it's more like some urgency bandage. Whole crap needs complete rewrite anyway,
BMesh's polygons make it really hard to work with current system (and looptri would not help much here).
Also, did not test everything possibly affected by those changes, so it needs some users' testing & validation too.
Reviewers: psy-fi
Subscribers: dfelinto, eyecandy
Maniphest Tasks: T47038
Differential Revision: https://developer.blender.org/D1685
