- User Since
- Aug 20 2015, 12:17 PM (113 w, 3 d)
Wed, Oct 18
Tue, Oct 17
Mon, Oct 16
Moved updates into add_modifier and remove_modifier.
Tue, Oct 10
Sat, Oct 7
Tue, Oct 3
Mon, Oct 2
Sun, Oct 1
Sat, Sep 30
After more looking at it: nobody would want this simplistic symmetry that is not aware of vertex group mirroring, and the proper old weight paint specific mirroring is not compatible with parallelism as it updates the mirror vertex inside the single vertex paint function. Plus, vertex group mirroring is another reason why weight paint may affect more than one weight value per vertex.
I just happened to start working on an idea I had more than a year ago and noticed that this commit basically rewrites weight painting while apparently completely ignoring the existence multipaint for some strange reason. I didn't actually test, but I bet it's now broken.
Sep 22 2017
Removed lib_link stuff and made BKE_fcurve_is_cyclic non-static.
Sep 19 2017
After a discussion in IRC it seems D2783 is the way to go, at least for now.
Sep 11 2017
Why no reply for almost a month?
Sep 1 2017
Try Principled with Transmission = 1.
Aug 29 2017
Aug 20 2017
Aug 19 2017
Change add_modifier and a few of the other points.
Took into account some of the feedback on the other version of the patch.
Aug 14 2017
This is an alternative to D2783 that doesn't involve hacky interactions between curves and modifiers.
Aug 11 2017
Aug 9 2017
As I understood the config in blender includes Base Contrast into the Filmic space itself, probably as a hacky way to make it in effect default to Base Contrast and thus improve usability for new users. The 'Base Contrast' option thus becomes a no-op.
Aug 4 2017
Jul 16 2017
May 31 2017
May 29 2017
May 21 2017
May 20 2017
May 19 2017
The *_fac versions evaluate the input with saturation, i.e. <= 0 and >= 1; could also be called *_clamped potentially.
May 11 2017
If I understand the physics correctly, the Transparency node should be basically equivalent to 'glass-type' transparency with IOR exactly equal to 1: all reflection and refraction effects (including microfacet roughness) disappear, and only surface absorption remains. If so, maybe the node could potentially use the transparency closure as a special case if the index of refraction is set to 1. Even now, it seems to work as you would expect: no reflections/refractions, and the transmitted light is multiplied by color.
May 10 2017
Well, I think that emission and cutout transparency (i.e. holes) can be handled perfectly well by mixing in other nodes, unlike translucency (diffuse transmission, which should share energy with diffuse after glossy), so it's not a priority; and the node may have enough parameters already. Also, is somebody writing a manual entry for it already? ;)
Apr 29 2017
Mar 9 2017
No idea why this happens, but an easy and quick solution is to bake the particle simulation so that rendering uses previously computed correct particle positions instead of computing them again on the fly.
Mar 5 2017
I'm not sure User Preferences is good enough, because loading and saving a blender file with a wrong config can lose data in the form of color space selections in various places.
Feb 24 2017
There are two factors to consider here:
Jan 12 2017
Jan 11 2017
I guess better to archive this until 2.8
Jan 7 2017
It seems to be a floating point precision limitation in raytracing around line 405 of elbeem/intern/solver_interface.cpp, causing an infinite loop.
Jan 5 2017
It's something of a known problem, and probably won't be addressed before 2.8. Basically, the collision modifier doesn't know if anybody would need collision, and thus always prepares the necessary data. This is somewhat mitigated in master by detecting when the object doesn't move and skipping updates, so static objects cause less of a hit, and you can also disable dedicated colliders by disabling modifiers that move them.
Jan 4 2017
Jan 3 2017
The test for my previous dynamic paint patch also demonstrates the effect of this change:
Updated with const and spaces around operators.
Dec 21 2016
Dec 10 2016
Dec 5 2016
Nov 7 2016
Nov 6 2016
I wonder if for 2.8 blender should switch to the new version of the spring constraint in bullet - from descriptions it seems to be better, but is not backwards compatible (especially the damping parameters). For that reason bullet itself has both old and new side by side.
Nov 5 2016
Oct 16 2016
Generate works just fine. The errors come from the actual generated script when you are posing the rig, and are caused by the changes in the script re pole targets: the pitchipoy version has the code commented out, but original expects it to be there. E.g. when you select knee pole target bones, this gets printed to the console:
Oct 15 2016
I noticed python errors and found this change broke custom mixed metarigs using original base with just some pitchipoy additions.
Oct 7 2016
Now the is_static flag is reset wherever bhvtree is reset to NULL, so it should be consistent.