- User Since
- Aug 20 2015, 12:17 PM (104 w, 5 d)
Sun, Aug 20
Sat, Aug 19
Change add_modifier and a few of the other points.
Took into account some of the feedback on the other version of the patch.
Mon, Aug 14
This is an alternative to D2783 that doesn't involve hacky interactions between curves and modifiers.
Fri, Aug 11
Wed, Aug 9
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.
Fri, Aug 4
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.
Oct 1 2016
Sep 28 2016
Sep 27 2016
Here is a simple test: without the fixes the paint can't spread through one edge just next to the source, yet can mysteriously jump to a separated corner.
Sep 20 2016
Can you test if it now works if you just bind to the mesh without applying the displace modifier? I have reported the fact that it didn't work properly almost a year ago as T46944, and it is supposed to have been fixed.
Sep 10 2016
Sep 8 2016
It works perfectly in 2.78 RC with the file by @Greg Zaal (gregzaal) above, and just posting screenshots is a rather useless thing for testing stuff.
I cannot reproduce this in 2.78 RC, so I suspect this is already fixed as T49187.
Sep 5 2016
Sep 4 2016
Well, looking at the code, it seems that the smoke and dynamic paint simulations fiddle with the scene-global current frame field in order to do emitter/collider subframes, so that section of the simulation code obviously cannot be run multithreaded at all. Disabling subframes for the emitters here seems to remove the bug as would be expected if this is the cause.
Sep 2 2016
Aug 30 2016
Aug 29 2016
Aug 28 2016
Aug 26 2016
This close to the release the safest approach may be to revert the modified version that applies to all objects, and apply my original that only works on particles. Changing the current code to only work on particles may be tricky, because it uses invalid transforms to store the state instead of separate bool flags that can just be safely ignored for non-particles.
That's how my original patch worked, but @Brecht Van Lommel (brecht) decided to apply it to everything.
This is an example of those artifacts. They are very noticeable among other normally rendered particles, and even in the best case can only be removed by manual touch up of the image.
This is sort of by design: rB1f19fba566