- User Since
- Feb 18 2011, 12:06 PM (447 w, 5 d)
Sun, Aug 25
first of all thanks for the patch! From a UX perspective, I don't see why we would need that (having all the mnemonics in menu entries in place it should be easy to select directly what you want).
If others disagree and there is a need for this feature, I would strongly vote for Home / End instead of PgUp / PgDown as this should be much more intuitive.
Feb 1 2019
Nov 22 2018
Nov 20 2018
Apr 27 2018
Apr 22 2018
@Lee Anderson (la10) Hi Lee, great that you'd like to help! Send in patches but start from the bottom of the list as I'm currently processing all items starting from the top and don't want us to have duplicated efforts on the same item..
From now on, I'll just add an "(in process)" to the item when I'm on it, so others can see which ones are worked on.
Apr 20 2018
Apr 19 2018
Apr 18 2018
Mar 30 2018
Sep 8 2017
Ah damn, @Brecht Van Lommel (brecht) was faster - ok if that's intended then we should definitely add that to the release logs!
I can confirm this, tested it with 2.78a and it shows exactly the behavior @Relja Trajković (Relja) is describing.
Sep 2 2017
Aug 22 2017
Just a heads up, I just fixed this point: "Right click at one of the materials. You will get a search for an unknown menu type WM_MT_button_context warning."
@Vuk Gardašević (lijenstina) I'll fix it in a sec. That has been caused by my commit, so I'll take care of it...
Jul 16 2017
Jul 7 2017
Jul 6 2017
Jun 18 2017
Jun 11 2017
@ronan ducluzeau (zeauro) Look at what I wrote under "Notice" - can confirm that.
May 29 2017
May 9 2017
Apr 28 2017
Documentation for the feature and a last comment on indices like Campbell proposed... going to commit that now.
Apr 23 2017
Apr 18 2017
So how does that work when multiple add-ons want to add such a custom menu item?
Apr 9 2017
Operator support, renaming of WM_MT_context to WM_MT_button_context
@Bastien Montagne (mont29) @Sybren A. Stüvel (sybren) Would be great if you could give me input on that too as I would like to commit that before our 2.79 release. As it's our production release and will definitely stay fresh a bit longer, I would really like to give add-on creates this functionality now. Thanks!
Feb 10 2017
@Brecht Van Lommel (brecht) Yep, that was far too imprecise from me. What I meant was if the shadow could be optionally coloured by the bounce light from a coloured object when this object is near the catcher. But that can be perfectly done with the Diffuse Indirect pass, so ignore that ... was too late apparently.
tested it as well in many different ways: Different light types, one light, multiple lights, colored lights, no lights, no world, plain world lighting, >1 shadow catcher, ... everything seems to work as intended!
There's only one case where I was unsure if the result is correct: textures on the catcher seem to give weird shadowing with point or spot lamps (no bump or displacement was used):
Feb 3 2017
Where would I need to change those definitions, and to what? I see an #ifdef Block in both kernel_path.h and kernel_path_branched.h, are those the files?
In intern/cycles/kernel/kernel_types.h (search for "kernel features" and add it there).
Jan 31 2017
Hi @João Araújo (genio84) as promised, here is a review of the operators from a user perspective (just realized that I noted everything down but never actually posted it)
Just as a side note: We're using the ShadowCatcher patch in production for a few months now without any issues.
Jan 25 2017
Jan 10 2017
@Julian Eisel (Severin) any chance to tackle that quickly or even revert the commit you made that introduced it? It's not only cluttering the ui but makes so many places worse. Even the modifier names have X'es that reset the name to the standard name - it's simply useless. As I'm making 1000s of images now for my upcoming book I find myself constantly in GIMP erasing X es that should not be there.
Oct 31 2016
Oct 28 2016
Oct 9 2016
Oct 4 2016
Sep 17 2016
Aug 28 2016
Aug 22 2016
Aug 18 2016
Jul 31 2016
Tested it on newest master running on an i7, 16gb ram, 2*gtx 560 ti oc 2GB on Linux64 - can confirm it. It crashes in 9 of 10 tries here. Does not crash on Blender 2.77a.
Jul 30 2016
May 22 2016
Campbell found the root of your issue, committed a fix and pushed it to master. When he pushed it with "Fix T..." , the system recognizes the reference and closes the issue. So compile Blender and test it or just wait for the buildbot build to be updated and test it there.
May 17 2016
May 10 2016
May 4 2016
Apr 16 2016
Apr 7 2016
Hi @Antonio Vazquez (antoniov), just upload it here - it's completely valid to develop it further here...
Mar 26 2016
Mar 25 2016
Mar 24 2016
Mar 20 2016
Feb 28 2016
this is definitely useful! Not only to visualize smoke (& its behaviour) in the viewport better but also because we render smoke oftentimes in the viewport and composit it over footage. The different visualization options are very helpful in this regard. Especially the "Axis / Single / Position" option is awesome for 2D scenes. What I didn't get yet was how to control the color ramp though. I could only make some single colored smoke (with various alpha values but no different colors)... will try to contact you in IRC - maybe it's just a dumb user error..
Feb 21 2016
Feb 13 2016
Feb 4 2016
Jan 27 2016
Hi Kevin, just came back from business trip - will now test it. Could you lift line 390 to 389 (rna_smoke.c) next time you update the patch? The #endif is one line too low...
Jan 19 2016
writing from Sweden atm. - was urgently sent to a client last week as a programmer drone and therefore just saw your message. HDRs should indeed be able to go above 1.0, completely agree about the division by zero tough, that should be avoided! Do we have an internal division method that catches those cases or should I just do it manually (by never going beneath 0.00001 for every channel for example)?