User Details
- User Since
- Feb 6 2013, 7:05 PM (485 w, 1 d)
Mon, May 23
Thu, May 12
A core design idea I'd like to emphasise is that "What you see is what you get".
Apr 20 2022
Apr 18 2022
Wouldn't it be nice to show a hint that explains why the option is greyed-out, inside the tooltip? I believe Blender supports this in a few places already, and such messages appear in red.
Apr 15 2022
Apr 12 2022
Mar 30 2022
Mar 29 2022
Mar 14 2022
Feb 23 2022
Feb 19 2022
Any chance this can be considered for 3.1 ? it has been such an annoyance, the sooner I can forget about it the better. Thanks a bunch for fixing this !
Feb 10 2022
Feb 8 2022
Feb 1 2022
Jan 21 2022
Jan 18 2022
Jan 17 2022
Jan 15 2022
Jan 13 2022
Dec 20 2021
Dec 11 2021
This is a wonderful addition ! If I understand correctly right now the node needs neighbouring faces to return an angle. Any reason why this wouldn't be possible between two edges not necessarily attached to faces ? (such as a curve converted to mesh)
Dec 10 2021
Dec 2 2021
I didn't know that. In my experience autokey works fine pretty much everywhere (scene properties, shading and compositing nodes, and so on). Thanks for taking a look. It's only misleading because changing the property values directly does work.
Dec 1 2021
Nov 22 2021
I am not entirely sure this is indeed what's mentioned in the manual. To help clarify things, here is my experience : there is indeed a hard zoom limit in the supplied file, something I have not encountered before -but in addition to that there is also some strange interaction between zoom and dolly that I encountered when trying to work around the issue : once the zoom limit is reached (something that in my experience should happen once the camera lens reaches the point of interest, which is not the case here), we can still dolly further with shift+ctrl+mmb. However this dollying pushes the point of orbit further than we would like to (beyond the point of interest), which is expected from a dolly, from there we're again able to orbit around the point of interest if and only if we use "auto depth" (PreferencesInput.use_mouse_depth_navigate). At that point however, trying to zoom or unzoom again results in the view immediately snapping back to the hard limit. So, all in all it seemed a little fishy to me... especially given it's all happening at the centimeter scale, so not especially close to where you see numerical problems creep in.
Nov 21 2021
Nov 17 2021
Nov 2 2021
Oct 26 2021
Oct 22 2021
Oct 18 2021
Oct 8 2021
Oct 4 2021
Oct 2 2021
I think I agree with Ludvik Koutny here : distinguishing single values from fields doesn't actually matter that much for the end user. What's the difference, after all ? one uses a single value (or a single vector, etc) whereas the other uses a bunch of values that vary over the mesh. Compare it to Cycles nodes : it's the same as using an input variable (such as the "normal" output from the "geometry" node) versus using a constant vector. The particularity of fields is entirely technical, and the socket change already communicates the fact that it's carrying many values instead of just one -which is a distinction that was never even brought up for Cycles nodes.
Sep 29 2021
The part I like is the grouping of "path" and "filename" fields. The current dissociation was always a bit jarring. On the other hand, moving the navigation buttons seems uncalled for, and the "path" field has become very short too -may quickly become a problem with long paths, files on remote disks, or just deeply nested projects (which are most projects, in my experience).
Sep 27 2021
Sep 21 2021
Sep 16 2021
Sep 15 2021
I wonder if it's not worth just clamping the index ? It sounds sort of counter-intuitive that an index of 10 will end up 1 if there are three connected inputs. In practice I'm not sure artists want such cycling behaviour (maybe they do).
Sep 9 2021
Sep 6 2021
Sep 1 2021
Aug 9 2021
Jul 14 2021
Jul 13 2021
Jul 8 2021
Jul 5 2021
Jul 4 2021
Jul 3 2021
Jul 2 2021
Jun 28 2021
Jun 26 2021
Jun 25 2021
Jun 24 2021
Jun 19 2021
Jun 10 2021
Alright. Has it been decided whether or not to decouple the node that gets inspected in the spreadsheet from the node that gets "visualized" in the viewport ? I'm asking this because a "node toggle" like what's in 2.93 seems more straightforward than a full-on node "viewer node". Even further, maybe just make the overlay show the active node output? That's what we really want to see when we tweak properties on a node : its output in particular. Every extra step in a process that involves a lot of "node inspecting" is going to be a burden, I'd encourage you to simplify the process to the max.
Is a viewer node functionally different from the toggle on each node? in addition to being represented in the spreadsheet I thought it was supposed to enable an overlay of the node's output over the final derived geometry in the viewport? or did I read that incorrectly?
Jun 6 2021
Jun 5 2021
May 31 2021
May 30 2021
This can be done with two additional bones per handle and control pair:
A child of the control, oriented the same as the handle in rest pose, without constraints.
A sibling of the control, oriented the same as the handle in rest pose, with a Copy Transforms (World Space) from child.
May 20 2021
May 18 2021
May 17 2021
May 14 2021
May 10 2021
May 8 2021
Apr 28 2021
Apr 13 2021
Just a thought about UI : I think it makes sense to have filter options both inside the popover and in a sidebar, akin to tool/brush options in the 3D view that are both accessible through the header as popovers and in the sidebar (so they're always visible).
Apr 9 2021
Apr 8 2021
Apr 7 2021
I thought I had a bug, so I checked this task and if I understand correctly overrides in material node trees is still incomplete, am I correct ? It works in some files, and not in others (same character though, which is unexpected). Should I report it ? (I am using 2.92)
Mar 31 2021
@Hans Goudey (HooglyBoogly) The radio button idea is consistent with other places in Blender (fcurve modifiers) and it serves that it's an explicit button instead of an "invisible-hitbox" activation like in 2.92. It's further less horizontal space in a place that's running out of it already though (unless the new datablock selector goes in as well?)
Having shortcuts affect not what seems to be selected is indeed confusing. This is not how the rest of Blender works : viewport, sequencer, ... every editor operates on selection. The problem here is that this is no selection, but looks like one. I'm not sure what being active entails for a modifier, but I think the indicator should be proportional to its importance. If we're going to have shortcuts affects the hovered modifier, then there needs to be a hover indicator that's more prominent than the active indicator.
Mar 25 2021
Mar 23 2021
Mar 22 2021
I don't know, doesn't this seem more complicated than the problem it tries to solve ? Don't frames and reroutes already provide all the organizing functionality ? Is scrolling actually an issue ? Maybe a minimap could help in that regard ?
Mar 21 2021
Concerning the "limits" fmodifier : wouldn't it make sense to group value sliders by dimension (first X, then Y) rather than minimum and maximum ? Using this layout, I feel there is a disconnect between the way they're grouped and the way I tend to mentally picture myself setting the limits in question : first set abcissa bounds, then set ordinate bounds. I realize this is quite nitpicky.