- User Since
- Aug 20 2015, 12:17 PM (83 w, 3 d)
Thu, Mar 9
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.
Sun, Mar 5
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
Aug 22 2016
Aug 20 2016
Aug 16 2016
Aug 13 2016
Updated according to feedback, and added a sentence about removal of nodes not connected to output.
Aug 12 2016
@Sergey Sharybin (sergey) said that particles may actually be evaluated by the final ubereval, so add links to geometry when processing particle-emitted force fields just in case. Redundant links are less of a problem than missing ones.
Aug 11 2016
Aug 9 2016
Added to TODO wiki page, so I think this can be archived.
Upon reflection, move the callback function handling to the depsgraph specific code to reduce changes in collision.c.
The amount of code duplication between new and old depsgraph that this causes is negligible.
Aug 8 2016
Here are some test files for collision and force field relations:
Add depsgraph resets to rna for collision group fields, and more dependencies on transforms for new depsgraph.
This is a test for rigidbody, cloth and softbody in order from left to right. All of them are partially baked to current frame, and should render as stopping.
Aug 7 2016
Aug 6 2016
Aug 5 2016
This is the risk of changing semantics of already existing fields to store extra state: now all code that uses motion must check the values are valid. The checks for mtfm_pre/mtfm_post specifically fix the speed problem here.