- User Since
- Apr 18 2016, 11:44 PM (143 w, 2 d)
Can confirm that it's not possible to keyframe this property. In 2.7x it was, so this is a regression since then.
Well, no. That's what I just wrote - this has always been the case. It is a bug, but not a new one. It should be fixed, but it's a fairly harmless display glitch that happens in rare instances. Not sure how to prioritise these kinds of things.
Was the case in 2.7x too:
Confirmed. Could be related to recent changes in Workbench drawing? I'm fairly sure this worked in earlier versions of 2.8.
Can you try doing File > Load Factory Settings and see if you still have this issue?
Yes, I agree with the editors thing. Mainly it was an attempt to try and see if we could get rid of the Misc panel also, which is not optimal. But I agree to leave it as is, since, as you say, it will be quite lopsided.
I was just about to add a suggestion about the Install... buttons being a bit inconsistent, and then you've updated this diff to address exactly that. Nice!
This report is too vague.
Overall this is a nice improvement.
Adding more sections fits well with the concept of the vertical list on the left. Seems good to me.
Sounds good to me! It will make it a lot less likely to end in the bad state of having active object not be selected, or no active object at all.
Overall I agree - it's just that the active object is quite important. The active object is the one whose properties you see in the Properties Editor. If it makes a random one active, you'll see a random set of properties here. IMO it's slightly nicer, although admittedly still weak, if we at least try and do something more deterministic, such as the object that was closest when starting or ending the box selection, if the active object is outside the selection box.
We could do that - but it would indeed be random, which is not nice. If you then do a merge or join, it will happen relative to a completely random object in your scene. The more deterministic solutions are also weak, but at least repeatable.
Yes, that seems like a nicer overall solution. Sorry for leading you down a strange path here.
Yes, we could do that, but as you say, there's no obvious solution when box selecting multiple objects. We could try and do something smart, like making active the one that is closest to the starting point of the box selection, or if an object is under the cursor when you let go. Something like that.
Technically I would say it's not a bug, but a design issue to do with the fact that we even have the concept of active vs selected in Blender, which can be entirely different.
The thing is that this feature is somewhat obscure, so making a big popover for it directly in the 3D View seems excessive, and not in line with the relative importance of this feature. We usually only put essential things there, like the mode, the command menus and viewport controls.
We have the same problem elsewhere. With the box select tool, you can easily end up in a situation where the active object is not selected, or there is no active object at all. Many tools and commands in Blender act on the active object.
Yes it’s a bit weird. The whole issue stems from the fact that we don’t have an active viewport in Blender. Not sure what else we can do - alternatively we could do what you suggested, to make it go to a picker or always take the biggest viewport.
We could constrain this to only lights and cameras?
Setting lights as a camera can be useful sometimes if you want to see what the light is hitting. I have, however, never seen anyone use normal objects as a camera. It is indeed rather strange that we support this.
Confirmed. Strangely, this property is completely stuck if it has a key on it. Not sure what is going on here.
I can't reproduce it here. It seems to work correctly, taking the correct vertex colors from the boolean object, which works correctly in materials too.
@Philipp Oeser (lichtwerk) To do this kind of thing, you need to use a popover. This makes it possible to add essentially a panel inside of a menu.
This change matches what we did elsewhere to make the checkboxes work correctly, so the diff should be correct. @Brecht Van Lommel (brecht) can confirm.
As an aside, to me it makes no sense that you can only modify the render border while the camera is selected. This seems like a rather strange limitation that users are not likely to guess or find out. IMO I think we should just make it so you can always drag the render border gizmo handles while in the camera view.
Ok to assign to you @Campbell Barton (campbellbarton) ? I know you have worked on the undo system.
Could be fine too I suppose, yes.
Good catch. Confirmed. Missing undo push when using the color picker?
Tue, Jan 15
Cain either of you check if this is ok? Is it still needed?
So, I guess the solution is for the input to fall back to the underlying view when there is no panel under the cursor?
@Brecht Van Lommel (brecht): Can you check on this? Thanks :)
@JUGURTHA (mazigh) I don't get it. This is already how it works.
@Jacques Lucke (JacquesLucke) With the toolbar especially, we gain a lot of space by making the toolbar float on a transparent background. It'd be a shame to get rid of that - even if only on hover.
@Jacques Lucke (JacquesLucke) Not sure. We could make it so you can only resize the panels when you are over a panel, not the region, and let the view manipulation fall through to the 3d view when in an empty area?
Are referring to Eevee or Cycles? Indeed, in Eevee, the Transmission Roughness parameter seems to do nothing.
I don't see a bug here. Works correctly.
Mon, Jan 14
Emulate 3 Button Mouse does not update the status bar at all. Not sure if this is doable, because it's not on the keymap level - would be nice though.
Hi again @Campbell Barton (campbellbarton) :) Seems like we are still showing some wrong tool properties here.
Updated preview blend above with an updated fluid scene. It is lighter, with a greatly reduced poly count.
I think we can make this a lot easier. In the top bar, we could have an enum with options to add, remove, move rulers.
@Brecht Van Lommel (brecht) Sure, that sounds fine I think.
Confirmed. This is due to the strange behaviour of the transform tools, where they actually scale on all axes, but use these weird constrain axis toggles.
@Sergey Sharybin (sergey): would this kind of creasing become possible with OSD vertex creasing? We currently don't support this yet.
Assigning to Sergey.
I'm not sure if it can be made to work? Alt is used to simulate the MMB, so it can't be used here afaik.
Sat, Jan 12
Fri, Jan 11
Yes I think that’s fair - we could do this consistently when symmetry is enabled in any mode.
The reverse is also true. If you enable Symmetry, and switch to a different object, you'll accidentally then start to manipulate it without Symmetry, because the tool setting was forgotten, because it is now a different mesh. That is equally as annoying. This is my point: There are cases where you may want to use it only with certain objects, and there are other cases where you won't. And that applies to any tool setting.
Sculpt Mode and Edit Mode are just two different ways of altering your mesh. Sculpt Mode can be used on objects inside scenes with unlimited objects, and users may jump from one to the other regularly while modeling. There’s no logical reason why symmetry is a mode-wide tool setting in Sculpt Mode, while being this inconsistent per-object tool setting in Edit Mode. They really should work exactly the same. At some point we should also add Z and Y symmetry to Edit Mode to make it truly consistent with Sculpt Mode.
Right, I assumed that was the case. But the image blending type Overlay does something quite different from this blending type. This blending mode is more like 'Do the right blending based on the F-Curve type to make layering work properly' Anyway, I don't think it's much of an issue.
Thu, Jan 10
This is a massive feature for animators. It basically means that layered animation is now fully supported via the NLA, and that you can even properly keyframe items while they are being layered, with the correct offset being applied.
Yes, would be useful indeed.
If you are animating, you could certainly argue that it could be useful to use a certain pivot or orientation with a certain object or bone. You might also want to use a certain transform tool with certain bones always. You don't ever want to move a wheel, but you always want to rotate it. So X-Mirror is no different. It's just a tool setting.
This argument could be made for literally any tool setting. You might want to use different orientations when transforming different objects, or use different pivots, etc. Having this inconsistent behaviour for one specific tool setting in only one specific mode is not good practice.
Yes, I think that is a fair solution. We could add an indicator when X, Y or Z Mirror is enabled in the viewport in any mode that supports symmetry.
Can you test in the build from today, and remember to go to File > Load Factory Defaults first. Thanks.
I can't reproduce this issue here. Switching to the Texture Paint workspace tab always shows the correct items in Tool Properties.
I can confirm this here also.
As I expected, the issue is with the new Subdivision Surface modifier, which doesn't handle vertex colors correctly for triangles and N-gons.
Wed, Jan 9
Confirmed here also.
@ThinkingPolygons (ThinkingPolygons) I have no idea if that is the issue the reporter was trying to convey, but I can confirm that issue.
@Julien DUROURE (julien) Thanks.
Sorry, but you'll have to actually explain 1) the issue, and 2) how to reproduce it, otherwise developers have no way to help you with your problem.
Hey, it seems like we still have some cases where we are showing the wrong tool settings for the chosen tool.
Tue, Jan 8
Sure, those would also be invisible I suppose. @Brecht Van Lommel (brecht) : you also agree to make it so turning Overlays off hides the Edit cage?
What do you mean by an animation that changes the influence of a bone? The same animation seems to export from the GLTF exporter in 2.7x just fine. The issue is only with the new GLTF exporter.
Hey Campbell, it seems like we are missing one property here.
Please provide an example blend file. Thanks.
So, after thinking about this more, my conclusion is that I think the X Mirror option should be moved away from the mesh datablock and into the mode. Here's why:
Mon, Jan 7
Can you try using Blender 2.8, and an up-to-date version?