- User Since
- Jul 4 2014, 11:26 PM (189 w, 4 d)
Thu, Feb 15
I'm not entirely sure what the cause is, but it seems to related to the number of hair segments interacting strangely with interpolation. There are plans to replace particles with a new system, so not sure if this will end up getting fixed in the current system or not. In the mean time increasing the 'steps' parameter should give you a better result.
Tue, Feb 13
Must have been caused by a recent commit then.
Wed, Feb 7
I'm not really sure which version would be 'correct' in this case, as the changes that are related to this aren't recent and come from both master and 2.8. I think this should be fine as long as no one has intentionally set the draw size to 0 recently (cant imagine why someone would).
Tue, Feb 6
This fixes an issue where old cache data was used after an object has been moved. Particles were coming from very wrong positions. Reproduction case is to move an object while animation is running and then let the animation loop back and play again.
Sun, Feb 4
The displacement issue should be opened as a separate task for organization purposes.
Fri, Feb 2
Builds are done nightly, so look for it tomorrow.
I'm unable to reproduce. Are there any other steps that lead to crash? Try checking that your drivers are up to date.
This was caused by 7261d675e6aeb. Nothing to do with displacement, but rather bad memory access in OSL code.
Thu, Jan 25
Yay, finally renaming the displacement methods!
Wed, Jan 24
Tue, Jan 23
Might need fixing in the split kernel as well.
Looks mostly good, would be great to finally have this done.
Jan 22 2018
Why didn't this go thru review? This doesn't work for ngons. Are you sure the tangents produced by this method are correct for Catmull-Clark subdivision?
Jan 19 2018
Jan 11 2018
Dec 5 2017
Segfault is happening on line 312 of datatoc_icon.c, looks like canvas_w (and _h) from the first icon loaded isn't matching the head.canvas_w of later icons, causing pixels_canvas to be allocated too small. Not sure why the canvas sizes aren't matching tho.
Also happens on Arch with Inkscape 0.92.2.
Nov 30 2017
Nov 28 2017
Nov 27 2017
Nov 26 2017
Updated to current branch state:
- ShaderEvalTask is split kernel only again.
- ShaderEvalIntent is passed to shader eval functions instead of path_flag and max_closures.
- Minor cleanup
Nov 21 2017
Nov 16 2017
Nov 15 2017
Nov 14 2017
Nov 11 2017
Nov 9 2017
Nov 2 2017
Oct 25 2017
How valid is it really to use the perspective camera projection for points outside the frustum? It provides a smooth transition at the frustum edges, but the further you go away it doesn't seem so meaningful. A panorama camera projection may be better.
I haven't heard anything back from them in a while, I'll try contacting them again and see what the status is. Hopefully it won't take long to get fixed.
Oct 20 2017
Oct 2 2017
Sep 27 2017
Sep 19 2017
The image node is set to box projection, which might be using the wrong coordinate system during bump evaluation.
Could be a duplicate of T52645, which was closed for some reason...
Sep 4 2017
Looks to be the same compiler crash from T52589. Not sure if there's anything we can do as there's no proper error from the compiler. I don't think reverting to older drivers will help in this case either, as the crash is likely an existing issue triggered by some code change we made at some point. Maybe someone could bisect this, could help the compiler team in getting this fixed.
Please keep the discussion to the reported crash only. Discussion of other stuff can happen in irc, mailing list or another dedicated task.
Aug 31 2017
The crash appears to be coming from the driver, AMD has been notified.