- User Since
- Feb 18 2011, 12:06 PM (339 w, 5 d)
Tue, Aug 22
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)?
Jan 10 2016
Just checked if I can redo it but can't... see
Will check, but can't promise that I can do much this week (first week after holidays for me ;) )
Jan 1 2016
Dec 28 2015
- After changing the ...new_modfier function we have to set scene on file load, otherwise an invalid scene access happens
- Picked color value was not in correct color space (display) - thanks to Psy-fi for detection and assistance
- Review points solved
Dec 27 2015
Nov 24 2015
Having tested the patch thoroughly: No crashes so far on two systems (where previously were crashes all the time), so functionality wise it's good to go!
Nov 16 2015
Just came back from a massive business trip. Will test your patch tomorrow (after you hopefully enable me to build blender again [OSL issue - mont will talk to you] ;)
Many greetings, Thomas
Oct 30 2015
Oct 5 2015
@Aaron Carlisle (Blendify) This was just an additional info. When I like this specific bug to be fixed, I'll report that separately with a file that shows the issue. Otherwise it's just guessing...
Oct 4 2015
Hi Alex, just checked the file on my machine with your patch. Everything seems to work fine.
Oct 3 2015
Oct 1 2015
@ronan ducluzeau (zeauro), Please, this is no forum, we try to locate the bug here... your posts don't help in processing the bug and are irrelevant for actual problem. We're rendering here and are not previewing anything.
@Alexander Romanov (a.romanov) Let's wait for @Campbell Barton (campbellbarton) then...
@ronan ducluzeau (zeauro) Ronan, there does not need to be a lamp - the world is using "ambient occlusion" with "Add" - so that's our lamp.
for me it's always "bad" - no matter if the viewport is rendering the scene or the rendering has been started via F12. Even if I delete the material node and only use a color ramp plugged directly into the output, the behaviour persists...