Everything I've tested works fine without these hacks. Variety of Mac, Linux, Windows, Intel, nVidia, AMD.
If these workarounds are for old unsupported systems let's clean house.
Reviewers: #opengl_gfx
Differential Revision: https://developer.blender.org/D1707
This uses selection history to select the next vert/edge/face based on surrounding topology.
Select previous just removes the last selected element.
Uses key-bindings: Ctrl-Shift +/-
This isn't really ideal fix, but currently i can't tell how proxies should work
with the new dependency graph. This backward links are crazy, non-threadsafe
and mindblowing. Need to do some smarter/easier system.
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
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
nVidia Linux driver reports GL_CONTEXT_PROFILE_MASK = 0, which is a bug.
In that case check for the ARB_compatibility extension.
Non-buggy drivers will continue to use
GL_CONTEXT_COMPATIBILITY_PROFILE_BIT.
Thx to Dr Hackerman for reporting.
This time, all tools' code itself.
Not much to say, except that we can also get rid of that OMP caching pre-process ugly stuff
for multires smoothing.
Together with previous commit, we have about 5% average speedup on stroke execution
(though this vary a lot, up to 30% speedup in rare cases, and in even rarer cases some
odd massive slowdowns...).
Tech note: we may want to add 'guided'-similar feature to our BLI_task threaded loop,
I suspect this could explain random massive slowdowns of new code (very rare, but annoying...).
Logic here is weird. Generally, textured drawing overrides
material color unless material uses object color instead?
It doesn't make sense, material color is a material color
whatever the circumstance.
Repeating: idea as always is to push all those options out of per-
polygon callbacks and make decisions such as color enable in the higher
level functions.
It would be good to get rid of this entirely, ideally decision
about mcols can be taken at material level and not done per face. More
work needs to be done for that to work though.
Only used for color for now, but we need this for any kind of buffer
updates actually.
This should get rid of some allocation/deallocation, making
vertex painting a bit faster.
This commit adds "Bands Saw" and "Rings Saw" to the options for the Wave texture node in Cycles, behaving similar to the Saw option in BI textures.
Requested by @cekuhnen on BA.
Reviewers: dingto, sergey
Subscribers: cekuhnen
Differential Revision: https://developer.blender.org/D1699
