User Details
- User Since
- May 27 2008, 4:40 PM (560 w, 1 d)
Apr 8 2018
Many thanks to Brecht for the revision! It works just fine as far as I tested.
Apr 7 2018
Feb 28 2018
Hi Dalai,
Feb 27 2018
Just for record, I quote from D3084 the reason of reverting:
It turned out that I was testing the patch based on an old copy of the blender2.8 branch. After a merge-and-push, a Freestyle-enabled Eevee F12 render leads to a crash. I should have tested the merged code before pushing it to the repository. I have just revered the commit for now. The crash comes from a to-do item described as Note 2 of the commit rBc14925bddf9b, and related work seems ongoing on the temp-render-depsgraph branch. I will wait for the things settled and then bring the patch back to the repository.
It turned out that I was testing the patch based on an old copy of the blender2.8 branch. After a merge-and-push, a Freestyle-enabled Eevee F12 render leads to a crash. I should have tested the merged code before pushing it to the repository. I have just revered the commit for now. The crash comes from a to-do item described as Note 2 of the commit rBc14925bddf9b, and related work seems ongoing on the temp-render-depsgraph branch. I will wait for the things settled and then bring the patch back to the repository.
Feb 26 2018
Since this is the first time I touched the Eevee related area of code, I would add three of you as a tentative group of reviewers. Please, introduce a better reviewer if any.
Feb 8 2018
Thanks Brecht and Dalai for the prompt reviews. I was not aware the "Use Freestyle" option was missing also in master. My bad, sorry Dalai for the confusion.
Feb 7 2018
Feb 6 2018
Feb 5 2018
Thank you all for the prompt reviews, and thanks @Brecht Van Lommel (brecht) for spotting the cause of the crash. I confirmed that fixing the suggested line of code resolved the crash. But still the copying of Cycles options from one scene to another does not work. Even after the RNA_STRUCT_BEGIN(&freestyle_cycles_ptr, prop) ... RNA_STRUCT_END block as in the removed code block, the Cycles parameter values remain the default ones (e.g., cycles.samples is 128 no matter how it is set in the user-defined scene). Any suggestions of where to check out?
Sep 19 2017
Animated edge marks could be a partial solution (a workflow in this approach could be tedious and even not applicable in some cases though) -- see https://wiki.blender.org/index.php/User:Kjym3/DevFundProject/InterimReport for more information.
Feb 16 2017
Jan 31 2017
Jan 30 2017
Jan 11 2017
Just a report of a compilation error with VS 2015. A comment is inlined.
Dec 28 2016
Dec 5 2016
I confirmed this is a regression from the 2.76 release. I will look into the issue.
Nov 18 2016
Thanks Bastien for the triage, and I confirmed the issue on my side. I will look into it as soon as time permits.
Oct 30 2016
If I remember correctly, I didn't even consider the possibility of imposing the constraint that there must be at least one lineset. It is easy to check if there's a lineset, and I was not aware of negative effects due to an empty set of linesets.
Aug 23 2016
Thanks @Sergey Sharybin (sergey) for the triage. I will look into the reported issue.
Aug 5 2016
May 8 2016
Thanks a lot @Bastien Montagne (mont29), I will look into the reported issue when time permits.
May 5 2016
May 3 2016
Thanks @Sergey Sharybin (sergey), I will look into the reported issue.
Apr 5 2016
Scaling down the mesh objects by a factor of 10 and zooming the camera into the scaled objects to compensate the smaller sizes would give a correct line rendering result. This means that there is an issue related to numerical precision (i.e., float and double in C/C++). I will further test the code and make an attempt to fix the problem.
Jan 5 2016
Just to confirm what @Ignatz (ignatz) said, adding a Triangulate mesh modifier gives Freestyle lines consistent with the Solid render component. Without the extra mesh modifier, Freestyle seems to compute lines based on geometry data that is different from what Cycles and the Blender Internal actually see.
Dec 26 2015
The patch compiles fine and the binary runs without hassle. By choosing a font containing CJK glyphs (e.g., meiryo.ttc) curve text objects in the edit mode accept key operations from the Japanese MS-IME on Windows 7.
Dec 15 2015
Freestyle requires filled faces to render lines along selected edges of the faces.
@Sergey Sharybin (sergey) Yes I am and thanks for the triage. Will look into the reported issue as soon as time permits.
Nov 17 2015
Hi Doxin,
Many thanks for the problem report. I can confirm the problem is reproducible on my end. Blender 2.75a gives much better results out of the same crate5.blend file, so the issue is considered a regression. I will take a closer look into the documented bug asap.
Nov 14 2015
You have chosen the Inside thickness position option in your 'test' line style. The first two cases as to objects 'Cube' and 'Cube.001' suffer from a technical limitation of the Inside thickness option.
Nov 7 2015
@Bastien Montagne (mont29) Indeed the reported assertion failures are not related to the crash. I am still not sure why these assertion failures occur because they are from a checking of a condition addressed by an old issue T39669. It seems that some degenerate faces are involved (and Freestyle are not good at treating them).
Confirmed the crash on both Windows and Linux using the latest master d8233d230885 as of this writing. The reported problem seems a regression because:
- Cycles in the latest master leads to a crash;
- Cycles in Blender 2.75a does not crash; and
- the Blender Internal of the latest master does not crash either.
The input scene (i.e., an auto-generated scene populated with meshes representing Freestyle strokes) is the same for all the three cases, and the only difference is the use of Cycles. I guess there is a recent change that causes a crash within Cycles.
Oct 28 2015
Oct 26 2015
Thank you Campbell for the proposed fix.
Oct 25 2015
Independent quick tests on Ubuntu 14.04 LTS using Fcitx-Mozc showed that the over-the-spot input style works nicely as seen in the following screen captures of the Text Editor and the scene name entry. Functionality-wise the present patch looks quite operational.
Oct 16 2015
Usually Freestyle strokes are open and not closed (do not loop). If strokes are open, filling them is likely to cause visual artifacts. As of this writing, it is a responsibility on the user side to make sure that the strokes to be filled are closed.
Oct 12 2015
The fix is very much appreciated, thanks Brecht.
Many thanks for the fix Brecht!
Sep 25 2015
Thank you @Sergey Sharybin (sergey) for the proposed fix.
Aug 18 2015
One more inline comment.
Thanks for the patch updates. A few inline notes are found below.
Thanks for the patch submission. Here are my notes on some of the posed questions.
Aug 9 2015
Hi flokkievids,
Jul 24 2015
I believe we can assume that a Material object always exists and never gets freed while a wrapper FrsMaterial for it exists. As we discussed FrsMaterial objects will be created on the fly when underlying Material objects needs to be exposed to style modules in Python during the Freestyle line rendering process. During Freestyle rendering, Material objects won't be freed. By the same token, we don't really need a default material for FrsMaterial.
Jul 23 2015
Jul 22 2015
Do you think it is easier to remove FrsMaterial completely and instead use Material?