- User Since
- Jul 4 2014, 11:26 PM (267 w, 5 d)
Fixed some more cases where T could vary. In particular, edge factor limits weren't applied during recursive resolve of T.
Some existing related tasks: T53901
Fri, Aug 16
Did a simple test to see if branched path tracing is affected by this, and in fact it is, as can be seen in these images. Note that this test was CPU only, so this is a regression and not limited to the new device backend. The branched functions will need to be corrected, I haven't looked too deeply at it yet, but it looks like some lines from the original are missing from the new versions of these functions. I'll do a more thorough look thru and testing later.
- Removed vertex ordering from partition_edge, this caused incorrect stitching.
- Silenced warning about unused variable.
Thu, Aug 15
Updating with diff against master instead of intermediate commit as done by accident in last update...
I think this should fix it. I was able to render a significantly complex scene after making these changes, but more testing would be good.
Wed, Aug 14
This was never committed to master due to a crash discovered at the last minute. The method used here assumes that the T value calculated on each edge is the same for both sides of the edge. While this seems reasonable, there are apparently some uncommon cases where this assumption is wrong. I'm investigating weather the current Diagsplit implementation can be made to ensure that both sides produce the same value, otherwise an alternate approach will be needed.
Thu, Aug 8
Thanks for the contribution!
Tue, Aug 6
Did a quick test and found the following issues:
Sep 14 2018
Attempted to address all style issues.
Sep 6 2018
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.