- User Since
- Jul 4 2014, 11:26 PM (206 w, 4 d)
May 16 2018
May 12 2018
Thanks @Sybren A. Stüvel (sybren) for the review.
May 11 2018
May 8 2018
May 3 2018
May 2 2018
Apr 24 2018
Apr 18 2018
Apr 17 2018
Apr 12 2018
Pretty sure this is the difference between decoupled volume sampling on the CPU vs regular volume sampling on GPU (decoupled isn't supported on GPU). Doesn't look like a bug to me.
Apr 10 2018
Apr 4 2018
Oops, used the wrong variable, will commit a fix shortly.
Mar 24 2018
Could you please find and run the program clinfo and attach the output, it will help in figuring out why your card is listed when it shouldn't be.
Mar 23 2018
Please check that your drivers are up to date.
It looks like your GPU is from GCN 1 generation. Its unfortunate, but support for those cards had to be dropped. Your card shouldn't have been available to select for GPU rendering, did you enable debug mode? This mode isn't meant for regular use, and cant be expected to function properly. If you didn't enable debug mode and were still able to select your card then that would be a bug we should fix.
Mar 10 2018
Narrowed this down further to some bug in the proprietary Nvidia drivers, at some point after version 381.22. Still nothing in the logs.
Mar 7 2018
This has already been fixed, but the fix wasn't included in 2.79a.
To disable drawing I had made the ED_gpencil_draw_* functions in drawgpencil.c in master branch noops.
Mar 6 2018
Bit of an update...
Mar 3 2018
Mar 2 2018
Mar 1 2018
After playing with this for a while I'm not sure things are broken, at least for Linux. It feels like something had changed which is why I thought this might have been broken, things could definitely be in proved in this area.
Feb 28 2018
Also not working correctly on Linux (kkc / ibus). I can enter Japanese text into the text editor and object name boxes, but not in the python console or edit text objects.
Feb 21 2018
Feb 15 2018
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.
Feb 13 2018
Must have been caused by a recent commit then.
Feb 7 2018
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).
Feb 6 2018
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.
Feb 4 2018
The displacement issue should be opened as a separate task for organization purposes.
Feb 2 2018
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.
Jan 25 2018
Yay, finally renaming the displacement methods!
Jan 24 2018
Jan 23 2018
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.