I agree that this can be and is very annoying in some other cases, e.g.
a material output node..
The only other nodes which could use this that immediately come to mind
are math nodes.
The wildcard is node groups. If someone makes a node group that has a
mix node connected to the inputs, then i
I'm wondering in what other nodes appart from the different mix nodes this
functionality makes sense? Maybe it's not too hard to implement this in
only where it makes sense
On Apr 14, 2014 11:15 PM, "Greg Zaal" wrote:
> I know this might not be a perfect solution, but a little while ago I added
>
I know this might not be a perfect solution, but a little while ago I added
something to the Node Wrangler addon that you might like - select your mix
node or whatever and hit Alt+S. It'll swap the two colour inputs.
On 15 Apr 2014 3:02 AM, "patrick boelens" wrote:
> Aaand I should learn to read
Aaand I should learn to read before commenting. =P Sorry about that!
> Date: Mon, 14 Apr 2014 16:16:41 -0700
> From: zzyx...@gmail.com
> To: bf-committers@blender.org
> Subject: Re: [Bf-committers] Node link swapping
>
> Actually that was one of the ideas in my proposal :)
>
> On 04/14/14 16:13,
Mostly I only have the need for socket swapping because I forget that in
Blender -the bottom socket is the top layer and the top socket is the
bottom layer of a mixed image :P
But yeah the mix node or nodes with similar duplicated sockets are of
issue, it's not ideal to just swap to the next avail
Actually that was one of the ideas in my proposal :)
On 04/14/14 16:13, patrick boelens wrote:
> Perhaps the swapping behaviour could be mapped to a key? For example,
> plugging in a new image output into a Mix node makes the existing link
> disappear, while doing so while holding shift could pe
-1 On adding it back like it was before. It just made no sense most of
the time. This needs to be done right
Daniel Salazar
patazstudio.com
On Mon, Apr 14, 2014 at 5:14 PM, joe wrote:
> I agree, but I think maybe we should bring it back until the new
> implementation. Though it shouldn't be too
I agree, but I think maybe we should bring it back until the new
implementation. Though it shouldn't be too hard, just an extra flag per
node.
On Apr 14, 2014 3:56 PM, "Daniel Salazar - patazstudio.com" <
zan...@gmail.com> wrote:
> The old behavior was too broad and intrusive, maybe swapping could
Perhaps the swapping behaviour could be mapped to a key? For example, plugging
in a new image output into a Mix node makes the existing link disappear, while
doing so while holding shift could perform the swap.
Just some thoughts.
Cheers!
> From: zan...@gmail.com
> Date: Mon, 14 Apr 2014 16:55
The old behavior was too broad and intrusive, maybe swapping could be
implemented just in the few cases where it actually makes sense like
in mix nodes
Daniel Salazar
patazstudio.com
On Mon, Apr 14, 2014 at 4:53 PM, gandalf3 wrote:
> I have missed the node connection usability feature which was
I have missed the node connection usability feature which was removed in
r61178, and I'm convinced that my node workflow is slightly slower than
it was before.
I have written up a wiki page/request explaining why I think the old
behavior was faster in most cases. You can find it here:
http://wi
Hi Jeffrey,
In cuda 5.5 and 6.0 there is a regression with texture memory handling that
costs us significant performance I think.
Cuda 5.0 requires msvc 2008 or 2010 to run but since we only use nvcc to
compile a kernel and do dynamic runtime loading of libucda you can just use
the 2008 install yo
Martijn,
That would be fantastic if you could document how you configured your
builders.
Out of curiosity, what is the status of CUDA 5.5? I know we just updated to
5.0 to support newer cards and kernels, but I haven't seen any discussion
on using 5.5 yet. I'm already using 5.0 as per Brecht's re
13 matches
Mail list logo
